Bug 2502233 (CVE-2026-53394) - CVE-2026-53394 kernel: nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race
Summary: CVE-2026-53394 kernel: nfsd: avoid leaking pre-allocated openowner on unconfi...
Keywords:
Status: NEW
Alias: CVE-2026-53394
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-19 13:03 UTC by OSIDB Bzimport
Modified: 2026-07-20 14:00 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-19 13:03:10 UTC
In the Linux kernel, the following vulnerability has been resolved:

nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race

When find_or_alloc_open_stateowner() encounters an unconfirmed owner, it
calls release_openowner() and sets oo = NULL. Control then falls through
past the `if (oo)` guard -- which would have freed any pre-allocated
`new` -- and unconditionally executes `new = alloc_stateowner(...)`. If
`new` was already allocated on a prior iteration, the pointer is
silently overwritten and the previous allocation (slab object + owner
name buffer) is leaked.

This requires a race: two NFSv4.0 OPEN threads with the same owner
string, where a concurrent thread inserts a new unconfirmed owner into
the hash between retry iterations. The window is narrow but repeatable
under adversarial conditions.

Fix by adding `goto retry` after `oo = NULL` so the already-allocated
`new` is reused on the next iteration rather than overwritten.


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