Last week, two critical Linux kernel vulnerabilities were disclosed, prompting significant concern within the community. In response, developers are now reviewing a proposal for an emergency “killswitch” mechanism to reduce exposure following public disclosure of serious vulnerabilities.
Sasha Levin, an NVIDIA engineer and Linux stable kernel co-maintainer, submitted the patch. It allows system administrators to temporarily disable a vulnerable kernel function while awaiting a security update.
The concept is simple: if a dangerous code path is identified, the kernel can be instructed to stop using that function. Instead of executing normally, the function would return an error. While this does not resolve the underlying bug, it can block access to the vulnerable path until a patched kernel is available.
The proposal follows recent Linux kernel vulnerability disclosures, including Copy Fail and Dirty Frag. Copy Fail is particularly relevant, as the patch includes a self-test referencing CVE-2026-31431 to demonstrate how the killswitch could block the affected AF_ALG path.
Dirty Frag is not used as a direct test case, but it is also relevant and illustrates the broader issue: serious kernel bugs may become public before fixes are widely available. During this period, administrators may need a temporary method to reduce risk without waiting for the full update cycle.
Levin’s patch makes the feature available through the kernel’s securityfs interface. A privileged administrator can enable a killswitch for a specific function, causing it to fail immediately. This change takes effect at runtime and remains active until disabled or the system is rebooted.
The proposal targets code paths that most systems do not rely on daily. Levin cites areas such as AF_ALG, ksmbd, nf_tables, vsock, and ax25. In some environments, temporarily disabling these features may be less disruptive than running a kernel with a known vulnerability.
However, the feature carries clear risks. The patch does not include automatic safety checks to determine if a function can be safely disabled. Disabling the wrong function or returning an incorrect value could disrupt system behavior or cause new issues. Therefore, this is not intended as a general-purpose security switch for casual use.
It is also important to make it clear that this mechanism is not live patching. It does not replace vulnerable code with a corrected version, but only blocks a selected function from running. A full kernel update is still required to properly address the vulnerability. It could simply provide an emergency mitigation tool for the period between public disclosure and full patch deployment.
As of now, the killswitch patch is still under review and has not been accepted into the Linux kernel.
The kill switch would be an attack surface itself. The other thing – why introduce a killswitch when you already have livepatch available. I guess distributions could use that in the same way and that has been there for some time now and have logic for detecting if the code path is in use already(which from the description this new proposal does not have)
Livepatch will not help if there is no fix available yet. I do not think it adds a attack surface but it could break things on your system if you do no fully understand what it is doing and you are not required to use it anyways if it ever becomes anything. I doubt the average home user would even use it. It is more likely to be used on shared servers that are part of business or similar in my opinion while they wait for a patch.
A Denial Of Service (DOS) attack can render a machine unusable. Needs a flood of network activity.
But now, a single user could target the Kill Switch, and disable vital processes.
If I was a bad actor, that Kill Switch would be the perfect target.
If a bad actor could activate the kill switch then they are probably already inside your system and it will not matter if you have this killswitch at that point.
This could be useful not only for threats, but also for driver/modules malfunctions, ie. experiencing a cpu soft-lockup freeze for the ath9k driver which results in having to reboot (irq-non-interruptible lockup).
This will misused by sysadmins and abused by threat actors.
Let’s please reject this idea.
No. But, thank you.
Great something I will not fully understand that can help me break my system. I seen openwrt was affected by recent vulnerabilities no idea when my router will get a update maybe a year from now as slow as the updates seem to be for my router are and also since the next update is still in beta and most likely does not include fixes for current issues. I may slowly rethink my network over the next year. I’m guessing all routers are at risk.
the best I can tell openwrt by default only has 1 account admin which is root and no one else should be able to execute anything to make changes on router. You could further isolate devices and people by using guest network. Not sure how this could be used if people or other software on network have no access to change anything on router and I mean no account or login. I may be missing something since I probably do not fully understand.
After thinking some more on this I think you would basically have to attack yourself to make these flaws work if your the only admin or something you added to openwrt would have to be compromised at which point your probably screwed regardless since a compromised add-on would already have elevated privileges. If another vulnerability was used to gain access you would also most likely be screwed regardless if this is patched or not. Someone smarter then me may know more or have a better answer.
Ai Answer not mine.
a normal (non‑admin) user on your Wi‑Fi cannot directly “use” esp4, esp6, or rxrpc to exploit Dirty Frag on the router.
Briefly:
esp4 and esp6 are Linux kernel modules for the Encapsulating Security Payload protocol (IPv4/IPv6) used with IPsec; rxrpc is a kernel module for the RxRPC protocol. They are kernel‑level components, not user apps.
To exploit Dirty Frag you need code running with enough privileges on the target device to interact with those modules (i.e., local code execution on the router or a vulnerable service that lets an attacker run commands).
Simply being a regular wireless client does not let someone load or call those kernel modules on the router.
Practical takeaway:
Most casual users on your Wi‑Fi cannot use those modules to attack your router unless they can first exploit some other vulnerability (e.g., an RCE in a router service) to run code on it. Keep firmware updated, disable unnecessary services, and use strong Wi‑Fi security to minimize that initial access risk.
Isn’t this going to increase attack surface for bad things to happen ???