Brad Spengler
@spendergrsec
Followers
4K
Following
750
Media
471
Statuses
6K
President of @opensrcsec, developer of @grsecurity Personal account
Joined June 2011
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.
0
0
2
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!
1
0
3
The fix commit, required to be applied to the 5.4, 5.10, 5.15, 6.1, and 6.6 LTS kernels:
1
0
2
I've cited all this before ( https://t.co/jEVwJem412), but to show it all again: the mention of AI AUTOSEL regarding the batch that included the commit that didn't belong: https://t.co/5HAXO6Rppc The AUTOSEL recommendation:
Vibe coding has no place in Linux kernel maintenance. The vulnerability inserted into 5 LTS kernels at once apparently without any review is yet another instance of AUTOSEL fallout, here with the "new" LLM-powered version. Sources: https://t.co/5HAXO6QRzE
1
0
2
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.
1
0
2
https://t.co/QIhmVJH5lH with no mention of the vuln that was introduced, and no CVE either, shocker.
1
0
1
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:
1
0
2
And then the very next commit after that is the one at question here: https://t.co/OVbM52a97m So believe what you want, I don't care 🤷♂️
1
0
1
here: https://t.co/H56b7YpjQZ Commit after that was a fixup, as the AI didn't add SPDX/copyright lines: https://t.co/HFNWixziDD (which it's not even clear he can legally do, but whatever, he doesn't seem to care about this).
1
0
2
The one after that was https://t.co/LbQgtTw3rj 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)
1
0
1
Let's look at all of his commits from this year. First was this one: https://t.co/o9iLl0AF23 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-authored
1
0
4
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)
1
0
2
Including this for transparency: https://t.co/rx912BIZWK 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
Kernel development and machine learning seem like vastly different areas of endeavor; there are [...]
1
0
4
These kinds of issues are more common than people would expect. I remember running tcpdump in 2003 and seeing some obvious kernel data being leaked over the network. Similar to the coredump case, it's there but nobody really looks:
Did you know the Linux kernel's been leaking uninitialized data (KASLR defeat) through coredumps for over a decade, and someone's custom syzkaller instance finally noticed it? https://t.co/DpqAF33Y0R We found it (manually) and fixed it properly almost two years ago
1
0
5
https://t.co/jityWpAkE9 A bit odd, it's the opposite of what I suggested and leaves some strange behavior in, like allowing the reads to flood logs, letting reads modify core_pattern from the recovery code, and turning the recovery code into a no-op.
0
0
1
Very confused by this, because I sent 3 mails about exactly this back in August:
1
0
6