CVE-2026-79619: OpenZFS Privilege Escalation Vulnerability

CVE-2026-79619 Overview

CVE-2026-79619 is an authorization flaw [CWE-863] in OpenZFS on Linux. Several ioctl authorization checks in the ZFS kernel module accept a capability held only inside a user-created, unprivileged namespace as equivalent to real host root privilege. An unprivileged local user can perform pool-administrative operations such as create, import, and destroy, access the pool event log through zpool events, and trigger fault injection via zinject. Exploitation requires the ability to open /dev/zfs and a kernel that allows unprivileged user namespace creation. No prior access to the target pool or its underlying devices is required.

Critical Impact
A local unprivileged user can execute root-only ZFS pool administration operations, leading to data destruction, pool tampering, and host integrity loss.

Affected Products

OpenZFS on Linux prior to zfs-2.2.11
OpenZFS on Linux prior to zfs-2.3.9
OpenZFS on Linux prior to zfs-2.4.4

Discovery Timeline

2026-08-26 - CVE-2026-79619 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-79619

Vulnerability Analysis

OpenZFS exposes privileged administrative functionality through ioctl calls on the /dev/zfs character device. Multiple handlers verify caller privilege using capability checks that do not distinguish between capabilities held in the initial (host) user namespace and capabilities held within an unprivileged, user-created namespace. Linux allows unprivileged users to create user namespaces where they gain a full capability set inside that namespace. When the ZFS handlers evaluate these capabilities without pinning the check to init_user_ns, an unprivileged caller appears authorized for operations that must require true host root.

The affected surface includes pool lifecycle operations (zfs_ioc_pool_create, zfs_ioc_pool_import, zfs_ioc_pool_destroy), event log retrieval used by zpool events, and the zinject fault-injection interface. The result is a local privilege escalation against ZFS-managed storage.

Root Cause

The root cause is incorrect authorization [CWE-863]. Capability checks in several zfs_ioc_* handlers do not confirm that the required capability is held in the initial user namespace. Any user who can open /dev/zfs and create a namespace grants themselves the required capability inside it, and the check accepts it as equivalent to host privilege.

Attack Vector

The attack requires local access. The attacker must have permission to open /dev/zfs under the current device permission model, and the kernel must permit unprivileged user namespace creation (kernel.unprivileged_userns_clone=1 on distributions that expose the toggle). The attacker creates a new user namespace, acquires the necessary capabilities inside it, then issues ioctl calls to /dev/zfs. No credentials for the target pool and no access to the underlying block devices are needed.

See the OpenZFS Security Advisory GHSA-mhf5-q8gw-qg9v and the remediation pull request #18959 for the code-level fix, which anchors capability checks to the initial user namespace.

Detection Methods for CVE-2026-79619

Indicators of Compromise

Unexpected zpool events or new pool creation, import, or destruction actions attributable to non-root users.
Process ancestry showing an unprivileged user invoking zpool, zfs, or zinject binaries after calling unshare or clone with CLONE_NEWUSER.
open() on /dev/zfs followed by ioctl traffic from a UID that does not typically administer storage.

Detection Strategies

Audit execve events for zpool, zfs, and zinject where the effective UID is non-zero on the host but the caller has entered a user namespace.
Monitor openat syscalls targeting /dev/zfs and correlate with prior unshare -U or namespace-creation activity in the same process tree.
Alert on ZFS Event Daemon (zed) log entries recording pool state changes without a corresponding change-management ticket.

Monitoring Recommendations

Forward /var/log/zfs/zpool.d/ and zed logs to a centralized log platform for baseline deviation analysis.
Enable Linux auditd rules on /dev/zfs access and on the unshare, clone, and setns syscalls with the CLONE_NEWUSER flag.
Track kernel module versions across the fleet to identify hosts still running vulnerable OpenZFS builds.

How to Mitigate CVE-2026-79619

Immediate Actions Required

Upgrade OpenZFS to zfs-2.2.11, zfs-2.3.9, or zfs-2.4.4 or later, depending on the release branch in use.
Restrict access to /dev/zfs so that only trusted administrative accounts and groups can open the device.
Disable unprivileged user namespace creation on hosts that do not require it, using sysctl kernel.unprivileged_userns_clone=0 where supported.

Patch Information

Fixed releases are available from the OpenZFS project: zfs-2.2.11, zfs-2.3.9, and zfs-2.4.4. The corrective changes land in pull request #18959, which pins the affected capability checks to the initial user namespace. Apply the update matching your current OpenZFS branch and reload the kernel module or reboot to activate the fix.

Workarounds

Tighten permissions on /dev/zfs so it is not accessible to non-administrative users or groups.
Set kernel.unprivileged_userns_clone=0 on distributions that expose this toggle to block the prerequisite namespace creation.
Where supported, apply seccomp or AppArmor profiles that deny unshare(CLONE_NEWUSER) for interactive user sessions.

bash

# Configuration example
# Restrict /dev/zfs to root and the storage admin group
sudo chown root:zfsadmin /dev/zfs
sudo chmod 660 /dev/zfs

# Disable unprivileged user namespace creation (where supported)
echo 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-disable-userns.conf
sudo sysctl --system

# Verify installed OpenZFS version
modinfo zfs | grep -E '^version:'