You too can crash today's 6.12.43 LTS kernel thanks to a stable maintainer's AI slop. All you need is CAP_SYS_RESOURCE, modern systemd, and this:
40 b7 40 c1 e7 18 83 ef 08 57 57 31 ff 40 b7 07 31 c0 b0 a0 48 89 e6 0f 05 5e ff ce 31 ff b0 21 0f 05
Look at all this extra space!
40 b7 40 c1 e7 18 83 ef 08 57 57 31 ff 40 b7 07 31 c0 b0 a0 48 89 e6 0f 05 5e ff ce 31 ff b0 21 0f 05
Look at all this extra space!
How do I know it's plagiarized AI slop that evaded upstream reviewers? The well-written commit message is riddled with basic errors that nobody who actually produced the code through testing it would make: first, it does a setrlimit of RLIMIT_NOFILE that's higher than...
the nr_open it just set. That will fail immediately regardless of privilege level in setrlimit at: git.kernel.org/pub/scm/linux/…
Next, it tries to dup2 with a fd *higher* than the resource limit it just set, that too will fail immediately early in dup2 regardless of privilege level without calling alloc_fdtable or doing any allocations here: git.kernel.org/pub/scm/linux/…
It really looks like an LLM was just pointed at: and it failed to understand the system limitations and the relationship between the different values, but spit something out that "looked" similar, complete with the dup'd fd being offset by 64 from nr_opengit.kernel.org/pub/scm/linux/…
But the important point is that this was supposedly code to reproduce a specific bug, a real one I had already tweeted about in January. But the bogus test tests nothing at all, it will simply fail 100% of the time without ever testing what it claimed. Worse than that...
because the "developer" didn't go through a real process producing the code and commit, slapping a stable@ on it, they never looked at what would happen to that commit on older kernels. It patched a function (alloc_fdtable()) that was changed in 6.13 to return ERR_PTR values...
On earlier kernels, alloc_fdtable() returns NULL on all errors, and callers will dereference any non-NULL return value. So when it got cherry-picked clean despite the obvious difference visible in diff context, you end up with a vuln in a core syscall.
There's no point in reporting this stuff because the vulnerability is simple:
stable maintainers using AI who have no idea what they're doing and are using it as a substitute for the work everyone else assumes they've performed
It'll keep happening until that bug's fixed.
stable maintainers using AI who have no idea what they're doing and are using it as a substitute for the work everyone else assumes they've performed
It'll keep happening until that bug's fixed.
Including this for transparency: lwn.net/Articles/10425… But anyone can also look up that the author's kernel contributions prior to this year date to 2022, with a number from this year admitted to be generated by AI, undisclosed in the commits themselves: lwn.net/Articles/10265…
Can look at the commit message itself and ask if a perfectly-formatted/indented testcase and bulleted report which is entirely non-functional on multiple levels is what normal humans produce without any AI involvement (which a 'not used for the patch' doesn't necessarily deny)
Let's look at all of his commits from this year. First was this one: He didn't admit this one was authored by AI as far as I've seen, but it's identical in purpose/verbiage as this one authored 3 days later and (via the earlier link) admitted AI-authoredgit.kernel.org/pub/scm/linux/…
The one after that was which the author later admitted was AI-generated via the same link above (i.e. plagiarized). You can view the dismissive tone toward the maintainer and others who felt the submission should have been labeled(as done for static tools)git.kernel.org/pub/scm/linux/…
here: lwn.net/Articles/10275… Commit after that was a fixup, as the AI didn't add SPDX/copyright lines: git.kernel.org/pub/scm/linux/… (which it's not even clear he can legally do, but whatever, he doesn't seem to care about this).
And then the very next commit after that is the one at question here: So believe what you want, I don't care 🤷♂️git.kernel.org/pub/scm/linux/…
Can try to downplay it by just repeating what I said in the original post as if it's somehow a correction of what I wrote, nevermind that he's on the CNA and they issue CVEs for exactly issues like this day and night. But in this case it got silently fixed by backporting:
with no mention of the vuln that was introduced, and no CVE either, shocker.git.kernel.org/pub/scm/linux/…
Similar to how when he blindly accepted AI-AUTOSEL output to backport an x86 mitigation patch that didn't belong at all in 5 LTS kernels, turning the userland Spectre v2 mitigation into a no-op for a month, no CVE was issued there either.
I've cited all this before (x.com/spendergrsec/s…), but to show it all again: the mention of AI AUTOSEL regarding the batch that included the commit that didn't belong: lwn.net/Articles/10202… The AUTOSEL recommendation: lore.kernel.org/all/2025050522…
The fix commit, required to be applied to the 5.4, 5.10, 5.15, 6.1, and 6.6 LTS kernels: git.kernel.org/pub/scm/linux/…
Anyway, clearly his AI is so good that he doesn't need any more of his slop fixed up by me in LTS kernels. Happy to oblige!
FTR, our business is not affected by AI succeeding or failing. I don't have any strong convictions either way, but what I do know is slop is slop, and I (and others) don't trust this person's judgment in using AI critically, based on the above (& more) info that I've documented.
Some other recent examples of why I don't trust his judgment or ability to review/test what he publishes:
https://x.com/spendergrsec/status/1943405684919308358
Here he proposed to backport a whole network scheduler just to get one random fix (out of a dozen or so others) applied to it (have to introduce the bug to fix it, right?): git.kernel.org/pub/scm/linux/… lore.kernel.org/stable/871prjv…
Here he backported a patch to fix support for something that doesn't exist at all in the kernel he backported to:
https://x.com/spendergrsec/status/1877354422784647519
Above quote tweet shows the earlier time the same thing was done a few months earlier regarding the same feature by the same person.
May of last year, his "backport" of "NFSD: Fix
nfsd4_encode_fattr4() crasher", which was a simple fix for a uninitialized kfree, caused him to backport as a supposed "dependency" for an entirely unrelated file per-netns NFS statistics
nfsd4_encode_fattr4() crasher", which was a simple fix for a uninitialized kfree, caused him to backport as a supposed "dependency" for an entirely unrelated file per-netns NFS statistics
which crashed the kernel on NFS use:
https://x.com/spendergrsec/status/1793489498443252143
Others have noted he ignores feedback: In most of the cases I've documented, he's nowhere to be found on the mailing lists related to the problems created by his sloppiness, and so no real learning happens.social.kernel.org/notice/Amj9cj6…
@__picaro8 @arivero @jocadbz Just to show the distinction for people that aren't aware:
git.kernel.org/pub/scm/linux/… is the mainline Linux tree, all commits in there have to go through Linus in some form
Stable/LTS kernel versions are in a separate repo, managed by the stable maintainers: git.kernel.org/pub/scm/linux/…
git.kernel.org/pub/scm/linux/… is the mainline Linux tree, all commits in there have to go through Linus in some form
Stable/LTS kernel versions are in a separate repo, managed by the stable maintainers: git.kernel.org/pub/scm/linux/…
@__picaro8 @arivero @jocadbz Can click the combo box at the top right to view other present/past stable/LTS versions (each is in its own branch).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
