Bug 2545962 (CVE-2026-105516)

Summary: CVE-2026-105516 nfs-ganesha: nfs-ganesha: 9P TWALK component count stack buffer overflow
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
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 stack buffer overflow vulnerability was found in the 9P protocol implementation of NFS-Ganesha. The server does not validate the number of path components in a TWALK request against the protocol-defined limit of 16. An attacker can send a specially crafted TWALK message with thousands of path components, causing the server to write past the end of a fixed-size stack buffer during response construction. This 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:03:31 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.

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.