CVE-2026-89691

What it actually does

Failure to reset opcnt after freeing the dynamic ops buffer in nfsd4_release_compoundargs allows the RPC status dump handler to read beyond the 8-element inline iops array into adjacent slab memory when rq_status_counter is odd, resulting in kernel memory disclosure to userspace via netlink.

Why it matters to the business

Local users can obtain sensitive kernel memory contents, increasing the risk of credential theft, privilege escalation, or further kernel attacks on NFS servers; the low EPSS and lack of KEV listing indicate limited in-the-wild exploitation so far, but the 43-day-old disclosure still requires prompt kernel updates on affected systems.

How an attack unfolds

An attacker with local access triggers an NFSv4 compound RPC that causes nfsd_dispatch to take an error path leaving rq_status_counter odd; after the compound args are released with a stale opcnt value, the status dump handler reads min(opcnt,16) entries from the now-freed buffer, leaking up to 8 additional slab objects through the netlink interface.

How to fix it

Upgrade to a Linux kernel containing the fix that unconditionally zeros opcnt in nfsd4_release_compoundargs; apply the stable backports or distribution updates released after 2026-09-11.

How to confirm the fix worked

Confirm the source change that sets args->opcnt = 0 inside nfsd4_release_compoundargs before the buffer free; run kernel selftests for NFSv4 compound argument handling and verify no out-of-bounds reads occur under error-path conditions.

Typical attack path

1. Obtain local shell on an NFS server running the vulnerable kernel
2. Issue a crafted NFSv4.1+ compound request that forces an error path in nfsd_dispatch
3. Trigger the status dump handler while opcnt remains non-zero after buffer release
4. Read disclosed slab memory from the netlink response to gather kernel pointers or data

How to detect it

Inspect kernel audit logs and netlink traffic for unexpected reads from the nfsd status interface after compound RPC errors; look for processes invoking nfsd-related netlink calls with elevated opcnt values.

What your security team should do

• Prioritize kernel updates on all systems exposing NFSv4 services
• Monitor vendor advisories for the exact backported commit
• Restrict local access to NFS servers until patched
• Review netlink and RPC audit logs for unusual status-dump activity