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

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

[Kees Cook]

Hi Linus,

Please pull this small handful of hardening fixes for v6.16-rc1.

Thanks!

-Kees

The following changes since commit f8b59a0f90a2adfce5a9206ce5589ed0dc19543c:

  Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core (2025-05-29 09:11:39 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/hardening-v6.16-rc1-fix1

for you to fetch changes up to 7ea1ca94c1278615c55a9f61f63d2286b1b10853:

  randstruct: gcc-plugin: Fix attribute addition (2025-05-31 07:51:14 -0700)

----------------------------------------------------------------
hardening fixes for v6.16-rc1

- randstruct: gcc-plugin: Fix attribute addition with GCC 15

- ubsan: integer-overflow: depend on BROKEN to keep this out of CI

- overflow: Introduce __DEFINE_FLEX for having no initializer

- wifi: iwlwifi: mld: Work around Clang loop unrolling bug

----------------------------------------------------------------
Kees Cook (4):
      wifi: iwlwifi: mld: Work around Clang loop unrolling bug
      ubsan: integer-overflow: depend on BROKEN to keep this out of CI
      overflow: Introduce __DEFINE_FLEX for having no initializer
      randstruct: gcc-plugin: Fix attribute addition

 lib/Kconfig.ubsan                             |  2 ++
 scripts/gcc-plugins/gcc-common.h              | 32 +++++++++++++++++++++++++++
 scripts/gcc-plugins/randomize_layout_plugin.c | 22 +++++++++---------
 include/linux/overflow.h                      | 25 ++++++++++++++++-----
 drivers/net/wireless/intel/iwlwifi/mld/d3.c   |  2 +-
 5 files changed, 65 insertions(+), 18 deletions(-)

-- 
Kees Cook

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

[Linus Torvalds]

On Sat, 31 May 2025 at 08:00, Kees Cook <kees@kernel.org> wrote:
>
> Please pull this small handful of hardening fixes for v6.16-rc1.

WTF, Kees?

You seem to have actively maliciously modified your tree completely.

There are completely crazy commits in there that are entirely fake.

You have this: f8b59a0f90a2 Merge tag 'driver-core-6.16-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

which *claims* to be from me, and committed by me, but is very much
not. It's some garbage you have entirely made up.

Yes, there is a real commit like that, but it's has the SHA1 ID of
9d230d500b0e.

And this isn't some kind of innocent rebasing mistake, because this
actively lies about who committed it.

This is completely unacceptable.

I will now refuse to pull *anything* from you until you explain what
the f&*^ you have been up to, because this looks like you have been
doing actively bad things.

You need to nuke that tree, and come up with a good explanation for
this kind of shit.

I'm cc'ing Konstantin, because I really think these kinds of games are
COMPLETELY UNACCEPTABLE, and this is not the kind of behavior we can
have on kernel.org accounts.

Konstantin - please disable Kees' account immediately until this is
cleared up. Because this looks *malicious*.

                 Linus

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

[Konstantin Ryabitsev]

On Sat, May 31, 2025 at 11:20:20AM -0700, Linus Torvalds wrote:
> Konstantin - please disable Kees' account immediately until this is
> cleared up. Because this looks *malicious*.

Account disabled until further notice.

-K

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

[Konstantin Ryabitsev]

On Sat, May 31, 2025 at 11:20:20AM -0700, Linus Torvalds wrote:
> You have this: f8b59a0f90a2 Merge tag 'driver-core-6.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

For the record, this object came in through this push:
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/plain/m?id=7df025cb5c2a034128abf8b6d064c4c17cddff65

There is a push signature on it, which does verify:

    gpg: Signature made Sat 31 May 2025 11:04:02 AM EDT
    gpg:                using EDDSA key 523E475E4448ED8757479D21362B0BDE39E424BB
    gpg: Good signature from "Kees Cook <kees@outflux.net>"

-K

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

[Al Viro]

On Sat, May 31, 2025 at 11:20:20AM -0700, Linus Torvalds wrote:
> On Sat, 31 May 2025 at 08:00, Kees Cook <kees@kernel.org> wrote:
> >
> > Please pull this small handful of hardening fixes for v6.16-rc1.
> 
> WTF, Kees?
> 
> You seem to have actively maliciously modified your tree completely.
> 
> There are completely crazy commits in there that are entirely fake.
> 
> You have this: f8b59a0f90a2 Merge tag 'driver-core-6.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
> 
> which *claims* to be from me, and committed by me, but is very much
> not. It's some garbage you have entirely made up.
> 
> Yes, there is a real commit like that, but it's has the SHA1 ID of
> 9d230d500b0e.

Interesting - looks like a large part of commit graph had been mirrored
with mergetag parts filed off; actual tree objects appear to match...

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

[Kees Cook]

On May 31, 2025 11:20:20 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Sat, 31 May 2025 at 08:00, Kees Cook <kees@kernel.org> wrote:
>>
>> Please pull this small handful of hardening fixes for v6.16-rc1.
>
>WTF, Kees?
>
>You seem to have actively maliciously modified your tree completely.
>
>There are completely crazy commits in there that are entirely fake.
>
>You have this: f8b59a0f90a2 Merge tag 'driver-core-6.16-rc1' of
>git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
>
>which *claims* to be from me, and committed by me, but is very much
>not. It's some garbage you have entirely made up.
>
>Yes, there is a real commit like that, but it's has the SHA1 ID of
>9d230d500b0e.
>
>And this isn't some kind of innocent rebasing mistake, because this
>actively lies about who committed it.
>
>This is completely unacceptable.
>
>I will now refuse to pull *anything* from you until you explain what
>the f&*^ you have been up to, because this looks like you have been
>doing actively bad things.

I have no idea. I had noticed a bunch of my trees were refusing to have sane merges. I kept trying to rebase them to sort it out, but it seems it has not worked. This is all on top of an SSD that was getting mad at me and I had to replace it, but it threw errors during the copy. I thought everything got recovered in my various worktrees, but clearly something is still wrong.

>You need to nuke that tree, and come up with a good explanation for
>this kind of shit.

I'll throw it all out and rebuild from patches.

>I'm cc'ing Konstantin, because I really think these kinds of games are
>COMPLETELY UNACCEPTABLE, and this is not the kind of behavior we can
>have on kernel.org accounts.
>
>Konstantin - please disable Kees' account immediately until this is
>cleared up. Because this looks *malicious*.

Sorry! AFAICT it's all just from broken trees I tried to reconstruct (badly it seems).

Since I can't push to kernel.org, what shall I do for resending this PR after I've re-re-constructed everything?

-Kees


-- 
Kees Cook

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi Kees,

On Sat, 31 May 2025 18:06:00 -0700 Kees Cook <kees@kernel.org> wrote:
>
> I'll throw it all out and rebuild from patches.

If you want to start from what you had in linux-next on Friday, you could fetch commit

  eef1355c269b ("ubsan: integer-overflow: depend on BROKEN to keep this out of CI")

(that was your for-next/kspp branch) from
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Linus Torvalds]

On Sat, 31 May 2025 at 18:06, Kees Cook <kees@kernel.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

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

[Kees Cook]

On Sat, May 31, 2025 at 07:35:45PM -0700, Linus Torvalds wrote:
> On Sat, 31 May 2025 at 18:06, Kees Cook <kees@kernel.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.

Well, I didn't do it on purpose. I think I have an established track
record of asking you first before I intentionally do stupid things with
git (like the recent prefix collision PoC[1] that I privately emailed
you about).

I'm trying to figure it out now. I must have shot myself in the foot
somewhere, since I had a number of "by hand" things going on this week.
My current guess (while AFK) was that something went sideways while
trying to rebase my for-next/hardening vs my for-linus/hardening trees,
since I had, at one point, based my for-next on
9d7a0577c9db35c4cc52db90bc415ea248446472 (1 commit past v6.15-rc3) since
I was still working on -Wunterminated-string-initialization patches.
(Normally I exclusively base on -rc2.) Then I had my SSD failure, but
things seemed okay after that, but then when I built the
for-linus/hardening tree I rebased patches that were on top of for-next
over on to latest "master" because basing it on 1 past rc3 seemed weird.
It was around here that I started having problems.

But like I said, I'll see if I can reproduce it. I have a lot of
scripting to sanity check my pushes, and I (stupidly) overrode them
because normally they get angry when I'm not basing on rc2, etc. But
I've never had anything like this happen.

-Kees

[1] https://people.kernel.org/kees/colliding-with-the-sha-prefix-of-linuxs-initial-git-commit

-- 
Kees Cook

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

[Kees Cook]

On Sat, May 31, 2025 at 07:35:45PM -0700, Linus Torvalds wrote:
> 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".

Here's my reflog, but tl;dr it looks like "b4 trailers" did it. If you
want to skip to that, search for "fast-import" below...


eef1355c269b (HEAD -> for-next/hardening, origin/for-next/hardening, for-next/kspp) HEAD@{0}: checkout: moving from broken/for-next/hardening to for-next/hardening

Getting back to sfr's recommended "known good state".

f8b59a0f90a2 (broken/for-next/hardening) HEAD@{1}: Branch: renamed refs/heads/for-next/hardening to refs/heads/broken/for-next/hardening
f8b59a0f90a2 (broken/for-next/hardening) HEAD@{3}: checkout: moving from broken/for-linus/hardening to for-next/hardening
7ea1ca94c127 (tag: hardening-v6.16-rc1-fix1, origin/for-next/kspp, origin/for-linus/hardening, kees/for-linus/hardening, broken/for-next/kspp, broken/for-linus/hardening) HEAD@{4}: Branch: renamed refs/heads/for-linus/hardening to refs/heads/broken/for-linus/hardening

This is renaming both my for-next and for-linus to "broken/..."

7ea1ca94c127 (tag: hardening-v6.16-rc1-fix1, origin/for-next/kspp, origin/for-linus/hardening, kees/for-linus/hardening, broken/for-next/kspp, broken/for-linus/hardening) HEAD@{6}: am: randstruct: gcc-plugin: Fix attribute addition
2050f9ffa893 HEAD@{7}: commit (amend): overflow: Introduce __DEFINE_FLEX for having no initializer
d316fb5f88c9 HEAD@{8}: checkout: moving from for-next/hardening to for-linus/hardening
f8b59a0f90a2 (broken/for-next/hardening) HEAD@{9}: checkout: moving from fix-rand2 to for-next/hardening

This is amending "overflow: Introduce __DEFINE_FLEX for having no
initializer" and pulling down "randstruct: gcc-plugin: Fix attribute
addition" from lore to get the Tested-by tag -- but it's all going on
top of the broken for-linus/hardening, not having realized it was broken.

32838c389761 (fix-rand2) HEAD@{10}: commit (amend): randstruct: gcc-plugin: Fix attribute addition
e4750e3b77b6 HEAD@{11}: commit (amend): randstruct: gcc-plugin: Fix attribute addition
3e77d5ec7b16 HEAD@{12}: commit (amend): randstruct: gcc-plugin: Fix attribute addition
d8b0249fc36e HEAD@{13}: commit: gcc-plugins: randstruct: Fix attribute creation
8dcf80e5097b HEAD@{14}: rebase (finish): returning to refs/heads/fix-rand2
8dcf80e5097b HEAD@{15}: rebase (pick): overflow: Introduce __DEFINE_FLEX for having no initializer
66989cf66d91 HEAD@{16}: rebase (pick): ubsan: integer-overflow: depend on BROKEN to keep this out of CI
8bfebe2e9cc5 HEAD@{17}: rebase (pick): wifi: iwlwifi: mld: Work around Clang loop unrolling bug
e0797d3b91de (linux-next/stable, master) HEAD@{18}: rebase (start): checkout master
d316fb5f88c9 HEAD@{19}: checkout: moving from for-linus/hardening to fix-rand2

This is trying to figure out why merging didn't work, so I restarted on
master and cherry-picked the patches to a separate tree ("fix-rand2")
for testing.

d316fb5f88c9 HEAD@{20}: commit (amend): overflow: Introduce __DEFINE_FLEX for having no initializer
8c2917224046 HEAD@{21}: commit: overflow: Introduce __DEFINE_FLEX for having no initializer
2e058d249588 HEAD@{22}: checkout: moving from for-next/hardening to for-linus/hardening

This is working on and testing "overflow: Introduce __DEFINE_FLEX for having no
initializer".

f8b59a0f90a2 (broken/for-next/hardening) HEAD@{23}: reset: moving to f8b59a0f90a2
96e5b773dff6 HEAD@{24}: commit: platform/x86: thinkpad_acpi: Handle KCOV __init vs inline mismatches
f8b59a0f90a2 (broken/for-next/hardening) HEAD@{25}: am --abort
f8b59a0f90a2 (broken/for-next/hardening) HEAD@{26}: reset: moving to f8b59a0f90a2
2e058d249588 HEAD@{27}: checkout: moving from for-linus/hardening to for-next/hardening

This is splitting out "platform/x86: thinkpad_acpi: Handle KCOV __init
vs inline mismatches" so I could send it out, and then throwing away the
patch since its going via a separate tree and I need to review that whole
tree separately anyway. (This tree is still the _broken_ for-next tree...)

2e058d249588 HEAD@{28}: checkout: moving from for-next/hardening to for-linus/hardening
2e058d249588 HEAD@{29}: checkout: moving from test/1 to for-next/hardening
9d230d500b0e HEAD@{30}: rebase (skip) (finish): returning to refs/heads/test/1
9d230d500b0e HEAD@{31}: rebase (start): checkout master
939b93ecd094 HEAD@{32}: checkout: moving from landing/v6.16-rc1-pre/hardening to test/1

I was cleaning up old trees, and went back to look at old commits
(9d230d500b0e) but couldn't figure out why I was having trouble with
merge bases, and tried a rebase but it exploded. I return to the
(broken) for-next.

dbfe626a6fbf (landing/v6.16-rc1-pre/hardening) HEAD@{33}: reset: moving to HEAD
dbfe626a6fbf (landing/v6.16-rc1-pre/hardening) HEAD@{34}: Branch: renamed refs/heads/dev/hardening to refs/heads/landing/v6.16-rc1-pre/hardening
dbfe626a6fbf (landing/v6.16-rc1-pre/hardening) HEAD@{36}: rebase (finish): returning to refs/heads/dev/hardening
dbfe626a6fbf (landing/v6.16-rc1-pre/hardening) HEAD@{37}: rebase (pick): ovl: Check for NULL d_inode() in ovl_dentry_upper()
a3ca08cb5fb3 HEAD@{38}: rebase (pick): slab: Decouple slab_debug and no_hash_pointers
9d230d500b0e HEAD@{39}: rebase (start): checkout master
345b264de969 HEAD@{40}: rebase (finish): returning to refs/heads/dev/hardening
345b264de969 HEAD@{41}: rebase (pick): ovl: Check for NULL d_inode() in ovl_dentry_upper()
31f107a183e6 HEAD@{42}: rebase (pick): drm/amdgpu/atom: Work around vbios NULL offset false positive
3523b5868c43 HEAD@{43}: rebase (pick): slab: Decouple slab_debug and no_hash_pointers
8ffd015db85f (tag: v6.15-rc2) HEAD@{44}: rebase (start): checkout 8ffd015db85f
541157c72800 HEAD@{45}: checkout: moving from for-next/hardening to dev/hardening

Checking if some expected patches have already landed in master while
cleaning up older dev trees and rebasing them forward for potential
revisions during the coming dev cycle. This appears to be sanely based
on master, not a broken tree.

2e058d249588 HEAD@{46}: checkout: moving from dev/v6.15-rc4/hardening to for-next/hardening
9d230d500b0e HEAD@{47}: rebase (skip) (finish): returning to refs/heads/dev/v6.15-rc4/hardening
9d230d500b0e HEAD@{48}: rebase (start): checkout master
b7286d1e8cad HEAD@{49}: checkout: moving from dev/v6.16-rc1-pre/-Wunterminated-string-initialization to dev/v6.15-rc4/hardening
62329e859b25 (dev/v6.16-rc1-pre/-Wunterminated-string-initialization) HEAD@{50}: checkout: moving from for-next/hardening to dev/v6.16-rc1-pre/-Wunterminated-string-initialization

Trying to figure out why I can't sanely rebase. (Note that 2e058d249588 is on a
broken base tree, repeated above. Below, c102753312e8 is on a sane tree.)

2e058d249588 HEAD@{51}: reset: moving to 2e058d249588
bd31653e0d81 HEAD@{52}: reset: moving to HEAD
bd31653e0d81 HEAD@{53}: fast-import
62329e859b25 (dev/v6.16-rc1-pre/-Wunterminated-string-initialization) HEAD@{54}: checkout: moving from test/kern-splat to for-next/hardening
9a7d4e791037 HEAD@{55}: reset: moving to 9a7d4e791037
62329e859b25 (dev/v6.16-rc1-pre/-Wunterminated-string-initialization) HEAD@{56}: checkout: moving from for-next/hardening to test/kern-splat

This is where 2e058d249588 first appears, and before it is the branch
juggling of one of my scripts to send a single patch out of the middle of
a tree ("kern-splat" was a script to email the top patch, "kern-splat-one"
sends a specific sha from the tree by temporarily making a new branch,
"test/kern-splat", with that sha at the top, using "kern-splat", and
then restoring the tree to the prior state.)

But the "fast-import" is NOT part of that, but rather from "b4
trailers". I checked my reflog against my bash history...

"l" is "git log -1"
"s" is "git show"
"d" is "git diff"
"latr" is "git branch --sort=committerdate"

14029  git commit --amend
14030  s
14031  d
14032  git commit -asm '[DUP]'
14033  l
14034  kern-splat-one 9a7d4e791037
14035  l
14036  b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
14037  l
14038  git reset --hard 2e058d249588
14039  l
14040  latr
14041  l dev/v6.16-rc1-pre/-Wunterminated-string-initialization
14042  git reflog
14043  l 62329e859b25
14044  latr
14045  #git checkout 62329e859b25
14046  git branch -D dev/v6.16-rc1-pre/-Wunterminated-string-initialization
14047  git checkout 62329e859b25 -b dev/v6.16-rc1-pre/-Wunterminated-string-initialization
14048  l
14049  latr
14050  git branch -D dev/next-20250516/Wunterminated-string-initialization
14051  git branch -D dev/mld

HEAD@{57} below is 14029 above.
HEAD@{58} below is 14032 above.

HEAD@{54} through HEAD@{56} above is 14034 above.

HEAD@{53} and HEAD@{52} above is 14036 above.

Then I try to throw away (with 14038):

62329e859b25 (dev/v6.16-rc1-pre/-Wunterminated-string-initialization) [DUP]
9a7d4e791037 crypto: Annotate crypto strings with nonstring
b080c44c4d69 kbuild: Re-enable -Wunterminated-string-initialization

and just have "ubsan: integer-overflow: depend on BROKEN to keep this
out of CI" on top, but for some reason it shows in "git log -1" as
2e058d249588 not 8c2bb7d12601.

Now, looking at the tree for 8c2bb7d12601, I see I'm on sane "master"
base. I'll bet "b4 trailers" did something Exciting when rewriting stuff.
More below...

62329e859b25 (dev/v6.16-rc1-pre/-Wunterminated-string-initialization) HEAD@{57}: commit: [DUP]
9a7d4e791037 HEAD@{58}: commit (amend): crypto: Annotate crypto strings with nonstring
08652ab8b218 HEAD@{59}: commit (amend): crypto: Annotate crypto strings with nonstring
7bf10004aed0 HEAD@{60}: commit: crypto: Annotate crypto strings with nonstring
b080c44c4d69 HEAD@{61}: commit (cherry-pick): kbuild: Re-enable -Wunterminated-string-initialization
8c2bb7d12601 HEAD@{62}: rebase (finish): returning to refs/heads/for-next/hardening
8c2bb7d12601 HEAD@{63}: rebase (pick): ubsan: integer-overflow: depend on BROKEN to keep this out of CI
b9dbd69a32e3 HEAD@{64}: rebase (pick): wifi: iwlwifi: mld: Work around Clang loop unrolling bug
9d230d500b0e HEAD@{65}: rebase (start): checkout master

9d230d500b0e and 8c2bb7d12601 are sane trees. I'm pulling forward my
patches to enable -Wunterminated-string-initialization for testing, and
I find a new warning (in crypto) which I make, as well as another that
I'd already fixed before, that I split and leave as "[DUP]", then run
"kern-splat-one" on the crypto patch to get it sent[1].

c102753312e8 HEAD@{66}: checkout: moving from dev/v6.16-rc1-pre/-Wunterminated-string-initialization to for-next/hardening
9d230d500b0e HEAD@{67}: checkout: moving from for-next/hardening to dev/v6.16-rc1-pre/-Wunterminated-string-initialization
c102753312e8 HEAD@{68}: rebase (finish): returning to refs/heads/for-next/hardening
c102753312e8 HEAD@{69}: rebase (pick): ubsan: integer-overflow: depend on BROKEN to keep this out of CI
fec8dc564c2f HEAD@{70}: rebase (reword): wifi: iwlwifi: mld: Work around Clang loop unrolling bug
368556dd234d HEAD@{71}: rebase: fast-forward
f0cd6012c40d (tag: hardening-v6.16-rc1, kees/for-next/kspp, kees/for-next/hardening) HEAD@{72}: rebase (start): checkout f0cd6012c40d
70f74ef707fc HEAD@{73}: commit (amend): ubsan: integer-overflow: depend on BROKEN to keep this out of CI
eef1355c269b (HEAD -> for-next/hardening, origin/for-next/hardening, for-next/kspp) HEAD@{74}: commit (amend): ubsan: integer-overflow: depend on BROKEN to keep this out of CI

c102753312e8 is based on a sane tree, I'm starting to build patches that
I'd like to land in -rc1, based on my existing for-next tree. Which gets
us back to the "known good state", per sfr.


Okay, reproducing the "b4 trailers" steps:

#### start from known good tree
$ git checkout 62329e859b25 -b test/wreckage/before
$ l
62329e859b25 (HEAD -> test/wreckage/before, dev/v6.16-rc1-pre/-Wunterminated-string-initialization) [DUP]
9a7d4e791037 crypto: Annotate crypto strings with nonstring
b080c44c4d69 kbuild: Re-enable -Wunterminated-string-initialization
8c2bb7d12601 ubsan: integer-overflow: depend on BROKEN to keep this out of CI
b9dbd69a32e3 wifi: iwlwifi: mld: Work around Clang loop unrolling bug
9d230d500b0e Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
bf373e4c786b Merge tag 'devicetree-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
8ca154e4910e Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
43db11110730 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
12e9b9e5223b Merge tag 'ipe-pr-20250527' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
90b83efa6701 (stable/master) Merge tag 'bpf-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
1b98f357dadd Merge tag 'net-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
...
### Try to update 8c2bb7d12601 with the Acked-by from the list...
$ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
Finding code-review trailers for 39 commits...
Grabbing thread from lore.kernel.org/all/CANpmjNPpyJn%2B%2BDVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F%2B_8Xg@mail.gmail.com/t.mbox.gz
---
  + Acked-by: Marco Elver <elver@google.com>
    https://lore.kernel.org/all/CANpmjNPpyJn%2B%2BDVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F%2B_8Xg@mail.gmail.com
---
Press Enter to apply these trailers or Ctrl-C to abort
  ubsan: integer-overflow: depend on BROKEN to keep this out of CI
    + Acked-by: Marco Elver <elver@google.com> (✓ DKIM/google.com)
---
Invoking git-filter-repo to update trailers.
New history written in 3.28 seconds...
Completely finished after 3.76 seconds.
Trailers updated.
$ l
bd31653e0d81 (HEAD -> test/wreckage/before) [DUP]
b68e360e9673 crypto: Annotate crypto strings with nonstring
650370e9729c kbuild: Re-enable -Wunterminated-string-initialization
2e058d249588 ubsan: integer-overflow: depend on BROKEN to keep this out of CI
50d526235542 wifi: iwlwifi: mld: Work around Clang loop unrolling bug
f8b59a0f90a2 (broken/for-next/hardening) Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
301559ea27b1 Merge tag 'devicetree-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
ca1f463363e2 Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
...

Welp, that precisely recreated it -- even identical shas! Looking at
the b4 output, I do see a suspicious "39 commits" listed for some reason.

So, I assume the "git-filter-repo" invocation is what mangled it. I will
try to dig into what b4 actually asked it to do in the morning...

-Kees

[1] https://lore.kernel.org/lkml/20250529173113.work.760-kees@kernel.org/

-- 
Kees Cook

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

[Konstantin Ryabitsev]

On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> Okay, reproducing the "b4 trailers" steps:
> 
> #### start from known good tree
> $ git checkout 62329e859b25 -b test/wreckage/before
> $ l
> 62329e859b25 (HEAD -> test/wreckage/before, dev/v6.16-rc1-pre/-Wunterminated-string-initialization) [DUP]
> 9a7d4e791037 crypto: Annotate crypto strings with nonstring
> b080c44c4d69 kbuild: Re-enable -Wunterminated-string-initialization
> 8c2bb7d12601 ubsan: integer-overflow: depend on BROKEN to keep this out of CI
> b9dbd69a32e3 wifi: iwlwifi: mld: Work around Clang loop unrolling bug
> 9d230d500b0e Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
> bf373e4c786b Merge tag 'devicetree-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> 8ca154e4910e Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> 43db11110730 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> 12e9b9e5223b Merge tag 'ipe-pr-20250527' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
> 90b83efa6701 (stable/master) Merge tag 'bpf-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> 1b98f357dadd Merge tag 'net-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> ...
> ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
> Finding code-review trailers for 39 commits...

Yeah, this is danger territory, because you're asking to update a random
commit in the tree history. Without passing --since, we're looking at raw git
history in the current branch as far as 1 month back to try to figure out the
range of commits that we should work with:

https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/src/b4/ez.py#n1048

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.

> Welp, that precisely recreated it -- even identical shas! Looking at
> the b4 output, I do see a suspicious "39 commits" listed for some reason.

Well, that's the point where the user, in theory, goes "this is weird, why is
it 39 commits," and does Ctrl-C, but I'm happy to accept blame here -- we
should be more careful with this operation and bail out whenever we recognize
that something has gone wrong. To begin with, we'll output a listing of all
the commits that will be rewritten, just to make it more obvious when things
are about to go wrong.

> So, I assume the "git-filter-repo" invocation is what mangled it. I will
> try to dig into what b4 actually asked it to do in the morning...

Thanks for looking into this. Linus, this is accurate and I am 100% convinced
that there was no malicious intent. My apologies for being part of the mess
through the tooling.

I will reinstate Kees's account so he can resume his work.

-K

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

[Kees Cook]

On Sun, Jun 01, 2025 at 10:40:18AM -0400, Konstantin Ryabitsev wrote:
> On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> > Okay, reproducing the "b4 trailers" steps:
> > 
> > #### start from known good tree
> > $ git checkout 62329e859b25 -b test/wreckage/before
> > $ l
> > 62329e859b25 (HEAD -> test/wreckage/before, dev/v6.16-rc1-pre/-Wunterminated-string-initialization) [DUP]
> > 9a7d4e791037 crypto: Annotate crypto strings with nonstring
> > b080c44c4d69 kbuild: Re-enable -Wunterminated-string-initialization
> > 8c2bb7d12601 ubsan: integer-overflow: depend on BROKEN to keep this out of CI
> > b9dbd69a32e3 wifi: iwlwifi: mld: Work around Clang loop unrolling bug
> > 9d230d500b0e Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
> > bf373e4c786b Merge tag 'devicetree-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> > 8ca154e4910e Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> > 43db11110730 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> > 12e9b9e5223b Merge tag 'ipe-pr-20250527' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
> > 90b83efa6701 (stable/master) Merge tag 'bpf-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> > 1b98f357dadd Merge tag 'net-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> > ...
> > ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> > $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
> > Finding code-review trailers for 39 commits...
> 
> Yeah, this is danger territory, because you're asking to update a random
> commit in the tree history. Without passing --since, we're looking at raw git
> history in the current branch as far as 1 month back to try to figure out the
> range of commits that we should work with:

Yeah, my SSD glitches were a red-herring -- they happened before the
"known good state" sfr pointed out (so, yay, I did fix my trees from
that).

My mistakes were:

- not noticing the "39 commits" warning

- overriding my push sanity checks

Sorry about all the noise and confusion!

> https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/src/b4/ez.py#n1048
> 
> 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 for looking into this. Linus, this is accurate and I am 100% convinced
> that there was no malicious intent. My apologies for being part of the mess
> through the tooling.
> 
> I will reinstate Kees's account so he can resume his work.

Thank you! I will now *very carefully* construct a v2 PR...

-- 
Kees Cook

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

[Linus Torvalds]

On Sun, 1 Jun 2025 at 07:40, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> > Okay, reproducing the "b4 trailers" steps:
> > ...
> > ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> > $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
> > Finding code-review trailers for 39 commits...
>
> Yeah, this is danger territory, because you're asking to update a random
> commit in the tree history.

So the *real* danger territory is lying about committer information.
That's the thing that *no* standard too should ever do, and what made
me so upset.

Konstantin, can you please fix b4 to never *ever* rewrite a commit
that has different committer information than the current user?

I don't think this is about "39 commits down". This is apparently b4
just doing plain bad things, adn it would be bad even if it was only
rewriting the top-most commit.

Setting authorship to somebody else is normal and expected: "author"
is about giving credit.

But setting *committer* information to somebody else is not about
giving credit, it's about lying. Tools that do that are broken tools.

I'm also not clear on why apparently the script tries to retain
committer dates. That's also just plain lying.

> I will reinstate Kees's account so he can resume his work.

Yeah, I see the updated pull request,

         Linus

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

[Konstantin Ryabitsev]

On Sun, Jun 01, 2025 at 10:12:02AM -0700, Linus Torvalds wrote:
> > Yeah, this is danger territory, because you're asking to update a random
> > commit in the tree history.
> 
> So the *real* danger territory is lying about committer information.
> That's the thing that *no* standard too should ever do, and what made
> me so upset.
> 
> Konstantin, can you please fix b4 to never *ever* rewrite a commit
> that has different committer information than the current user?

Yes, I will add that safety check in for sure. This is one of those scope
creep situations -- the trailers command started out as a way to apply
trailers only to your own curated series, e.g. before submitting a vN+1, but
it was then hacked to also work on arbitrary trees, without properly
considering all possible implications.

> I don't think this is about "39 commits down". This is apparently b4
> just doing plain bad things, adn it would be bad even if it was only
> rewriting the top-most commit.
> 
> Setting authorship to somebody else is normal and expected: "author"
> is about giving credit.
> 
> But setting *committer* information to somebody else is not about
> giving credit, it's about lying. Tools that do that are broken tools.
> 
> I'm also not clear on why apparently the script tries to retain
> committer dates. That's also just plain lying.

It's working as designed, I'm afraid -- git-filter-repo is a powerful tool
for rewriting git history and will happily fire off even when you are pointing
it at your own two feet.

-K

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

[Konstantin Ryabitsev]

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

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

[Linus Torvalds]

On Sun, 1 Jun 2025 at 10:49, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> It's working as designed, I'm afraid -- git-filter-repo is a powerful tool
> for rewriting git history and will happily fire off even when you are pointing
> it at your own two feet.

Yeah, well, it's designed for rewriting the repo.

But it most certainly can also rewrite the committer name, email and date.

And I do think that even if you check that the committer doesn't
change, you *should* make it rewrite the commit date, so that people
see when the thing was used to rebase commits.

Afaik, that's as easy as just setting the 'committer_date' member in
the commit callback. No?

           Linus

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

[Kees Cook]

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

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

[Christian Brauner]

On Sun, Jun 01, 2025 at 10:12:02AM -0700, Linus Torvalds wrote:
> On Sun, 1 Jun 2025 at 07:40, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> > > Okay, reproducing the "b4 trailers" steps:
> > > ...
> > > ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> > > $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
> > > Finding code-review trailers for 39 commits...
> >
> > Yeah, this is danger territory, because you're asking to update a random
> > commit in the tree history.
> 
> So the *real* danger territory is lying about committer information.
> That's the thing that *no* standard too should ever do, and what made
> me so upset.
> 
> Konstantin, can you please fix b4 to never *ever* rewrite a commit
> that has different committer information than the current user?
> 
> I don't think this is about "39 commits down". This is apparently b4
> just doing plain bad things, adn it would be bad even if it was only
> rewriting the top-most commit.
> 
> Setting authorship to somebody else is normal and expected: "author"
> is about giving credit.
> 
> But setting *committer* information to somebody else is not about
> giving credit, it's about lying. Tools that do that are broken tools.
> 
> I'm also not clear on why apparently the script tries to retain
> committer dates. That's also just plain lying.

Fwiw, this has happened to me with b4 multiple times before so I've
stopped using b4 trailers -u. Whenever I do end up using it I look at
the base that I was using to make sure that only things got rewritten
that I expected to be rewritten (b4 is excellent though).

The last time this happened was when I did the struct kmem_cache_args
rework a few months back. Vlastimil and I ended up sharing a common base
and then he complained that something was off with our shared trees. He
later emailed me and we figured out that it was the b4 trailers thing
again iirc.

I do test-merges before I send stuff out and that's usually how I catch
stuff like that.

But for a while I was really confused how trees I had somehow ended up
being rewritten and it took a little to figure out that it was the
trailer auto updating which caused it.

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

[Vlastimil Babka]

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@suse.cz"
gpg: Good signature from "Vlastimil Babka <vbabka@suse.com>" [ultimate]
gpg:                 aka "Vlastimil Babka <vbabka@suse.cz>" [ultimate]
Merge: 5be63fc19fca 6e016babce7c
Author:     Vlastimil Babka <vbabka@suse.cz>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@suse.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@linux.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@suse.cz>
AuthorDate: Thu Sep 5 11:31:32 2024 +0200
Commit:     Vlastimil Babka <vbabka@suse.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