[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] Sun, 21 Jun 2026 04:06:13 +0000
Newsgroups gmane.os.freebsd.devel.file-systems
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295485

--- Comment #32 from Mark Millard <[email protected]> ---
(In reply to Mark Millard from comment #31)

Turns out (as I reported upstream):

QUOTE
I see that there is both:
```
/usr/src/sys/contrib/openzfs/lib/libzfs/libzfs_util.c:  zpool_feature_init();
and:
/usr/src/sys/contrib/openzfs/module/zfs/spa_misc.c:     zpool_feature_init();
```
So it appears that libzfs_util.c has the zpool feature information without the
module being loaded. zpool_main.c looks to put the libzfs_util.c related
information to use. The module has its own copy, not used by `zpool upgrade
-v`.

The "legacy versions" text from `zpool upgrade -v` is explicit (via gettext
use), also not from zfs.ko .

zfs_main.c has explicit text (via gettext use) for its `zfs upgrade -v` output.

So it seems that the 2 "upgrade -v" commands end up with the zfs.ko loaded just
by overall program structure and it is not really used by them.

That still leaves the question of if a restructuring to allow those 2 "limiting
condition" commands to specially avoid the zfs.ko load related code involvement
from the overall code structure is appropriate/reasonable.

At least now it appears that the correct context has been identified for the
original issue: `zpool status` and `zfs list` were not involved.
END QUOTE

-- 
You are receiving this mail because:
You are the assignee for the bug.