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: lwn.net/Articles/10202… lore.kernel.org/all/2025050522… I think good questions to ask when someone reports a vulnerability or regression caused by an incorrect backport are: can you articulate a reason why you backported this change? what review did you perform on the change to ensure it's appropriate for the kernel it's applied to?

"one kernel developer mentioned to me that this was definitely not the intent and might have been a regression" I'd be very shocked if that developer had anything to do with the code, because this behavior was basically documented even when the PCID-enabled variant was written Not in any user-visible way of course, but even the PCID variant was only described as "a little more secure" wrt global pages, and the mapping of entry text and it being part of the kernel image was evident from the code all along.

This is the right response: openwall.com/lists/kernel-h… For the same reason that NX is necessary even if it doesn't stop ROP, or that CFI is necessary even if it doesn't stop data-only attacks. They each serve their own purpose (and you'd be hard-pressed to have useful CFI w/o NX) When the pieces are defined in advance and there's a clear path to achieving them that doesn't involve unrealistic assumptions (as is the case here) there should be no debate. At this point it's just useless posturing on the part of the upstream dev.

Some more history: marc.info/?l=openbsd-mis… "unless the application requests it, of course..." cf. openwall.com/lists/kernel-h… "W^X is not supposed to protect you from attackers that can already do
system calls." then many years later ("A W^X refinement"): marc.info/?l=openbsd-tec… "I wish to block direct system calls from those areas"

Bruce Perens gives a talk where he mentions in passing the "Red Hat loophole" -- archive.is/laW2p Why doesn't he call Red Hat a GPL violator in a blog post published worldwide on news sites? The "information" he talks about (for the kernel) are split-out GPL'd patches No copyright holder contacted us with concerns prior to Bruce's post, and none have contacted us after. This is likely because everyone (including Bruce himself) knows it's perfectly legal (otherwise Bruce wouldn't be calling it a "loophole": i.e. something legal he doesn't like)

25 days since a trivially-reproduced warning at boot was introduced in KVM affecting an L1TF backport, a volunteer provided the same fix we applied to our 4.14 kernel 25 days ago: spinics.net/lists/stable/m…

https://twitter.com/spendergrsec/status/1281164511790141440

Some things we've learned from this: there is apparently no even basic upstream boot testing happening that would cause a release to be delayed for newly-introduced warnings in extremely common functionality like KVM. The policy of reverting problematic commits wasn't followed..

Did you know? Linux started out with a license different from the GPL: mirrors.edge.kernel.org/pub/linux/kern… As early as 2000, Linus Torvalds was claiming the GPL license on Linux meant "If you make changes, you have to send the changes back to me." cnn.com/TRANSCRIPTS/00… He's repeated this claim multiple times at conferences: The problem is, that language doesn't exist in the GPL at all, as pointed out to him by the Vice President of the FSF in 2007: lkml.org/lkml/2007/6/14…

One other thing: I was informed that the CII originally only involved a 3 year commitment from the companies involved (so 2014-2017), which was mentioned in one NYT article someone found, but which isn't mentioned anywhere on the CII website that I was able to see. This was obviously not something we were aware of, with @paxteam expressing some interest early on and discussing on their mailing list at the time. Had that been communicated up front, I don't think that would even have happened.

I shared some additional links/references regarding today's presentation in the conference Slack, sharing them here as well in this thread for those interested Current unfixed upstream 4.14 KVM bug present in 3 stable releases, warning visible simply by booting a kernel with KVM support: lkml.org/lkml/2020/6/24…

If Halvar watches my talk today, he will see the effort expended on KASLR dwarfs anything CFI-related. It's a necessary component, regardless of whether you think MT will be more important in the future. It's ok to have an incorrect opinion :)

https://twitter.com/halvarflake/status/1278389589351284736

Complaining in 2020 about CFI being a waste of defender resources, when all the work and problems were solved years ago is like complaining about NX being a waste of defender resources today. We've already moved on to other things

In case you needed any more evidence the CII is a dead and entirely irrelevant marketing effort: linuxfoundation.org/blog/2020/06/l… Among the items they are claimed to meet: "All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed." bestpractices.coreinfrastructure.org/en/projects/34…

@tombkeeper I read you're still holding a grudge about my comment ("I'm 99.9% sure the details don't match what that title impresses") about the title of your 2013 talk, "DEP/ASLR bypass without ROP/JIT" -- Allow me to explain To me, the title impressed that some generic bypass had been developed that didn't involve any existing categorization (and often, people use DEP interchangeably with PaX-style PAGEEXEC and even MPROTECT restrictions)

FYI, the Huawei repo has been modified with a new commit this morning that adds a comment to the README attempting to distance the code from Huawei. It was (intentionally or not) backdated to make it appear it was in the public repo on Friday, prior to our blog post. Conveniently, it addresses the two things mentioned in the blog post: 1) whether it was an official Huawei release, and 2) whether it is shipping on any Huawei devices, and mimics a similar post to the KSPP list this morning

The embarrassingly slow trickle of CFI fixes that were already present in the very first public RAP release over 4 years ago continues: git.kernel.org/pub/scm/linux/…