Linux kernel developers are reviewing a proposal for an emergency risk mitigation mechanism (“Killswitch”) that would allow administrators to disable vulnerable kernel functions at runtime.

The proposal, submitted by Linux kernel developer/maintainer Sasha Levin, arrives in the wake of the public disclosure of two privilege escalation vulnerabilities affecting the Linux kernel.

What prompted the proposal

The impetus for the proposal is explicit: the patch’s selftest references Copy Fail (CVE-2026-31431), a nine-year-old local privilege escalation flaw in the AF_ALG cryptographic socket interface disclosed by researchers at Theori on April 29.

The flaw allows an unprivileged local user to write four controlled bytes into the kernel page cache of any readable file, reliably achieving root without needing to win a race condition.

Copy Fail’s disclosure process was chaotic: Linux kernel developers were notified in advance and had time to work on a fix, but various Linux distributions were still working on issuing patched kernel packages when Theori researchers published a working proof-of-concept exploit.

Dirty Frag was publicly disclosed on May 7 by researcher Hyunwoo Kim, who privately reported CVE-2026-43284 and CVE-2026-43500, which together “make” Dirty Frag, to kernel maintainers on April 29–30.

But when a patch for CVE-2026-43284 got merged on May 5, it didn’t take long for another researcher to analyze it, create a working exploit, and publish it, forcing Kim to proceed with public disclosure before the agreed-upon embargo window ended.

(The researcher in question didn’t know about the embargo. “The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree,” he noted.)

Copy Fail demonstrated that due to a poor understanding of the intricacies of the process, even well-intentioned disclosure can leave distros scrambling. Dirty Frag demonstrated how vulnerability disclosure embargos are futile if a fix lands in a public repository.

The Killswitch

The killswitch proposal is an acknowledgment of the fact that if the window between disclosure and patched packages cannot be reliably controlled, Linux administrators need a way to reduce their exposure on their own terms.

“When a (security) issue goes public, [Linux] fleets stay exposed until a patched kernel is built, distributed, and rebooted into,” Levin explained.

For many vulnerabilities, including Copy Fail and Dirty Frag, administrators can reduce their exposure immediately by blacklisting the affected kernel module or unloading it if already running (though this may break specific functionality).

But that approach only works for code that lives in loadable modules. Some vulnerable code paths are compiled directly into the kernel and can’t be unloaded. That’s why Killswitch is meant to work at the function level, regardless of where that vulnerable code lives.

“Killswitch lets a privileged operator [i.e., admin] make a chosen kernel function return a fixed value without executing its body,” Levin explained, and pointed out that the mitigation is immediate and lasts until the next reboot.

Killswitch can reduce exposure during the window between public disclosure and the availability of patched kernel packages, but it’s good to note that it’s meant as a stop-gap measure until a fix can be implemented.

Nevertheless, it may be just what many admins (and especially those administrating large computer fleets) are looking for.

The patch is currently being reviewed and re-worked, and it remains to be seen if it will be added to the kernel.

Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!