Bug 2545966 (CVE-2026-105517)

Summary: CVE-2026-105517 nfs-ganesha: nfs-ganesha: 9P TWRITE/TCLUNK race condition use-after-free
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: amctagga, aoconnor, bniver, flucifre, gmeno, groman, mbenjamin, mhackett, sostapov, vereddy
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A use-after-free vulnerability was found in the 9P protocol implementation of NFS-Ganesha. The server does not protect the lifetime of file identifier (FID) objects when processing concurrent requests. An attacker can race a write operation against a close operation on the same FID, causing one worker thread to free the FID and its associated data while another thread continues to use it. This allows attacker-controlled data to be written into freed heap memory, which can result in a crash or potentially remote code execution. The 9P protocol handler does not implement authentication, so the vulnerability is reachable without credentials by any client with network access to the 9P listener.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-05 16:05:48 UTC 
Source code review of nfs-ganesha V15.6 (9P code identical to reported V15.2, zero diff on affected files).

Vulnerability confirmed by code analysis.

Race condition between concurrent 9P workers on the same FID with no per-FID locking:

- TWRITE path (src/Protocols/9P/9p_write.c:80): reads pfid from the connection FID table, then at line 100–111 accesses pfid->xattr and performs memcpy(pfid->xattr->xattr_content + offset, attacker_data, size).
- TCLUNK path (src/Protocols/9P/9p_clunk.c:63–74): reads the same pfid, calls _9p_tools_clunk(pfid) which calls free_fid() (src/Protocols/9P/9p_proto_tools.c:314), freeing pfid->xattr (line 349) and pfid itself (line 350), then sets fids[fid] = NULL (line 74).

A concurrent TWRITE worker that already holds the pfid pointer continues to memcpy attacker-controlled network data through the stale xattr pointer into freed heap memory. The fids[fid] = NULL in TCLUNK does not help — the writer already resolved the pointer. There is zero synchronization on FID lifetime.

Pre-auth: same as the TWALK issue — TAUTH returns EOPNOTSUPP unconditionally, SecType is irrelevant for 9P.

Reporter claims progression from UAF to instruction-pointer control and end-to-end RCE. The code supports this: the attacker controls the memcpy source data (network payload), the copy size (xattr allocation size set via TXATTRCREATE), and the target offset.

Upstream confirmed; same remediation path (9P removal).