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

[Vlastimil Babka]

On 6/1/25 7:58 PM, Konstantin Ryabitsev wrote:
> On Sun, Jun 01, 2025 at 08:38:10AM -0700, Kees Cook wrote:
>>> 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.
>>
>> This shows the same problem (using Linus's tree and linux-next):
>>
>> $ git checkout 9d230d500b0e -b test/repro/before
>> $ git cherry-pick 368556dd234d
>> $ git cherry-pick eef1355c269b
>> $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@xxxxxxxxxxxxxx
> 
> Thanks, I was able to recreate it and will use it as my test case. I suggest
> that until I have a fix in place, that you always use `br trailers -u` with a
> `--since-commit` flag, to restrict the range we're looking at. The solution

I think even with --since-commit it behaves somewhat unexpectedly.
I've tried recreating an issue I had last year, that Christian just
mentioned in this thread as I was writing this up.

> git fetch git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git b4-reproducer
>From git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux
 * branch                      b4-reproducer -> FETCH_HEAD

> git checkout FETCH_HEAD
HEAD is now at 8a01634625a9 io_uring: port to struct kmem_cache_args

> git show HEAD~17 --show-signature --pretty=fuller 
commit f65b0043b92284cf7c8e986a476a9b169a132de1
gpg: Signature made Thu 05 Sep 2024 11:31:55 AM CEST
gpg:                using RSA key 7BBBC8411599234896484DF1BBE0B075D245889A
gpg:                issuer "vbabka@xxxxxxx"
gpg: Good signature from "Vlastimil Babka <vbabka@xxxxxxxx>" [ultimate]
gpg:                 aka "Vlastimil Babka <vbabka@xxxxxxx>" [ultimate]
Merge: 5be63fc19fca 6e016babce7c
Author:     Vlastimil Babka <vbabka@xxxxxxx>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@xxxxxxx>
CommitDate: Thu Sep 5 11:31:32 2024 +0200
...

> b4 trailers -u --since-commit HEAD~17
Finding code-review trailers for 17 commits...
Analyzing 124 code-review messages
---
  + Reviewed-by: Roman Gushchin <roman.gushchin@xxxxxxxxx>
    https://lore.kernel.org/all/ZtpI27swD1GIC0YR@xxxxxxxxxx
---
Press Enter to apply these trailers or Ctrl-C to abort
...
---
Invoking git-filter-repo to update trailers.
New history written in 0.17 seconds...

> git show HEAD~17 --show-signature --pretty=fuller 
commit 01cc2238ba4ad3c940db76f134f56b2e0f082243
Merge: 5be63fc19fca 0f389adb4b80
Author:     Vlastimil Babka <vbabka@xxxxxxx>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@xxxxxxx>
CommitDate: Thu Sep 5 11:31:32 2024 +0200

See how it changed not only the merge commit itself but the right
side of the merge, which was at the time from the vfs tree.

Passing --since-commit HEAD~16 doesn't have this result, so perhaps 
is it intentional that "since" is inclusive? I think that would differ
from the usual interpretation in git/b4 so unexpected. Even then such 
off-by-one error (misunderstanding) would still not explain rewriting
one side on the merge further in the history.

Vlastimil