Groups | Search | Server Info | Login | Register

Groups > linux.debian.security > #6504

Questions re: modprobe mitigations and auditing (from: CVE-2026-31431)

Show all headers | View raw

Hello,

After learning about CopyFail (CVE-2026-31431), I understood that the
vulnerability involved Linux kernel-space code that is optional;
sometimes it's included in dynamically-loaded kernel modules,
sometimes it is compiled-in to the kernel binary, and sometimes it is
not available on the host at all.

Because the systems I operate on a daily basis all have the relevant
kernel code included in a dynamically-loadable kernel module (.ko
file), my instinct from outdated knowledge was to add modprobe.d
blacklist entry for them.  I did notice that the vulnerability
disclosure[1] mentioned a slightly different modprobe.d mechanism, but
I felt that the blacklist keyword would work.

What I've learned since then is that the recommended "install
algif_aead /bin/false" mitigation is stronger than the blacklist
keyword.

For example: if I add "install null_blk /bin/false" to
/etc/modprobe.d/nullblk-example.conf and then attempt "sudo modprobe
null_blk", the command fails:

  $ sudo modprobe null_blk
  modprobe: ERROR: Error running install command '/bin/false' for
module null_blk: retcode 1
  modprobe: ERROR: could not insert 'null_blk': Invalid argument

However, replacing the content of that file with "blacklist null_blk"
does not prevent the module from being loaded:

  $ sudo rmmod null_blk
  $ sudo modprobe null_blk
  $ lsmod | grep -w null_blk
null_blk               86016  0
configfs               65536  2 null_blk

It is when adding the '-b' flag that the blacklist entry is consulted:

  $ sudo rmmod null_blk
  $ sudo modprobe --use-blacklist null_blk
  $ lsmod | grep -w null_blk
  $

Some other packages contain /etc/modprobe.d/*.conf files that use the
blacklist keyword instead of the install keyword.

And the Debian wiki documentation mentions both methods:
https://wiki.debian.org/KernelModuleBlacklisting

My questions are:

 - Is one method safer than the other?  And/or are there use-cases for both?
 - Should other packages using the blacklist keyword be audited?

If auditing _would_ be useful, then an apt-file command I've used to
find potentially-affected packages (25 results at the time-of-writing
on my testing/forky machine) is:

  apt-file search -x "^/etc/modprobe.d/.*[.]conf$"

Thanks,
James

[1] - https://www.openwall.com/lists/oss-security/2026/04/29/23

Back to linux.debian.security | Previous | Find similar

Thread

Questions re: modprobe mitigations and auditing (from: CVE-2026-31431) James Addison <jay@jp-hosting.net> - 2026-05-13 13:10 +0200

csiph-web