Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - fs/ntfs3：在 ntfs_create_inode（） 中使用 d_instantiate_new（） 并谋杀 do_new_mount saga 中的 syzbot's WARNING ntfs_create_inode（） 通过 ntfs_new_inode（） 创建新的 inode。它使用 insert_inode_locked（） 对其进行哈希处理，因此在 unlock_new_inode（） 之前被标记为 I_NEW。不过，NTFS 3 会在中间调用 d_instantiate（）...
    由于在创建之前，查找已对 dentry 进行哈希，因此 path walk 可在不接触父i_rwsem的情况下找到该目录项，因此可以锁定 inode。如果 inode 是一个目录，unlock_new_inode（） 会调用 lockdep_annotate_inode_mutex_key（） 并用 i_mutex_dir_key 类标记i_rwsem。这重置了计数，其他人现在可能已经持有的锁的所有者......自 2023 年以来，syzbot 一直在 do_new_mount 中向我们发送同样被遗弃的错误警告。我再也受不了了，所以我去找了。
    Afaict（syzbot 的执行程序 chdirs 到新装载的 ntfs3 镜像中）创建目录，然后在其上挂载一些伪装。mkdir（） 每次花费的时间长于 syzbot 等待 mount（） 并发运行：
    mkdir（./sys） mount（NULL， ./sys， sysfs） ntfs_create_inode（） d_instantiate（） user_path_at（） 查找 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） 然后挂载端释放一个根据 rwsem 无人持有的锁定：
    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 调用跟踪：inode_unlock include/linux/fs.h：877 [内联] unlock_mount fs/namespace.c：2892 [内联] do_new_mount_fc fs/namespace.c：3828 [内联] do_new_mount+0x777/0xa40 fs/namespace.c：3887 在 PREEMPT_RT 上，相同内容显示为 DEBUG_LOCKS_WARN_ON（rt_mutex_owner（lock） ！= current） 警告：
    kernel/locking/rtmutex_common.h：193 在 rt_mutex_slowunlock up_write（） 下溢重置计数。然后，该目录上的后续 inode_lock（） 再也不会返回。进入与 mkdir（） 争用的新目录的路径以相同的方式通过 lookup_slow（） 中的 inode_lock_shared（） 损坏锁定。切换到 d_instantiate_new（） 并删除结尾的 unlock_new_inode（）。所有错误路径在该点之前退出，但仍设置了 I_NEW 并继续使用 discard_new_inode（）。愿我们再也见不到这个 fscking 错误报告。
    (CVE-2026-98539)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - fs/ntfs3：在 ntfs_create_inode（） 中使用 d_instantiate_new（） 並在 do_new_mount saga 中謀殺 syzbot 的警告 ntfs_create_inode（） 透過 ntfs_new_inode（） 建立新的 inode。它使用 insert_inode_locked（） 對其進行雜湊處理，因此在 unlock_new_inode（） 之前將其標記為I_NEW。不過，NTFS 3 會在兩者之間調用 d_instantiate（）...
    由於在建立之前，查找已經對 dentry 進行了雜湊處理，因此任何路徑遍歷都會在不接觸父項i_rwsem的情況下找到它，因此可以鎖定 inode。如果 inode 是目錄 unlock_new_inode（），則呼叫 lockdep_annotate_inode_mutex_key（） 並用 i_mutex_dir_key 類別標示i_rwsem。這會重置計數，並且其他人現在可能已經持有的鎖的所有者......自 2023 年以來，syzbot 一直在 do_new_mount 向我們發送同樣的 Godforsaken 錯誤警告。我再也受不了了，所以我去找了。
    Afaict 是 syzbot 的執行程式 chdir 到新掛載的 ntfs3 映像中，建立一個目錄，然後在其上掛載一些假名。每當 mkdir（） 花費的時間比 syzbot 等待的時間更長時，mount（） 就會同時運行：
    mkdir（./sys） mount（NULL， ./sys， sysfs） ntfs_create_inode（） d_instantiate（） user_path_at（） 找到 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） 然後掛載端釋放一個鎖，根據 rwsem 沒有人持有：
    DEBUG_RWSEMS_WARN_ON（（rwsem_owner（sem） ！= current） &&; ...）： count = 0x0， magic = 0xffff888043a854e8， owner = 0x0， curr 0xffff888000244880， list empty： 警告： CPU： 0 PID： 5346 at kernel/locking/rwsem.c：1368
    __up_write 呼叫追蹤： 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 在 PREEMPT_RT 上，同樣的內容顯示為 DEBUG_LOCKS_WARN_ON（rt_mutex_owner（lock） ！= current） 警告：
    kernel/locking/rtmutex_common.h：193 在 rt_mutex_slowunlock up_write（） 將重設計數反向溢位。然後，該目錄上的後續 inode_lock（） 永遠不會傳回。進入新目錄的路徑與 mkdir（） 競爭，透過 lookup_slow（） 中的 inode_lock_shared（） 以相同的方式破壞鎖定。切換到 d_instantiate_new（） 並刪除尾端 unlock_new_inode（）。所有錯誤路徑都會在該點之前退出I_NEW但仍設定並繼續使用 discard_new_inode（）。願我們再也看不到這個該死的錯誤報告了。
    (CVE-2026-98539)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - fs/ntfs3:ntfs_create_inode() の d_instantiate_new() を使用し、do_new_mount saga の syzbot の警告をマージします ntfs_create_inode() は、ntfs_new_inode() を介して新しい inode を作成します。insert_inode_locked()でハッシュするため、unlock_new_inode()までI_NEWとしてマークされます。NTFS 3はその間にd_instantiate()を呼び出しますが...
    dentry は、任意のパス作成の前に検索によりすでにハッシュされているため、walk は親のi_rwsemに触れずに dentry を見つけ、inode をロックできます。inodeがディレクトリの場合、unlock_new_inode()はlockdep_annotate_inode_mutex_key()を呼び出し、i_mutex_dir_keyクラスでi_rwsemをマークします。これによりカウントがリセットされ、他の誰かがすでに保持している可能性のあるロックの所有者が...syzbot は、2023 年以来、do_new_mount で同じ神見捨てられたバグ警告をスパム送信しています。もう我慢できないので探しに行きました。
    syzbot の実行者である Afaict は、新たにマウントされた ntfs3 イメージに chdirs し、ディレクトリを作成してから、その上にいくつかの偽装をマウントします。mkdir() が syzbot が mount() を待機する時間よりも時間がかかるたびに、mount() が同時に実行されます:
    mkdir(./sys) mount(NULL, ./sys, sysfs) ntfs_create_inode() d_instantiate() user_path_at() は 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) マウント側はその後、rwsem によれば誰も保持しないロックを解放します:
    DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &; ...): count = 0x0、magic = 0xffff888043a854e8、owner = 0x0、curr 0xffff888000244880、list empty 警告:CPU:0 PID:5346 at kernel/locking/rwsem.c:1368
    __up_write 呼び出しトレース:inode_unlock include/linux/fs.h:877 [インライン] unlock_mount fs/namespace.c:2892 [インライン] do_new_mount_fc fs/namespace.c:3828 [インライン] do_new_mount+0x777/0xa40 fs/namespace.c:3887 PREEMPT_RTでも、DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) として同じ結果が表示されます 警告:
    kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock up_write() がリセットカウントをアンダーフローします。そのディレクトリの後続の inode_lock() はその後、返されません。mkdir() と競合している新しいディレクトリへのパスウォークは、lookup_slow() の inode_lock_shared() を通じて、同じ方法でロックを破損します。d_instantiate_new() に切り替えて、末尾の unlock_new_inode() を削除します。全てのエラーパスは、依然として I_NEW が設定された状態でその時点前に救済され、引き続き discard_new_inode() を使用します。この fscking バグレポートを二度と見ませんように。
    (CVE-2026-98539)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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.
    (CVE-2026-98539)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
367038	Linux Distros 未修补的漏洞：CVE-2026-98539	Nessus	Misc.	2026/10/18	2026/10/20	medium
367038	Linux Distros 未修補弱點：CVE-2026-98539	Nessus	Misc.	2026/10/18	2026/10/20	medium
367038	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98539	Nessus	Misc.	2026/10/18	2026/10/20	medium
367038	Linux Distros Unpatched Vulnerability : CVE-2026-98539	Nessus	Misc.	2026/10/18	2026/10/20	medium

检测

插件搜索

medium

medium

medium

medium