Linux Kernel EUVD-2026-38858

Exploitation requires a local account with at least low-privilege access (CVSS PR:L confirmed). The attacker must be able to create fsnotify watchers on a mounted filesystem - standard inotify_add_watch() or fanotify_mark() API calls available to unprivileged users on most Linux distributions. The race window is the brief interval between fsnotify_add_mark_list() releasing conn->lock and fsnotify_recalc_mask() being invoked in the same thread, during which a concurrent thread calls fsnotify_detach_mark() on a different mark on the same connector. Triggering the race reliably requires multi-threaded workload with deliberate timing; accidental triggering under normal workloads is possible but unlikely. Remote exploitation is not possible (AV:L). No special non-default configuration is required - the vulnerable code path is reached via normal fsnotify usage on any mounted filesystem. Limiting factors: local access required, race timing dependency increases practical difficulty beyond the AC:L CVSS rating, and impact is limited to local DoS with no data exposure.

CVSS 5.5 Medium (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and EPSS at 0.18% (7th percentile) together signal a very low real-world exploitation priority. The vulnerability is not in CISA KEV and no public exploit code has been identified. Practical exploitation requires local access, low privileges, and deliberate race-condition timing - it cannot be triggered remotely and does not yield code execution or data access. The sole impact is availability: a hung task on the umount path, observable as a 120-second block in fsnotify_sb_delete(). The assigned AC:L in the NVD vector is arguably optimistic for a race condition requiring precise thread interleaving; the realistic exploitation complexity is higher than AC:L implies. The 'Information Disclosure' tag in the input is inconsistent with CVSS (C:N) and the description - this discrepancy should be verified with the vendor but does not change the risk posture. For most environments this is a patch-on-next-cycle issue rather than an emergency, unless unmount reliability is operationally critical (e.g., container orchestration environments that frequently unmount volumes).

A local user spawns two threads that simultaneously add and remove fsnotify marks on the same filesystem connector object, deliberately timing the removal to land in the gap between conn->lock release in fsnotify_add_mark_list() and the call to fsnotify_recalc_mask(). This causes __fsnotify_recalc_mask() to return a non-NULL inode pointer that is discarded, leaking the reference. Repeating this accumulates leaked references on the superblock's watched-objects count, causing any subsequent unmount of that filesystem to hang indefinitely in fsnotify_sb_delete() waiting for a reference count that will never reach zero. No public proof-of-concept exists for this scenario.