CVE-2026-63795 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
9p: avoid putting oldfid in p9_client_walk() error path
When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally.
This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow.
Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below.
This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability described represents a critical use-after-free condition in the Linux kernel's 9p file system implementation that stems from improper reference counting management during error handling paths. This flaw exists within the p9_client_walk() function where fid aliasing creates a scenario that can lead to premature resource deallocation while caller code still maintains references to the freed memory structures. The issue specifically manifests when clone parameter is set to false, causing fid to become an alias of oldfid, which then creates confusion in the error handling mechanism that lacks proper conditional logic for reference management.
The technical implementation flaw occurs in the error path of the 9p protocol handler where the clunk_fid function unconditionally calls p9_fid_put(fid) regardless of whether the fid parameter represents a cloned reference or the original oldfid. This fundamental mismanagement of reference counting creates a race condition between the kernel's cleanup operations and the caller's expected resource state. When multiple components in a walk operation are split into separate p9_client_walk() calls, and subsequent non-cloning walks fail, the system enters an inconsistent state where the reference counter for oldfid is decremented prematurely, potentially leading to immediate memory corruption or delayed crashes.
The operational impact of this vulnerability extends beyond simple memory corruption as it represents a potential attack vector for privilege escalation or system instability. The flaw can be triggered through specific 9p protocol sequences involving multi-component walks that are split across multiple function calls, making it particularly concerning in networked environments where 9p file systems are actively used. Security researchers should note this vulnerability's alignment with CWE-415 and CWE-416 categories related to double free conditions and use-after-free errors, while the ATT&CK framework would classify this under privilege escalation techniques through kernel memory corruption.
Mitigation strategies should focus on implementing proper conditional reference counting in the error paths of 9p protocol handling functions. The fix requires modifying the clunk_fid error path to only decrement reference counts for fid when it does not alias oldfid, effectively creating a guard mechanism that prevents premature deallocation. System administrators should ensure kernel updates are applied promptly, particularly in environments where 9p file systems are deployed and where network-based file access is common. Regular monitoring for reference count warnings and memory corruption indicators should be implemented as part of security operations procedures to detect potential exploitation attempts.