Stop modprobe from loading tainted modules behind your back

Technical Briefing | 8/19/2026

You spend all morning debugging a weird interrupt storm, convinced it is a hardware fault or a bad NIC driver. You check the usual suspects in dmesg, but everything looks clean. Then you dig into /proc/modules and see a tiny T flag next to one of your storage drivers. That is the moment you realize the kernel has been running in an unsupported state for days because some out-of-tree binary blob decided to load itself without a proper license header.

Why the T flag matters more than you think

When a module is marked as tainted, the kernel stops making promises about stability. If you hit a kernel panic while a proprietary module is loaded, good luck getting upstream to look at your vmcore. Most sysadmins ignore these flags until a production outage forces them to deal with a blackbox driver that cannot be debugged. You should be auditing these flags before you even think about calling for external support.

awk '$6 ~ /T/ {print $1}' /proc/modules

• The T flag specifically indicates a module was loaded without a GPL-compatible license.
• Check /proc/sys/kernel/tainted to see the decimal mask if you suspect deeper issues.
• Use modinfo to inspect the license field of any module that looks suspicious on your stack.

Taking control of your module loading behavior

If you are running hardware that forces these modules, document it in your runbooks immediately. But if you find modules loading that have no business being on your servers, stop them at the source by blacklisting them in /etc/modprobe.d. It is much easier to explain to a manager why a non-essential driver was blocked than to explain why your kernel oops dump is effectively useless for root-cause analysis.

Next time you feel like you are chasing ghosts in the logs, start by verifying exactly what code is actually running in kernel space. A quick check of the taint mask often clears up why the kernel is behaving erratically.