There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks
    with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release()
    to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have
    provision to go through dying_tasks because of dying threadgroup leaders or explicit
    CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is
    possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release()
    and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The
    race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at
    a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero.
    (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would
    could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the
    dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that
    are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The
    repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to
    css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R
    (reader of cgroup.procs) T (thread) L (group leader) ---------------------------------
    -------------------------------- -------------------------------- L exits, signal->live > 0
    cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list,
    &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live
    != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) //
    css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L)
    put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */
    ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos =
    &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L)
    css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L)
    (CVE-2026-98163)

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

  - cgroup：避免零參照計數的垂死任務迭代 提交 260fbcb92bbea （cgroup：將dying_tasks清理從 cgroup_task_release（） 移至 cgroup_task_free（）） 延長了dying_tasks清單中任務的生命週期。迭代器有通過 dying_tasks 的規定，因為線程組領導者正在消亡或明確CSS_TASK_ITER_WITH_DEAD，但是，預計此類任務可以獲得新的引用（在 cgroup_task_release（）/put_task_struct_rcu_user（） 之前是可能的）。cgroup_task_release（） 之後和 cgroup_task_free（） 之前的任務受爭用的影響，因為它們可能有也可能沒有
    ->使用計數> 0。爭用窗口是在 css_task_iter_next（） 調用之間，當 css_set_lock 被釋放時，我們可能會到達一個新的 ->task_pos。迭代器不應嘗試還原其
    ->使用計數降至零。（發生這種情況時，__put_task_struct_rcu_cb（） 已經迫在眉睫，返回的task_struct可以在釋放後使用。至於修復，我們不能簡單地檢查垂死名單上任務的信號>實時計數，因為這無法區分等待收割的普通殭屍和將要釋放的 RCU 殘餘任務。因此，請新增額外的檢查以排除
    ->usage==0 個任務。css_task_iter_advance（） 中的 repeat： 迴圈不考慮 ->usage 計數，因此在 css_task_iter_next（） 中新增一個迴圈以跳過dying_list上已停用的任務。可能爭用的粗略說明 R （cgroup.procs 的讀取器） T （執行緒） L （群組領導者）
    --------------------------------- -------------------------------- -------------------------------- L 退出，signal->live > 0 cgroup_task_dead（L） css_set_skip_task_iters（） // 僅跳過 cset->tasks list_add_tail（&L->cg_list， &cset->dying_tasks） css_task_iter_next（） take css_set_lock css_task_iter_advance（） leader &&; signal->live ！= 0 => it->task_pos = &L->cg_list release css_set_lock T 退出 --signal->live == 0 cgroup_task_dead（T） // css_set_lock release_task（T） cgroup_task_release（T） release_task（L） // zap_leader cgroup_task_release（L） put_task_struct_rcu_user（L） ...RCU...
    put_task_struct（L） L->usage = 0 /* L 仍開啟 dying_tasks */ ...RCU... __put_task_struct（L） css_task_iter_next（） // 另一個迭代 take css_set_lock it->task_pos = &L->cg_list get_task_struct（L） => 加法 0 drop css_set_lock cgroup_task_free（L） css_set_skip_task_iters（） // 死亡跳過來得太晚 free_task（L） cgroup_procs_show（） task_pid_vnr（L） （CVE-2026-98163）

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

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

  - cgroup：避免使用零引用计数的终止任务迭代 提交 260fbcb92bbea（cgroup：将dying_tasks清理从 cgroup_task_release（） 移至 cgroup_task_free（）））延长了dying_tasks上任务的生命周期。由于线程组前导符即将终止或显式CSS_TASK_ITER_WITH_DEAD，迭代器具有经历dying_tasks的配置，但是，预期此类任务可以获取新的引用（在 cgroup_task_release（）/put_task_struct_rcu_user（） 之前可能）。在 cgroup_task_release（） 之后和 cgroup_task_free（） 之前的任务可能会受到争用的影响，当它们可能有也可能没有时
    ->usage 计数> 0。当 css_set_lock 发布时，争用窗口处于 css_task_iter_next（） 调用之间，可能会遇到新的 ->task_pos。迭代器不应尝试恢复其
    ->使用计数降至零。（发生此情况时，__put_task_struct_rcu_cb（） 已迫在眉睫，返回的task_struct可在释放后使用。）至于修复，我们不能简单地检查垂死列表中任务的>实时信号计数，因为这无法区分等待收割的常规僵尸和即将释放的 RCU 残余任务。因此，添加一个额外的检查以排除这种可能性
    ->usage==0 任务。css_task_iter_advance（） 中的 repeat： 循环未考虑 ->usage 计数，因此将新循环添加到 css_task_iter_next（） 以跳过dying_list上已停用的任务。可能争用的粗略说明 R（cgroup.procs 的阅读器） T（线程） L（组组前导）
    --------------------------------- -------------------------------- -------------------------------- L 退出，signal->live > 0 cgroup_task_dead（L） css_set_skip_task_iters（） // 仅跳过 cset->tasks list_add_tail（&L->cg_list， &cset->dying_tasks） css_task_iter_next（） take css_set_lock css_task_iter_advance（） leader &; signal->live ！= 0 => it->task_pos = &L->cg_list 释放 css_set_lock T 退出 --signal->live == 0 cgroup_task_dead（T） // css_set_lock release_task（T） cgroup_task_release（T） release_task（L） // zap_leader cgroup_task_release（L） put_task_struct_rcu_user（L） ...RCU...
    put_task_struct（L） L->usage = 0 /* L 仍开启 dying_tasks */ ...RCU... __put_task_struct（L） css_task_iter_next（） // 另一个迭代 take css_set_lock it->task_pos = &L->cg_list get_task_struct（L） => 添加 0 drop css_set_lock cgroup_task_free（L） css_set_skip_task_iters（） // 死亡跳过来得太晚 free_task（L） cgroup_procs_show（） task_pid_vnr（L） （CVE-2026-98163）

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

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

  - cgroup:ゼロ refcount で機能しかけているタスクの繰り返しを回避します コミット 260fbcb92bbea(cgroup:クリーンアップを cgroup_task_release() から cgroup_task_free() へ移動dying_tasks)により、dying_tasksリストのタスクの有効期間が延長されました。無効なスレッドグループリーダーまたは明示的なCSS_TASK_ITER_WITH_DEADのために、イテレータは dying_tasks を通過するためのプロビジョニングを持っていますが、そのようなタスクは新しい参照を取得できることが期待されていました(それは cgroup_task_release()/put_task_struct_rcu_user() より前に可能です)。cgroup_task_release() の後と cgroup_task_free() より前のタスクは、競合の対象となります。
    ->使用カウント> 0。競合ウィンドウは、css_set_lock がリリースされたときの css_task_iter_next() 呼び出しの間にあり、新しい ->task_pos に到達する可能性があります。イテレータは、
    ->使用カウントがゼロにドロップしました。(その場合、__put_task_struct_rcu_cb() はすでに差し迫っており、返されたtask_structは AFTER free で使用される可能性があります。)修正に関しては、死にかけリスト上のタスクのシグナル>ライブカウントを単純にチェックすることはできません。これは、刈り取られるのを待っている通常のゾンビと、解放される予定の RCU 残存タスクを区別できないためです。したがって、除外するために余分なチェックを追加してください
    ->usage==0 タスク。css_task_iter_advance() の repeat: ループは ->usage カウントを考慮しないため、css_task_iter_next() に新しいループを追加して、dying_list上の未使用のタスクをスキップします。可能性のある競合の大まかな例示:R(cgroup.procs のリーダー)、T(スレッド)、L(グループリーダー)
    --------------------------------- -------------------------------- -------------------------------- L が終了し、signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // cset->tasks のみをスキップします list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader &&; signal->live != 0 => it->task_pos = &L->cg_list リリース css_set_lock T が終了します --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU...
    put_task_struct(L) L->usage = 0 /* L まだオンdying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // 別の反復 take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => add on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // 死ぬスキップが遅すぎます free_task(L) cgroup_procs_show() task_pid_vnr(L) (CVE-2026-98163)

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

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

  - cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea (cgroup: Move     dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()) extended the lifetime of tasks on     the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup     leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new     reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after     cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have
    ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is     released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose
    ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the     returned task_struct would could be used after free.) As for the fix, we cannot simply check the     signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to     be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out
    ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage     count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough     illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader)
    --------------------------------- -------------------------------- -------------------------------- L     exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks     list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock     css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T     exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T)     release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU...
    put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L)     css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L)     => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too     late free_task(L) cgroup_procs_show() task_pid_vnr(L) (CVE-2026-98163)

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

ID	Name	Product	Family	Published	Updated	Severity
474754	Chainguard: multiple linux-desktop-7.2 packages: security update to 7.2.11-r0	Tenable Cloud Security	Chainguard Local Security Checks	10/16/2026	10/21/2026	high
474754	Chainguard: multiple linux-desktop-7.2 packages: security update to 7.2.11-r0	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	10/16/2026	10/21/2026	high
369312	Linux Distros 未修補弱點：CVE-2026-98163	Nessus	Misc.	10/21/2026	10/22/2026	high
369312	Linux Distros 未修补的漏洞：CVE-2026-98163	Nessus	Misc.	10/21/2026	10/22/2026	high
369312	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98163	Nessus	Misc.	10/21/2026	10/22/2026	high
369312	Linux Distros Unpatched Vulnerability : CVE-2026-98163	Nessus	Misc.	10/21/2026	10/22/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high