PT-2026-51884 · Linux · Linux
Published
2026-06-24
·
Updated
2026-06-24
·
CVE-2026-52990
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: fix inode reference leak in fsnotify recalc mask()
fsnotify recalc mask() fails to handle the return value of
fsnotify recalc mask(), which may return an inode pointer that needs
to be released via fsnotify drop object() when the connector's HAS IREF
flag transitions from set to cleared.
This manifests as a hung task with the following call trace:
INFO: task umount:1234 blocked for more than 120 seconds.
Call Trace:
schedule
schedule
fsnotify sb delete
generic shutdown super
kill anon super
cleanup mnt
task work run
do exit
do group exit
The race window that triggers the iref leak:
Thread A (adding mark) Thread B (removing mark)
────────────────────── ────────────────────────
fsnotify add mark locked():
fsnotify add mark list():
spin lock(conn->lock)
add mark B(evictable) to list
spin unlock(conn->lock)
return
/* ---- gap: no lock held ---- */
fsnotify detach mark(mark A):
spin lock(mark A->lock)
clear ATTACHED flag on mark A
spin unlock(mark A->lock)
fsnotify put mark(mark A)fsnotify recalc mask():
spin lock(conn->lock)
fsnotify recalc mask():
/* mark A skipped: ATTACHED cleared /
/ only mark B(evictable) remains /
want iref = false
has iref = true / not yet cleared /
-> HAS IREF transitions true -> false
-> returns inode pointer
spin unlock(conn->lock)
/ BUG: return value discarded!
* iput() and fsnotify put sb watched objects()
* are never called */
Fix this by deferring the transition true -> false of HAS IREF flag from
fsnotify recalc mask() (Thread A) to fsnotify put mark() (thread B).
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux