Inspect Loaded Kernel Modules with kmod Without Changing State

Use kmod to see which kernel modules are loaded or which static device nodes the running kernel advertises, without loading or removing anything. This guide uses kmod 31 from Ubuntu package 31+20240202-2ubuntu7.2. Allow about 10 minutes if you only need a check, or 20 minutes if you are documenting the result for a change review.

Before you start

You need a shell on the Linux machine you want to inspect and the kmod package installed. The commands below are read-only and normally need no elevated privileges. Run them on the target host, because the list describes that host's running kernel, not a remote machine or a kernel image stored on disk.

Check the installed program first:

kmod --version

On the tested system the beginning of the output is:

kmod version 31

Checkpoint: confirm what kmod actually does

kmod is a multi-call binary. The top-level command exposes only three useful subcommands in this installed build: help, list and static-nodes. It is not a single command with a general-purpose load or remove action.

The same binary also serves the familiar commands lsmod, modprobe, modinfo, insmod, rmmod and depmod through compatible names. That design is the source of a common distraction: seeing those names in the help output does not mean that kmod list will load a module, or that an arbitrary module command can safely be replaced with kmod.

Read the local help when you need to check the available interface:

kmod --help

Expect output containing:

Commands:
  help         Show this help message
  list         list currently loaded modules
  static-nodes outputs the static-node information installed with the currently running kernel

1. List the modules currently loaded

Run list:

kmod list

The output has a header followed by one row per loaded module. A typical first part looks like this:

Module                  Size  Used by
ip_set_hash_ip         49152  0
macsec                 77824  0
algif_hash             12288  0

The names are module names, not necessarily the names of the packages that supplied them. Size is the module's kernel memory size in bytes in this display. Used by shows the number of current users and, where available, the modules depending on it. Treat this as a snapshot that can change while the system is running.

For a quick check that the command returned module rows, keep the header visible and count the remaining lines:

kmod list | awk 'NR == 1 { print; next } NF { count++ } END { print count " loaded module rows" }'

This pipeline is an ordinary user command. A zero count is not automatically an error: a restricted environment, an unusual kernel, or a point-in-time change can produce a different result. If a module you expected is absent, record the kernel identity and check again before taking action:

uname -r
kmod list

2. Inspect static device-node information

Use static-nodes to print device-node information supplied by modules for the currently running kernel version:

kmod static-nodes

On the tested machine the output begins in this shape:

Module: cuse
	Device node: /dev/cuse
		Type: character device
		Major: 10
		Minor: 203

This is information output, not a request to create every listed node. Do not mistake it for a list of currently loaded modules, and do not paste it into a device-management script without first defining what state the script is meant to enforce.

3. Keep inspection separate from changes

The commands in this guide do not alter module state. Loading and removing modules are separate administrative operations exposed by the compatible tools named in the kmod manual, particularly modprobe and rmmod. They can affect networking, storage, filesystems or other running services, and usually require elevated privileges.

Stop before running a command that loads or removes a module. First identify the exact module, check what depends on it, and confirm that you have console or recovery access. Removing a module from a live system can interrupt the service using it. Loading an untrusted module is a security-sensitive action because kernel code runs with kernel privileges.

For an inspection-only audit, save output to a new file rather than trying to change the machine:

audit_file="/tmp/kmod-audit-$(date +%Y%m%d-%H%M%S).txt"
{
    printf '%s\n' 'Kernel:'
    uname -r
    printf '%s\n' 'Loaded modules:'
    kmod list
    printf '%s\n' 'Static device nodes:'
    kmod static-nodes
} > "$audit_file"
printf 'Wrote %s\n' "$audit_file"

This writes only under /tmp. The file is a snapshot, so remove it after review if it is not needed:

rm -- "$audit_file"

That removal is irreversible for the snapshot. If you need an audit trail, copy it to an approved protected location instead and handle it according to your system's logging policy.

Common traps

• Expecting a load command. kmod itself lists modules and prints static-node information through the documented top-level commands. Use the dedicated compatible tool only after checking the change and its privileges.
• Reading stale output as current state. A module can be loaded or removed after your command finishes. Include uname -r and the capture time when comparing hosts.
• Assuming a module name is a package name. Module names identify kernel components. Package ownership is a separate question and cannot be inferred from the three columns printed by kmod list.
• Running everything with sudo by habit. The read-only checks here do not need it. Reserve elevated privileges for a separately reviewed state change or for a host policy that explicitly requires them.

Done means

• kmod --version confirmed the installed version.
• kmod list produced a current loaded-module snapshot.
• kmod static-nodes produced static device-node information, if the kernel provides any.
• No module was loaded or removed during inspection.
• Any saved audit file has either been protected for review or removed deliberately.