Skip to content

Back to the catalog

dfir.chwriteup

Tainted Kernels

A DFIR-focused walkthrough on Linux kernel taint flags, explaining how loading out-of-tree or unsigned kernel modules (e.g. via insmod) marks the kernel as tainted, and how to investigate this using dmesg, /proc/sys/kernel/tainted, the kernel-chktaint script, /proc/modules, lsmod, modinfo, journalctl, and /proc/kallsyms. The author demonstrates the process with a custom test module (dfir.ko) and notes the practical limits of tracing a tainting module back to its origin, recommending bash history, filesystem searches for .ko files, and auditd as complementary artifacts.

TL;DR Walkthrough of Linux kernel taint flags and the DFIR commands (dmesg, kernel-chktaint, modinfo, kallsyms) used to detect and investigate unsigned/out-of-tree kernel modules that may signal malicious activity.
Open original ↗
Document

What it is

A DFIR walkthrough of how to detect and investigate a tainted Linux kernel — a kernel marked as running in a non-standard state after loading an unsigned or out-of-tree module. It works a concrete example: a custom module named dfir loaded via insmod, which tainted the kernel with a value of 12288.

How it works

Taint state lives in /proc/sys/kernel/tainted as a bitmask; 0 means untainted. The example value 12288 decodes to two flags: bit #12 (externally-built / out-of-tree module) and bit #13 (unsigned module). dmesg records the tainting event with the module name at load time; /proc/modules marks out-of-tree modules with the (OE) tag.

What to do

Search the message buffer — this is the only method here that yields the module's name:

dmesg | grep taint

Find out-of-tree modules by their OE tag:

cat /proc/modules | grep OE

Read and decode the raw taint value:

cat /proc/sys/kernel/tainted

Decode it with the kernel script (ships in linux-tools/kernel-tools, or fetch it):

wget https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/tools/debugging/kernel-chktaint
chmod +x kernel-chktaint
./kernel-chktaint

List loaded modules and pull detailed metadata (filename, license, signer, vermagic):

lsmod | grep dfir
modinfo x_tables

Caveats

The page states its own key limitations, worth knowing before you rely on any single method:

  • kernel-chktaint, /proc/sys/kernel/tainted, and /proc/modules tell you a module tainted the kernel but not which one — only dmesg or the journal give the module name.
  • lsmod confirms a module is loaded but provides no further detail.
  • A tainted kernel is not necessarily malicious: proprietary device drivers, unsupported modules, licence mismatches, and even kernel Oops/panics all taint the kernel. Treat it as an indicator to investigate, not a verdict.
flowchart TD
  A[tainted != 0] --> B{need module name?}
  B -->|yes| C[dmesg / journal grep taint]
  B -->|no, just reasons| D[kernel-chktaint decodes flags]
  C --> E{taint malicious?}
  D --> E
  E -->|maybe| F[modinfo: license, signer, path]
  E -->|proprietary driver / Oops| G[benign]

Technologies named here

Techniques named here

  • Loading an out-of-tree/unsigned kernel module
  • Kernel taint flag inspection

Related in Blue Team & Detection