CVE-2026-63795: Linux Kernel Use-After-Free Vulnerability

CVE-2026-63795 Overview

CVE-2026-63795 is a use-after-free vulnerability in the Linux kernel's 9p (Plan 9 filesystem protocol) client. The flaw resides in the p9_client_walk() function, where the error path incorrectly releases a reference to oldfid when the fid aliases it. Attackers who can trigger a failing multi-component walk split across multiple p9_client_walk() calls can cause a refcount underflow or use-after-free on oldfid. The vulnerability affects Linux kernel builds that mount 9p filesystems, common in virtualization scenarios such as QEMU/KVM guest-host file sharing.

Critical Impact
Exploitation can lead to kernel memory corruption, privilege escalation, or denial of service on systems using 9p filesystem mounts.

Affected Products

Linux kernel (mainline and stable branches prior to the fixing commits)
Distributions shipping vulnerable kernel builds with 9p filesystem support
Virtualization hosts and guests using 9p/VirtFS for file sharing

Discovery Timeline

2026-07-19 - CVE-2026-63795 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63795

Vulnerability Analysis

The vulnerability exists in the 9p client walk logic in the Linux kernel. When p9_client_walk() is invoked with the clone parameter set to false, the newly returned fid aliases the caller-provided oldfid rather than referencing a distinct object. If the walk request succeeds in transmission but the subsequent processing fails, the error path jumps to the clunk_fid label. That label unconditionally calls p9_fid_put(fid), which decrements the reference count on the shared object.

Because ownership of oldfid remains with the caller in the non-cloning case, this extra p9_fid_put() releases a reference the callee never acquired. When this reference was the last one, oldfid is clunked and freed while the caller still holds a pointer to it. Any subsequent dereference or p9_fid_put() on oldfid then operates on freed memory, resulting in a use-after-free condition or a refcount underflow.

Root Cause

The root cause is missing aliasing checks in the clunk_fid error path of p9_client_walk(). The function already guards against double-put in a later error path, but the earlier clunk_fid label lacked the equivalent condition. The fix ensures p9_fid_put(fid) runs only when fid does not alias oldfid, matching the existing guard.

Attack Vector

An attacker capable of driving 9p filesystem operations from user space can trigger the vulnerable path. Multi-component path walks are split into multiple p9_client_walk() calls, and if a later non-cloning walk fails after the request has been sent, the flawed error path executes. In virtualization deployments where a guest mounts a host-shared directory over 9p, malicious activity in the guest can drive the host or guest kernel into the buggy state. Successful exploitation corrupts kernel refcount state, enabling use-after-free primitives that can be leveraged for privilege escalation.

The vulnerability manifests in the p9_client_walk() error handling logic. See the referenced kernel commits for the exact patch content.

Detection Methods for CVE-2026-63795

Indicators of Compromise

Kernel warnings referencing refcount underflow or refcount_t saturation in p9_fid_put or related 9p client symbols
Kernel oops or panic traces originating in net/9p/client.c or fs/9p/
Unexpected disconnects or errors on 9p mounts under sustained multi-component path lookup workloads

Detection Strategies

Monitor kernel logs (dmesg, journalctl -k) for WARNING or BUG messages mentioning p9_client_walk, p9_fid_put, or refcount
Verify running kernel version against the fixing commits 1a3860d4, 6dbe9443, 99c379ca, a61bdcba, a7656d36, and b84f4617 from git.kernel.org
Audit which hosts and guests have 9p filesystem support compiled in and actively mounted

Monitoring Recommendations

Enable CONFIG_DEBUG_LIST and CONFIG_REFCOUNT_FULL-equivalent kernel debug options in test environments to surface refcount anomalies
Ship kernel logs to a centralized SIEM or data lake and alert on 9p-related fault signatures
Track process activity that mounts or interacts with 9p shares, especially in virtualization workloads

How to Mitigate CVE-2026-63795

Immediate Actions Required

Update to a Linux kernel release that includes the upstream fix from the referenced stable commits
Where patching is not immediately feasible, unload or disable the 9p and 9pnet kernel modules on systems that do not require 9p filesystem support
Restrict guest-to-host 9p sharing in virtualization deployments to trusted workloads only

Patch Information

The fix modifies the clunk_fid error path in p9_client_walk() to skip p9_fid_put(fid) when fid aliases oldfid, matching the existing guard in the later error path. Patches are available in the following commits: Linux Kernel Commit #1a3860d, Linux Kernel Commit #6dbe9443, Linux Kernel Commit #99c379ca, Linux Kernel Commit #a61bdcba, Linux Kernel Commit #a7656d36, and Linux Kernel Commit #b84f4617.

Workarounds

Blacklist the 9p and 9pnet modules on hosts where 9p filesystems are not required
Unmount active 9p filesystems and remove them from /etc/fstab until a patched kernel is deployed
In virtualization platforms, replace 9p/VirtFS shares with alternative sharing mechanisms such as virtiofs where practical

bash

# Blacklist 9p kernel modules until a patched kernel is installed
echo "blacklist 9p"    | sudo tee -a /etc/modprobe.d/blacklist-9p.conf
echo "blacklist 9pnet" | sudo tee -a /etc/modprobe.d/blacklist-9p.conf
echo "blacklist 9pnet_virtio" | sudo tee -a /etc/modprobe.d/blacklist-9p.conf
sudo update-initramfs -u