nfsd: fix cpntf publish race in nfs4_init_cp_state
21Vexday Risk Score
No sign of exploitation. No public exploitation artifact known so far.
ssvc Trackcvss 7.5epss 0.5%
exploitation probability
0.5%top 58% of all CVEs
observed exploitation
nono source reports it
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.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Affected products
Linux · LinuxReferences
https://git.kernel.org/stable/c/21d6c5957f5ca97d7352e60f55ea412beb9419f5https://git.kernel.org/stable/c/63e18fc65587fd3f7b4c6d70e96d32fc41d82ba3https://git.kernel.org/stable/c/6ac469a274e3c7d87fc46ba46d83b95009680407https://git.kernel.org/stable/c/8eeca993357a0bc35aaefebfd7462ac7b0a21d9ahttps://git.kernel.org/stable/c/a631a26a8777bb235eabd478bbbaf26a4db750bfhttps://git.kernel.org/stable/c/be3a5c1d857b0dcbc11796cea603ef25834f75b2https://git.kernel.org/stable/c/bfeac42d9074e539bacd1898dd8c14b7f5776620https://git.kernel.org/stable/c/c7270f62e7a05a2ee68aa2b74262b658a14463bd