Bug 2535158 (CVE-2026-90036) - CVE-2026-90036 kernel: NFSD: Prevent client use-after-free during blocked-lock reaping
Summary: CVE-2026-90036 kernel: NFSD: Prevent client use-after-free during blocked-loc...
Keywords:
Status: NEW
Alias: CVE-2026-90036
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-16 11:03 UTC by OSIDB Bzimport
Modified: 2026-10-14 23:23 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:83156 0 None None None 2026-10-14 21:23:13 UTC
Red Hat Product Errata RHSA-2026:83157 0 None None None 2026-10-14 21:10:11 UTC
Red Hat Product Errata RHSA-2026:83159 0 None None None 2026-10-14 21:11:47 UTC
Red Hat Product Errata RHSA-2026:83207 0 None None None 2026-10-14 23:23:18 UTC

Description OSIDB Bzimport 2026-09-16 11:03:46 UTC
In the Linux kernel, the following vulnerability has been resolved:

NFSD: Prevent client use-after-free during blocked-lock reaping

A bare lock owner -- its only remaining reference a blocked lock on
nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but
no reference keeping the client alive. When the per-net laundromat
reaps such a lock, freeing the nbl drops the owner reference
held through flc_owner, and the final nfs4_put_stateowner()
takes the client's cl_lock. Because the laundromat detaches the
nbl first, __destroy_client() no longer finds it, so a concurrent
force_expire_client() can free the client before nfs4_put_stateowner()
runs, dereferencing cl_lock in freed memory.

Pin the client with cl_rpc_users before dropping
nn->blocked_locks_lock, and skip clients already expiring, whose
blocked locks __destroy_client() frees while holding an owner
reference. Take nn->client_lock outside nn->blocked_locks_lock.
Every other site holds nn->blocked_locks_lock as a leaf, acquiring
no further lock, so placing nn->client_lock outside it cannot form
a lock-order cycle.

Comment 7 Jon Orris 2026-10-14 21:10:10 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:83157 https://access.redhat.com/errata/RHSA-2026:83157

Comment 8 Jon Orris 2026-10-14 21:11:44 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:83159 https://access.redhat.com/errata/RHSA-2026:83159

Comment 9 Jon Orris 2026-10-14 21:23:11 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:83156 https://access.redhat.com/errata/RHSA-2026:83156

Comment 10 Jon Orris 2026-10-14 23:23:16 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:83207 https://access.redhat.com/errata/RHSA-2026:83207


Note You need to log in before you can comment on or make changes to this bug.