CVE-2026-63795

What it actually does

This is a Linux kernel use-after-free/refcount handling flaw in the 9p filesystem client. In p9_client_walk(), when a non-cloning walk fails after the request has been sent, the error path can incorrectly drop a reference to oldfid even though the caller still owns and may later use it. If that was the last reference, the fid can be clunked and freed prematurely, leading to later use-after-free, refcount underflow, kernel memory corruption, crash, or potentially code execution in kernel context depending on exploitability and hardening.

Why it matters to the business

Systems that use the Linux 9p filesystem client, including some virtualization, container, embedded, and shared-folder deployments, may be exposed to kernel crashes or compromise if they interact with a malicious or faulty 9p server or if an attacker can trigger crafted 9p path-walk failures through an exposed mount. Although the CVSS is critical, current public exploit maturity is listed as none, EPSS is low, and it is not currently in CISA KEV; organizations should still prioritize remediation where 9p is enabled because successful exploitation affects kernel availability and potentially host integrity/confidentiality.

How an attack unfolds

An attacker first needs a path to influence 9p filesystem operations, most plausibly by controlling or impersonating a 9p server used by a Linux client, or by being able to cause operations against an already mounted 9p filesystem. The attacker causes a multi-component path walk to be split across multiple p9_client_walk() calls, then induces a later non-cloning walk failure after the request is sent. The vulnerable error path incorrectly releases the aliased fid/oldfid reference. If the reference count reaches zero, the kernel destroys the fid while caller code still believes it is valid. Subsequent use or release of that stale fid can trigger refcount underflow, use-after-free, memory corruption, or a kernel panic. No known public exploitation is indicated in the supplied data, but a reliable exploit could turn a remotely influenced filesystem protocol error into denial of service and possibly kernel-level compromise.

How to fix it

Apply the vendor-supplied Linux kernel update that contains the 9p client fix preventing p9_client_walk() from putting an aliased oldfid in the clunk_fid error path. No exact fixed kernel versions were provided in the input, so track the relevant distribution advisories and package changelogs for backports of the 9p/p9_client_walk fix. Where immediate patching is not possible, reduce exposure by disabling or unloading 9p/v9fs support where unused, unmounting 9p filesystems, avoiding untrusted 9p servers, blocking unauthenticated network access to 9p services such as TCP port 564 where applicable, and restricting the ability to create mounts to trusted administrators. In virtualized environments, review shared-folder features that rely on 9p and disable them if not required until patched kernels are deployed.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix, not merely that an installed package is updated; reboot into the corrected kernel and verify with uname, package manager metadata, and vendor advisory/changelog references for the 9p p9_client_walk fix. Check whether 9p exposure exists by reviewing loaded modules, mounted filesystems, and kernel configuration for 9p/v9fs support. Validate mitigation by confirming no active 9p mounts remain where they are not required and that 9p network listeners or allowed outbound paths to untrusted servers are blocked. For high-assurance validation, run vendor regression tests or a controlled reproducer only in a non-production lab and confirm that refcount warnings, KASAN use-after-free reports, or kernel panics no longer occur.

Typical attack path

1. Identify Linux systems using the 9p/v9fs client, such as virtual machine shared folders, remote 9p mounts, or container/embedded integrations.
2. Gain control of, intercept, or emulate a 9p server that a vulnerable client will mount or access, or obtain the ability to trigger filesystem operations on an existing 9p mount.
3. Cause a multi-component path walk that results in multiple p9_client_walk() calls.
4. Return or induce a failure during a later non-cloning walk after the request has been sent.
5. Trigger the vulnerable error path that incorrectly drops the caller-owned oldfid reference.
6. Cause subsequent operations on the stale fid to produce refcount underflow, use-after-free, kernel crash, or potentially controlled memory corruption.

How to detect it

Review kernel logs and persistent journal data for signs of 9p/v9fs failures followed by refcount anomalies, use-after-free reports, kernel oopses, panics, or KASAN/KFENCE findings. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore records, hypervisor console logs, and EDR telemetry that records kernel crashes. Correlate events with 9p mount activity, access to multi-component paths on 9p mounts, unexpected disconnects or errors from 9p servers, and network sessions involving 9p transports such as TCP port 564 where used. Also inspect /proc/mounts or historical configuration management data for 9p mounts active at the time of the crash. There are no universally reliable network payload IOCs from the supplied data; detection should focus on kernel fault artifacts and anomalous 9p server interactions.

• p9_client_walk
• p9_fid_put
• clunk_fid
• 9pnet
• v9fs
• 9p:
• refcount_t: underflow
• refcount_t: addition on 0
• refcount_t: decrement hit 0
• KASAN: use-after-free
• KFENCE: use-after-free
• BUG: KASAN
• kernel BUG at
• general protection fault
• Oops:
• Kernel panic - not syncing
• /proc/mounts
• type 9p
• tcp/564

What your security team should do

• Prioritize patching Linux systems that use 9p/v9fs, especially virtualization hosts/guests, development sandboxes, container platforms, embedded systems, and environments using 9p shared folders or remote 9p mounts.
• Inventory active 9p usage by searching mounts, loaded modules, kernel configs, and network paths to 9p servers.
• Temporarily disable 9p/v9fs or remove unneeded 9p mounts where operationally feasible until patched kernels are running.
• Restrict access to trusted 9p servers only; block or monitor TCP port 564 and other configured 9p transports at network boundaries.
• Reboot after kernel updates and verify the fixed kernel is active on all affected systems.
• Increase monitoring for kernel refcount, KASAN, use-after-free, v9fs, and 9p-related errors that may indicate attempted triggering or instability.
• Because current exploit maturity is listed as none and it is not KEV, balance emergency response against actual 9p exposure, but treat exposed 9p deployments as high priority due to kernel-level impact.