CVE-2026-105517: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-105517 is a use-after-free (UAF) vulnerability in the 9P protocol implementation of NFS-Ganesha, arising from a race condition between concurrent TWRITE and TCLUNK operations on the same file identifier (FID) object. The vulnerability was reported and confirmed via source code review of NFS-Ganesha V15.6 (with the 9P code identical to V15.2), and was publicly disclosed on October 5, 2026. Because the 9P protocol handler unconditionally returns EOPNOTSUPP for TAUTH, the vulnerability is reachable without any credentials by any client with network access to the 9P listener. It carries a CVSS v3.1 base score of 8.1 (High) (Red Hat CVE, Red Hat Bugzilla).

The root cause is CWE-416 (Use After Free): NFS-Ganesha's 9P implementation performs no per-FID locking, leaving FID object lifetimes unprotected during concurrent request processing. In the TWRITE path (src/Protocols/9P/9p_write.c, lines 100–111), a worker thread reads a pfid pointer from the connection FID table and then performs memcpy(pfid->xattr->xattr_content + offset, attacker_data, size). Concurrently, a TCLUNK worker on the same FID calls _9p_tools_clunk(pfid) → free_fid() (src/Protocols/9P/9p_proto_tools.c, lines 349–350), freeing pfid->xattr and pfid itself, then sets fids[fid] = NULL. Because the TWRITE worker already resolved the pfid pointer before the NULL assignment, it continues writing attacker-controlled network data — with attacker-controlled source, size (set via TXATTRCREATE), and offset — into freed heap memory. The reporter claims demonstrated progression from UAF to instruction-pointer control and end-to-end RCE (Red Hat Bugzilla).

Successful exploitation can result in a server crash (denial of service) or, more critically, remote code execution on the NFS-Ganesha process. Because the attacker controls the memcpy source data, copy size, and target offset into freed heap memory, the vulnerability supports heap exploitation primitives that can lead to full compromise of the NFS-Ganesha server process. Given that NFS-Ganesha typically runs with elevated privileges to serve file system data, a successful RCE could expose sensitive file system contents, allow data manipulation, and serve as a pivot point for lateral movement within the network (Red Hat CVE, Red Hat Bugzilla).

As of the disclosure date, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation. However, the bug report notes that the original reporter claimed successful progression from the UAF primitive to instruction-pointer control and end-to-end RCE, indicating the vulnerability is practically exploitable by a skilled attacker. The attack requires no authentication (TAUTH is unconditionally unsupported), no user interaction, and is reachable over the network, though exploitation requires winning a race condition (High attack complexity). No CISA KEV listing or threat actor attribution has been observed at this time (Red Hat CVE, Red Hat Bugzilla).

1. Reconnaissance: Identify NFS-Ganesha servers with the 9P protocol listener exposed on the network (default TCP port 564). Scan for open ports using tools like nmap -p 564 <target>.
2. Establish 9P connection: Connect to the 9P listener without authentication — TAUTH returns EOPNOTSUPP unconditionally, so no credentials are needed. Use any 9P client library (e.g., py9p, v9fs tools) to establish a session.
3. Walk to a target file and open a FID: Send a TWALK message to obtain a FID for a target file or directory, then open it with TOPEN to prepare for xattr operations.
4. Allocate xattr buffer via TXATTRCREATE: Send a TXATTRCREATE message on the target FID to allocate an xattr buffer of a controlled size. This sets pfid->xattr->xattr_content and determines the heap allocation size used in the subsequent memcpy.
5. Trigger the race condition: Concurrently send a TWRITE request (with attacker-controlled payload data and offset) and a TCLUNK request targeting the same FID. The TCLUNK frees pfid->xattr and pfid while the TWRITE worker continues to memcpy attacker data into the freed memory region.
6. Achieve heap corruption: By winning the race, attacker-controlled data is written into freed heap memory. Repeated attempts can be used to reliably win the race and corrupt heap metadata or function pointers.
7. Escalate to RCE: Leverage heap exploitation techniques (e.g., heap feng shui, tcache poisoning) to redirect execution flow, ultimately achieving remote code execution as the NFS-Ganesha process user (Red Hat Bugzilla).

• Network: Unusual or high-volume concurrent 9P protocol connections (TCP port 564) from a single source IP; rapid sequences of TWRITE and TCLUNK messages targeting the same FID from the same client.
• Logs: NFS-Ganesha crash logs or core dumps with stack traces referencing 9p_write.c, 9p_clunk.c, or 9p_proto_tools.c; segmentation fault or heap corruption errors in /var/log/ganesha/ganesha.log.
• Process: Unexpected termination or restart of the ganesha.nfsd process; unusual child processes spawned by the NFS-Ganesha process.
• File System: Unexpected core dump files (e.g., core.*) in the NFS-Ganesha working directory or /var/crash/; new or modified files in exported file system paths that cannot be attributed to legitimate clients (Red Hat Bugzilla).

A patch has been made available through Red Hat (tracked in Bugzilla bug 2545966); administrators should apply the available fix as the primary remediation. Upstream confirmed the same remediation path as a related TWALK issue — removal of the 9P protocol support from NFS-Ganesha. As immediate workarounds: restrict network access to the 9P listener (TCP port 564) to trusted clients only using firewall rules or network segmentation; or disable the 9P protocol entirely in the NFS-Ganesha configuration if it is not required. Monitor NFS-Ganesha process health for unexpected crashes or restarts as a detection measure (Red Hat CVE, Red Hat Bugzilla).