Linux Is Getting an Emergency Kill Switch

Added: 2026-05-15

[00:00:00]As I explained in the copy fail video about one of the worst kernel exploits recently discovered in Linux, AI security tools are a serious force multiplier in the discovery of bugs that affect so many machines. And malware that's able to exploit these vulnerabilities is falling into the hands of bad actors faster, leaving Linux admins in a serious world of hurt trying to defend their servers from becoming free real estate to dark web hacker mans. The time frame from vulnerability discovery to machines being exploited in the wild is growing shorter and shorter. So to combat the onslaught of these exploits and custom malware, kernel developers are considering an extremely controversial security measure, kill switches for potentially vulnerable kernel functions.

[00:00:43]Now from a very simplistic view, this security mitigation makes a lot of sense because you can't pone the kernel if the vulnerable code paths aren't in use. In fact, this is one of the mitigations that were recommended early on to deal with the copy fail bug in the first place. If your particular Linux distribution didn't issue patches, then you could just disable the vulnerable AFG code paths if you don't have to actually use them in your production system. This approach basically let you slam the door on the vulnerable function before attackers were able to walk through it. And it's important to make a distinction between a kernel kill switch and the current approach of live patching that some distros provide out-of-the-box support for. So live patching tries to replace broken code with corrected code while the system stays up while the kill switch as the name implies is a much more blunt approach where you disable the path to vulnerable code that you don't necessarily need to use for your production application. And there's a lot of modules that ship with a standard Linux kernel that you may not realize you don't actually need. And this is unironically one of the reasons why you should install Gen 2 or at least try compiling your own minimalist Linux kernel at some point in your career.

[00:01:57]Because one of the bittersweet aspects of Linux is it's designed to run everywhere. Linux powers routers, servers, desktops, kiosk, and other embedded devices. And across these different kinds of devices, there's a much wider variety of programs running that benefit from or outright require those different kernel modules.

[00:02:17]But even though installing Gen 2 is one of the answers to every major tech support issue, for the users that don't have time to make their own kernels, the kill switch might be the next best option. So under the hood, this patch is built on very old school kernel machinery. Security FS, K probes, fracebacked probing, and function error injection. K probes already let the kernel dynamically trap almost any kernel routine, run a handler when the break point is hit, and even alter execution flow if the handler changes registers or the instruction pointer.

[00:02:54]The official kernel documentation explicitly warns that changing execution paths in a running kernel requires serious care because you can very easily shoot your foot off. Kill switch turns that dangerous debugging superpower into an admin facing emergency mitigation primitive. The interface for this kill switch is pretty small. There's one file called control where the admin sends commands like turn the kill switch off for this function or turn it back off.

[00:03:20]Then another file called engaged shows which functions are currently being blocked. And there's a taint file that tells you whether the running kernel has been modified by the kill switch at all.

[00:03:31]Then for every function that you activate the kill switch on, the kernel creates a little status folder for it.

[00:03:37]So if you kill switched afg send message, you get a folder for afalg send message under the kill switch interface.

[00:03:45]Inside that folder are simple status files like retv val which shows the fake return value the function is being forced to return and hits which show you how many times something has tried to call that function while the kill switch was active. Access control is also very blunt. You need capis admin. The patch rejects unknown symbols symbols the k probe layer refuses duplicate engagements and writes from operators without that capability. Every engage and disengage emits a warning line that includes things like the symbol, the return value, hit count, UID, audit log, UID, session ID, and command name. So at least there is an audit trail whenever somebody turns part of the kernel into a stub function. And this kill switch is not limited to commands you run after the server is already booted. There's also a boot time version. An admin can pass something like kill switch function name equals return value as a kernel boot parameter. So the mitigation is applied automatically when the machine starts up. This matters a lot for big server fleets because if you have one machine, manually echoing a command into security FS is fine. But if you're responsible for hundreds or thousands of Linux boxes, you probably want to push the mitigation through your bootloadader config, PXE boot setup or fleet management system. Then you want to reboot the machines in a controlled rollout while the real patch kernel is still being built, tested, and deployed.

[00:05:16]And importantly, if the kill switch boot parameter is malformed, the patch does not just panic the system and brick the boot. It warns about the bad entry, skips it, and keeps on going. So, even though this is a very sharp tool, the boot time version is designed to fail in a way that does not immediately take the whole machine down. The built-in diagnostics are important because this feature changes what the kernel is actually doing while it's still running.

[00:05:43]The first successful engagement sets a new taint bit. Taint kill switch shows as H and that taint persists until reboot even if the function is later disengaged. This is the kernel equivalent of leaving fingerprints at the scene. If the box oops is later, maintainers need to know they are not debugging a clean kernel. They are debugging a runtime where at least one function was forcibly shortcircuited.

[00:06:09]Now, here is the scary part. The patch itself gives examples where the kill switch can make things worse. If you engage AFG count TSGL with return value zero, the caller may allocate a scatter list that is too small and then write past it. If you engage the kill switch on AFG pull tsgl, it'll return void. But if the caller depends on the per request SGL being filled, it'll be left with null pages in the SGL. And the next memc copy sglist step can dreference those null pages and then crash the kernel.

[00:06:44]Now some people wonder what if an attacker gets root and accesses the kernel kill switch and then just disables everything to cause a denial of service attack. Well honestly if a hacker has root on your server, you better hope a denial of service is all they decide to do. If you're running a popular online service and malicious actors can access the private information of your customers, the damage to your business and reputation will be much more severe than it would be if your service just goes down for a little while. The kernel kill switch is basically a nuclear option. It's ugly.

[00:07:18]It may break your applications, but granular shutdown could be better than leaving a known kernel exploit path open. The real risk is that people are going to treat this like a patch when it's obviously not. If your organization kills vulnerable functions to avoid a compromise, you still need to patch, reboot, validate, and remove the kill switch mitigation once a proper fix is available. But tell me what you think.

[00:07:44]Could this help mitigate the threat of malware AI discovered or otherwise? Or do you think it will be an overabuse mitigation that creates more problems than it solves? Let me know your thoughts in the comments below. If you enjoyed this video, please like and share it to hack the algorithm and check out my online store, base.win, where you can buy my awesome merch or accessories for your phone or laptop. 10% storewide discount when you pay with Monero XMR at checkout. Have a great rest of your day.