Stop the kernel from auto-loading modules you never asked for

Technical Briefing | 8/9/2026

You probably think your kernel only loads what is strictly necessary to run your hardware. Most of the time that is true, but modprobe and udev are way too eager to help. I have spent hours debugging weird network latency only to find a redundant driver shimmed itself in during a hardware scan. If you are hardening a bare-metal server, you do not want an unused subsystem loading modules just because it saw a specific device class.

Kill the module bloat before it starts

Blacklisting a module in /etc/modprobe.d/ is the standard play, but it has a catch. If something else calls modprobe specifically, the alias can still trigger a load. If you really want to lock down a module like bluetooth or firewire, you have to ensure it is installed to /bin/true so the kernel effectively runs nothing when it tries to initialize the driver.

echo install bluetooth /bin/true | sudo tee /etc/modprobe.d/disable-bluetooth.conf

• Use install instead of blacklist to force the kernel to run a null command
• Check lsmod periodically to see if you have modules with a 0 reference count that keep coming back
• Verify your initramfs doesn’t have the module baked in, or you will be chasing your tail forever

The kernel is an opportunistic beast. If it finds a bus match, it will try to find a driver. By pointing the installer to /bin/true, you are telling the module loader that the job is done without actually executing a single instruction of the driver code. It is a hack, sure, but it is one that stops unnecessary attack surfaces from mounting themselves in the middle of a shift.

Take a look at your loaded modules list after you think you have cleaned it up. If you still see things you do not recognize, trace the load using a kernel event log before you assume the hardware is acting up. Knowing exactly what is running in your ring 0 is half the battle when you are troubleshooting a ghost in the machine.