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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250601-electric-olivine-wren-d8c5ca@lemur>
Date: Sun, 1 Jun 2025 13:58:27 -0400
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: 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>
Subject: Re: [GIT PULL] hardening fixes for v6.16-rc1

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'll work on is to iterate the range of commits we get back and further
restrict it to just the contiguous range matching the current committer, going
backwards from the HEAD. This would have avoided the problem by restricting
the commits being considered to just the handful that were cherry-picked on
top of the latest merges from Linus.

-K