CVE-2026-90103: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix LAYOUTSTATS send buffer exhaustion
encodelayoutstatsmaxsz budgets XDRQUADLEN(PNFSLAYOUTSTATSMAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that.
fflayoutencodefflayoutupdate() emits, per data server, a netaddr4, an nfsfh4, two ffiolatency4, an nfstime4 and a bool. A data server whose filehandle is NFSMAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ffiolatency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encodelayoutstats() additionally writes the deviceid4 and the layoutupdate4 loutype word, neither of which the macro accounts for.
The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdrreservespace() returns NULL once that happens, and the two fflayoutencodeiolatency() calls run with dssinfo->mirror->lock held, so a NULL return there leaves the lock permanently held.
Raise PNFSLAYOUTSTATSMAXSIZE to 384 so that the record fits inside the reservation.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for exploitation?
A client must use NFSv4.2 pNFS flexfiles layout statistics with a server that supplies sufficiently large filehandle or network-address data through LAYOUTGET and GETDEVICEINFO. The server-controlled values can cause the client’s LAYOUTSTATS encoder to exceed its send-buffer budget.
What is the likely impact on an affected client?
When the encoder exhausts the send buffer, xdr_reserve_space() returns NULL. The affected latency-encoding path can then leave a mirror lock permanently held, which can cause the client to become stuck in that path.
Which systems are realistically exposed?
Linux kernel clients using the NFSv4.2 pNFS flexfiles layout driver are the systems implicated by the described path. The issue is driven by data received from an NFS server, rather than by locally chosen filehandle and address sizes.
How can I determine whether a client may be affected?
Check whether the client mounts or otherwise uses NFSv4.2 with pNFS flexfiles and sends LAYOUTSTATS updates. Review the kernel change associated with the provided stable references to determine whether the send-buffer sizing fix is present.