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

  - smb： client：驗證 DFS 轉介 PathConsumed parse_dfs_referrals（） 會驗證回應是否包含固定轉介項目陣列，以及 for-next 上每個轉介字串位移。不過，回應也會包含稍後用於 DFS 路徑剖析的 PathConsumed 值。如果格式錯誤的回應提供的 PathConsumed 值大於搜尋名稱，則稍後的 DFS 剖析可以推進到路徑結尾之外。先針對搜尋名稱長度驗證 PathConsumed，然後再將 PathConsumed 儲存在剖析的轉介中。
    (CVE-2026-68343)

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

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

  - wifi：cfg80211：檢查非繼承時讀取的綁定元素 ID cfg80211_is_element_inherited（） 讀取候選元素的第一個資料八位元組 （id = elem->data[0]） 以在擴充非繼承清單中查詢它。它會在測試 elem->id 之後執行此動作，但未驗證元素是否確實具有資料八位元組。因此，零長度擴充元素（長度為 0 的WLAN_EID_EXTENSION）使其讀取元素末尾一個八位元組。一旦存在非繼承上下文，_ieee802_11_parse_elems_full（） 就會對幀的每個元素執行此檢查 -- 例如，在剖析 （重新）關聯回應中多鏈路元素的 per-STA 設定檔時，或未傳輸的 BSS 設定檔 -- 因此，來自 AP 的特製幀可以在元素剖析期間觸發一個八位元組 slab-of-bounds 讀取： 錯誤： KASAN：大小為 1 的 cfg80211_is_element_inherited 讀取中的 slab-out-of-bounds ...在 net/wireless/scan.c 中 當擴充元素不攜帶任何資料時，提前返回 （將元素視為繼承），以反映現有的空 ID 清單處理方式。
    該錯誤是透過在 KASAN 下對 ieee802_11_parse_elems_full（） 進行模糊測試而發現的。（CVE-2026-68402）

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

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

  - net/sched：針對並行的 get/put qdisc_get_rtab（） 和 qdisc_put_rtab（） 序列化 qdisc_rtab_list 突變進程全域單一鍊錶qdisc_rtab_list和沒有鎖定的普通非原子「int refcnt」。這只是安全的，因為每個呼叫者歷史上都持有 RTNL 互斥，它序列化所有費率表查找、插入和釋放。這個不變量不再成立。cls_flower 設定TCF_PROTO_OPS_DOIT_UNLOCKED，因此 tc_new_tfilter（） 為其保留 rtnl_held == false 並設定 TCA_ACT_FLAGS_NO_RTNL。該標誌通過 tcf_exts_validate_ex（） -> tcf_action_init（） -> tcf_action_init_1（） -> tcf_police_init（） 傳播，後者調用 qdisc_get_rtab（）/qdisc_put_rtab（），而 RTNL 互斥 NOT 持有。兩個RTM_NEWTFILTER請求在不同的 CPU 上，每個請求都添加了一個具有相同速率的警察動作的花過濾器，然後在qdisc_rtab_list和非原子參考上爭用，導致 kmalloc-2k 結構qdisc_rate_table的釋放後使用/雙重釋放。qdisc_rtab_list 是單一全域 （不是每個網路），因此損毀的物件會在全系統範圍內共用。錯誤：KASAN：qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90中的 slab-use-after-free 屬於大小為 2048 的快取 kmalloc-2k 保護qdisc_rtab_list和具有專用微調鎖的參照計數。qdisc_get_rtab（） 中的 （sleeping， GFP_KERNEL） 分配是在取得鎖定之前執行的;如果並行插入器同時添加了相同的表，則新分配的表將在鎖定下釋放，因此不會洩露重複項。qdisc_put_rtab（） 現在會遞減參照計數並取消相同鎖定下的連結。
    (CVE-2026-68138)

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

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

  - drm/amdgpu/gfx11：將 BUG_ON（） 替換為 WARN_ON（） 在這些情況下，不需要當機核心。
    （從提交 daa62107452d2451787c4248ca38fa2d1a0cbefd 中挑選）（CVE-2026-68246）

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

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

  - SMB/用戶端：當伺服器傳回的已分配範圍在目前 fallocate 位移之前啟動時，處理 fallocate smb3_simple_fallocate_range（） 中重疊的已分配範圍時，可以略過漏洞。跳過的漏洞不是零填充的，但 fallocate 仍然傳回成功。因此，稍後寫入該漏洞可能會因 ENOSPC 而失敗。函式會查詢配置的範圍，以便保留現有的內容，並只將零寫入孔中。不過，伺服器可能會傳回在目前 fallocate 位移之前開始的範圍。例如，假設 fallocate 要求是 [100， 400），而伺服器傳回的唯一分配範圍是 [0， 200）： 請求：[100， 400） 伺服器範圍：[ 0， 200） 已分配 正確：[100， 200） 已分配數據，跳過 [200， 400） 孔，零填充 當前：[100， 300） 跳過 [300， 400） 之後填零 當前代碼添加完整的服務器範圍長度， 200，到當前偏移 100 並移動到 300。結果，[200， 300] 中的孔被跳過而不填滿零。若要修正此問題，請只前進至已分配範圍中與目前 fallocate 位移重疊的部分。忽略在目前偏移之前結束的範圍，並拒絕其結束偏移溢位的範圍。這也可以防止格式錯誤的範圍長度造成越界零緩衝區讀取。（CVE-2026-68388）

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

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

  - wan：wanxl：僅在 BAR 映射後重置硬件 wanxl_pci_init_one（） 在映射 PLX BAR 之前將新配置的卡存儲在驅動程序數據中。然後，數個早期探查失敗會透過 wanxl_pci_remove_one（） 展開，包括無法配置一致狀態區域或還原 DMA 遮罩。
    wanxl_pci_remove_one（） 無條件調用 wanxl_reset（），而 wanxl_reset（） 解除參照 card->plx。在這些早期故障中，card->plx 仍為 NULL，因此錯誤路徑可能會取消參照 NULL MMIO 指標。只有在 BAR 對應存在時才發出硬體重設。wanxl_pci_remove_one（） 中的其餘清除作業已檢查是否已配置後續資源。此問題由靜態分析檢查程式發現，並經手動來源檢閱確認。（CVE-2026-68327）

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

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

  - Icinga 2 是一個開源監控系統。在 2.14.9、 和 2.15.42.16.2之前，剖析深度巢狀 JSON 可能會耗盡呼叫堆疊，因為巢狀深度沒有限制。未經身份驗證的網路用戶端可透過 TCP 連接埠 5665 上的 Icinga 2 服務存取受影響的 JSON 剖析路徑，從而允許遠端攻擊者使進程崩潰，但尚未證明可能的程式碼執行。此問題已在 、 2.15.4和 2.16.2版本中2.14.9修正。（CVE-2026-61551）

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

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

  - wifi： mac80211：將連結 RX 統計資訊 percpu 釋放給 RCU sta_remove_link（） 會立即釋放已移除的 MLO 連結的 RX 統計資訊 percpu 緩衝區，但僅將連結容器延遲到 RCU：
    sta_info_free_link（&alloc->info）;kfree_rcu（alloc， rcu_head）;RX 快速路徑讀取 rcu_read_lock 下的link_sta並寫入 percpu 統計資料。在移除之前解析link_sta的讀取器會保留指標。容器從kfree_rcu中保持活動狀態，因此讀取仍然有效。但它指向的 percpu 區塊已經被釋放。這需要uses_rss。那是pcpu_rx_stats存在的時候。完整的 STA 拆卸僅在 synchronize_net（） 之後釋放 deflink 統計資料。連結移除路徑沒有這樣的障礙。比賽在練習中很難獲勝，但自由賽仍然應該等待RCU。從單一 RCU 回呼中釋放連結及其資料，因此只有在讀取器耗盡後才會回收 percpu 區塊。(CVE-2026-68409)

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

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

  - ksmbd：將 destroy_previous_session（） 延遲到 NTLM 驗證之後 在 ntlm_authenticate（） 中，在驗證 NTLMv2 回應之前，會使用從用戶端提供的 NTLM Blob 使用者名稱欄位解析的使用者指標呼叫 destroy_previous_session（）。經過驗證的攻擊者可以將 NTLM Blob 使用者名稱設定為符合受害者帳戶，並將 PreviousSessionId 設定為受害者的工作階段識別碼;
    destroy_previous_session（） 會破壞受害者的工作階段，而 ksmbd_decode_ntlmssp_auth_blob（） 隨後會使用 -EPERM 拒絕請求。將 destroy_previous_session（） 和prev_id指派移至 ksmbd_decode_ntlmssp_auth_blob（） 傳回成功之後，並使用 sess->user 而不是預先驗證查詢結果。這與 krb5_authenticate（） 已經使用的順序相符，其中只有在 ksmbd_krb5_authenticate（） 傳回成功後才呼叫 destroy_previous_session（）。
    (CVE-2026-68130)

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

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

  - net： qrtr：將通訊端建立限制為初始網路命名空間 QRTR 將其整個連接埠和節點狀態保留在模組全域變數中，這些變數未按網路命名空間進行分割：qrtr_local_nid 是單一全域節點 ID （一律為 1），qrtr_ports 是單一全域 xarray。qrtr_port_lookup（） 和 qrtr_local_enqueue（） 在該全域狀態上運行，無需檢查網路命名空間，並且 qrtr_create（） 對建立通訊端的命名空間沒有限制。因此，在單獨的網路命名空間中建立AF_QIPCRTR通訊端的無權限進程，例如透過 unshare（CLONE_NEWUSER |CLONE_NEWNET） 可以將 QRTR 資料包 （包括控制平面訊息 （例如 QRTR_TYPE_NEW_SERVER） 傳送至另一個命名空間所擁有的 QRTR 通訊端，反之亦然。接收通訊端會將這類訊息視為來自節點識別碼 1，與合法的本機用戶端無法區分，從而破壞網路命名空間預期提供的隔離。QRTR 是對全域硬體端點（數據機和其他遠端處理器）的傳輸，並且沒有每個命名空間語義;其核心內名稱服務已僅在 init_net 中建立通訊端。將通訊端系列限制在初始網路命名空間內，就像其他非命名空間感知通訊端系列一樣 （請參閱 llc_ui_create（） 和 ieee802154 通訊端代碼）。
    (CVE-2026-68294)

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

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

  - drm/i915/mst：限制 DP MST ESI 服務迴圈 intel_dp_check_mst_status（） 中的迴圈會不斷為源自接收的中斷提供服務，而不會受到限制。將上限新增至中斷處理期間發生的新中斷，以免卡在可能停滯的接收裝置上。使用任意 32 次嘗試一次清除傳入的中斷。使用 Intel 產品安全性確認的 AI 輔助靜態分析發現。注意：該條件可能早於 Fixes： 標籤中的提交，但這大約可以追溯到反向移植成功的機會。在此之前，重試有一個 goto。（從提交 b4ea5272133059acb493cc36599071a9e852ec2e 中挑選）（CVE-2026-68241）

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

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

  - drm/amdgpu：修正 amdgpu_bo_create_reserved amdgpu_bo_create_reserved（） 中的 bo->pin 洩漏 只有在 *bo_ptr （結構amdgpu_bo **bo_ptr 作為輸入參數） 為 NULL 時才會配置新的 BO，當
    *bo_ptr 為非空值。但它會無條件地保留、固定、gart 分配和映射 BO。
    當再次傳入相同的非 NULL BO 指標時，例如存在於 adev 中的韌體緩衝區，並在每次恢復/cp_resume/啟動時在 AMDGPU_FW_LOAD_DIRECT 下重新載入，amdgpu_bo_pin（） 只會無條件地增加pin_count，但匹配的拆卸只會取消固定一次，因此pin_count永遠不會降到零，因此 TTM 無法移動， 交換或驅逐 BO，導致 BO 洩漏。此認可會藉由在建立時只釘選一次 bo 來修正此問題，而且重複呼叫不再採用額外的釘選參考。（從提交 3ddc0ae76202c447b6aec61e907b852bc94671cf 中挑選）（CVE-2026-68234）

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

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

  - wifi：brcmfmac：使release_scratchbuffers冪等 brcmf_pcie_release_scratchbuffers（） 使用 dma_free_coherent（） 釋放 shared.scratch 和 shared.ringupd DMA 緩衝區，但之後不會清除指標，這與同級 release_ringbuffers（） 不同，同級 （） 在發佈時將 commonrings/flowrings/idxbuf 設為 NULL。
    bus_reset .reset 回呼 （brcmf_pcie_reset） 和 brcmf_pcie_remove（） 呼叫release_scratchbuffers。
    當在移除之前執行重設拆卸時，移除自己的拆卸會在已釋放的 DMA 配置上第二次呼叫 dma_free_coherent（）。NULL 釋放後的指標，符合 release_ringbuffers（），因此更新的版本會觀察到配置已釋放。此修補程式使重複的循序發布變得安全;重設工作存留期由下列修補程式單獨處理。此問題是由內部靜態分析工具發現的。（CVE-2026-68192）

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

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

  - drm/xe： 保留匯入 BO 的 dma-buf 參照 匯入的 dma-buf BO 會建立為 ttm_bo_type_sg BO，其保留物件是匯出商的 dma_buf->resv。不過，匯入程式只會在成功 dma_buf_dynamic_attach（） 之後取得 dma-buf 參照。在那之前，沒有任何東西能讓匯出器保持活動狀態，因此，如果匯出器在 BO 仍在參照其 resv 時被釋放，則稍後對該 resv 的存取是釋放後使用： 哎呀：一般保護錯誤，可能是非規範位址 0x6b6b6b6b6b6b6b9c 工作佇列：ttm ttm_bo_delayed_delete [ttm] RIP：0010：mutex_can_spin_on_owner+0x3f/0xc0 這可以透過兩條路徑實現：
    - dma_buf_dynamic_attach（） 失敗，或 - ttm_bo_init_reserved（） 在建立 BO 期間失敗。在這兩種情況下，BO 都已經有指向匯出程式 resv 的 bo->base.resv，並且 sg BO 總是透過 ttm_bo_delayed_delete（） 拆除，這會以非同步方式鎖定 bo->base.resv - 可能在匯出程式被釋放之後。在 ttm_bo_init_reserved（） 之前獲取 xe_bo_init_locked（） 中的 dma-buf 參照，因此它也涵蓋了那裡的創建失敗，並在 xe_ttm_bo_destroy（） 中釋放它。參照會在整個 BO 存留期內保留，讓共用的 resv 在每條路徑上保持運作狀態。v2： - 重構了修正，以避免在 dma_buf_dynamic_attach（） 成功之前建立匯入的 sg BO。- 附加 importer_priv == NULL，並使invalidate_mappings忽略不完整的匯入。v3： - 刪除了 xe 端重新排序方法，因為當 dma_buf_dynamic_attach（） 發佈附件時，importer_priv必須有效。- 根據 Christian 在 v1 線程上的建議，鍵控檢查 import_attach 而不是完全刪除 sg 保護。
    - 在單一 TTM 修補程式中同時修正 xe 和 amdgpu。v4： - 將import_attach檢查移至 dma_resv_copy_fences（） 之後，以便在返回以成功匯入之前複製柵欄 （Thomas）。- 從提交訊息中移除 exporter-alive 宣告 （Thomas）。v5： - 新增 drm/xe 修補程式，以在連接成功之前將匯入的 sg BO 排除在 LRU 之外;如果 BO 已經是 LRU 可見的，則僅 TTM 修正對於 xe 來說是不夠的。
    （Thomas） v4 修補程式： https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - 修補程式 1 （drm/ttm） 繼承了 v4 中 Christian 的 Reviewed-by。 v6： - 根據 Thomas 的建議重新設計了修正。不要使用 TTM resv 個別化 （v1-v5） 加上 xe off-LRU/放置處理 （v5），只需保留匯入的 BO 存留期的 dma-buf 參照，這樣當 BO 仍在參照它時，共用的 resv 就永遠無法被釋放。單一 xe 補丁，沒有 TTM 更改。（Thomas） - 在 ttm_bo_init_reserved（） 之前引用 xe_bo_init_locked（），因此也涵蓋了 TTM 創建失敗 （Thomas）。- 刪除了 v5 系列 （drm/ttm + drm/xe off-LRU）;非 LRU 方法也通過 ttm_bo_pipeline_gutting（） 在 CI BAT 中回歸，創建了一個比出口器更長壽的幽靈 BO。v5 的連結： https://patchwork.freedesktop.org/series/169984/ v7： - 將變更日誌移至 --- 上方，使其保留在提交訊息中。- 將變更記錄項目從舊到最新重新排序。
    （托馬斯）（從提交 3516f3fae6be35642f8f06f8a218da6425c0306a 中挑選）（CVE-2026-68266）

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

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

  - pppoe：在 dev_hard_header（） 之後重新載入標頭指標 pppoe_sendmsg（） 在呼叫 dev_hard_header（） 之前儲存指向 PPPoE 標頭的指標。允許裝置標頭回呼重新配置 skb 頭，使指標失效。當第一個非乙太網路連接埠新增至空白團隊裝置時，傳送在 copy_from_user（） 中遭到封鎖時，可能會發生這種情況。然後，團隊委派的 GRE 標頭回呼會展開 skb 標頭。PPPoE 隨後會透過過時指標將 6 個位元組寫入釋放的磁頭。建立裝置標頭後，透過 skb 的網路標頭位移重新載入 PPPoE 標頭。pskb_expand_head（） 在重新定位頭部時更新該偏移量。（CVE-2026-68121）

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

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

  - wifi：cfg80211：驗證 PMSR FTM 前導碼範圍 PMSR FTM 要求剖析接受列舉 nl80211 前導碼範圍之外的前導碼值。在使用原則的剖析器功能位元測試中使用超出範圍的值之前，先拒絕這些值。[刪除不必要的檢查]（CVE-2026-68406）

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

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

  - iommu/amd：等待完成，而不是在 iommu_completion_wait（） 中儘早返回need_sync這是該 IOMMU 後方所有網域和裝置共用的每個 IOMMU 旗標。每當命令以 sync == true 排入佇列時，就會設定它，並在完成等待 （CWAIT） 命令排入佇列時清除。不過，清除的need_sync僅表示涵蓋的 CWAIT 已排入佇列，並不表示所有先前排入佇列的命令實際上已在硬體中完成。iommu_completion_wait（） 無鎖定地讀取need_sync，並在它為 false 時提前返回。這會破壞阻塞，直到所有先前排入佇列的命令在多 CPU 案例中完成合約： CPU2：佇列 inv-B => need_sync = true CPU1：佇列 CWAIT（N）;need_sync = false;then wait_on_sem（N） CPU2：讀取 need_sync == false => 傳回 0 （不用等待！CPU2 返回而不等待任何序號，即使其 inv-B 可能尚未完成 （在 inv-B 之後排入佇列的 CWAIT （N） 尚未發出訊號）。例如，CPU2 繼續釋放頁面，而 IOMMU 仍然可以遍歷過時的翻譯，從而打開一個釋放後使用窗口。這是旗幟意義上的邏輯競賽，而不是記憶體可見性問題，因此僅靠障礙無濟於事。在不失去避免冗餘 CWAIT 命令的最佳化的情況下修復它：在測試need_sync之前採取 iommu->lock，當它為 false 時，不要提前返回，而是等待最後分配的序號 （cmd_sem_val）。由於 need_sync == false 表示在最後一個 CWAIT 之後沒有同步命令排入佇列，因此該 CWAIT 在每個尚未完成的命令之後都會以 FIFO 排序，因此等待其序號可確保所有先前的命令 （可能由另一個 CPU 排入佇列） 都已完成。擱置工作的一般路徑不會變更，且不會發出額外的硬體命令。（CVE-2026-68329）

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

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

  - wifi：ath6kl：修正 aggr_reset_state（） 中的釋放後使用 aggr_reset_state（） 函數在繼續刪除 TID 狀態之前以及在 aggr_module_destroy（） 等調用程式釋放結構之前，將 timer_delete（） （非同步） 用於聚合計時器。如果計時器回呼 （aggr_timeout） 在呼叫 aggr_reset_state（） 時正在執行，則回呼將繼續存取aggr_conn欄位，例如 rx_tid[] 和 stat[]，這些欄位可能會立即被 aggr_module_destroy（） 中的 kfree（aggr_info->aggr_conn） 釋放。
    此外，計時器回呼可以在 aggr_reset_state（） 執行時透過 mod_timer（） 重新布防自身，從而產生更複雜的爭用情形。請改用 timer_delete_sync（） 來確保任何執行中的計時器回呼在傳回之前已完成。（CVE-2026-68198）

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

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

  - drm/i915/bios：範圍檢查 LFP 資料區塊 panel_type2 雖然來自 LFP 資料區塊的panel_type已進行範圍檢查，但 panel_type2 則沒有。新增一些範圍檢查的助手，使用它們不僅可以檢查panel_type2，還可以提高面板類型選擇的清晰度和正確性。使用 Intel 產品安全性確認的 AI 輔助靜態分析發現。v2： - 修正提交訊息拼寫錯誤 （Micha） - 新增 is_panel_type_pnp（） （Ville） （從提交 c9ebe5d2f25729d6cfbbb1235d640bf67f9275df 中挑選） （CVE-2026-68247）

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

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

  - dpaa2-switch：將 MAC 端點裝置置於中斷連接狀態 fsl_mc_get_endpoint（） 會傳回具有透過 device_find_child（） 取得的參照的 MAC 端點裝置。交換器埠連接路徑會將該裝置儲存在 mac->mc_dev 中，並在連線的 MAC 物件存留期內保留。但是，中斷連線路徑只會關閉 MAC 並釋放dpaa2_mac物件。它不會丟棄儲存在 mac->mc_dev 中的端點裝置參照，因此每次成功連線都會在稍後中斷 MAC 連線時洩漏該裝置參照。
    在釋放 dpaa2_mac 物件之前，先刪除端點裝置參照。（CVE-2026-68333）

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

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

  - wifi：brcmfmac：修正 802.1X-SHA256 呼叫追蹤警告 基於wpa_auth作為1x_256模式，需要與BRCMF_PROFILE_FWSUP_1X設定use_fwsup。或者調用 brcmf_cfg80211_set_pmk（） 時會發生追蹤警告。[ 4481.831101] ------------[ 切到這裡 ]------------ [ 4481.831102] 警告： CPU：
    1 PID：2997，位於 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c：7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...][ 4481.831202] 呼叫追蹤： [ 4481.831204] [4481.831205<TASK>] nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233] genl_family_rcv_msg_doit+0xea/0x150 [4481.831237] genl_rcv_msg+0x104/0x240 [ 4481.831239] ？ cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [4481.831257] ？ genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259] netlink_rcv_skb+0x4e/0x100 [4481.831261 ] genl_rcv+0x24/0x40 [ 4481.831262] netlink_unicast+0x236/0x380 [ 4481.831264] netlink_sendmsg+0x250/0x4b0 [ 4481.831266] sock_sendmsg+0x5c/0x70 [ 4481.831269]
    ____sys_sendmsg+0x236/0x2b0 [ 4481.831271] ？ copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]
    ___sys_sendmsg+0x86/0xd0 [ 4481.831274] ？ avc_has_perm+0x8c/0x1a0 [ 4481.831276] ？ preempt_count_add+0x6a/0xa0 [ 4481.831279] ？ sock_has_perm+0x82/0xa0 [ 4481.831280]
    __sys_sendmsg+0x57/0xa0 [ 4481.831282] do_syscall_64+0x38/0x90 [ 4481.831284] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP：0033：0x7fd270d369b4 （CVE-2026-68304）

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

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

  - 藍牙：hci_sync：保護 UUID 清單遊走 hci_sync轉換將裝置類別和 EIR 產生從在 hdev->lock 下建置的 HCI 要求移至非同步命令同步處理工作。背景工作程式保留 hdev->req_lock，但該鎖定不會針對 add_uuid（） 和 remove_uuid（） 序列化對 hdev->uuid 的存取，這會更新 hdev->lock 下的清單。因此可能會發生下列交錯：
    CPU0 （命令同步工作） CPU1 （管理通訊端） 從清單擷取 uuid list_del（&uuid->list） kfree（uuid） 讀取 uuid->size KASAN 會報告產生的釋放後使用： 錯誤： KASAN：eir_create+0xb8f/0xee0 中的 slab-use-after-free 透過任務 kworker/u17：0/87 在 addr ffff88810dbd8620 讀取大小 1 工作佇列：hci0 hci_cmd_sync_work 呼叫追蹤：eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 由任務 86 分配： __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 由任務 92 釋放：
    __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 在產生和提交裝置類別和 EIR 快照時保持 hdev->lock。在傳送 HCI 命令之前釋放它，這樣控制器等待就不會在裝置鎖定下發生。這可以保護這些路徑中的所有 UUID 清單遍歷，並還原在命令同步轉換中遺失的序列化。
    (CVE-2026-68189)

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

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

  - MCTP： serial：處理零長度框架以防止 rx 緩衝區溢位 MCTP 序列接收狀態機器在 mctp_serial_push_header（） 案例 2 中讀取框架長度位元組，並僅對其進行上界驗證：
    if （c > MCTP_SERIAL_FRAME_MTU） { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0;
    dev->rxstate = STATE_DATA;... }長度為零會通過此檢查，因此 rxlen 設定為 0，狀態機器會前進至 STATE_DATA。在 mctp_serial_push（） STATE_DATA中，傳入位元組被存儲，並在終止符之前遞增 rxpos dev->rxbuf[dev->rxpos] = c;dev->rxpos++;dev->rxstate = STATE_DATA;
    if （dev->rxpos == dev->rxlen） { dev->rxpos = 0; dev->rxstate = STATE_TRAILER; }使用 rxlen == 0 時，rxpos == rxlen 終止符永遠無法觸發 （rxpos 在第一個資料位元組上已經是 1），因此後續位元組會寫入固定 74 位元組 rxbuf 的結尾，這是 netdev 專用區域的最後一個成員。
    後面的每個資料位元組都是攻擊者控制的 1 位元組越界堆積寫入，溢位一直持續到幀 （0x7e） 或逸出位元組重設剖析器為止 -- 實際上是無限的。若要達到此目的，需要CAP_NET_ADMIN附加N_MCTP行紀律，並啟動產生的 mctpserialN netdev，之後位元組會透過 tty 接收路徑到達。將零長度的框架直接路由到 STATE_TRAILER 而不是STATE_DATA。拖尾/框架位元組仍會被消耗，並且幀解析為 MCTP 核心拒絕的零長度 skb;剖析器永遠不會輸入具有 rxlen == 0 的STATE_DATA，因此無法再發生越界寫入。KASAN，在 0x7e 0x01 0x00 後面接著資料位元組的框架上 （在此變更之前）： UBSAN： array-index-out-of-bounds 在 drivers/net/mctp/mctp-serial.c：370 中，索引 74 超出類型「u8 [74]」的範圍 錯誤：KASAN：mctp_serial_tty_receive_buf 中的 slab-out-of-bounds 在 addr 處寫入大小為 1 ...由任務 kworker/u16：0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc 由任務 152 分配： alloc_netdev_mqs mctp_serial_open v2：將零長度框架路由到 STATE_TRAILER 而不是 STATE_ERR，因此仍會消耗尾部/框架位元組 （Jeremy Kerr）。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。（CVE-2026-68124）

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

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

  - 藍牙：hci_uart：當write_work取消HCI_UART_SENDING位時清除HCI_UART_SENDING tx_state表示write_work處於擱置狀態並阻止再次排隊。目前，取消 hci_uart_close（） 中的工作時不會清除此位，如果裝置處於擱置狀態，則稍後重新開啟裝置時，會封鎖未來的寫入write_work。透過取消作品時清除HCI_UART_SENDING來修復。此外，使用 disable_work_sync + enable_work 而不是僅使用 cancel_work_sync 來安全地清除tx_skb。hci_uart_flush（） 會清除原始 tx 佇列，以便我們可以取消那裡的擱置write_work，而不是只在 hci_uart_close（） 中執行。在佇列排清之後，重新啟用並可能將工作重新排入佇列。（CVE-2026-68085）

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

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

  - userfaultfd：防止註冊特殊的 VMA Vova Tokarev 說： userfaultfd 允許在影子堆疊 VMA 上註冊。透過 userfaultfd 存取，您可以在影子堆疊上註冊、捨棄頁面...並透過UFFDIO_COPY插入包含所選傳回地址的頁面。更新 vma_can_userfault（） 以拒絕VM_SHADOW_STACK。在上面，也拒絕VM_SPECIAL，這樣如果驅動程式要實作vm_uffd_ops，就無法向 userfaultfd 註冊特殊的 VMA。由於VM_SPECIAL包含已設定但 hugetlb 的 VM_DONTEXPAND，因此請從VM_SPECIAL檢查中排除 hugetlb VMA。（CVE-2026-68166）

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

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

  - net： gro：修正具有排清標記的 skbs 的雙重彙總 提交 0ab03f353d36 （net-gro：修正收到 GSO 封包時的 GRO 排清。） 對 skb_gro_receive（） 新增了排清檢查，但 skb_gro_receive_list（） 缺少相同的驗證。因此，標有 NAPI_GRO_CB（skb）->flush 的封包仍可能被重新彙總。這允許具有現有frag_list的已 GRO 封包重新聚合到新的 GRO 會話中，從而破壞frag_list鏈結構。當 skb_segment（） 嘗試解壓縮這些格式錯誤的封包時，它會遇到無效狀態並觸發核心錯誤。場景 （網路共享/裝置轉送）： 1.
    驅動程式：透過 LRO 與 frag_list 2 產生彙總封包 P1。開發 A：接收彙總的碎片清單封包和排清旗標集 3。Dev A：重新進入 GRO，skb_gro_receive_list（） 稱為 4。遺漏排清檢查允許重新彙總，儘管有排清旗標 5。Frag_list鏈損壞（循環或懸空引用） 6.
    Dev B： TX 路徑呼叫 skb_segment（），在損毀的 frag_list 上損毀 skb_segment（） 中的根本原因： 在 ~4891 行進行檢查： if （hsize <= 0 &; i >= nfrags &&; skb_headlen（list_skb） &; （skb_headlen（list_skb） == len || sg）） { 當 frag_list 因雙重聚合而損毀時，當 list_skb 是來自 skb->next 的 NULL 指標時， skb_headlen（list_skb） 取消參照 NULL/損毀的指標。呼叫追蹤：skb_headlen（空 skb） skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action 修正：將 NAPI_GRO_CB（skb）->flush 驗證新增至 skb_gro_receive_list（） 中的提前返回檢查， 符合 skb_gro_receive（） 的防禦程式設計模式。（CVE-2026-68136）

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

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

  - ata： sata_dwc_460ex：僅在註冊 IRQ 處理常式後啟用 SATA 中斷 sata_dwc_enable_interrupts（） 在 platform_get_irq（） 和 ata_host_activate（） 之前呼叫，使 SATA 控制器的中斷遮罩在沒有註冊處理常式的情況下啟用。如果後續步驟失敗 （irq request、phy init 等），或控制器在探測期間宣告中斷，則 irq 行可能會在沒有處理常式的情況下觸發，進而造成虛假中斷風暴。將 sata_dwc_enable_interrupts（） 移至 ata_host_activate（） 之後，以便只有在註冊處理常式且核心完全初始化後，中斷才會解除遮罩。
    (CVE-2026-68395)

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

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

  - dpaa2-eth：將 MAC 端點裝置置於中斷連線狀態 fsl_mc_get_endpoint（） 會傳回具有透過 device_find_child（） 取得的參照的 MAC 端點裝置。乙太網路連線路徑會將該裝置儲存在 mac->mc_dev 中，並在連線的 MAC 物件的存留期內保留。但是，中斷連線路徑只會在釋放 dpaa2_mac 物件之前中斷連線並關閉 MAC。它不會丟棄儲存在 mac->mc_dev 中的端點裝置參照，因此每次成功連線都會在稍後中斷 MAC 連線時洩漏該裝置參照。關閉 MAC 之後、釋放 dpaa2_mac 物件之前，請刪除端點裝置參照。（CVE-2026-68331）

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

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

  - wifi： carl9170：修正 TX 狀態處理常式中從差 2 讀取的 OOB carl9170_tx_process_status（） 中的邊界檢查使用「i > （（cmd->hdr.len / 2） + 1）'，這會偏離 2，當韌體控制的 hdr.ext 超過 hdr.len/2 時，允許在有效 _tx_status 項目之後進行 2 次額外迭代。使用正確的比較「i >= （cmd->hdr.len / 2）」進行修正。（CVE-2026-68350）

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

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

  - 藍牙：RFCOMM：修正 set_termios rfcomm_tty_set_termios（） 中的會話 UAF，無需rfcomm_mutex測試 dlc->session，然後將指標傳遞至 rfcomm_send_rpn（）。後者會同時取消參照 session->initiator 和 session->sock。同時，krfcommd 可以在保持 rfcomm_mutex 時取消連結 DLC 並釋放會話。爭用可以按如下方式進行： TTY ioctl 任務 krfcommd -------------- --------載入 dlc->session 輸入 rfcomm_send_rpn（） 鎖定rfcomm_mutex清除 dlc->session 釋放會話解鎖rfcomm_mutex讀取 session->initiator KASAN 報告： 錯誤： KASAN：slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 任務 poc/92 在 addr ffff88810012a850 讀取大小 4 呼叫追蹤：
    rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 由任務 92 分配：rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 由任務 68 釋放： kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 新增 rfcomm_dlc_send_rpn（），在驗證 DLC 是否仍附加並傳送 RPN 框架時保留rfcomm_mutex。讓 TTY 路徑使用協助程式並刪除其解鎖的工作階段檢查。這會讓工作階段透過框架建構和通訊端傳送保持有效。（CVE-2026-68188）

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

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

  - mac802154：llsec：拒絕短於驗證標籤的幀 llsec_do_decrypt_auth（） 將 AEAD 要求的關聯資料長度計算為 assoclen += datalen - authlen;其中 datalen 是 MAC 標頭之後的位元組數，authlen （4、8 或 16） 是驗證標籤的長度。沒有任何內容可以驗證框架實際上至少攜帶 authlen 負載位元組。負載短於標籤的安全框架會使 datalen - authlen 為負;然後，assoclen 作為接近 4 GiB 的無符號值傳遞給 aead_request_set_ad（），因此 crypto_aead_decrypt（） 會遠離僅跨越實際幀的散點清單的末尾。幀完全由攻擊者控制，並從無線電範圍內的任何IEEE 802.15.4 對等體到達此路徑。拒絕承載短於減法前驗證標籤的影格。在 KASAN 核心上動態重現為 AEAD 散佈路徑中的一般保護故障，並確認修正。（CVE-2026-68125）

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

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

  - drm/amdgpu/gfx9.4.3：將 BUG_ON（） 替換為 WARN_ON（） 在這些情況下，不需要當機核心。
    （從提交 5676593d08998d7a6d9e2d51d6b54b3820e3755c 中挑選）（CVE-2026-68112）

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

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

  - audit：修正 audit_dupe_exe（） 中的遞迴鎖定鎖死 複製可執行檔相關規則時，稽核子系統中會發生鎖死。當檔案被移動時（例如，透過 do_renameat2（）），VFS 層會鎖定父目錄 （I_MUTEX_PARENT），從而同步觸發fsnotify_move事件。如果現有的可執行稽核規則符合正在移動的檔案，則稽核子系統會擷取此事件並呼叫 audit_dupe_exe（） 以複製監看並更新規則。然後，audit_alloc_mark（） 會呼叫 kern_path_parent（） 來解析路徑，導致盲目嘗試取得任務已持有的完全相同的I_MUTEX_PARENT鎖定，從而導致下列遞迴鎖定鎖死：
    ============================================ 警告：偵測到可能的遞迴鎖定 6.12.0-55.27.1.el10_0.x86_64+debug #1 未受污染 -------------------------------------------- mv/5099 正在嘗試取得鎖定：ffff888132845358 （&inode->i_sb->s_type->i_mutex_dir_key/1）{+.+.}-{3:3}，位於：
    __kern_path_locked+0x10a/0x2f0，但任務已經保持鎖定：ffff888132846b58 （&inode->i_sb->s_type->i_mutex_dir_key/1）{+.+.}-{3:3}，在：lock_two_directories+0x13f/0x2b0可能有助於我們調試的其他資訊： 可能的不安全鎖定場景：CPU0 ---- lock（&inode->i_sb->s_type->i_mutex_dir_key/1）;lock（&inode->i_sb->s_type->i_mutex_dir_key/1）;鎖死
    可能是因為缺少鎖巢狀表示法 mv/5099 持有的 6 個鎖： #0： ffff888112a9c440 （sb_writers#13） at： do_renameat2+0x34c/0xbc0 #1： ffff888112a9c790 （&type->s_vfs_rename_key#3） at：
    do_renameat2+0x415/0xbc0 #2：ffff888132846b58 （&inode->i_sb->s_type->i_mutex_dir_key/1） 位於：
    lock_two_directories+0x13f/0x2b0 #3：ffff888132845358 （&inode->i_sb->s_type->i_mutex_dir_key/5） 在：
    lock_two_directories+0x175/0x2b0 #4：ffffffffb3a1fb10 （&fsnotify_mark_srcu） 網址：fsnotify+0x454/0x28a0 #5：
    ffffffffaf886230 （audit_filter_mutex） at： audit_update_watch+0x36/0x11e0 堆疊回溯： 呼叫追蹤：
    <TASK> dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00
    __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230
    __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP： 0033：0x7f0491fe8c4e 代碼： 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP： 002b：00007ffc7210bf38 EFLAGS：00000246 ORIG_RAX：0000000000000108 RAX：ffffffffffffffda RBX：00000000000000000 RCX：
    00007f0491fe8c4e RDX：0000000000000003 RSI：00007ffc7210e6c8 RDI：00000000ffffff9c RBP：0000000000000000000 ： 00000000000000000 R09： 0000000000000001 R10： 00005575eb2dae2a R11： 0000000000000246 R12：R08
    00005575eb2dae2a R13： 00007ffc7210e6c8 R14： 0000000000000003 R15： 00000000ffffff9c </TASK> 透過執行以下指令碼，可以一致地重現上述鎖死： audit-dupe-exe-deadlock.sh -------------------------- #！/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl
    -a always，exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo 此修補程式透過引入結構audit_watch_ctx將 fsnotify 事件內容向下傳遞至 audit_alloc_mark（） 來修正此問題。透過利用事件提供的已解析目錄 inode，我們繞過了 kern_path_parent（） 路徑 resol ---truncated--- （CVE-2026-68096）

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

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

  - drm/i915：active_instance 中錯誤時傳回 NULL 避免在GFP_ATOMIC配置期間因為 OOM 而導致節點為 NULL 時傳回 &node->base。使用 Intel 產品安全性確認的 AI 輔助靜態分析發現。（從提交 6029bc064f0b1bac184203a50fbaaf070fa18832 中挑選）（CVE-2026-68248）

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

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

  - ALSA： seq：關閉析構函式中重新開啟的佇列計時器 queue_delete（） 會關閉佇列計時器，然後釋放它。snd_seq_timer_close（） 清除 q->timer->timeri。然後snd_use_lock_sync（） 耗盡借款人，而 snd_seq_timer_delete（） 釋放 q->timer。借款人可以在該窗口內重新打開計時器。在佇列取消連結之前採用 queueptr（） use_lock參照的SET_QUEUE_CLIENT會在關閉後執行 snd_seq_timer_open（）。Open 僅在設定 timeri 時才拒絕重新開啟，而 close 剛剛清除了它，因此它會重新開啟 timeri。snd_seq_timer_delete（） 不會關閉該執行個體。它的 snd_seq_timer_stop（） 是無操作的，因為運行是先清除的。因此，它會在實例仍然存在的情況下釋放 q->timer。接下來會釋放佇列。執行個體會保留在全域計時器上，callback_data指向已釋放的佇列。未鎖定佇列上的非擁有者 START 會武裝它。下一個刻度會解除參照 snd_seq_timer_interrupt（） 中釋放的佇列。可由具有 /dev/snd/seq 存取權的無權限使用者存取。無需 CAP 也無需佇列擁有權。關閉析構函式中任何滯留的執行個體。在那裡，->timeri 無法再更改：佇列已取消連結，所有use_lock借款人都已耗盡，因此沒有 snd_seq_queue_use（） 可以重新開啟它。在清除 q->timer 之前將其關閉。snd_timer_close（） 等待任何正在進行的 snd_seq_timer_interrupt（） 完成，並且該回呼仍讀取 q->timer（透過 snd_seq_check_queue（）），因此 q->timer 必須保持有效，直到它耗盡為止。（CVE-2026-68202）

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

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

  - drm/amd/display：修正暫停期間的 ISM dc_lock鎖死 [原因] 在影片播放時，在暫停/恢復期間觀察到系統懸置。amdgpu_dm_ism_disable（） 在 dc_lock 下呼叫，並透過 disable_delayed_work_sync（） 等待 ISM 延遲工作。工作處理程式本身會採取dc_lock，當工作者在暫停時間飛行時產生 ABBA 鎖死。[如何]將停用路徑分成兩個階段，並具有相反的鎖定合約： 1. amdgpu_dm_ism_disable（） -- 靜默工作者，不得持有dc_lock。2.
    amdgpu_dm_ism_force_full_power（） （新） -- 將 ISM FSM 驅動回FULL_POWER_RUNNING，必須保持dc_lock。（CVE-2026-68364）

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

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

  - media： rtl2832_sdr：在 start_streaming（） 失敗時傳回佇列的緩衝區 vb2 架構會在呼叫 start_streaming（） 之前，透過 buf_queue（） 將緩衝區交給驅動程式。如果 start_streaming（） 傳回錯誤，而沒有先透過 vb2_buffer_done（） 傳回這些緩衝區，則 vb2_start_streaming（） 會觸發 WARN_ON（owned_by_drv_count） 並且佇列的緩衝區會洩漏。rtl2832_sdr_start_streaming（） 有多個錯誤路徑擊中了這個陷阱：兩個直接的早期返回（-ENODEV、-ERESTARTSYS），加上六個「goto err」路徑，涵蓋子開發s_power、調諧器設定、ADC 設定、串流緩衝區分配、urb 分配和 urb 提交失敗。它們都沒有傳回佇列的緩衝區。原始函式沒有明顯的成功退出，直接落入 err 標籤，該標籤以前只執行 mutex_unlock 和返回 ret。因此，在錯誤時新增佇列緩衝區清除必須與明確的成功傳回配對;否則，每次成功啟動也會耗盡緩衝區佇列並終止串流。新增該成功傳回，然後在 err 標籤處和每次提前傳回之前新增 rtl2832_sdr_cleanup_queued_bufs（）。
    清理協助程式會採用vb2_buffer_state引數，以便start_streaming錯誤路徑可以傳遞VB2_BUF_STATE_QUEUED （如使用者空間在失敗時所預期start_streaming），而 stop_streaming 會保留其現有的VB2_BUF_STATE_ERROR語意。這反映了提交 4cf3b6fd54eb 中的 uvcvideo 修正 （media：
    uvcvideo：在 start_streaming（） 失敗時傳回佇列的緩衝區）。錯誤標籤仍然不會復原失敗步驟之前可能發生的 power_ctrl （） 、frontend_ctrl （） 、POWER_ON 旗標或資料流程/URB 配置。這些是不同類別的預先存在的洩密事件，此處不涉及。
    (CVE-2026-68213)

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

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

  - wifi： ath6kl：修正從 TX 完整處理常式中韌體num_msg讀取的 OOB 韌體控制的num_msg欄位 （u8， 0-255） 驅動 ath6kl_wmi_tx_complete_event_rx（） 中的迴圈，而不針對緩衝區長度進行驗證。當韌體傳送膨脹的num_msg時，這允許透過 WMI 事件緩衝區進行最多 1020 位元組的越界讀取。新增緩衝區是否足夠大，以容納固定結構和num_msg可變長度項目的檢查。（CVE-2026-68353）

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

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

  - drop_monitor：修正 64 位元屬性的大小計算 net_dm_packet_report_fill（） 和 net_dm_hw_packet_report_fill（） 使用 nla_put_u64_64bit（） 附加 64 位元屬性 （NET_DM_ATTR_PC 和 NET_DM_ATTR_TIMESTAMP）。在沒有CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS的 32 位元架構上，nla_put_u64_64bit（） 可能會附加一個 4 位元組的 NET_DM_ATTR_PAD 屬性以進行 64 位元對齊。然而，net_dm_packet_report_size（） 和 net_dm_hw_packet_report_size（） 使用 nla_total_size（sizeof（u64）） 而不是 nla_total_size_64bit（sizeof（u64）），預算為 12 位元組，而不是最多 16 位元組。這種對 SKB 大小的低估可能會導致隨後調用 __nla_reserve（） 或 skb_put（） 時出現 skb_over_panic（）。在兩個大小計算中使用 nla_total_size_64bit（sizeof（u64）） 來修正此問題。（CVE-2026-68287）

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

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

  - sctp：修正 sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid（） 中auth_chunk_list容量檢查使用 SCTP_NUM_CHUNK_TYPES （20） 作為 ep->auth_chunk_list 的容量限制，允許它最多容納 20 個區塊項目 （param_hdr.length 最多 24 個）。但是，struct sctp_cookie中的複製目的地 asoc->c.auth_chunks 只有 SCTP_AUTH_MAX_CHUNKS （16） 個項目 （20 位元組）。當新增區塊超過 16 個時，sctp_association_init（） memcpy 會使目的地溢位最多 4 個位元組。使用 SCTP_AUTH_MAX_CHUNKS 作為容量限制來修正，以符合目的地容量。（CVE-2026-68320）

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

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

  - drm/amdgpu/gfx：修正更乾淨的著色器 IB 緩衝區溢位 更乾淨的著色器 sysfs 路徑會配置 16 dword （64 位元組） IB，但錯誤地填入 （align_mask + 1） dword。在 GFX 環上，align_mask 0xff，因此迴圈將 256 個 dword 寫入 64 位元組緩衝區，導致核心頁面錯誤。IB 只需要是最小的 NOP shell 即可排程工作;更乾淨的著色器本身會透過 emit_cleaner_shader（） 在環上發出。
    填入 16 個 dword 以符合分配。v2：使用ib_size_dw變數 （Lijo） （從提交 bf21af331ebf72d0935fd70c73192414a422c03a 中挑選） （CVE-2026-68276）

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

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

  - binfmt_elf_fdpic：僅遵循第一個PT_INTERP程式標頭掃描處理來自巢狀掃描迴圈中的交換器的PT_INTERP，因此其中斷會離開交換器，而不是迴圈。攜帶多個PT_INTERP的二進位檔會再次執行案例，並覆寫interpreter_name和解譯器。先前的名稱分配洩露，先前的解譯器參照以及寫入拒絕 open_exec（） 也會洩露。拒絕永遠不會釋放，因此只要系統執行，檔案就會保持不可寫入狀態。無特權的呼叫者使用特製的二進位檔案來達到此目的，並隨意重複它。binfmt_elf在第一個PT_INTERP停止。在這裡做同樣的事情。此缺陷可以追溯到 91808d6ebe39 在 v2.6.11 中引入的 pre-git 歷程記錄樹狀結構中引入驅動程式 （[PATCH] FRV：新增 FDPIC ELF 二進位格式驅動程式）。
    (CVE-2026-68151)

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

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

  - drm/xe/guc：保持排程器時間軸名稱處於活動狀態 排程器會保留指向時間軸名稱的指標，但 q->name 會隨 exec 佇列一起釋放，而排程器柵欄仍可參照它。將名稱儲存在結構xe_guc_exec_queue中，以便共用排程器的 RCU 延遲存留期。（從提交 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8 中挑選）（CVE-2026-68383）

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

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

  - bonding：修正停用 IPv6 時devconf_all NULL 解除參照 使用 'ipv6.disable=1' 參數開機時，永遠不會初始化devconf_all，因為 inet6_init（） 會在呼叫 addrconf_init（） 之前結束，從而初始化它。然而，即使 ipv6 確實停用，bond_send_validate（） 仍會呼叫 bond_ns_send_all（）。這將導致 ip6_pol_route（） 中 net->ipv6.devconf_all 的 NULL 解除引用。錯誤：
    核心 NULL 指標解除參照，位址：000000000000000c [...]工作佇列：bond0 bond_arp_monitor [bonding] RIP：0010：ip6_pol_route+0x69/0x480 [...]呼叫追蹤： <TASK> ？srso_return_thunk+0x5/0x5f ？
    __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ？wakeup_preempt+0x8a/0x90 ？srso_return_thunk+0x5/0x5f ？srso_return_thunk+0x5/0x5f ？sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280【羈絆】bond_ab_arp_probe+0x296/0x320【羈絆】？srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0【羈絆】process_one_work+0x196/0x370 worker_thread+0x1af/0x320？srso_return_thunk+0x5/0x5f ？
    __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ？
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 透過在呼叫端中新增 ipv6_mod_enabled（） 條件檢查來修正此問題。（CVE-2026-68336）

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

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

  - drm/dp/mst：修正邊帶區塊累積中的緩衝區溢位 drm_dp_sideband_append_payload（） 在處理裝置提供的邊帶回覆資料時有三個相關錯誤： 1. 零長度curchunk_len下溢：
    msg_len 是直接從 DP 邊帶標頭取得的 6 位元欄位。如果裝置傳送 msg_len=0，則 curchunk_len 會設定為零。條件 （curchunk_idx >= curchunk_len） 立即為真，curchunk_len-1 換行為 255 （u8 反向溢位）。drm_dp_msg_data_crc4（） 從 chunk[48] 讀取 255 個位元組，然後 memcpy（） 將 255 個位元組寫入 msg[]，兩者都遠遠超出了範圍。2、區塊[48]溢位：curchunk_len可達63（6位元欄位）。chunk[] 只有 48 個位元組。多重迭代承載組件會附加 16 位元組區塊，直到 curchunk_idx 達到 curchunk_len，將 chunk[] 結尾之後最多 15 個位元組寫入 msg[]。3.
    msg[256] 溢位：每個區塊向 msg[] 貢獻 （curchunk_len-1） 個位元組。沒有檢查可確保 curlen + （curchunk_len-1） 保持在 msg[256] 內，因此 memcpy 可以溢出到相鄰的結構欄位中。這三個裝置都可以從任何可以在實體連線上偽造邊帶回覆訊息的 DP MST 裝置存取。
    (CVE-2026-68278)

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

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

  - bpf：拒絕沒有bpf_net_context的重新導向協助程式 bpf_redirect*（） 協助程式和 skb_do_redirect（） 透過 bpf_net_ctx_get_ri（） 取得每個任務的bpf_redirect_info，這會無條件地取消參照目前的>bpf_net_context。該上下文是在執行 tc BPF 的路徑上建立的，例如 sch_handle_{ingress，egress}（），*除了* {cls，act}_bpf 附加到適當的 qdisc 的情況。從那裡運行的程式以兩種方式到達 NULL 解除參照： * 它直接調用 bpf_redirect（），這會取消參照協助程式頂部的上下文： tc qdisc add dev eth0 root handle 1： red limit 1MB min 10KB max 20KB \ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * 它只是傳回 TC_ACT_REDIRECT 而不需要協助程式呼叫： 然後tcf_qevent_handle（） 分派給 skb_do_redirect（），後者解除參照上下文 而不是將bpf_net_context管理擴展到 qdisc 路徑中，而是使重新導向協助程式在不存在上下文時拒絕運行，並讓 tcf_qevent_handle（） 丟棄TC_ACT_REDIRECT判定而不是呼叫 skb_do_redirect（）。以前的行為是崩潰的，所以不支持它不會倒退。（CVE-2026-68337）

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

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

  - comedi：comedi_parport：處理過早中斷 Syzbot 報告了「comedi_get_is_subdevice_running（）」中的一般保護錯誤，這是從 comedi_parport 驅動程式中的中斷處理常式「parport_interrupt（）」呼叫的，但目前沒有針對該問題的 C 再現程式。這可能是由於兩個原因之一而過早中斷： 1. 驅動程式會在配置中斷處理常式所使用的 comedi 子裝置之前設定中斷處理常式，但不會先停用平行埠的 CTRL 暫存器中的中斷。2. 驅動程式使用使用者提供的 I/O 埠基底位址，Syzbot 會提供該基底位址，但可能沒有真正的平行埠硬體支援。
    變更驅動程式 comedi 附加處理常式 （'parport_attach（）'） 中的初始化順序，以便在要求中斷處理常式之前初始化硬體暫存器。這應該可以防止實際硬體發生過早中斷。此外，將測試新增至中斷處理常式，以確保 commedi 裝置已完全連接，如果未連接，請提前返回。（CVE-2026-68182）

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

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

  - 提示：修正媒體和承載 MTU 驗證中的 u16 MTU 截斷 TIPC_NL_MEDIA_SET和TIPC_NL_BEARER_SET都接受使用者提供的 MTU 值，但只強制執行最小界限，而不是最大值。當使用者將 MTU 設定為超過 U16_MAX （65535） 的值時，它會通過驗證，但當指派給 tipc_link_create（） 中的 u16 欄位 l->mtu 和 l->advertised_mtu 時，會以無訊息方式截斷。像 65536 （0x10000） 這樣的值會截斷為 0，導致 tipc_link_set_queue_limits（） 中的除以零，計算 TIPC_MAX_PUBL / （l->mtu / ITEM_SIZE）。其他溢位值 （例如 65537-131071） 會產生小而不正確的 MTU 值，進而導致鏈路故障行為。損毀堆疊 （透過使用者命名空間以無特權使用者身分觸發）：tipc_link_set_queue_limits net/tipc/link.c：2531 tipc_link_create net/tipc/link.c：520 tipc_node_check_dest net/tipc/node.c：1279 tipc_disc_rcv net/tipc/discover.c：252 tipc_rcv net/tipc/node.c：2129 tipc_udp_recv net/tipc/udp_media.c：392 兩個獨立的路徑缺少上限檢查： 1. tipc_udp_mtu_bad（） -- 從 __tipc_nl_media_set（） 調用 （MEDIA_SET） 2.內嵌簽入
    bearer.c：1160 的 __tipc_nl_bearer_set（） （BEARER_SET） 透過拒絕高於 U16_MAX 的 MTU 值來修正這兩個問題。
    (CVE-2026-68297)

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

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

  - LoongArch：將 jump_label_init（） 移至 parse_early_param（） 之前 當同時啟用 CONFIG_MEM_ALLOC_PROFILING=y 和 CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y 時，透過新增啟動參數「sysctl.vm.mem_profiling=0」來進行記憶體分析將導致核心無法啟動。
    經過分析，這是因為必須在parse_early_param（）之前呼叫jump_label_init（），早期的參數處理常式可能會透過static_branch_enable/disable（）來修改靜態金鑰。透過將 jump_label_init（） 移至 parse_early_param（） 之前來修正此問題。該解決方案與其他架構類似。
    (CVE-2026-68185)

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

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

  - media：saa7134：修正 saa7134_video_init1 中可能的記憶體洩漏 在 saa7134_video_init1（） 中，不檢查第一個 saa7134_pgtable_alloc（） 的傳回值。如果失敗，函式會繼續進行，就像成功一樣，讓驅動程式留下無效的頁面表格。此外，如果在配置視訊佇列頁面表格後，VBI 佇列的 vb2_queue_init（） 失敗，則在傳回之前不會釋放配置的記憶體。第二個 saa7134_pgtable_alloc（） 也缺少傳回值檢查。在裝置完全註冊之前，裝置探測期間會發生錯誤，saa7134_finidev（） 中的正常清理路徑不會執行，進而導致記憶體洩漏，並可能使用未初始化的 DMA 資源。檢查兩個 saa7134_pgtable_alloc（） 呼叫的傳回值並傳播錯誤。後續步驟失敗時，釋放已配置的頁面表格以避免記憶體流失。確保控制處理常式也會在錯誤時釋放，以防止進一步的資源洩漏。透過程式碼審查找到。（CVE-2026-68212）

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

ID	名稱	嚴重性
334277	Linux Distros 未修補弱點：CVE-2026-68343	critical
334276	Linux Distros 未修補弱點：CVE-2026-68402	high
334275	Linux Distros 未修補弱點：CVE-2026-68138	high
334274	Linux Distros 未修補弱點：CVE-2026-68246	medium
334273	Linux Distros 未修補弱點：CVE-2026-68388	critical
334272	Linux Distros 未修補弱點：CVE-2026-68327	medium
334271	Linux Distros 未修補弱點：CVE-2026-61551	high
334270	Linux Distros 未修補弱點：CVE-2026-68409	high
334269	Linux Distros 未修補弱點：CVE-2026-68130	high
334268	Linux Distros 未修補弱點：CVE-2026-68294	high
334267	Linux Distros 未修補弱點：CVE-2026-68241	medium
334266	Linux Distros 未修補弱點：CVE-2026-68234	low
334265	Linux Distros 未修補弱點：CVE-2026-68192	high
334264	Linux Distros 未修補弱點：CVE-2026-68266	high
334263	Linux Distros 未修補弱點：CVE-2026-68121	high
334262	Linux Distros 未修補弱點：CVE-2026-68406	critical
334261	Linux Distros 未修補弱點：CVE-2026-68329	high
334260	Linux Distros 未修補弱點：CVE-2026-68198	high
334259	Linux Distros 未修補弱點：CVE-2026-68247	medium
334258	Linux Distros 未修補弱點：CVE-2026-68333	medium
334257	Linux Distros 未修補弱點：CVE-2026-68304	low
334256	Linux Distros 未修補弱點：CVE-2026-68189	high
334255	Linux Distros 未修補弱點：CVE-2026-68124	critical
334254	Linux Distros 未修補弱點：CVE-2026-68085	high
334253	Linux Distros 未修補弱點：CVE-2026-68166	critical
334252	Linux Distros 未修補弱點：CVE-2026-68136	critical
334251	Linux Distros 未修補弱點：CVE-2026-68395	critical
334250	Linux Distros 未修補弱點：CVE-2026-68331	medium
334249	Linux Distros 未修補弱點：CVE-2026-68350	high
334248	Linux Distros 未修補弱點：CVE-2026-68188	high
334247	Linux Distros 未修補弱點：CVE-2026-68125	high
334246	Linux Distros 未修補弱點：CVE-2026-68112	medium
334245	Linux Distros 未修補弱點：CVE-2026-68096	high
334244	Linux Distros 未修補弱點：CVE-2026-68248	low
334243	Linux Distros 未修補弱點：CVE-2026-68202	high
334242	Linux Distros 未修補弱點：CVE-2026-68364	critical
334241	Linux Distros 未修補弱點：CVE-2026-68213	high
334240	Linux Distros 未修補弱點：CVE-2026-68353	high
334239	Linux Distros 未修補弱點：CVE-2026-68287	high
334238	Linux Distros 未修補弱點：CVE-2026-68320	high
334237	Linux Distros 未修補弱點：CVE-2026-68276	high
334236	Linux Distros 未修補弱點：CVE-2026-68151	medium
334235	Linux Distros 未修補弱點：CVE-2026-68383	high
334234	Linux Distros 未修補弱點：CVE-2026-68336	medium
334233	Linux Distros 未修補弱點：CVE-2026-68278	medium
334232	Linux Distros 未修補弱點：CVE-2026-68337	high
334231	Linux Distros 未修補弱點：CVE-2026-68182	high
334230	Linux Distros 未修補弱點：CVE-2026-68297	high
334229	Linux Distros 未修補弱點：CVE-2026-68185	critical
334228	Linux Distros 未修補弱點：CVE-2026-68212	critical

偵測

Nessus 的 Misc. 系列

critical

high

high

medium

critical

medium

high

high

high

high

medium

low

high

high

high

critical

high

high

medium

medium

low

high

critical

high

critical

critical

critical

medium

high

high

high

medium

high

low

high

critical

high

high

high

high

high

medium

high

medium

medium

high

high

high

critical

critical