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: <CAHk-=wjktqa94u_=++YX7XxUr57iLAs1GqtHPOY-o-N0z7wyeA@mail.gmail.com>
Date: Sat, 31 May 2025 19:35:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: Konstantin Ryabitsev <konstantin@...uxfoundation.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 Sat, 31 May 2025 at 18:06, Kees Cook <kees@...nel.org> wrote:
>
> I have no idea. I had noticed a bunch of my trees were refusing to have sane merges.

The rebased history would explain that, but the reason I'm upset about
it is that I don't even see how that rebasing could possibly happen
"by mistake".

Any normal git merge rebasing should re-write the committer. So to get
the kinds of rewritten history that I saw, it almost has to be
intentional. I don't see how that has happened by mistake.

At a minimum there is some truly effed up scripting going on.

Because it wasn't just one or two commits, it was a whole slew of
them. I mentioned one, but there were *thousands* of rewritten
commits.

IThat bad branch of yours had 330 (!) merge commits that were
attributed to me (both authorship and commit information) and weren't
actually from my tree.

And those are just *my* commits. Never mind the 6000+ other commits
that didn't purport to be from me.

This is not some "disk corruption" issue.

There was real *work* involved in re-creating 330 copies of my merges
and 6000 copies of other peoples commits. I only looked at one, but it
appears identical except for the lack of source tag signature
information (and then all the subsequent ones that depend on it will
obviously then have different parent SHA1s etc).

               Linus