How to Blacklist a Kernel Module as a Stopgap Mitigation Without Breaking Production

When CISA gave federal agencies until 21 September 2026 to remediate three Linux kernel flaws, Red Hat's published mitigations for two of them (CVE-2025-39682 in kernel TLS and CVE-2025-39964 in the AF_ALG crypto interface) were the same: stop the affected module from loading. That is the standard kernel stopgap, and it is a good one, provided you understand what you are switching off. This guide walks through the mechanism, the decision, and the verification, in that order.

Why a blacklist works as a mitigation

The Linux kernel is modular. Large parts of the networking, filesystem and crypto stacks are compiled as loadable modules that the kernel pulls in on demand the first time something asks for them. A socket created with an unusual address family, a filesystem mount of a rare type, or a netfilter rule referencing a target the kernel has not seen yet will all trigger a module load.

That on-demand behaviour is what makes a blacklist effective. If the vulnerable code lives in a module that is not loaded, the vulnerable code is not in memory and cannot be reached, no matter how the attacker tries to trigger it. It is also what makes a naive blacklist ineffective: a module listed as "blacklisted" in the traditional sense is only excluded from automatic loading at boot, and can still be pulled in later by a request that names it. The approach that closes that gap is to tell the module loader to run a harmless command in place of loading the module at all.

SentinelOne's analysis of the third bug in the same KEV batch, CVE-2026-53266 in the ebtables SNAT target, gives the pattern for the `ebt_snat` module:

``` echo 'install ebt_snat /bin/true' | sudo tee /etc/modprobe.d/disable-ebt_snat.conf ```

The `install` directive replaces the module's load action with the command that follows, so any attempt to load it succeeds silently while loading nothing. The same shape applies to the `tls` and `af_alg` modules named in Red Hat's mitigations; substitute the module name in both the directive and the filename. Red Hat documents the general procedure in its knowledge base article on blacklisting kernel modules, which is the reference its CVE pages point to.

Decide what breaks before you break it

A module-level mitigation is a functional change to the host, not a configuration tweak. Before you apply one, answer three questions.

**What depends on this module?** For the KEV batch that prompted this guide, the answers differ sharply. Blocking `tls` disables kernel TLS, so any service using kTLS for zero-copy sends or NIC offload falls back to userspace crypto or fails, depending on how it was configured. Blocking `af_alg` removes the userspace interface to the kernel's crypto API, which some crypto libraries, VPN daemons and disk-encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. tooling use when it is available. Blocking `ebt_snat` removes source-address rewriting on bridged Ethernet frames, which matters on virtualisation hosts and container networks that use ebtables. Our explainer on how kernel TLS moves encryption into the kernel and what that exposes covers the first case in depth.

**Is the module currently loaded?** If it is already resident, adding an `install` line does not unload it. You need to remove it explicitly or reboot, and if it is in use by an open socket or an active rule you may not be able to remove it without stopping the consumer first. On a host that is already going to reboot for the kernel update, the honest answer is often that the blacklist is pointless: reboot into the fixed kernel instead.

**Is the exposure real on this host?** Red Hat's statement on CVE-2025-39682 is a model of precision: the bug "only affects systems with kernel TLS (CONFIG_TLS) enabled and the TLS ULP attached to TCP sockets." A host where the module exists but nothing attaches it is exposed only to a local attacker who attaches it themselves. That is still a local privilege escalationPrivilege Escalation🛡️An attack technique where an adversary gains elevated access rights beyond what was initially granted., which is why the KEV entry exists, but it changes whether the mitigation is worth the disruption on a single-tenant server versus a shared build host.

Apply it in a way you can reverse

Put each mitigation in its own file under the `modprobe.d` directory with a name that says what it does and why. A file called `disable-ebt_snat.conf` containing one line is easy to audit and easy to delete. Folding it into an existing distribution-managed file is neither.

Record the mitigation wherever you track compensating controls, with the CVE it addresses and the condition for removal. Module blacklists have a way of surviving for years after the kernel that needed them is gone, quietly disabling a feature someone later spends a week trying to enable.

If your initramfs includes the module (common for storage and crypto modules), rebuild it after adding the file. The exact procedure depends on your distribution; the point is that a `modprobe.d` change that is not reflected in the early boot image may not apply until later in boot, if at all.

Verify

After applying the mitigation and either unloading the module or rebooting, confirm three things: the module is absent from the loaded-module list, an attempt to load it by name returns without loading it, and the services you identified in the dependency step are either still working or have failed in the way you planned for. Check the kernel log for messages from the affected subsystem. If a service silently fell back to a slower code path, that is acceptable; if it silently dropped TLS or encryption altogether, it is not, and you need to know today.

Know when to stop

A blacklist buys time. It does not fix the bug, it does not help if the module is compiled into the kernel rather than loaded, and it does not address the other two thirds of a three-CVE batch. The end state is always the fixed kernel and a reboot. If you find yourself planning to keep a module disabled indefinitely instead of scheduling that reboot, the problem is not the module. It is the maintenance window, and our piece on why the three-day KEV deadline changes how you plan kernel reboots is about exactly that.

One more thing worth internalising from this batch: the mitigation for the ebtables bug is not a module blacklist at all in Red Hat's version, but a rule change, disabling ARP hardware-address rewriting in ebtables SNAT rules. Not every kernel bug maps to a module, and not every module maps to a single feature. Read the vendor's mitigation text for each CVE rather than assuming the same lever works for all of them.