CVE-2026-79619: OpenZFS: user-namespace capability check allows unprivileged local authorization bypass
Last updated 1 September 2026
Other sources
On Linux, several OpenZFS ioctl authorization checks accept a capability held only within a user-created, unprivileged namespace as equivalent to real host privilege, allowing an unprivileged local user to perform operations that should require root. Affected operations include pool-administrative operations (eg create, import, destroy), pool event log access (zpool events) and fault injection (zinject). Exploiting the problem requires only that the local user is permitted to open /dev/zfs (governed by local device permissions) and that the kernel permits unprivileged user namespace creation. No prior access to the target pool or its underlying devices is needed.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/zfs-linuxto a version that resolves this vulnerability.Fixed in 2.3.9-0+deb13u1Fixed in 2.4.4-1 - Compensating control
Mitigate by preventing unprivileged user namespace creation on Linux (since exploitation requires that the kernel permits unprivileged user namespace creation). Use the appropriate kernel/user namespace hardening controls (e.g., disable unprivileged user namespaces) so the unprivileged namespace capability cannot be used for OpenZFS ioctl authorization bypass.
- Compensating control
Mitigate by ensuring local device permissions do not allow unprivileged users to open /dev/zfs (exploitation requires the local user to be permitted to open /dev/zfs). Restrict /dev/zfs access to trusted users/groups via device permissions/udev rules so non-root users cannot access it.
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Linux systems are exposed when unprivileged users can open /dev/zfs and the kernel allows unprivileged user-namespace creation. The issue does not require the user to already have access to a target ZFS pool or its underlying devices.
What does an attacker need to exploit it?
An attacker needs local unprivileged access, permission to open /dev/zfs under the system's device-permission policy, and the ability to create an unprivileged user namespace. No host-root capability or prior pool access is required.
What can an attacker do after exploiting the authorization bypass?
The affected ioctl checks can authorize operations that should require root, including pool administration such as creating, importing, or destroying pools. They can also access pool event logs through zpool events and perform fault injection with zinject.
What can be done if updating OpenZFS is not immediately possible?
Restrict unprivileged users' access to /dev/zfs and disable or otherwise prevent unprivileged user-namespace creation where operationally feasible. Both conditions are required for exploitation based on the available information.