For the few people who have spent the past weeks living under a security rock, the Linux kernel has found itself the subject of multiple severe bugs in the form of Copy Fail and Dirty Frag, both of which allow for privilege escalation. They’ve made many people very upset, and also potentially put many thousands of systems at risk of exploitation. Worse is that system managers are generally left to twiddle their thumbs while waiting for patches to be rolled out. This is where NVIDIA engineer [Sasha Levin] has proposed a ‘kill switch’ for affected kernel functions.
The basic concept seems rather simple, with this feature merely intercepting a call to the affected function and instead returning a predefined return value. This makes it less extreme than hitting a general SCRAM button on the entire kernel, and could theoretically allow the affected systems to keep running until the patched kernel becomes available.
A disadvantage of this is that it obviously modifies the kernel, patching it in-memory so that you need to reboot the system to clear it. Another potential disadvantage is that it opens a potentially massive attack vector, with people in the Cybersecurity sub-Reddit roundly rejecting the idea. Amidst all the other anxious conversions there is also the concern that this particular patch was at least partially generated by an LLM (Claude Opus 4.7) , so one may hope that if it does gets merged into mainline it’ll at least be properly vetted by multiple pairs of well-caffeinated human eyes.
ignoring the fact that mac and windows have also been repeatedly slammed these last few days i see.
Whataboutism… Not what this article is about.
Its more a “Ok not like anything else does any better so why are you bitching”
Which is whataboutism.
Downplaying one thing by pointing out something similar that is also recognized as a problem.
It is unhelpful to the point of destroying the conversation.
It’s about the ever more sensationalized reporting in the security sphere for those sweet sweet dollars, right?
Don’t let the fix be worse than the problem.
Yes! If a kill switch exists it will be the new target, instead of having to cobble together your own kill switch from whatever you find lying around in the system you just gained access to.
sounds like the ‘fix’ would be many times worse than the problem…
This is already widely deployed.
The kernel already makes extensive use of live-patching of itself on hot paths as an alternative to conditional branches, purely for regular configuration. It’s better for performance to rewrite an unconditional jump than to have a conditional jump where you need to load a variable from ram and use it to determine the direction you go, or serve as an offset into a jump table.
It’s also widely used forsecurity in the form of livepatch, for which ubuntu etc offer subscription services. They send you patches, and those patches replace specific functions in running kernels to mitigate vulnerabilities without rebooting. You can’t change kernel data structures, but you can close a hole quickly.
This isn’t as fancy as that being as it doesn’t offer the ability to fix functions, just make calls automatically fail. But it might be the kind of thing you could carry in deployed kernels with a simple root-only file you could write to that switches off functionality and makes calls fail until the next reboot.
Below an article about (black hat) hackers (ab) using AI for their nefarious purposes and also a bit of using ai to thwart them.
https://singularityhub.com/2026/03/09/hackers-are-automating-cyberattacks-with-ai-defenders-are-using-it-to-fight-back/
Like if the world wasn’t in a big enough mess already at this moment.
If there is one thing all this ai stuff is going to do, then it’s putting more power in the hands of an ever smaller group of people. And that is not a good thing.
there’ve been a lot of howlers scrawled in here by the writers, but this is a new level of hilarious.
Monolithic kernel is a mess that’s full of security issues, who would’ve guessed 🤔
So what is the secure alternative that you are using?
“So what is the secure alternative that you are using?”
YES….. please do tell!!!!
M$ Windoze???? or the AppleTax??
Impress me…say BSD—- haha
Hurd?
Hey fanboi, The 90’s called, they want their in$ults back. 😂
Kek, said the guy that almost certainly doesn’t contribute or develop at all
Better idea: fix the problems in the code and deploy using more modules. Adding a kill switch is just adding one more vulnerability.
Can’t take this seriously
Half of the severe CVEs be like “requires physical access” or “only applicable under these very specific conditions, only when you run an executable specially made to exploit it”
Guess what, i could make a DoS CVE, computer stops working when a baseball bat is brought to the motherboard
Lowering it into a vat full of salt water would be better IMO.
I read one where someone claimed dirtyfrag could be exploited with a one liner… the “one liner” was something like “curl gitrepo && execute precompiled binary”
I think getting in the news and making headlines is becoming more important than objective analysis in the security sphere.
Maybe on desktop, not that big of a deal, don’r run untrusted programs.
It’s bigger problem on servers. Unprivileged user is usually the second line of defense, the first being the application itself. So if you have RCE in an app, the breach can be somehow contained. With these CVEs this line of defense is gone. These are basically su without password. If you have RCE it is now the same as if you would run the app as root. And that is BAD.
A killswitch already exists… You can use eBPF to disable functions.
I am sure it will be fine. Linux is built on an extremely stable community that is not fragmented nor using decades old patched software and repos are sound as a pound…