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

  - mm/slab：不要在 __kfree_rcu_sheaf（） 中喚醒 kswapd 由於 kfree_rcu（） 可以在 pi_lock （排程器中的原始微調鎖） 下調用，因此 kfree_rcu（） 本身永遠不應該使用 __GFP_KSWAPD_RECLAIM 配置記憶體，因為喚醒 kswapd 最終會取得 pi_lock，從而導致鎖死。即使有意重現這個問題也不簡單。在 pi_lock 下呼叫的 set_cpus_allowed_force（） 路徑很少執行，配置記憶體的競爭任務很可能會喚醒 kswapd。因此，已使用修改後的核心來驗證鎖死的存在，該核心具有用於喚醒 kswapd 的 lockdep 對應： ====================================================== 警告：偵測到可能的循環鎖定相依性 7.2.0-rc1-slab-for-next+ #10 未受污染
    ------------------------------------------------------ git/6660 正在嘗試取得鎖定：
    ffff8e524533c550 （&p->pi_lock）{-.-.}-{2:2}， at： _raw_spin_lock_irqsave+0x12/0x20但任務已經保持鎖定：ffff8e57bffff1a0 （&pgdat->kswapd_wait）{....}-{3:3}， at： _raw_spin_lock_irqsave+0x12/0x20哪個鎖已經依賴於新的鎖。 現有的依賴鏈 （以相反的順序） 是： -> #2 （&pgdat->kswapd_wait）{....}-{3:3}：__lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20
    __wake_up_common_lock+0x31/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] -> #1 （kswapd_wakeup）{-.-.}-{0:0}： __lock_acquire+0x5a4/0xc50 lock_sync.part.0+0x75/0x100 lock_sync+0x36/0x70 might_wakeup_kswapd+0x61/0xa0 __kfree_rcu_sheaf+0x33/0xd90 kvfree_call_rcu+0x1d4/0x3b0 set_cpus_allowed_force+0x163/0x220 cpuset_cpus_allowed_fallback+0x18b/0x240 select_fallback_rq+0x1e6/0x250 [...] -> #0 （&p->pi_lock）{-.-.}-{2:2}：check_prev_add+0xe6/0xe00 validate_chain+0x51e/0x6e0
    __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170
    __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 try_to_wake_up+0x77/0xa90 default_wake_function+0x27/0x60 autoremove_wake_function+0x23/0xb0 __wake_up_common+0xb8/0x170
    __wake_up_common_lock+0x51/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] 其他可能有助於我們調試此問題的資訊： 鏈存在以下內容： &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait 可能的不安全鎖定場景： CPU0 CPU1 ---- ----鎖定（&pgdat->kswapd_wait）;
    lock（kswapd_wakeup）;lock（&pgdat->kswapd_wait）;lock（&p->pi_lock）;DEADLOCK *** git/6660 持有的 3 個鎖： #0： ffff8e519f0e9e20 （&type->i_mutex_dir_key#6）{++++}-{4:4}， at： lookup_slow+0x2d/0x60 #1：
    ffffffff8a31c460 （kswapd_wakeup）{-.-.}- - （--truncated---CVE-2026-98818）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  - mm/slab：不在 __kfree_rcu_sheaf（） 中唤醒 kswapd 由于可在 pi_lock（计划程序中的原始自旋锁）下调用 kfree_rcu（），因此 kfree_rcu（） 本身始终不应使用 __GFP_KSWAPD_RECLAIM 分配内存，因为唤醒 kswapd 最终会获取pi_lock，从而导致死锁。即使有意重现该问题也不简单。在 pi_lock 下调用的 set_cpus_allowed_force（） 路径很少被执行，分配内存的竞争任务很可能唤醒 kswapd。因此，通过具有用于唤醒 kswapd 的 lockdep 映射的修改过内核验证死锁的存在：====================================================== 警告：检测到可能的循环锁定依赖关系 7.2.0-rc1-slab-for-next+ #10 未受感染
    ------------------------------------------------------ git/6660 正在尝试获取锁定：
    ffff8e524533c550 （&p->pi_lock）{-.-.}-{2:2}， at： _raw_spin_lock_irqsave+0x12/0x20 但任务已保持锁定： ffff8e57bffff1a0 （&pgdat->kswapd_wait）{....}-{3:3}， at： _raw_spin_lock_irqsave+0x12/0x20该锁定已经依赖于新锁定。 现有依赖关系链（顺序相反）为： -> #2 （&pgdat->kswapd_wait）{....}-{3:3}： __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20
    __wake_up_common_lock+0x31/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] -> #1 （kswapd_wakeup）{-.-.}-{0:0}： __lock_acquire+0x5a4/0xc50 lock_sync.part.0+0x75/0x100 lock_sync+0x36/0x70 might_wakeup_kswapd+0x61/0xa0 __kfree_rcu_sheaf+0x33/0xd90 kvfree_call_rcu+0x1d4/0x3b0 set_cpus_allowed_force+0x163/0x220 cpuset_cpus_allowed_fallback+0x18b/0x240 select_fallback_rq+0x1e6/0x250 [...] -> #0 （&p->pi_lock）{-.-.}-{2:2}：check_prev_add+0xe6/0xe00 validate_chain+0x51e/0x6e0
    __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170
    __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 try_to_wake_up+0x77/0xa90 default_wake_function+0x27/0x60 autoremove_wake_function+0x23/0xb0 __wake_up_common+0xb8/0x170
    __wake_up_common_lock+0x51/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] 可能有助于我们调试此漏洞的其他信息： 链存在于：&p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait 可能的不安全锁定情况： CPU0 CPU1 ---- ----锁定 （&pgdat->kswapd_wait）;
    lock（kswapd_wakeup）;lock（&pgdat->kswapd_wait）;lock（&p->pi_lock）;DEADLOCK *** git/6660 持有的 3 个锁： #0：ffff8e519f0e9e20 （&type->i_mutex_dir_key#6）{++++}-{4:4}，在：lookup_slow+0x2d/0x60 #1：
    ffffffff8a31c460 （kswapd_wakeup）{-.-.}- - （--truncated---CVE-2026-98818）

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

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

  - mm/slab:__kfree_rcu_sheaf() で kswapd を起動しません kfree_rcu() は pi_lock(スケジューラでの raw スピンロック)で呼び出すことができるため、kswapd の起動が最終的に pi_lock を取得し、デッドロックを引き起こすため、kfree_rcu() 自体は決して __GFP_KSWAPD_RECLAIM でメモリを割り当てるべきではありません。意図的に問題を再現するだけでも、簡単ではありませんでした。pi_lock で呼び出される set_cpus_allowed_force() パスが実行されることはほとんどなく、メモリを割り当てる競合するタスクによって kswapd がウェイクアップされる可能性が高くなります。このため、デッドロックの存在は、kswapd をウェイクアップするための lockdep マップがある変更カーネルで検証されました: ====================================================== 警告:循環ロッキング依存関係の可能性が検出されました 7.2.0-rc1-slab-for-next+ #10 汚染されていません
    ------------------------------------------------------ git/6660 がロックを取得しようとしています:
    ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}、at:_raw_spin_lock_irqsave+0x12/0x20 がタスクはすでにロックを保留しています: ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}、at:_raw_spin_lock_irqsave+0x12/0x20どのロックがすでに新しいロックに依存しているか。 既存の依存関係チェーン(逆の順序)は次のとおりです。-> #2 (&pgdat->kswapd_wait){....}-{3:3}: __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20
    __wake_up_common_lock+0x31/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] -> #1 (kswapd_wakeup){-.-.}-{0:0}: __lock_acquire+0x5a4/0xc50 lock_sync.part.0+0x75/0x100 lock_sync+0x36/0x70 might_wakeup_kswapd+0x61/0xa0 __kfree_rcu_sheaf+0x33/0xd90 kvfree_call_rcu+0x1d4/0x3b0 set_cpus_allowed_force+0x163/0x220 cpuset_cpus_allowed_fallback+0x18b/0x240 select_fallback_rq+0x1e6/0x250 [...] -> #0 (&p->pi_lock){-.-.}-{2:2}: check_prev_add+0xe6/0xe00 validate_chain+0x51e/0x6e0
    __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170
    __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 try_to_wake_up+0x77/0xa90 default_wake_function+0x27/0x60 autoremove_wake_function+0x23/0xb0 __wake_up_common+0xb8/0x170
    __wake_up_common_lock+0x51/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80
    __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] これをデバッグするのに役立つ可能性があるその他の情報: 以下のチェーンが存在する: &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait のチェーンが存在する:&p- -- -- &pgdat- 起こり得る安全でないロックシナリオ: CPU0 CPU1 ---- ----ロック(&pgdat->kswapd_wait);
    ロック(kswapd_wakeup);ロック(&pgdat->kswapd_wait);ロック(&p->pi_lock);デッドロック *** git/6660 が保持している 3 つのロック: #0:ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}、at:lookup_slow+0x2d/0x60 #1:
    ffffffff8a31c460 (kswapd_wakeup){-.-.}- ---truncated--- (CVE-2026-98818)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not wake up kswapd in
    __kfree_rcu_sheaf() Since kfree_rcu() can be called under pi_lock (a raw spinlock in the scheduler),     kfree_rcu() itself should never allocate memory with __GFP_KSWAPD_RECLAIM as waking up kswapd ends up     acquiring pi_lock, which leads to a deadlock. Reproducing the issue even intentionally was not     straightforward. The set_cpus_allowed_force() path that is called under pi_lock is exercised very rarely,     and competing tasks that allocate memory will most likely wake kswapd up. Therefore the existence of the     deadlock was verified with a modified kernel that has a lockdep map for waking up kswapd:
    ====================================================== WARNING: possible circular locking dependency     detected 7.2.0-rc1-slab-for-next+ #10 Not tainted ------------------------------------------------------     git/6660 is trying to acquire lock: ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at:
    _raw_spin_lock_irqsave+0x12/0x20 but task is already holding lock: ffff8e57bffff1a0     (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20 which lock already depends on the     new lock. the existing dependency chain (in reverse order) is: -> #2 (&pgdat->kswapd_wait){....}-{3:3}:
    __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170
    __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 __wake_up_common_lock+0x31/0xa0
    __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0
    __alloc_pages_slowpath.constprop.0+0x282/0xf80 __alloc_frozen_pages_noprof+0x32a/0x360     alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190     refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] -> #1 (kswapd_wakeup){-.-.}-{0:0}:
    __lock_acquire+0x5a4/0xc50 lock_sync.part.0+0x75/0x100 lock_sync+0x36/0x70 might_wakeup_kswapd+0x61/0xa0
    __kfree_rcu_sheaf+0x33/0xd90 kvfree_call_rcu+0x1d4/0x3b0 set_cpus_allowed_force+0x163/0x220     cpuset_cpus_allowed_fallback+0x18b/0x240 select_fallback_rq+0x1e6/0x250 [...] -> #0     (&p->pi_lock){-.-.}-{2:2}: check_prev_add+0xe6/0xe00 validate_chain+0x51e/0x6e0 __lock_acquire+0x5a4/0xc50     lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80
    _raw_spin_lock_irqsave+0x12/0x20 try_to_wake_up+0x77/0xa90 default_wake_function+0x27/0x60     autoremove_wake_function+0x23/0xb0 __wake_up_common+0xb8/0x170 __wake_up_common_lock+0x51/0xa0
    __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0
    __alloc_pages_slowpath.constprop.0+0x282/0xf80 __alloc_frozen_pages_noprof+0x32a/0x360     alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190     refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] other info that might help us debug     this: Chain exists of: &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait Possible unsafe locking     scenario: CPU0 CPU1 ---- ---- lock(&pgdat->kswapd_wait); lock(kswapd_wakeup); lock(&pgdat->kswapd_wait);
    lock(&p->pi_lock); *** DEADLOCK *** 3 locks held by git/6660: #0: ffff8e519f0e9e20     (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60 #1: ffffffff8a31c460     (kswapd_wakeup){-.-.}- ---truncated--- (CVE-2026-98818)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
367500	Linux Distros 未修補弱點：CVE-2026-98818	Nessus	Misc.	2026/10/20	2026/11/11	medium
367500	Linux Distros 未修补的漏洞：CVE-2026-98818	Nessus	Misc.	2026/10/20	2026/11/11	medium
367500	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98818	Nessus	Misc.	2026/10/20	2026/11/11	medium
367500	Linux Distros Unpatched Vulnerability : CVE-2026-98818	Nessus	Misc.	2026/10/20	2026/11/11	medium

検出

プラグインの検索

medium

medium

medium

medium