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.

src/Protocols/9P/9p_walk.c: _9p_walk() reads client-controlled nwname (u16, 0–65535) at line 71 without checking against _9P_MAXWELEM (16, defined in src/include/9p.h:246). The reply loop at line 230 serializes one 13-byte QID per component into a fixed 70,000-byte stack buffer (replydata[_9P_MSG_SIZE], allocated in 9p_interpreter.c:127). At 5,400 components: 9 + (13 * 5400) = 70,209 bytes, overflowing by 209 bytes through the stack canary and saved return address. The bounds check (_9p_checkbound, line 237) runs AFTER the writes — damage precedes the guard.

Pre-auth claim verified: 9P authentication (TAUTH) is not implemented — src/Protocols/9P/9p_auth.c:74 unconditionally returns EOPNOTSUPP. The SecType export config governs NFS auth only; it has no effect on 9P. TATTACH succeeds subject to export/client policy without any preceding auth exchange. This is true regardless of SecType setting.

Upstream confirmed to reporter; planned remediation is removal of the 9P implementation from the next release.

Reproduction attempted in a podman container with ASAN-instrumented build; ASAN caught a SEGV (memory corruption in connection teardown after the PoC ran) but full end-to-end reproduction of the stack overflow requires real root for the VFS FSAL's name_to_handle_at syscall, which rootless podman cannot provide. Code path analysis is conclusive independently.