Re: [GIT PULL] hardening fixes for v6.16-rc1

[Konstantin Ryabitsev]

On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> Okay, reproducing the "b4 trailers" steps:
> 
> #### start from known good tree
> $ git checkout 62329e859b25 -b test/wreckage/before
> $ l
> 62329e859b25 (HEAD -> test/wreckage/before, dev/v6.16-rc1-pre/-Wunterminated-string-initialization) [DUP]
> 9a7d4e791037 crypto: Annotate crypto strings with nonstring
> b080c44c4d69 kbuild: Re-enable -Wunterminated-string-initialization
> 8c2bb7d12601 ubsan: integer-overflow: depend on BROKEN to keep this out of CI
> b9dbd69a32e3 wifi: iwlwifi: mld: Work around Clang loop unrolling bug
> 9d230d500b0e Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
> bf373e4c786b Merge tag 'devicetree-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> 8ca154e4910e Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> 43db11110730 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> 12e9b9e5223b Merge tag 'ipe-pr-20250527' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
> 90b83efa6701 (stable/master) Merge tag 'bpf-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> 1b98f357dadd Merge tag 'net-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> ...
> ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@xxxxxxxxxxxxxx
> Finding code-review trailers for 39 commits...

Yeah, this is danger territory, because you're asking to update a random
commit in the tree history. Without passing --since, we're looking at raw git
history in the current branch as far as 1 month back to try to figure out the
range of commits that we should work with:

https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/src/b4/ez.py#n1048

I don't yet know why it wants to rewrite 39 commits when we're updating a
commit that's only 3 away from the tip. If you manage to rerun this with b4 -d
and send me the output, I will be glad to look at it. Alternatively, if you
can let me know the steps to get my tree in the same state as yours, I can run
it locally.

> Welp, that precisely recreated it -- even identical shas! Looking at
> the b4 output, I do see a suspicious "39 commits" listed for some reason.

Well, that's the point where the user, in theory, goes "this is weird, why is
it 39 commits," and does Ctrl-C, but I'm happy to accept blame here -- we
should be more careful with this operation and bail out whenever we recognize
that something has gone wrong. To begin with, we'll output a listing of all
the commits that will be rewritten, just to make it more obvious when things
are about to go wrong.

> So, I assume the "git-filter-repo" invocation is what mangled it. I will
> try to dig into what b4 actually asked it to do in the morning...

Thanks for looking into this. Linus, this is accurate and I am 100% convinced
that there was no malicious intent. My apologies for being part of the mess
through the tooling.

I will reinstate Kees's account so he can resume his work.

-K