31.5. Blacklisting a Module

download PDF
Sometimes, for various performance or security reasons, it is necessary to prevent the system from using a certain kernel module. This can be achieved by module blacklisting, which is a mechanism used by the modprobe utility to ensure that the kernel cannot automatically load certain modules, or that the modules cannot be loaded at all. This is useful in certain situations, such as when using a certain module poses a security risk to your system, or when the module controls the same hardware or service as another module, and loading both modules would cause the system, or its component, to become unstable or non-operational.
To blacklist a module, you have to add the following line to the specified configuration file in the /etc/modprobe.d/ directory as root:
blacklist <module_name>
where <module_name> is the name of the module being blacklisted.
You can modify the /etc/modprobe.d/blacklist.conf file that already exists on the system by default. However, the preferred method is to create a separate configuration file, /etc/modprobe.d/<module_name>.conf, that will contain settings specific only to the given kernel module.

Example 31.4. An example of /etc/modprobe.d/blacklist.conf

# Listing a module here prevents the hotplug scripts from loading it.
# Usually that'd be so that some other driver will bind it instead,
# no matter which driver happens to get probed first.  Sometimes user
# mode tools can also control driver binding.
# Syntax: see modprobe.conf(5).

# watchdog drivers
blacklist i8xx_tco

# framebuffer drivers
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist i810fb
blacklist cirrusfb
blacklist intelfb
blacklist kyrofb
blacklist i2c-matroxfb
blacklist hgafb
blacklist nvidiafb
blacklist rivafb
blacklist savagefb
blacklist sstfb
blacklist neofb
blacklist tridentfb
blacklist tdfxfb
blacklist virgefb
blacklist vga16fb
blacklist viafb

# ISDN - see bugs 154799, 159068
blacklist hisax
blacklist hisax_fcpcipnp

# sound drivers
blacklist snd-pcsp

# I/O dynamic configuration support for s390x (bz #563228)
blacklist chsc_sch
The blacklist <module_name> command, however, does not prevent the module from being loaded manually, or from being loaded as a dependency for another kernel module that is not blacklisted. To ensure that a module cannot be loaded on the system at all, modify the specified configuration file in the /etc/modprobe.d/ directory as root with the following line:
install <module_name> /bin/true
where <module_name> is the name of the blacklisted module.

Example 31.5. Using module blacklisting as a temporary problem solution

Let's say that a flaw in the Linux kernel's PPP over L2TP module (pppol2pt) has been found, and this flaw could be misused to compromise your system. If your system does not require the pppol2pt module to function, you can follow this procedure to blacklist pppol2pt completely until this problem is fixed:
  1. Verify whether pppol2pt is currently loaded in the kernel by running the following command:
    ~]# lsmod | grep ^pppol2tp && echo "The module is loaded" || echo "The module is not loaded"
  2. If the module is loaded, you need to unload it and all its dependencies to prevent its possible misuse. See Section 31.4, “Unloading a Module” for instructions on how to safely unload it.
  3. Run the following command to ensure that pppol2pt cannot be loaded to the kernel:
    ~]# echo "install pppol2tp /bin/true" > /etc/modprobe.d/pppol2tp.conf
    Note that this command overwrites the content of the /etc/modprobe.d/pppol2tp.conf file if it already exists on your system. Check and back up your existing pppol2tp.conf before running this command. Also, if you were unable to unload the module, you have to reboot the system for this command to take effect.
After the problem with the pppol2pt module has been properly fixed, you can delete the /etc/modprobe.d/pppol2tp.conf file or restore its previous content, which will allow your system to load the pppol2pt module with its original configuration.


Before blacklisting a kernel module, always ensure that the module is not vital for your current system configuration to function properly. Improper blacklisting of a key kernel module can result in an unstable or non-operational system.
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.