[Bug 295485] need a way to block zfs.ko from being autoloaded by tools like puppet and facter (FatGID Vuln / CVE-2026-45250)
[email protected] Wed, 27 May 2026 15:49:29 +0000
| Newsgroups | gmane.os.freebsd.devel.file-systems |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295485 --- Comment #27 from Mark Millard <[email protected]> --- (In reply to Dan Mahoney from comment #22) Default Linux based distributions tend to be non-uniform in various ways. When I installed zfs for ubuntu, it was automatically configured to load zfs at boot. So in order to test the commands for list, status, and import (all zpool) to see if they auto-load zfs, I had to first unload zfs first: stop zfs-zed, zfs-import-cache, zfs-mount and then modprobe -r zfs . That got me to the point where nothing showed for: # lsmod | grep zfs # So, finally testing: # zpool import The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. # lsmod | grep zfs # # zpool status The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. # lsmod | grep zfs # # zpool list The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. # lsmod | grep zfs # So none of them caused a automatic load, not that it matters given the automatic load of zfs at boot when installed. Nothing about says what all other linux based distributions might do. All this also points out that openzfs is likely not in control of the behavior in general. Even basic commands like uname are sometimes linux-distribution tailored to be incompatible with each other for various attempts at using its output. (I've run into cross-linux examples in the past.) My guess is that removing zfs core support from puppet (and its variants) when zfs is not to be in use would be far easier to establish than uniformity across all the OS's where zfs can be used. -- You are receiving this mail because: You are the assignee for the bug.