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

  - drm/xe：當 fb-pin 執行最終取消固定時，修正過時的 pinned_link 條目 xe_bo_pin_external（） 和 xe_bo_unpin_external（） 根據目前呼叫是最外層的 pin 還是最終取消固定，在 xe->pinned.late.external 中維護 bo 的pinned_link清單成員資格。然而，同樣的外部 bo 的pin_count也可以透過 __xe_pin_fb_vma（）/__xe_unpin_fb_vma（） 直接升高和降低，它將 bo 固定為顯示掃描緩衝區，而無需經過 xe_bo_pin_external（）/xe_bo_unpin_external（），並且沒有概念或所有權，pinned_link。如果 bo 在外部固定 （例如 dma-buf 匯出） 和 fb，並且外部取消固定首先發生，則 xe_bo_unpin_external（） 會正確觀察 pin_count > 1 並將 bo 留在 pinned_link。當 fb 取消固定稍後執行真正的最後一個取消固定 （pin_count 1 -> 0） 時，它永遠不會接觸 pinned_link，從而使 bo 無限期地連結在 xe->pinned.late.external 上。一旦 bo 隨後被釋放，這個過時的清單項目就會指向釋放的記憶體，從而破壞清單，並在下次遍歷或拼接清單時面臨釋放後使用的風險。xe_bo_notifier_prepare_pinned（）/ xe_bo_notifier_unprepare_pinned（） 中的備份物件釘選/取消釘選站點具有相同的繞過特性，儘管它們永遠不會將其 bo 新增至釘選清單，因此不會受到此特定清單損毀問題的影響。將pinned_link移除移至 xe_bo_account_unpin（） 中，該路徑已在真正的 1 -> 0 pin_count轉換之前在每個取消固定路徑 （核心、外部、影像緩衝區、備份物件） 上執行。由於 list_del_init（） 僅在節點本身上運行，因此此刪除與列表無關，並且可以安全地執行，無論 bo 恰好鏈接在哪個列表（外部或kernel_bo_present）上，或者哪個代碼路徑正在執行最終的取消固定。刪除 xe_bo_unpin_external（） 和 xe_bo_unpin（） 中現在多餘的顯式 list_del_init（） 呼叫。v2： - 新補丁 v3： - 根據先前補丁的更改重新基於。（從提交 ca58d36a1f93af586ee93b340c9f9fd81312cc01 中挑選）（CVE-2026-98999）

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

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

  - drm/xe：修复 fb-pin 执行最终取消固定 xe_bo_pin_external（） 和 xe_bo_unpin_external（） 时过时的 pinned_link 条目，根据当前调用是最外层 pin 还是最终取消固定，在 xe->pinned.late.external 中维护 bo 的pinned_link列表成员资格。不过，也可以直接通过 __xe_pin_fb_vma（）/__xe_unpin_fb_vma（） 升高和降低同一外部 bo 的pin_count，这会将 bo 固定为显示 scanout 缓冲区，而完全不需要经过 xe_bo_pin_external（）/xe_bo_unpin_external（），并且对pinned_link没有概念或所有权。如果 bo 在外部（例如 dma-buf 导出）和 fb 固定，并且外部取消固定首先发生，则 xe_bo_unpin_external（） 会正确地观察 pin_count > 1 并保留 bo pinned_link。当 fb 取消固定稍后执行真正的最后一个取消固定 （pin_count 1 -> 0） 时，它永远不会接触pinned_link，使 bo 无限期地链接在 xe->pinned.late.external。随后释放 bo 后，此过时列表条目会指向已释放的内存，从而损坏列表并面临下次遍历或拼接该列表时出现释放后使用的风险。xe_bo_notifier_prepare_pinned（）/ xe_bo_notifier_unprepare_pinned（） 中的备份对象固定/取消固定站点具有相同的绕过特性，不过它们从不将其 bo 添加到固定列表，因此不受该特定列表损坏问题的影响。将pinned_link删除移至 xe_bo_account_unpin（），该路径已在真正的 1 -> 0 pin_count转换之前在每个取消固定路径（内核、外部、帧缓冲区、备份对象）上运行。由于 list_del_init（） 仅在节点本身上操作，因此无论 bo 恰好链接在哪个列表（外部或kernel_bo_present）上，或者哪个代码路径正在执行最终取消固定，此删除操作与列表无关且可以安全执行。终止 xe_bo_unpin_external（） 和 xe_bo_unpin（） 中现在多余的显式 list_del_init（） 调用。v2： - 新修补程序 v3： - 衍合对之前修补程序的更改。（从提交 ca58d36a1f93af586ee93b340c9f9fd81312cc01 中精选出的内容）（CVE-2026-98999）

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

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

  - drm/xe:fb-pin が最後のピン解除を実行する際の古い pinned_link エントリを修正します xe_bo_pin_external() および xe_bo_unpin_external() が、現在の呼び出しが最も外側のピンか最後のピン解除かに基づいて、xe->pinned.late.external における bo の pinned_link リストメンバーシップを維持します。ただし、同じ外部 bo のpin_countは、__xe_pin_fb_vma()/__xe_unpin_fb_vma() によって直接上げ下げすることもできます。これは、xe_bo_pin_external()/xe_bo_unpin_external() をまったく経由せずに bo をディスプレイスキャンアウトバッファとして固定し、pinned_linkの概念も所有権も持たせません。bo が外部(例:dma-buf エクスポート)および fb として両方でピンニングされており、外部ピン解除が最初に行われる場合、xe_bo_unpin_external() は pin_count > 1 を正しく観察し、bo を pinned_link のままにします。fb アンピンが後に真の最後のピン解除(pin_count 1 -> 0)を実行したとき、pinned_link に触れることはなく、bo を無期限に xe->pinned.late.external にリンクしたままにします。その後、bo が解放されると、この古いリストエントリが解放されたメモリ内を指し示し、リストが破損し、次回リストがウォークまたはスプライスされたときに use-after-free のリスクがあります。xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() のバックアップオブジェクトのピン留め/ピン解除サイトには同じバイパス特性がありますが、ピン留めされたリストに bo を追加することは決してないため、この特定のリスト破損の問題の影響を受けません。pinned_link削除を xe_bo_account_unpin() に移動します。これは、真の 1 -> 0 pin_count 遷移の直前に、すでにすべてのピン解除パス(カーネル、外部、フレームバッファ、バックアップオブジェクト)で実行されています。list_del_init() はノード自体でのみ動作するため、この削除はリストに依存しず、bo がリンクされているリスト(外部またはkernel_bo_present)や、最終的なピン解除を実行しているコードパスに関係なく安全に実行できます。xe_bo_unpin_external() と xe_bo_unpin() の、現在冗長になっている明示的な list_del_init() 呼び出しをドロップします。v2: - 新しいパッチ v3: - 以前のパッチに対する変更に基づいてリベースされました。(コミット ca58d36a1f93af586ee93b340c9f9fd81312cc01 からのチェリーピッキング)(CVE-2026-98999)

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

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

  - drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and     xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on     whether the current call is the outermost pin or the final unpin. However, the same external bo's     pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the     bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all,     and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf     export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes     pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin     (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external     indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory,     corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup     object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same     bypass characteristic, though they never add their bo to a pinned list, so are not affected by this     particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which already     runs on every unpin path (kernel, external, framebuffer, backup object) right before the true 1 -> 0     pin_count transition. Since list_del_init() only operates on the node itself, this removal is list-     agnostic and safe to perform regardless of which list (external or kernel_bo_present) the bo happens to be     linked on, or which code path is performing the final unpin. Drop the now-redundant explicit     list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin(). v2: - New patch v3: - Rebased on     changes to previous patch. (cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01)     (CVE-2026-98999)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
371573	Linux Distros 未修補弱點：CVE-2026-98999	Nessus	Misc.	2026/10/23	2026/11/7	high
371573	Linux Distros 未修补的漏洞：CVE-2026-98999	Nessus	Misc.	2026/10/23	2026/11/7	high
371573	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98999	Nessus	Misc.	2026/10/23	2026/11/7	high
371573	Linux Distros Unpatched Vulnerability : CVE-2026-98999	Nessus	Misc.	2026/10/23	2026/11/7	high

偵測

搜尋 Plugin

high

high

high

high