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

  - drm/ttm：修正被換出的資源永遠不會離開其bulk_move範圍 ttm_tt_swapout（） 在成功時傳回換出的頁數，在失敗時傳回負錯誤代碼;對於填入的 TTM，它永遠不會傳回零。提交 b2ed01e7ad3d （drm/ttm：修正交換失敗時的 ttm_bo_swapout（） 無限 LRU 遍歷） 將 ttm_bo_swapout_cb（） 中的bulk_move簿記移動到 if （！ret） 下，因此現在每次成功交換時都會跳過 ttm_resource_del_bulk_move_unevictable（） / ttm_resource_move_to_lru_tail（） 對。提交 1d59f36e95f7 中縮減器的等效更改 （drm/ttm： 修正備份失敗時的 ttm_bo_shrink（） 無限 LRU 遍歷） 測試 lret > 0，這也是這裡的預期。在 b2ed01e7ad3d 之前，資源在交換前已從bulk_move中移除;從那時起，交換的資源會保留在其 BO 的bulk_move範圍內 （以及在管理程式 LRU 上），儘管它是不可驅逐的。當它稍後被釋放或 BO 離開 bulk_move （ttm_resource_free（）、ttm_bo_set_bulk_move（） 通過 amdgpu_vm_bo_del（）） 時，ttm_resource_del_bulk_move（） 會因為它的 ！ttm_resource_unevictable（） 保護而跳過它，因此 pos->first / pos->last 中的範圍端點會指向釋放的記憶體。該游標上的下一個 ttm_lru_bulk_move_tail（） 或 ttm_resource_add_bulk_move（） 是釋放後使用，視為 ttm_lru_bulk_move_add（） 中的 resv WARN、list_del ttm_resource_move_to_lru_tail（） 中的損毀或 ttm_resource_manager_next（） 中的 NULL 解除參照 -- 休眠後幾分鐘到幾小時，或休眠後的進程結束/重新啟動時。Samuel Ainsworth 對 drm/amd 第 5387 期（見連結）的分析發現了懸空遊標;在更換時缺少移除是它懸而未決的原因。測試條件是否成功可還原移除。在 AMD Phoenix APU （ASUS UM3406GA， gfx1103） 上，在帶有反向移植 （Ubuntu 7.0.0-31） 的 7.0.y 穩定核心上執行 suspend-then-hibernate 時，該錯誤在 18 個休眠週期中當機了 5 個;一個休眠的函數設定檔顯示 336 次 ttm_tt_swapout（） 呼叫和零次 ttm_resource_del_bulk_move_unevictable（） 呼叫。透過此變更，每個交換的資源都會進行移除，並且另外 12 個週期是乾淨的。（CVE-2026-98166）

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

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

  - drm/ttm：修复被交换的资源从不离开其bulk_move范围的问题 ttm_tt_swapout（） 在成功时返回被交换的页数，在失败时返回负错误代码;对于已填充的 TTM，它永远不会返回零。提交 b2ed01e7ad3d（drm/ttm：修复 ttm_bo_swapout（） 无限 LRU 经过换出失败时的经过调整）将 ttm_bo_swapout_cb（） 中的bulk_move簿记移动到 if （！ret） 之下，因此现在每次成功换出时都会跳过 ttm_resource_del_bulk_move_unevictable（） / ttm_resource_move_to_lru_tail（） 对。对提交 1d59f36e95f7 中 shrinker 的等效更改（drm/ttm：修复备份失败时的 ttm_bo_shrink（） LRU 无限遍历）测试 lret > 0，这也是此处的预期。在 b2ed01e7ad3d 之前，资源已在换出前从bulk_move中删除;从那时起，被交换的资源尽管不可驱逐，但仍留在其 BO 的bulk_move范围内（和在管理器 LRU 上）。在之后将其释放或 BO 离开bulk_move时（ttm_resource_free（）、通过 amdgpu_vm_bo_del（） 的 ttm_bo_set_bulk_move（），ttm_resource_del_bulk_move（） 会因其 ！ttm_resource_unevictable（） 保护而跳过它，因此 pos->first / pos->last 中的范围端点仍然指向已释放的内存。该游标上的下一个 ttm_lru_bulk_move_tail（） 或 ttm_resource_add_bulk_move（） 为释放后使用，被视为 ttm_lru_bulk_move_add（） 中的 resv WARN），list_del ttm_resource_move_to_lru_tail（） 中的损坏或 ttm_resource_manager_next（） 中的空取消引用 -- 休眠之后几分钟到几小时，或者休眠之后进程退出/重新启动时。Samuel Ainsworth 对 drm/amd 问题 5387 的分析（参见 Link）发现了悬摆光标;更换时缺少移除是它悬而未决的原因。测试条件是否成功还原删除操作。在携带反向移植 （Ubuntu 7.0.0-31） 的 7.0.y 稳定内核上运行 suspend-then-hibernate 的 AMD Phoenix APU （ASUS UM3406GA， gfx1103） 上，此缺陷导致 18 个休眠周期中的 5 个崩溃;一个休眠的函数配置文件显示 336 个 ttm_tt_swapout（） 调用和 0 个 ttm_resource_del_bulk_move_unevictable（） 调用。通过此更改，每个交换的资源都会发生删除操作，并且再有 12 个周期是干净的。（CVE-2026-98166）

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

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

  - drm/ttm:スワップアウトされたリソースがbulk_move範囲を決して離れないのを修正します ttm_tt_swapout() は、成功時にスワップアウトされたページ数を返し、失敗時に負のエラーコードを返します。入力済みの TTM に対しては、ゼロを返しません。コミット b2ed01e7ad3d(drm/ttm:スワップアウト失敗時の ttm_bo_swapout() 無限 LRU ウォークを修正)が ttm_bo_swapout_cb() のbulk_move簿記を if(!ret)の下に移動したため、ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() のペアはスワップアウトが成功するたびにスキップされるようになりました。コミット 1d59f36e95f7(drm/ttm:ttm_bo_shrink() 無限 LRU ウォークオンバックアップエラーを修正)のシュリンカーの同等の変更は、lret > 0 をテストします。これはここでも意図されたことです。b2ed01e7ad3d の前に、リソースはスワップアウト前にbulk_moveから取り除かれていました。それ以降、スワップアウトされたリソースは、退去不可になりますが、BOのbulk_move範囲内(およびマネージャLRU)内にとどまります。後に解放されるか、BO がbulk_moveを離れる場合(ttm_resource_free()、amdgpu_vm_bo_del() による ttm_bo_set_bulk_move())、ttm_resource_del_bulk_move() はその !ttm_resource_unevictable() ガードのためにそれをスキップします。したがって、pos->first / pos->last の範囲エンドポイントは、解放されたメモリを指したままになります。そのカーソルの次の ttm_lru_bulk_move_tail() または ttm_resource_add_bulk_move() は、ttm_lru_bulk_move_add() の resv WARN、list_del ttm_resource_move_to_lru_tail() の破損、または ttm_resource_manager_next() の NULL 逆参照として見られる use-after-free です。ハイバネーションの数分から数時間後、またはそれに続くプロセスの終了/再起動で発生します。Samuel Ainsworth による drm/amd 問題 5387 の分析(リンクを参照)により、ダングリングカーソルが特定されました。スワップアウト時に取り外しがないことが、ぶら下がっている理由です。成功するかどうかをテストすると、削除が復元されます。バックポート(Ubuntu 7.0.0-31)を搭載する 7.0.y 安定版カーネルで suspend-then-hibernate を実行している AMD Phoenix APU(ASUS UM3406GA、gfx1103)で、バグにより 18 回のハイバネーションサイクルのうち 5 回がクラッシュしました。1 回のハイバネーションの関数プロファイルでは、336 回の ttm_tt_swapout() 呼び出しと 0 回の ttm_resource_del_bulk_move_unevictable() 呼び出しが表示されました。この変更により、削除はスワップアウトされたリソースごとに行われ、その後 12 サイクルはクリーンでした。(CVE-2026-98166)

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

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

  - drm/ttm: fix swapped-out resources never leaving their bulk_move range ttm_tt_swapout() returns the number     of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns     zero. Commit b2ed01e7ad3d (drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure) moved the     bulk_move bookkeeping in ttm_bo_swapout_cb() under if (!ret), so the     ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every     successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 (drm/ttm: Fix     ttm_bo_shrink() infinite LRU walk on backup failure) tests lret > 0, which is what was intended here as     well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a     swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is     unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(),     ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its     !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed     memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-     free, seen as the resv WARN in ttm_lru_bulk_move_add(), list_del corruption in     ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours     after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd     issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it     dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA,     gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31)     the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336     ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the     removal happens for every swapped-out resource and 12 further cycles were clean. (CVE-2026-98166)

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

ID	Name	Product	Family	Published	Updated	Severity
364238	Linux Distros 未修補弱點：CVE-2026-98166	Nessus	Misc.	10/8/2026	10/9/2026	high
364238	Linux Distros 未修补的漏洞：CVE-2026-98166	Nessus	Misc.	10/8/2026	10/9/2026	high
364238	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98166	Nessus	Misc.	10/8/2026	10/9/2026	high
364238	Linux Distros Unpatched Vulnerability : CVE-2026-98166	Nessus	Misc.	10/8/2026	10/9/2026	high

Detections

Analytics

Plugins Search

high

high

high

high