CVE-2026-52990

What it actually does

This is a Linux kernel race condition in the fsnotify subsystem. During concurrent mark addition and removal, fsnotify_recalc_mask() can trigger a transition where an inode reference should be dropped, but the returned inode pointer is discarded and the reference is leaked. The leaked reference can prevent filesystem shutdown paths from completing, leading to hung tasks during unmount or teardown operations. The impact is denial of service or operational instability, not code execution or privilege escalation based on the available description.

Why it matters to the business

Affected Linux systems may experience stuck unmount operations, blocked shutdown or container/runtime cleanup, lingering mounts, and degraded host reliability. In production environments this can delay maintenance, node recycling, workload migration, storage cleanup, or incident recovery. The issue is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so broad active exploitation is not currently indicated; however, kernel stability defects can still be operationally significant on heavily automated or multi-tenant Linux platforms.

How an attack unfolds

An attacker with local ability to exercise fsnotify functionality, such as creating and removing filesystem notification marks through inotify or fanotify-style interfaces, attempts to win a race between adding an evictable mark and detaching another mark on the same watched object. If the timing is successful, the connector's HAS_IREF state transitions from set to cleared while fsnotify_recalc_mask() discards the inode pointer that should have been released. The resulting inode reference leak can keep watched filesystem objects pinned. When the system later attempts to unmount or tear down the associated superblock, the shutdown path can block, producing hung task reports involving fsnotify_sb_delete() and generic_shutdown_super(). Repetition could be used to create persistent resource leakage or denial-of-service conditions. There is no indication from the provided metadata that this flaw is remotely exploitable or used by known threat actors.

How to fix it

Apply the vendor kernel update that includes the upstream fix for the fsnotify inode reference leak. Because no affected product list or exact fixed versions were provided, use the Linux distribution or appliance vendor advisory for the authoritative fixed kernel package. Prefer a full reboot into the corrected kernel after installation; live patching should only be considered fixed if the vendor explicitly states this fsnotify change is covered. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting container or workload capabilities where feasible, monitoring systems that allow untrusted users to create large numbers of filesystem watches, and scheduling controlled reboots for hosts showing hung unmount behavior. Mitigations are risk-reduction only; the durable fix is a kernel update.

How to confirm the fix worked

Confirm the running kernel includes the fsnotify fix, not merely that an updated package is installed. Validate using the distribution's package tools, kernel build changelog, or vendor advisory mapping for this CVE, then verify the active kernel with uname -a after reboot. Operationally, check that unmount, container teardown, namespace cleanup, and shutdown paths complete normally under workloads that use inotify or fanotify. Review kernel logs for absence of new hung task traces referencing fsnotify_sb_delete(), generic_shutdown_super(), cleanup_mnt(), or umount blocked for more than 120 seconds. If possible in a non-production test environment, run filesystem notification stress tests before and after patching to confirm the race no longer results in leaked references or stuck unmounts.

Typical attack path

1. Obtain local code execution on a Linux system where the affected kernel code is present.
2. Create filesystem notification marks on files, directories, or mounts using available fsnotify-backed interfaces.
3. Concurrently add and remove marks to create the specific race between mark insertion, mark detachment, and mask recalculation.
4. Trigger the condition where HAS_IREF transitions from true to false but the inode reference returned by the recalculation path is not dropped.
5. Cause or wait for filesystem unmount, namespace teardown, container cleanup, process exit, or mount cleanup activity.
6. Observe stuck unmount or teardown behavior, hung task warnings, and potential denial of service due to pinned filesystem objects.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, crash dumps, and monitoring alerts. Relevant sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg captures, hung-task detector alerts, kernel crash dumps, container runtime logs, and node drain or shutdown failure logs. Focus on hung task reports where umount, cleanup, container teardown, or process-exit paths block in fsnotify_sb_delete(), generic_shutdown_super(), kill_anon_super(), cleanup_mnt(), task_work_run(), do_exit(), or do_group_exit(). Also review spikes in inotify/fanotify usage, unusual numbers of filesystem watches, repeated mount namespace cleanup failures, or hosts that require forced reboot due to stuck unmounts. These artifacts indicate the vulnerable code path may have been triggered, but they do not by themselves prove malicious exploitation because normal workloads can also hit kernel races.

• INFO: task umount:* blocked for more than 120 seconds
• fsnotify_sb_delete
• generic_shutdown_super
• kill_anon_super
• cleanup_mnt
• task_work_run
• do_exit
• do_group_exit
• blocked for more than 120 seconds
• hung_task_timeout_secs
• Call Trace:
• __schedule
• schedule

What your security team should do

• Inventory Linux kernels across servers, container hosts, virtualization hosts, appliances, and embedded systems, and map them to vendor advisories for this issue.
• Prioritize patching systems that run untrusted local users, CI jobs, build workloads, containers, shared hosting, desktop sessions, or applications that heavily use inotify/fanotify.
• Schedule reboots after kernel updates and verify the fixed kernel is actually running.
• Search fleet kernel logs for hung task traces involving fsnotify_sb_delete(), generic_shutdown_super(), cleanup_mnt(), kill_anon_super(), or umount blocked for more than 120 seconds.
• For hosts showing matching symptoms, treat them as unstable: preserve logs, avoid repeated forced cleanup attempts where possible, drain workloads, and reboot during an approved window.
• Maintain least-privilege controls for local users and containers; avoid granting unnecessary capabilities or host filesystem access to untrusted workloads.
• Because the CVE is not KEV-listed, not associated with ransomware in the provided data, and has low EPSS, prioritize based on operational criticality and exposure to untrusted local workloads rather than emergency internet-facing patch procedures.