CVE-2026-89684

In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix cpntf publish race in nfs4 init cp state

nfs4 alloc init cpntf state() published the new cpntf entry into the s2s cp stateids IDR (with cs type set) in one s2s cp lock section, then took the lock again to list add() it onto p stid->sc cp list. In the gap the entry is reachable by so id but cp list is still {NULL,NULL} from kzalloc. A racing OFFLOAD CANCEL (so id is echoed to the client as cnr stateid, so any NFSv4.2 client can drive it) reaches manage cpntf state() -> free cpntf state locked() and does list del() on the zeroed list head, oopsing the server.

Fold the cs type assignment and the list add() into the same critical section as idr alloc cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp list. INIT LIST HEAD() the entry after allocation and switch free cpntf state locked() to list del init() so a stale unlink is a no-op. nfs4 init copy state() passes NULL p stid and skips the list add, preserving NFS4 COPY STID semantics.