CVE-2024-47660

What it actually does

Race condition in fsnotify allows __fsnotify_update_child_dentry_flags under inode->i_lock to contend with fsnotify_recalc_mask during watch removal on directories with many dentries, leading to softlockups and availability impact.

Why it matters to the business

Systems may experience kernel-level hangs or reduced responsiveness when removing filesystem watches on directories with high dentry counts, potentially disrupting container workloads or file monitoring services; low urgency given absence from known exploitation lists and stable EPSS.

How an attack unfolds

An attacker with local access triggers repeated watch removal and child dentry access patterns that race __fsnotify_parent calls against recalculation, causing prolonged lock hold times and softlockup reports; listed threat actors have targeted other Linux kernel issues but no confirmed campaigns against this race.

How to fix it

Update Linux kernel to commit 3f3ef1d9f66b93913ce2171120d9226b55acd41d or later stable release containing the lazy PARENT_WATCHED clearing logic; runc users should upgrade to version 1.1.12 or newer.

How to confirm the fix worked

Confirm kernel source contains the fsnotify_update_children_dentry_flags lazy-clear change and that __fsnotify_parent no longer unconditionally calls the full update under i_lock; test by adding/removing watches on high-dentry directories and verifying absence of softlockup warnings.

Typical attack path

1. Obtain local user access on affected Linux system
2. Create or access directory with large number of negative dentries
3. Install and then remove inotify/fanotify watch on parent directory
4. Trigger concurrent child accesses to race flag updates
5. Induce softlockup and potential denial of service

How to detect it

Review kernel logs for softlockup or watchdog messages mentioning fsnotify or dentry flag updates; no specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel upgrades on systems with heavy inotify/fanotify usage or container workloads
• Monitor for softlockup reports in dmesg related to fsnotify
• Apply the exact fixed commit or distribution backport when available