[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.