CVE-2026-89663: nfsd: revoke copy-notify stateids before dropping their reference

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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 s2s_cp_stateids IDR and on their parent
stid's sc_cp_list, pinned by a single membership reference.
_free_cpntf_state_locked() only unlinks an entry once its refcount reaches
zero, so any revoke path that runs while a concurrent
find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count 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 nfs4_put_cpntf_state().

This affected all three revoke paths:

  - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called
    _free_cpntf_state_locked() on the first list entry; a holder that had
    bumped cs_count made it return early, so the next iteration
    re-decremented and burned the holder's reference.

  - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise
    used _free_cpntf_state_locked() and could drop 2->1 without unlinking.

Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and
sc_cp_list first (deferring the final free to any holder), and use it from
all three revoke paths. The drain now walks with list_for_each_entry_safe()
and revokes each entry unconditionally, so it terminates in one pass per
entry regardless of cs_count. The unhash is gated on
!list_empty(&cps->cp_list); the idr_remove() gate matters because
idr_alloc_cyclic() may have recycled the so_id by then. Keep
_free_cpntf_state_locked() for the reference-holder put path only, where a
concurrent revoke may already have unlinked the entry (its list_del_init()
then a no-op).

The Linux kernel CVE team has assigned CVE-2026-89663 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.6 with commit 624322f1adc58acd0b69f77a6ddc764207e97241 and fixed in 6.12.109 with commit 6b8149448cdcb476fba4559d1ecc247efee9971b
	Issue introduced in 5.6 with commit 624322f1adc58acd0b69f77a6ddc764207e97241 and fixed in 6.18.50 with commit b56d2c5f01cddbeca7d11cce81d97db4ec9a464f
	Issue introduced in 5.6 with commit 624322f1adc58acd0b69f77a6ddc764207e97241 and fixed in 7.2.4 with commit ff8a3cff02b92b2a82f1a9876038fcf953ae9c25
	Issue introduced in 5.6 with commit 624322f1adc58acd0b69f77a6ddc764207e97241 and fixed in 7.3-rc1 with commit 3b0c3595db99bb4bebd7c8aa8a36f3c50e411bb7

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89663
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/nfsd/nfs4state.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/6b8149448cdcb476fba4559d1ecc247efee9971b
	https://git.kernel.org/stable/c/b56d2c5f01cddbeca7d11cce81d97db4ec9a464f
	https://git.kernel.org/stable/c/ff8a3cff02b92b2a82f1a9876038fcf953ae9c25
	https://git.kernel.org/stable/c/3b0c3595db99bb4bebd7c8aa8a36f3c50e411bb7