131

Under certain conditions, the Linux kernel may become tainted. For example, loading a proprietary video driver into the kernel taints the kernel. This condition may be visible in system logs, kernel error messages (oops and panics), and through tools such as lsmod, and remains until the system is rebooted.

What does this mean? Does it affect my ability to use the system, and how might it affect my support options?

8
  • possible duplicate of lsmod outputs: Not tainted Mar 4, 2014 at 23:51
  • 1
    I'm hoping to make this the canonical version of the question; see the most recent edit to the question.
    – bwDraco
    Mar 5, 2014 at 0:06
  • 15
    @MichaelMrozek: 1) I didn't see the existing question, since it wasn't obvious that the user was asking "what does 'tainted' mean", and 2) the question as worded is rather specific to a single command, lsmod. I wrote this question and answer to make it more general so that someone asking "what does 'tainted' mean" can find it easily.
    – bwDraco
    Mar 5, 2014 at 0:26
  • 1
    They could have used a word that was a bit more neutral than "tainted".
    – Roger Dahl
    Nov 10, 2018 at 18:08
  • 1
    @RogerDahl using a more neutral word would have missed the point they are trying to make. The statement is not neutral. Sep 9, 2023 at 15:06

2 Answers 2

164

A tainted kernel is one that is in an unsupported state because it cannot be guaranteed to function correctly. Most kernel developers will ignore bug reports involving tainted kernels, and community members may ask that you correct the tainting condition before they can proceed with diagnosing problems related to the kernel. In addition, some debugging functionality and API calls may be disabled when the kernel is tainted.

The taint state is indicated by a series of flags which represent the various reasons a kernel cannot be trusted to work properly. The most common reason for the kernel to become tainted is loading a proprietary graphics driver from NVIDIA or AMD, in which case it is generally safe to ignore the condition. However, some scenarios that cause the kernel to become tainted may be indicative of more serious problems such as failing hardware. It is a good idea to examine system logs and the specific taint flags set to determine the underlying cause of the issue.

This feature is intended to identify conditions which may make it difficult to properly troubleshoot a kernel problem. For example, a proprietary driver can cause problems that cannot be debugged reliably because its source code is not available and its effects cannot be determined. Likewise, if a serious kernel or hardware error had previously occurred, the integrity of the kernel space may have been compromised, meaning that any subsequent debug messages generated by the kernel may not be reliable.

Note that correcting the tainting condition alone does not remove the taint state because doing so does not change the fact that the kernel can no longer be relied on to work correctly or produce accurate debugging information. The system must be restarted to clear the taint flags.

More information is available in the Linux kernel documentation, including what each taint flag means and how to troubleshoot a tainted kernel prior to reporting bugs.

A partial list of conditions that can result in the kernel being tainted follows, each with their own flags. Note that some Linux vendors, such as SUSE, add additional taint flags to indicate conditions such as loading a module that is supported by a third party rather than directly by the vendor.

  • Loading a proprietary (or non-GPL-compatible) kernel module. As noted above, this is the most common reason for the kernel to become tainted.
  • The use of staging drivers, which are part of the kernel source code but are experimental and not fully tested.
  • The use of out-of-tree modules that are not included with the Linux kernel source code.
  • Forcibly loading or unloading modules. This can happen if one is trying to use a module that is not built for the current version of the kernel. (The Linux kernel module ABI is not stable across versions, or even differently-configured builds of the same version.)
  • Running a kernel on certain hardware configurations that are specifically not supported, such as an SMP (multiprocessor) kernel on early AMD Athlon processors not supporting SMP operation.
  • Overriding the ACPI DSDT in the kernel. This is sometimes needed to correct for firmware power-management bugs; see this Arch Linux wiki article for details.
  • Certain critical error conditions, such as machine check exceptions and kernel oopses.
  • Certain serious bugs in the BIOS, UEFI, or other system firmware which the kernel must work around.
3
  • 1
    This answer is missing a lot of information from the dup this question displaced.
    – user56041
    Jun 3, 2018 at 15:51
  • 4
    I would add at least one important possibility of the "unsigned module" scenario -- a kernel rootkit was loaded into the kernel or kernel exploit was just executed.
    – kravietz
    Dec 8, 2018 at 22:47
  • I've overhauled the answer in a series of edits to make it more accurate and easier to read, and have removed the unnecessary list of taint flags (readers can simply click through the kernel documentation link).
    – bwDraco
    Jan 8, 2022 at 2:24
3

Loading a proprietary or non-GPL-compatible module or unsigned module will set a 'taint' flag in the running kernel.

To check the kernel tainted state in kernel logs:

journalctl -k | grep taint

To check the kernel tainted state at runtime:

cat /proc/sys/kernel/tainted      // if 0 then kernel is not tainted, else it is.

The returned value is a bit field; you can find the bit meanings in this table.

In a kernel panic message, look for a line starting with ‘CPU:’

‘Not tainted:’ if the kernel was not tainted at the time of the kp event; if it was, then it will print ‘Tainted:’.

Reference: The Linux Kernel documentation on tainted kernels.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .