CVE-2026-89663: nfsd: revoke copy-notify stateids before dropping their reference
In the Linux kernel, the following vulnerability has been resolved:
nfsd: revoke copy-notify stateids before dropping their reference
Copy-notify stateids live in the s2scpstateids IDR and on their parent stid's sccplist, pinned by a single membership reference. freecpntfstatelocked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent findcpntfstate()/managecpntfstate() holder has elevated cscount drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4putcpntfstate().
This affected all three revoke paths:
- The parent-stid drain (nfs4freecpntfstatelist()) repeatedly called freecpntfstatelocked() on the first list entry; a holder that had bumped cscount made it return early, so the next iteration re-decremented and burned the holder's reference.
- OFFLOADCANCEL (managecpntfstate()) and laundromat expiry likewise used freecpntfstatelocked() and could drop 2->1 without unlinking.
Add revokecpntfstatelocked(), which unhashes the entry from the IDR and sccplist first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with listforeachentrysafe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cscount. The unhash is gated on !listempty(&cps->cplist); the idrremove() gate matters because idralloccyclic() may have recycled the soid by then. Keep freecpntfstatelocked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its listdelinit() then a no-op).
Event History
Frequently Asked Questions
What conditions are required for the use-after-free to occur?
The issue requires concurrent handling of a copy-notify stateid: a reader in find_cpntf_state() or manage_cpntf_state() must hold an elevated cs_count while a revoke path drops its membership reference. A later revoke operation or laundromat expiry can then free the stateid before the reader calls nfs4_put_cpntf_state().
Which operations can trigger the unsafe revoke behavior?
The affected revoke paths are parent-stid draining through nfs4_free_cpntf_statelist(), OFFLOAD_CANCEL handling in manage_cpntf_state(), and laundromat expiry. Each could use _free_cpntf_state_locked() in a way that consumed a reference without unlinking the still-discoverable entry.
How might this issue be detected during testing or investigation?
The described failure is a KASAN-detectable use-after-free at a reader's nfs4_put_cpntf_state(). Investigation should focus on concurrent copy-notify stateid lookup or management together with revocation, OFFLOAD_CANCEL activity, parent stateid cleanup, or laundromat expiration.