Blacklisting a kernel module is a five-minute edit under /etc/modprobe.d/, but when a sysadmin creates a tool to automatically blacklist kernel modules across a fleet, the tool is only as safe as your understanding of why each module got flagged. One blind rule can hang a boot target or hide a real intrusion. So read the strace, check dmesg, confirm what the module actually does, and then blacklist. Automation is fine once you know the failure. It is dangerous when it replaces knowing it.

Last updated: 2026-07-21

Done right, blacklisting keeps a system predictable by stopping certain drivers from loading automatically and exposing risky behavior. I have watched admins kill hardware conflicts and close attack paths with a small, repeatable policy. They cut down surprise device behavior and make boots repeatable, which matters for uptime and for audits. The trick is knowing the three ways to stop a module and picking the right one.

What does it mean to blacklist a kernel module?

The Linux kernel is modular by design, so drivers arrive as loadable pieces the system inserts on demand. Two programs run that discovery: udev matches hardware to a driver name, and modprobe loads it. A blacklist rule tells modprobe not to autoload a named module when udev asks for it.

Here is the part people miss. A plain blacklist name line only stops automatic autoloading. It does nothing against a manual modprobe name, and nothing against another module that pulls yours in as a dependency. If you want the module truly dead, you need an install rule that runs /bin/true instead of loading it. And if you just want it gone from the running kernel right now, that is rmmod or modprobe -r, which is a separate job.

So there are three tools, not one:

• blacklist name stops autoload only. Good for hardware conflicts.
• install name /bin/true blocks every insertion path, including dependencies. Use this for security.
• modprobe -r name unloads it live, but it can reload on the next boot or on demand.

Confusing these is the most common mistake I see. People add a blacklist line, reboot, find the module still loaded because a dependency pulled it in, and conclude the whole mechanism is broken. It is not. They used the wrong rule.

How do you manually blacklist a module with modprobe?

Start with an inventory, because guessing the module name wastes an evening. Run lsmod to list active drivers and modinfo name to confirm the exact name, path, dependencies, and parameters. Get this right first. Everything downstream keys off the precise name.

Here is the workflow I use:

1. Test the impact live. Run sudo modprobe -r name. If the module is in use, the command refuses and protects your devices from a sudden drop. That refusal is information, not an error.
2. Write a per-module file. Create /etc/modprobe.d/name.conf. The default location for modprobe configuration files is /etc/modprobe.d/, and a separate file per module keeps changes auditable and easy to revert.
3. Add the rule. For a conflict, blacklist name. To block insertion entirely, install name /bin/true in the same file. Add a comment explaining why, so the next person is not left guessing.
4. Rebuild early boot. Run depmod -ae, then update-initramfs -u (or dracut -f on RHEL-family systems) so the initramfs honors the rule before the root filesystem mounts.
5. Check for overrides. Look in /etc/initramfs-tools/modules and comment out anything that force-loads your module. Remove or fix an old /etc/modprobe.conf that overrides the .d directory.
6. Reboot on a schedule and verify. Run lsmod | grep '^name' after boot. No output means the module stayed out.

Back up any existing file before you overwrite it with echo. The official modprobe.d configuration format documents the exact syntax if you need the edge cases. For a broader refresher, see the guide on what a kernel module actually is.

Why are sysadmins building tools like ModuleJail to automate blacklisting?

The pain is scale plus time pressure. Blacklisting one module by hand is trivial. Doing it on three hundred boxes the same hour a kernel CVE drops, then proving every box actually applied the rule, is not. That gap is what drives a sysadmin to create something like ModuleJail to automatically blacklist kernel modules across a fleet, instead of SSHing into each host at 2 a.m.

A tool like that earns its place by doing the boring, error-prone parts consistently: detect which vulnerable modules are loaded, write the right rule to the right file, rebuild the initramfs, and report back which hosts are clean. When a bad module surfaces, patch lag is the enemy. The vendor fix may be days out, and the module may be your exposed attack surface right now.

What the tool must not do is decide for you. It should surface the evidence, then apply a rule you understood before you approved it. The moment a fleet tool blacklists modules on a rule nobody read, you have traded one slow night for a mystery outage across every host at once. Automate the typing. Do not automate the judgment.

How does an automatic blacklist tool work under the hood?

It walks the same steps you would by hand, just faster and everywhere. First it reads the loaded set from /proc/modules or lsmod and cross-checks names against a list of flagged modules. Then it inspects each candidate with modinfo to catch aliases and dependencies, because a module can hide behind another name.

For each hit it writes a file under /etc/modprobe.d/, chooses blacklist or install /bin/true based on the policy, runs depmod, and regenerates the initramfs with the distro's tool. Good ones verify the result after a reboot rather than trusting that the write succeeded.

The part that separates a real tool from a dangerous one is where its module list comes from. If it trusts a vendor feed blindly, you inherit that feed's mistakes. I want a tool that shows me why a module was flagged, links the advisory, and lets me confirm against the source before it touches a boot path. Read the reasoning, not just the verdict. That is the same rule whether the change comes from a script or from your own hands.

Can you blacklist a kernel module without rebooting?

Yes, for the live kernel, but understand what you are actually doing. sudo modprobe -r name (or rmmod name) unloads the module from the running kernel immediately and shrinks your attack surface right now. That is the fast half of the fix.

It is also the transient half. A live unload does not touch /etc/modprobe.d/, so udev or a dependency can reload the module minutes later, and a reboot brings it right back. The persistent rule and the live unload are two different actions, and you almost always want both: modprobe -r to stop the bleeding, then a config file so it stays gone across reboots.

One gotcha. If the module is in use, rmmod fails, and forcing it with rmmod -f can panic the box. If the refusal blocks you, stop the process or service holding the module first, then unload cleanly. Do not force it just to make the command return zero.

Does automatic blacklisting work the same across distributions?

No, and the difference that bites is the initramfs step, not the blacklist syntax. The blacklist and install lines under /etc/modprobe.d/ read the same everywhere. What changes is the tool that rebuilds early boot.

A fleet tool that hardcodes update-initramfs will silently no-op on a RHEL host, and now your rule looks applied but never made it into the boot image. That is the cross-distro trap. Whatever automates this has to detect the family and call the matching rebuild, then verify. If you manage a mixed fleet, test the tool on one host of each family before you trust its report.

Why does faster vulnerability discovery change your response window?

Because the time between "a kernel bug exists" and "someone is scanning for it" keeps shrinking. Automated fuzzing and AI-assisted analysis surface exploitable module bugs faster than teams can hand-patch a fleet. When the discovery-to-exploit window closes, your reactive process has to close with it.

That is the honest operational case for automation. It is not that scripts are clever. It is that a human patching hosts one at a time is now too slow for the threat cadence, and blacklisting a vulnerable-but-unused module buys you time until the real patch lands. Reducing attack surface fast is a stopgap, and a good one.

Do not let speed talk you out of verification, though. A rushed rule that hangs boot is a self-inflicted outage, which is worse than the CVE you were dodging. Fast response and confirmed response are the same discipline, just done quickly.

Should disabling unused modules be a standing policy?

Yes. Treat unused kernel functionality as attack surface you have not turned off yet. If your fleet never uses dccp, sctp, firewire, or a pile of obscure filesystem drivers, blacklisting them proactively means the next CVE in one of them is a non-event for you.

This is the shift from reactive to standing hardening. Instead of scrambling when an advisory names a module, you have already removed the ones you never needed, and your automated tool only has to handle the genuinely new cases. Fewer loaded modules also means a smaller, more predictable boot, which shows up as fewer weird device surprises and cleaner audits.

Keep the policy documented and reversible. Every blacklist file gets a comment saying why the module is off and who to ask before turning it back on. A hardening policy nobody can explain later becomes the thing that blocks a legitimate driver six months on. For a wider look at trimming what loads, the guide on dynamic module loading covers the mechanics.

What goes wrong when you automate this?

The failure I dread is a boot hang. Blacklist a storage or filesystem module the root device actually needs, rebuild the initramfs, and the next reboot drops to an emergency shell with the root filesystem unmounted. On a remote server with no console, that is a drive-to-the-datacenter night. So before any storage, network, or filesystem module goes on a blacklist, confirm with lsmod and findmnt that nothing in the boot path depends on it.

The quieter failure is masking a real problem. A module misbehaving because an attacker is poking it looks a lot like a module misbehaving because of a driver bug. Blacklist it on autopilot and you may have just hidden the intrusion instead of fixing it. Read dmesg and journalctl -b -p err and understand why the module was flagged before the rule goes in.

A short verification pass catches most of this:

1. After reboot, lsmod | grep '^name' returns nothing.
2. journalctl -b -p err shows no new mount or device failures.
3. The service or hardware you cared about still works.

Skip that pass and your fleet tool is just spraying rules and hoping. If a rule causes a boot failure, the recovery is boot an older kernel or append init=/bin/bash at the GRUB menu, comment out the offending file, and rebuild the initramfs. The related fix for a failed load kernel modules error walks that recovery in detail.

FAQ

How do I find which driver a device is currently using?

Map the device to its driver through sysfs. Look under /sys/class or /sys/bus for the device, then read the driver symlink to get the module name. Cross-check with lspci -k or lsusb -t, which print the kernel driver bound to each device. Once you have the exact name, modinfo confirms its dependencies before you write any rule. The list of loaded kernel modules walks the inspection commands.

What if the module is built into the kernel instead of loadable?

A blacklist rule cannot touch a built-in. If modinfo name shows the module is compiled into the kernel image rather than a separate .ko file, /etc/modprobe.d/ has nothing to act on. Your options are a kernel boot parameter that disables the feature, or a custom kernel build with that option turned off. Check whether the parameter exists before assuming you need to recompile.

Can I roll back a blacklist rule cleanly?

Delete or edit the file under /etc/modprobe.d/, then rebuild the initramfs with your distro's tool and reboot. Because each rule lives in its own commented file, reverting one module does not disturb the others. This is exactly why per-module files beat one giant config: you undo a single change without hunting through a monolith.

Does a fleet tool need root on every host, and is that safe?

Yes, writing to /etc/modprobe.d/ and rebuilding the initramfs both require root. That is a real trust concern, so scope the tool's credentials, log every change it makes, and require human approval before it applies a rule to production. A tool that can silently blacklist modules fleet-wide is powerful in both directions. Treat its access like you would any privileged automation.

Why did my module reload even after I blacklisted it?

Something pulled it in as a dependency, which a plain blacklist line does not stop. Switch that file to install name /bin/true, which blocks manual and dependency-driven insertion. If a specific parent module keeps dragging it back, blacklist the parent too, and check /etc/initramfs-tools/modules for a line that force-loads it at boot.

Related: How Linux Maps Hardware to Kernel Drivers

Related: Ubuntu Modules-Load.d: Autoload Kernel Modules at Boot