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