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: <202506011152.6D1E4F33B@keescook>
Date: Sun, 1 Jun 2025 11:56:59 -0700
From: Kees Cook <kees@...nel.org>
To: Konstantin Ryabitsev <konstantin@...uxfoundation.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 01:58:27PM -0400, 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

Okay, great.

> 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.

Yeah, that would solve my use-case entirely. I actually thought that's
roughly how it was already working, and it has worked for me fine before
this, so I'm not sure what was different here for it.

Thank you!

-Kees

-- 
Kees Cook