You spend hours hardening a server, stripping out unused packages and disabling non-essential services. Then you run lsmod and find a dozen drivers for hardware that does not exist on your physical or virtual chassis. It is the kernel autoloading mechanism at work, helpfully loading modules based on aliases it thinks you need. That is not helpful; it is a security risk and an unnecessary memory tax.

Why kmod loves to over-deliver

When the kernel detects a device or a request for a protocol, it fires off a request to userspace via netlink, which kmod catches. If there is a match in /lib/modules/$(uname -r)/modules.alias, it loads the module. This is great for desktops, but in a production environment, you should know exactly what modules your system needs. You would not let a random user run code, so why let the kernel load whatever driver it finds convenient?

echo 'install usb-storage /bin/true' > /etc/modprobe.d/disable-usb-storage.conf

• The install directive effectively tells modprobe to run /bin/true instead of loading the module
• It persists through updates, unlike just rmmod which comes back on reboot
• You can blacklist modules too, but install is safer because it catches dependency-based loads

Cleaning up the mess you already have

Before you start nuking things, check what is actually being used by looking at the third column of lsmod. If you see a zero there, nothing is currently referencing that module. Go through your dmesg output to ensure you are not disabling something the hardware actually needs for basic operation. I once accidentally disabled a virtual network driver on a cloud instance and had to fix it via a serial console; do not make that mistake.

If you are managing hundreds of nodes, do not try to maintain a giant blacklist file by hand. Build a baseline module profile for your hardware tier and automate the deployment of these config files. Keep your kernel lean, and you will have fewer weird driver bugs to hunt down when things go sideways at 3 AM.