CVE-2026-89700: nfsd: validate sockaddr length per family in listener_set
In the Linux kernel, the following vulnerability has been resolved:
nfsd: validate sockaddr length per family in listenerset
nfsdsocknlpolicy declares NFSDASOCKADDR as a bare NLABINARY attribute with no minimum length. A CAPNETADMIN caller can send a 16-byte NFSDASOCKADDR with safamily=AFINET6, causing a 12-byte OOB read across three consumers (rpccmpaddrport, svcfindlistener, kernelbind).
nfsdnllistenersetdoit() also parsed and validated each listener entry inline in two separate loops, interleaved with mutating the running listener configuration. The validation was duplicated, used an open-coded "nlalen < sizeof(struct sockaddr)" check that was too short for AFINET6, and handled a malformed entry inconsistently depending on which loop noticed it.
Add an nfsdnlvalidatelisteners() helper that walks the entire list once and confirms each entry parses, carries both an address and a transport name, and is long enough for its address family (sizeof(struct sockaddrin) for AFINET, sizeof(struct sockaddrin6) for AFINET6, -EAFNOSUPPORT otherwise). Call it before taking nfsdmutex or creating the serv, so a malformed request fails cleanly with no side effects.
Since every entry is known valid by the time the two existing loops run, drop the redundant presence and per-family length checks from both, leaving only the nlaparsenested() call needed to extract the data.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the vulnerable code path?
An attacker needs CAP_NET_ADMIN and must be able to submit an nfsd listener-set request containing the NFSD_A_SOCK_ADDR attribute. The issue is therefore limited to contexts where that capability is available.
What malformed input causes the out-of-bounds read?
A 16-byte socket-address attribute that declares sa_family as AF_INET6 is too short for an IPv6 sockaddr. This can cause a 12-byte out-of-bounds read in rpc_cmp_addr_port, svc_find_listener, and kernel_bind.
What happens to malformed listener requests after the fix?
Listener entries are validated before nfsd_mutex is taken or the service is created. Each entry must parse successfully, include both an address and transport name, and have a family-appropriate address length; unsupported families fail with -EAFNOSUPPORT.