Sasha Levin, NVIDIA engineer and co-maintainer of the stable and long-term support kernel trees, has proposed a new patch that adds a mechanism called killswitch to the Linux kernel.
It's pitched as a way for system administrators to disable a vulnerable kernel function on a running system, and the timing of it isn't a coincidence either. The patch follows the rising risk of Linux Privilege Escalation (LPE) vulnerabilities like Copy Fail and Dirty Frag.
What is it?
The Linux kernel is built out of many thousands of small functions, each handling a specific job, like processing a network packet, opening a file, or talking to a USB device. When a security flaw shows up in one of these functions, the proper fix is to patch the code and ship a new kernel.
What killswitch entails is a more "must exterminate" approach, where the admin gives the kernel a function name and a return value. From that point on, the function still gets called by whatever was calling it, but it just hands back that value and exits. The actual code inside never runs.
In practice, that means a single line at the terminal:
echo "engage af_alg_sendmsg -1" \
> /sys/kernel/security/killswitch/controlAfter this, every program trying to send data through AF_ALG (the kernel cryptography interface Copy Fail also exploited) gets an error back. Whatever bug sat in af_alg_sendmsg is now unreachable because the function never actually executes.
The effect kicks in across every CPU core immediately, and it lasts until the admin disengages it or the system reboots. Engaging anything requires root privileges.
There's also a boot parameter version killswitch=fn1=val,fn2=val,..., for cases where an operator needs to apply the mitigation across a whole fleet of machines through the bootloader.
Sasha points at AF_ALG, ksmbd, nftables, vsock, and ax25 as good candidates for this patch, saying that:
For most users, the cost of "this socket family stops working for the day" is
much smaller than the cost of running a known vulnerable kernel until the fix
land.
Any risks?
The biggest catch is that killswitch doesn't fix anything. It just stops the function from running. Anything in userspace that depends on that function stops working too, for as long as the killswitch stays engaged.
Engaging it also taints the kernel, which is its way of marking that the running code isn't pure upstream Linux anymore. A new flag (H, bit 20) gets set the moment any killswitch is active, and it persists across disengage all the way to the next reboot.
Any crash that happens afterward carries an H in its banner, which acts as a signal to the Linux maintainers triaging the bug that the image was modified. The patch also dedicates a whole section called "Choosing the right target," warning operators not to pick the wrong function.
Someone on Reddit has described this as "a security feature that may be worse than the vulnerability," and many people agree with that sentiment.
AI was involved
There's one more thing worth flagging. At the bottom of the patch, just above the diff, sits an Assisted-by: Claude:claude-opus-4-7 line, marking it as one Sasha put together with help from Anthropic's AI assistant.
That isn't a one-off. The Assisted-by tag itself comes from a kernel policy, which Sasha had a hand in shaping. It lays out how AI-assisted contributions should be attributed in commit messages, alongside configuration files for tools like Claude, Copilot, and Cursor.
It also fits a wider pattern. Greg Kroah-Hartman has been running his own AI fuzzer against the kernel, and the first bugs it surfaced were in ksmbd, which is one of the subsystems Sasha specifically called out as a killswitch candidate.
As things stand, killswitch is just a patch on the Linux Kernel Mailing List, not merged into mainline, and not in any released kernel or distro. Whether it lands and in what form depends on the upcoming review cycle.
Suggested Read 📖: A Clanker is Being Used to Carry Out AI Fuzzing in Linux
Sourav Rudra
