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

[Kees Cook <kees@kernel.org>]

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