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).