CVE-2026-52906: Linux Kernel Privilege Escalation Flaw

CVE-2026-52906 Overview

CVE-2026-52906 is a Linux kernel vulnerability in the 9p (Plan 9) filesystem client. The flaw exists in v9fs_apply_options(), which incorrectly combines parsed mount flags with previously set defaults using a bitwise OR (|=) instead of replacing them. As a result, when a user mounts a 9P2000.L share with access=user, both V9FS_ACCESS_CLIENT and V9FS_ACCESS_USER bits remain set. Access mode checks compare against exact values, so neither mode matches. This causes v9fs_fid_lookup() to fall through to the default case and use INVALID_UID (nobody/65534) for all fid lookups, breaking privileged operations such as chown for root.

Critical Impact

Root and other privileged users are unable to perform ownership changes or other privileged filesystem operations on affected 9p mounts, breaking expected access control semantics.

Affected Products

• Linux kernel versions containing commit 1f3e4142c0eb ("9p: convert to the new mount API")
• 9P2000.L filesystem client mounts using the access= option
• Distributions shipping affected stable kernel branches prior to the fix commits

Discovery Timeline

• 2026-06-09 - CVE-2026-52906 published to NVD
• 2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-52906

Vulnerability Analysis

The vulnerability resides in the Linux kernel 9p filesystem client introduced after the conversion to the new mount API. v9fs_session_init() sets V9FS_ACCESS_CLIENT as the default access mode for 9P2000.L sessions. When v9fs_apply_options() later parses user-supplied mount options, it applies parsed flags using |= rather than first clearing the access mask. Mounting with access=user therefore results in both the default V9FS_ACCESS_CLIENT bit and the requested V9FS_ACCESS_USER bit being set simultaneously.

The 9p code performs exact-value comparisons on the access mode field rather than masked tests. With two bits set, none of the defined access modes match. Execution falls through to the default switch case in v9fs_fid_lookup(), which assigns INVALID_UID (65534, the nobody user) to every fid lookup. Operations requiring privilege, such as chown, fail because the kernel no longer associates the operation with the actual current_fsuid().

Root Cause

The root cause is a logic error in how mount options are merged. The function should clear the existing access mask before applying the user's choice. Instead, the OR-assignment preserves stale default bits alongside the new selection, producing an invalid combined value that does not match any defined access mode constant.

Attack Vector

This is a functional regression with security-relevant consequences rather than a remotely exploitable flaw. Any system mounting a 9P2000.L share with an explicit access= option on an affected kernel exhibits the broken behavior. The defect can be reached locally by any user with permission to mount a 9p filesystem and affects authorization decisions for files accessed through that mount.

No verified exploit code is published. The vulnerability mechanism is described in the upstream patch commits referenced in the Kernel Git Commit b8f037e and Kernel Git Commit da2346a.

Detection Methods for CVE-2026-52906

Indicators of Compromise

• Repeated chown, chmod, or other privileged operations failing with EPERM on 9p mounts despite the caller being root.
• File ownership on 9p mounts unexpectedly showing UID/GID 65534 (nobody/nogroup).
• Mount entries showing 9p or 9P2000.L with an explicit access=user, access=any, or access=<uid> option on unpatched kernels.

Detection Strategies

• Inventory running kernels and compare against the fixed commits b8f037e87a08 and da2346a48a5a to identify vulnerable hosts.
• Audit /proc/mounts and mount output for 9p filesystems and capture the active access mode option.
• Correlate filesystem error logs with mount option configuration to spot the INVALID_UID fall-through behavior.

Monitoring Recommendations

• Monitor kernel logs (dmesg, journalctl -k) for 9p-related permission errors after mount configuration changes.
• Track EPERM returns from privileged syscalls against paths under 9p mount points using auditd rules.
• Alert on kernel package updates to confirm that hosts running 9p workloads receive the stable patch.

How to Mitigate CVE-2026-52906

Immediate Actions Required

• Apply the upstream stable kernel updates containing commits b8f037e87a08 and da2346a48a5a as soon as vendor packages are available.
• Identify systems using 9p mounts with non-default access= values and prioritize them for patching.
• Validate that root can perform chown and other privileged operations on 9p mounts after patching.

Patch Information

The fix clears the access mask before applying user-supplied options in v9fs_apply_options(), preventing stale default bits from coexisting with the requested mode. The relevant upstream changes are tracked in the Kernel Git Commit b8f037e and Kernel Git Commit da2346a. Distribution maintainers will backport these commits to supported stable branches.

Workarounds

• Avoid specifying an explicit access= option so the session default applies and the OR-merge does not produce conflicting bits.
• Where 9p is not required, unmount and disable the 9p and 9pnet kernel modules until a patched kernel is deployed.
• Restrict mount privileges so unprivileged users cannot create 9p mounts that rely on the broken access mode handling.

# Identify 9p mounts and their access mode options
grep -E '\s9p\s' /proc/mounts

# Temporarily disable the 9p modules on hosts that do not require them
sudo modprobe -r 9p 9pnet_virtio 9pnet
echo 'blacklist 9p'        | sudo tee /etc/modprobe.d/disable-9p.conf
echo 'blacklist 9pnet'    | sudo tee -a /etc/modprobe.d/disable-9p.conf