Cloudanix VulnDB

CVE-2026-98539

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel creates new directories on certain file systems can let two operations interfere, sometimes freezing parts of the system or producing scary error messages.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in ntfs3 where ntfs_create_inode() uses d_instantiate() between insert_inode_locked() and unlock_new_inode(), allowing concurrent path walks to acquire the inode lock before lockdep_annotate_inode_mutex_key() resets rwsem state, causing count underflow, owner mismatches, and deadlock or corruption on subsequent inode_lock operations.

Why it matters to the business

Linux systems using ntfs3 filesystems risk kernel warnings, deadlocks, or hangs during concurrent directory creation and mount operations, reducing availability and stability especially under load or automated testing; low EPSS and no KEV status indicate limited known exploitation five days after publication.

How an attack unfolds

An attacker mounts an ntfs3 image, issues mkdir while racing a concurrent mount of a pseudofs on the new directory path; the dentry lookup in user_path_at() acquires the inode lock before unlock_new_inode() runs, triggering rwsem underflow on unlock_mount and leaving the lock corrupted for later path walks.

How to fix it

Apply the upstream kernel fix that replaces d_instantiate() with d_instantiate_new() and removes the trailing unlock_new_inode() call in ntfs_create_inode(), falling back to discard_new_inode() on error paths; rebuild and deploy the patched kernel across affected distributions.

How to confirm the fix worked

Inspect ntfs_create_inode() in fs/ntfs3/inode.c for d_instantiate_new() usage and absence of unlock_new_inode() after the instantiate call; confirm no recurrence of the WARNING in do_new_mount or DEBUG_RWSEMS_WARN_ON messages under concurrent mkdir/mount workloads.

Typical attack path

  1. Mount ntfs3 filesystem image
  2. Issue mkdir on a path within the mount
  3. Concurrently execute mount of another filesystem targeting the newly created directory
  4. Trigger dentry lookup and inode_lock during the creation window before unlock_new_inode
  5. Cause rwsem underflow or rtmutex owner mismatch leading to deadlock on subsequent operations

How to detect it

Search kernel logs for repeated WARNING in do_new_mount, DEBUG_RWSEMS_WARN_ON messages referencing rwsem_owner or rt_mutex_owner mismatches, and stack traces containing ntfs_create_inode, unlock_new_inode, or do_new_mount_fc; correlate with ntfs3 mount activity and concurrent mkdir syscalls.

  • WARNING in do_new_mount
  • DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current)
  • DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current)
  • ntfs_create_inode
  • unlock_new_inode
  • do_new_mount_fc

What your security team should do

  • Prioritize kernel updates on systems exposing ntfs3 mounts within the next maintenance window
  • Add kernel lockdep and rwsem warning patterns to SIEM alerting for early detection
  • Restrict unprivileged concurrent mount and directory creation on ntfs3 volumes until patched
  • Review EPSS trend and ecosystem prevalence reports for any increase in scanning activity

The record

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug "WARNING in do_new_mount" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && ...): count = 0x0, magic = 0xffff888043a854e8, owner = 0x0, curr 0xffff888000244880, list empty WARNING: CPU: 0 PID: 5346 at kernel/locking/rwsem.c:1368 __up_write Call Trace: inode_unlock include/linux/fs.h:877 [inline] unlock_mount fs/namespace.c:2892 [inline] do_new_mount_fc fs/namespace.c:3828 [inline] do_new_mount+0x777/0xa40 fs/namespace.c:3887 On PREEMPT_RT the same thing shows up as DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock The up_write() underflows the reset count. A following inode_lock() on that directory then never returns. A path walk into the new directory racing with the mkdir() corrupts the lock the same way via inode_lock_shared() in lookup_slow(). Switch to d_instantiate_new() and drop the trailing unlock_new_inode(). All error paths bail out before that point with I_NEW still set and keep using discard_new_inode(). May we never see this fscking bug report again.

Affected packages

Ecosystem Package Introduced Fixed