CVE-2026-89691: nfsd: clear opcnt on compound arg release to prevent OOB read
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clear opcnt on compound arg release to prevent OOB read
nfsd4releasecompoundargs() resets args->ops to the inline iops[8] array when the dynamically-allocated ops buffer is freed, but leaves args->opcnt at its original value (which can be up to 200 for NFSv4.1+ compounds).
If rqstatuscounter is stuck at an odd value (which can happen when nfsddispatch() hits an error path after setting it odd), the RPC status dumpit handler reads min(opcnt, 16) entries from args->ops[]. Since iops only has 8 elements and is the last field in struct nfsd4compoundargs, reading indices 8-15 accesses adjacent slab memory and leaks it to userspace via netlink.
Zero opcnt unconditionally in nfsd4releasecompoundargs() so stale compound metadata is never exposed through the status interface.
[ cel: Remove the kvfreercumightsleep() sleep from the exposure window ]
Affected Software
Event History
Frequently Asked Questions
What conditions are required for memory disclosure to occur?
The affected request must involve an NFSv4.1 or later compound with dynamically allocated operations, and rq_status_counter must remain at an odd value after an nfsd_dispatch() error path. The RPC status dumpit handler must then read the released compound arguments.
What information can be exposed?
The status handler can read entries beyond the eight-element inline operations array, accessing adjacent slab memory. That memory is leaked to userspace through netlink.
Does this affect all NFS compound requests?
No. The out-of-bounds read depends on stale operation-count metadata after the dynamically allocated operations buffer is released, along with the status-counter error condition. The description states that the operation count can be as high as 200 for NFSv4.1 and later compounds.