USN-8705-2: OpenZFS ioctl Authorization Bypass on Ubuntu 18.04/20.04 LTS — Patching and Detection Guide

Canonical has issued USN-8705-2, extending the OpenZFS security fix originally shipped in USN-8705-1 to Ubuntu 18.04 LTS and Ubuntu 20.04 LTS systems. The underlying flaw is an authorization bypass in OpenZFS's handling of certain ioctl operations on Linux: OpenZFS fails to correctly perform authorization checks, which means a local attacker — any unprivileged user with shell access — can potentially execute pool-administrative operations or access privileged information without holding the required permissions.

This is the class of vulnerability I take seriously on any multi-tenant or shared system. ZFS administration is supposed to be gated behind root or carefully-scoped delegated permissions. A bug that lets a regular user manipulate pools, snapshots, or datasets — or read data they shouldn't — collapses that trust boundary entirely. If you are running ZFS-backed storage on Ubuntu 18.04 or 20.04 (file servers, backup targets, LXD/LXC container hosts, build servers, CI runners), this applies to you, and the correct answer is to patch and then verify no one got there first.

Technical Analysis

Affected Products and Platforms

• OpenZFS (zfsutils-linux and related zfs-linux source packages) as shipped on:
  • Ubuntu 18.04 LTS (Bionic) — ESM-supported
  • Ubuntu 20.04 LTS (Focal)
  • Earlier releases were covered under the original USN-8705-1 update; USN-8705-2 is the corresponding fix for these two LTS branches.
• Any local user context can reach the vulnerable code path — exploitation requires local access (a shell, a compromised service account, a container with ZFS device exposure, or an SSH session), not root.

How the Vulnerability Works (Defender's View)

ZFS on Linux exposes its administrative interface through the /dev/zfs character device. Userland tools like zfs and zpool — and any other process that can open that device node — communicate with the kernel module via ioctls. Each ioctl is supposed to be accompanied by an authorization check: does the calling user hold root, or a delegated ZFS permission (via zfs allow), appropriate to the requested operation?

The flaw is that certain ioctl operations skip or incorrectly perform those authorization checks. The practical consequences:

1. Pool-administrative operations without privilege — an unprivileged user could potentially perform operations that should require root or explicit delegation: dataset manipulation, snapshot operations, property changes, or other pool-state mutations.
2. Privileged information disclosure — ioctls that return pool or dataset metadata could leak information about data the user has no business seeing.

The attack chain from an incident-response perspective is simple and that is what makes it dangerous: any local foothold = potential storage-layer control. A compromised web service account, a CI job running as a build user, or a low-privilege SSH user on a shared host becomes a path to the storage layer. On hosts where ZFS holds backups, snapshots are both an availability target (delete snapshots before ransomware detonation) and a confidentiality target (read delegated/restricted datasets).

Exploitation Status

• No public in-the-wild exploitation has been confirmed in connection with this USN at time of writing, and it is not listed in the CISA Known Exploited Vulnerabilities catalog.
• The advisory does not assign a CVE identifier in the notice text; track it via USN-8705-1 / USN-8705-2.
• Treat it as exploitable-by-design: local authorization bypasses in storage tooling have a long history of being folded into privilege-escalation chains once PoCs circulate. Ubuntu 18.04/20.04 fleets still in service (often under ESM) are exactly the kind of long-tail infrastructure where attackers hunt for local privesc.

Detection & Response

Detection here is about watching who touches the ZFS administrative interface. On a healthy system, zfs and zpool invocations come from root, from a small set of admin accounts, or from automation (cron, systemd units, backup tooling). Any execution by a service account (www-data, nobody, build users, container runtimes users) or unexpected invocation of pool-mutating subcommands deserves scrutiny. Also monitor for unexpected access to /dev/zfs by processes that are not the standard ZFS tooling.

Sigma Rules

---
title: ZFS Pool Administrative Operations by Non-Privileged User
id: 3f8a1c92-7d4e-4b6a-9f21-8c5d2e6a7b01
status: experimental
description: Detects execution of zfs or zpool administrative/mutating subcommands by users other than root or known admin accounts. May indicate exploitation of the OpenZFS ioctl authorization bypass (USN-8705-2) or post-compromise storage tampering.
references:
  - https://ubuntu.com/security/notices/USN-8705-2
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/zfs'
      - '/zpool'
  selection_cmd:
    CommandLine|contains:
      - 'destroy'
      - 'create'
      - 'snapshot'
      - 'rollback'
      - 'set '
      - 'allow'
      - 'unallow'
      - 'export'
      - 'import'
      - 'scrub'
      - 'send'
      - 'receive'
  filter_root:
    User:
      - 'root'
  condition: selection_img and selection_cmd and not filter_root
falsepositives:
  - Delegated ZFS administration via zfs allow for backup operators
  - Automated snapshot tooling running under service accounts
level: high
---
title: Suspicious Access to ZFS Control Device by Non-ZFS Process
id: 91c4e7a2-5b3f-4d68-a1c9-2e7f8b4d6c03
status: experimental
description: Detects processes other than standard ZFS tooling opening the /dev/zfs control device, which may indicate direct ioctl abuse exploiting the OpenZFS authorization bypass (USN-8705-2).
references:
  - https://ubuntu.com/security/notices/USN-8705-2
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename: '/dev/zfs'
  filter_legit:
    Image|endswith:
      - '/zfs'
      - '/zpool'
      - '/zpool.d/'
      - '/zed'
      - '/mount.zfs'
      - '/zdb'
      - '/zstream'
  condition: selection and not filter_legit
falsepositives:
  - Custom storage management agents or monitoring tooling that queries ZFS state
  - Container runtime or virtualization tooling with legitimate ZFS integration
level: medium

KQL (Microsoft Sentinel via Syslog/CEF Ingestion)

If your Ubuntu hosts forward syslog (or auditd/execve telemetry via the Azure Monitor agent or a CEF forwarder) into Sentinel, this query surfaces non-root ZFS administrative activity — the highest-signal behavioral indicator for this flaw:

// Hunt for ZFS pool-administrative commands executed by non-root users
// Relevant to OpenZFS ioctl authorization bypass (USN-8705-2)
let ZfsAdminCommands = dynamic(["destroy", "create", "snapshot", "rollback", " allow", "unallow", "export", "import", "scrub", " send ", " receive", " set "]);
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName in ("zfs", "zpool")
    or SyslogMessage has_any ("/sbin/zfs", "/sbin/zpool", "/usr/sbin/zfs", "/usr/sbin/zpool")
| where SyslogMessage has_any (ZfsAdminCommands)
| extend CommandLine = extract(@"(?i)(zpool|zfs)\s+[^;]*", 0, SyslogMessage)
| extend ExecutingUser = tostring(coalesce(column_ifexists("ProcessID", ""), ""))
| project TimeGenerated, Computer, HostIP, ProcessName, CommandLine, SyslogMessage, SeverityLevel
| order by TimeGenerated desc

If you ingest Linux auditd logs into LinuxAuditLog or CommonSecurityLog, pivot the same logic on the a0/exe fields for zfs/zpool with a non-root auid. Investigate any hits where the executing context is a service account, build user, or unknown interactive user — especially destroy, send, or set operations, which map to data destruction, exfiltration, and permission manipulation respectively.

Velociraptor VQL

For fleet-wide hunting on Ubuntu hosts, this artifact identifies currently running or recently spawned ZFS administrative processes by non-root users, plus which processes have the ZFS control device open:

-- Hunt for non-root ZFS administrative activity and unexpected /dev/zfs handles
-- Relevant to OpenZFS ioctl authorization bypass (USN-8705-2)
LET procs = SELECT Pid, Ppid, Name, Username, CommandLine, Exe, CreateTime
FROM pslist()
WHERE Name =~ '^(zfs|zpool)$'
   OR CommandLine =~ '(zfs|zpool)\s+(destroy|create|snapshot|rollback|allow|unallow|export|import|scrub|send|receive|set)'

SELECT Pid,
       Ppid,
       Name,
       Username,
       CommandLine,
       Exe,
       CreateTime,
       if(condition=Username != 'root', then='SUSPICIOUS - non-root ZFS admin op', else='Review') AS Assessment
FROM procs

Pair this with a glob-based check for ZFS tooling in unexpected locations (attackers sometimes drop static zfs binaries) and an audit of recent shell history for unprivileged users who touched ZFS commands:

-- Identify ZFS binaries outside standard paths and recent zfs/zpool usage in shell histories
SELECT FullPath, Size, Mtime
FROM glob(globs=['/usr/sbin/zfs', '/usr/sbin/zpool', '/sbin/zfs', '/sbin/zpool',
                 '/tmp/**/zfs', '/tmp/**/zpool', '/var/tmp/**/z*', '/home/*/**/zpool', '/dev/shm/**'])
WHERE FullPath !~ '^/(usr/)?sbin/'
   OR FullPath =~ '(tmp|shm|home)'

Any ZFS binary living in /tmp, /dev/shm, or a user home directory is a strong indicator of hands-on-keyboard activity.

Remediation / Verification Script

Run this on Ubuntu 18.04/20.04 hosts to verify patch state, apply the USN-8705-2 fix, and baseline who has been touching ZFS:

#!/usr/bin/env bash
# USN-8705-2 verification and remediation for Ubuntu 18.04/20.04 LTS
set -euo pipefail

echo "=== [1] Identify release ==="
. /etc/os-release
echo "Release: ${VERSION_ID} (${VERSION_CODENAME})"

echo "=== [2] Current installed ZFS package versions ==="
dpkg -l | grep -E 'zfsutils-linux|libzfs[0-9]+linux|libzpool[0-9]+linux|zfs-zed' || echo "No ZFS packages installed - host not affected."

echo "=== [3] Check for pending security updates ==="
apt-get update -qq
apt list --upgradable 2>/dev/null | grep -i zfs || echo "No pending ZFS updates (either patched or not installed)."

echo "=== [4] Apply the USN-8705-2 fix ==="
DEBIAN_FRONTEND=noninteractive apt-get install --only-upgrade -y zfsutils-linux libzfs2linux libzpool2linux zfs-zed 2>/dev/null \
  || DEBIAN_FRONTEND=noninteractive apt-get install --only-upgrade -y zfsutils-linux zfs-zed

echo "=== [5] Confirm USN-8705-2 status (requires ubuntu-security-tools or manual check) ==="
echo "Verify against: https://ubuntu.com/security/notices/USN-8705-2"
dpkg -l | grep zfsutils-linux

echo "=== [6] NOTE: The zfs kernel module must be reloaded or the host rebooted ==="
lsmod | grep '^zfs' && echo "zfs module loaded - schedule reboot or: systemctl stop zfs-zed zfs-share zfs-mount; modprobe -r zfs; modprobe zfs"

echo "=== [7] Hunt: non-root ZFS admin activity in auth/audit logs ==="
grep -E 'sudo.*(zfs|zpool)' /var/log/auth.log* 2>/dev/null | grep -v 'root' | tail -n 20 || echo "No suspicious sudo ZFS usage found."
ausearch -m execve -ts recent 2>/dev/null | grep -E '(zfs|zpool)' | grep -v 'auid=0' | tail -n 20 || true

echo "=== [8] Baseline delegated ZFS permissions (zfs allow) ==="
for pool in $(zpool list -H -o name 2>/dev/null); do
  echo "--- Pool: ${pool} ---"
  zfs allow "${pool}" 2>/dev/null || true
done

echo "=== Done. Reboot or reload the zfs module to complete remediation. ==="

Step 8 matters more than it looks: if an attacker abused this bypass to grant themselves delegated permissions (zfs allow) as a persistence mechanism, patching alone won't remove that access. Audit and revoke any delegation entries you don't recognize with zfs unallow.

Remediation

1. Patch immediately. Apply the USN-8705-2 updates via apt-get update && apt-get upgrade (or --only-upgrade the ZFS packages as in the script above) on all Ubuntu 18.04 LTS and 20.04 LTS systems with zfsutils-linux installed. For 18.04, note that security fixes require an active Ubuntu Pro / ESM subscription — if you're still on 18.04 without ESM, you are not receiving this fix at all, and that is the bigger problem.
2. Reload the kernel module or reboot. The vulnerable code lives in the kernel-space ZFS module. A userspace package upgrade does not protect you until the zfs module is reloaded or the host reboots. Plan maintenance windows accordingly — do not assume apt upgrade closed the hole.
3. Verify against the official advisories:
   • https://ubuntu.com/security/notices/USN-8705-2
   • https://ubuntu.com/security/notices/USN-8705-1
4. Hunt before and after patching. Review auth logs, auditd execve records, and shell histories for non-root zfs/zpool usage in the weeks prior to patching. Pay special attention to zfs destroy (snapshot deletion — a pre-ransomware move), zfs send (data staging/exfiltration), and zfs allow (persistence via delegation).
5. Reduce the attack surface going forward:
   • Restrict who can open /dev/zfs (default permissions are root-only, but verify — ls -l /dev/zfs — especially on hosts with custom udev rules or container device passthrough).
   • Do not pass /dev/zfs into containers unless strictly required; a container escape plus this bug is a full storage-layer compromise.
   • Audit zfs allow delegations quarterly and after any IR engagement.
6. Plan the upgrade off 18.04/20.04. Both releases are deep into or past standard support. This USN is a reminder that long-tail LTS fleets accumulate exactly the local-privesc debt that turns a minor web bug into a full breach. Prioritize migration to 22.04/24.04 LTS in your 2026 roadmap.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub