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
