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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <67a02051-f736-4fbb-8c70-208364264542@suse.cz>
Date: Tue, 3 Jun 2025 14:55:18 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
 Kees Cook <kees@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-kernel@...r.kernel.org, Eric Biggers <ebiggers@...nel.org>,
 Ingo Saitz <ingo@...nover.ccc.de>, kernel test robot
 <oliver.sang@...el.com>, Marco Elver <elver@...gle.com>,
 Nathan Chancellor <nathan@...nel.org>,
 Thiago Jung Bauermann <thiago.bauermann@...aro.org>,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [GIT PULL] hardening fixes for v6.16-rc1

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@mail.gmail.com
> 
> 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@...e.cz"
gpg: Good signature from "Vlastimil Babka <vbabka@...e.com>" [ultimate]
gpg:                 aka "Vlastimil Babka <vbabka@...e.cz>" [ultimate]
Merge: 5be63fc19fca 6e016babce7c
Author:     Vlastimil Babka <vbabka@...e.cz>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@...e.cz>
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@...ux.dev>
    https://lore.kernel.org/all/ZtpI27swD1GIC0YR@google.com
---
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@...e.cz>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@...e.cz>
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