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

  - amt：每次提取後重新讀取 skb 標頭指標 數個 AMT 接收和傳輸路徑會將指標快取到 skb 標頭 （ip_hdr（）、ipv6_hdr（） 、eth_hdr（） 或 AMT 訊息標頭），然後呼叫可以在再次使用快取指標之前重新配置該標頭的協助程式。pskb_may_pull（）、ip_mc_may_pull（）、ipv6_mc_may_pull（）、iptunnel_pull_header（）、ip_mc_check_igmp（） 和 ipv6_mc_check_mld（） 都可以釋放舊頭並移動數據，因此在調用之前獲取的指標之後懸空，以後的訪問是釋放頭的釋放後使用。受影響的站點包括： amt_rcv（） 在 amt_parse_type（） 拉取之前快取 ip_hdr（），然後讀取 iph->saddr。amt_dev_xmit（） 在 ip_mc_check_igmp（）/ ipv6_mc_check_mld（） 和 pskb_may_pull（） 之前快取 ip_hdr（）/ipv6_hdr（），然後讀取群組位址。
    amt_multicast_data_handler（） 在 pskb_may_pull（） 之前快取 eth_hdr（），然後寫入 L2 標頭。
    amt_membership_query_handler（） 在 iptunnel_pull_header（） 和多次拉取之前快取 AMT 標頭、外部和內部 eth_hdr（） 以及 ip_hdr（），然後讀取和寫入它們。amt_igmpv3_report_handler（） 和 amt_mldv2_report_handler（） 會快取 ip_hdr（）/ipv6_hdr（） 和目前的群組記錄，並透過 *_mc_may_pull（） 呼叫從記錄迴圈內的報表標頭讀取記錄計數。
    amt_update_handler（） 在 pskb_may_pull（）、iptunnel_pull_header（）、ip_mc_check_igmp（） 和報告處理常式之前快取 ip_hdr（） 和 AMT membership-update 標頭，然後讀取 iph->daddr 和 amtmu->nonce / amtmu->response_mac。在第一次提取執行之前，對提取之後使用的純量進行快照處理，或在最後一次可以移動頭部的提取之後，從 skb 重新衍生標頭指標，以修正每個網站。在提取過程中穩定的值 （來源和群組位址、回應 MAC 和隨機數、記錄計數、外部來源 MAC） 會建立快照;寫入或重複讀取的指標會重新衍生。（CVE-2026-68302）

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

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

  - wifi：nl80211：當 RNR 項目少於 MBSSID 項目時，MBSSID 不相符的釋放 RNR 資料 nl80211_parse_beacon（） 會拒絕 EMA RNR 資料。拒絕的 RNR 配置尚未附加至信標資料，因此在傳回錯誤之前先釋放它。（CVE-2026-68407）

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

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

  - drm/xe/guc：保留裝置參照直到佇列拆卸完成 GuC exec 佇列銷毀可以非同步執行。如果最終裝置放置來自銷毀工作角色，則 drmm 清理最終可能會耗盡相同的工作佇列和鎖死。保留佇列存留期的drm_device參照，並在佇列拆除完成後將其捨棄。這可防止 drmm 清除在非同步銷毀工作仍在擱置中時執行。
    將 GuC 銷毀工作移至 module-lifetime Xe 工作佇列，並在 PCI remove 上排清，以便熱解綁/重新綁定仍會等待擱置中的銷毀工作。使用佇列保留的裝置參照時，guc_submit_sw_fini（） 無法使用即時 GuC ID 執行。將 fini wait 替換為判斷提示，並移除未使用的fini_wq。v2： - 重定基底 v3： - 切換至佇列存留期 drm_dev_get（）/drm_dev_put（） 模型。（Matt） - 在 system_dfl_wq 上而不是 xe->destroy_wq 上進行佇列非同步拆卸。（Matt） - 刪除單獨的延遲drm_dev_put工作者。- 從 guc_submit_sw_fini（） 中移除過時的 drain_workqueue （xe->destroy_wq）。v4： - 將 guc_submit_sw_fini（） 等待替換為判斷提示，並移除現在未使用的fini_wq。（sashiko） v5： - 將銷毀工作移至模組存留期 Xe 工作佇列，而不是 system_dfl_wq。（Matt） - 在 PCI 移除期間排清 module-lifetime 銷毀工作佇列，以保留舊的 device-remove 等候語意。v6： - 讓 SVM 頁面地圖銷毀工作在每個裝置destroy_wq上，以避免其超過xe_device/drm_device。（Sashiko） - 對 xe->destroy_wq 使用 WQ_MEM_RECLAIM，因為 SVM 頁面地圖銷毀工作可以從回收路徑排入佇列。
    v7： - 刪除每個裝置的 xe->destroy_wq，並使用模組層級銷毀 WQ 進行 SVM 頁面地圖銷毀。（Matt） - 將 xe_exec_queue_destroy_wq_*（） 協助程式重新命名為 xe_destroy_wq_*（） 協助程式，因為 WQ 不再是執行佇列特定的。（Matt） v8： - 重定基底。v9： - 保留 SVM 頁面地圖銷毀在每個裝置WQ_MEM_RECLAIM destroy_wq上的工作，因為它可以從回收排入佇列，並嵌入 devres 拆卸所使用的dev_pagemap。（Sashiko） - 保留模組級僅摧毀 WQ GuC 並從中掉落WQ_MEM_RECLAIM。- 更新 module-WQ kdoc 以記錄 GuC/SVM 分割。v10： - 保留每個 CPU 的 xe->destroy_wq，同時新增 WQ_MEM_RECLAIM 以修正工作佇列配置警告。v11： - 刪除 SVM 頁面地圖銷毀註解，因為它是特定於修訂的。（Thomas） v12： - 重定基底。（從提交 da1124abac689cc2b1d8995e5f0a816f8a122edb 中挑選）（CVE-2026-68382）

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

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

  - wifi：mt76：connac：修正 mt76_connac_mcu_uni_bss_he_tlv（） 中可能的 NULL 指標解除參照mt76_connac_get_he_phy_cap常式理論上可以傳回 NULL，因此在取消引用之前檢查 cap 指標。（CVE-2026-68309）

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

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

  - sctp： auth：當 auth_chunk 為 NULL 時，驗證驗證要求 sctp_auth_chunk_verify（） 當 chunk->auth_chunk 為 NULL 時無條件傳回 true，無訊息地跳過身份驗證。在下列情況下，這是不正確的：
    1. skb_clone（） 在 BH 接收路徑中失敗，留下 auth_chunk 為 NULL。在 sctp_endpoint_bh_rcv（） 中，asoc 對於新連接為 NULL，因此早期的 sctp_auth_recv_cid（） 檢查無法捕獲此問題。2. COOKIE-ECHO 之前沒有 AUTH 區塊，因此永遠不會呼叫 skb_clone（），並且auth_chunk保持為 NULL。當 auth_chunk 為 NULL 時，透過檢查 sctp_auth_recv_cid（） 來修正：如果需要驗證，則傳回 false 以刪除區塊;否則正常繼續。（CVE-2026-68300）

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

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

  - sctp：驗證 sctp_process_strreset_inreq（） 中的資料流計數 當處理來自對等的RESET_IN_REQUEST時，sctp_process_strreset_inreq（） 會從參數長度衍生資料流計數，但不會檢查產生的RESET_OUT_REQUEST是否會超過 SCTP_MAX_CHUNK_LEN。OUT 要求標頭 （sctp_strreset_outreq，16 位元組） 比 IN 要求標頭 （sctp_strreset_inreq，8 位元組） 大 8 個位元組。一般而言，IP 承載會限制為 65535 位元組，因此資料流清單不能大到足以觸發溢位。但是，在具有 MTU > 65535 的介面上 （例如，具有 IPv6 巨型圖的回送），在計算 OUT 要求大小時，適合傳入 IN 參數的串流清單可能會導致 sctp_make_strreset_req（） 中的 __u16 溢位，進而導致 skb 分配過小和核心錯誤：net/core/skbuff.c：207 skb_panic net/core/skbuff.c：2625 skb_put net/sctp/sm_make_chunk.c：1535 sctp_addto_chunk net/sctp/sm_make_chunk.c：3695 sctp_make_strreset_req net/sctp/stream.c：655 sctp_process_strreset_inreq 本機 setsockopt 路徑會驗證產生的重設要求大小。不過，對於僅傳入重設，即使對等必須產生具有相同資料流清單的 OUT 要求，它也會考慮較小的 IN 要求。對等無法順利完成此類要求。拒絕對應 OUT 要求將超過 SCTP_MAX_CHUNK_LEN 的對等 IN 要求。此外，請收緊本機檢查，使其不會傳送需要對等體過大的 OUT 要求的 IN 要求。
    (CVE-2026-68315)

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

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

  - drop_monitor：在 IRQ-disabled 區段下執行u64_stats更新 在 net_dm_packet_trace_kfree_skb_hit（） 和 net_dm_hw_trap_packet_probe（） 中，u64_stats_update_begin在 spin_unlock_irqrestore（&u64_stats_update_end u64_stats_inc...drop_queue.lock， flags），當本機 IRQ 已重新啟用時。追蹤點探查可以在 IRQ 或 softirq 內容中執行。在 32 位元架構上，u64_stats_update_begin（） 會停用搶佔，但不會停用中斷，而是依賴 seqcount 寫入。如果在 64 位元統計資料更新期間，相同的 CPU 上發生巢狀中斷，則可重入的 seqcount 更新可能會損毀 seqcount 狀態或統計資料值。在透過 spin_unlock_irqrestore（） 釋放 drop_queue.lock 之前，執行 64 位元的每個 CPU 統計資料更新來解決此問題，確保在u64_stats更新期間保持本機中斷處於停用狀態。（CVE-2026-68286）

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

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

  - drm/amdgpu：在叫用驅動程式 fini 常式之前，修正孔徑映射洩漏 amdgpu_pci_remove（） 呼叫 drm_dev_unplug（）。這會導致 amdgpu_ttm_fini（） 中的 drm_dev_enter（） 一律傳回 false，因此 iounmap（aper_base_kaddr） 永遠不會在正常驅動程式卸載時執行，在 x86 PAT 間隔樹狀結構中留下孤立的項目。在connected_to_cpu硬體上，光圈會透過 ioremap_cache（） 對應回寫 （WB） 。
    重新載入時，IP 探索會在相同範圍內呼叫 memremap（...， MEMREMAP_WC）。WC 與 WB 衝突導致： 0x... 的 ioremap 錯誤，請求 0x1，已0x0 amdgpu：發現失敗：-2 透過切換到 devres 管理的映射進行修正，因此無論 drm_dev_enter（） 狀態如何，都可以保證清理： - connected_to_cpu路徑：devm_memremap（MEMREMAP_WB）。對於IORESOURCE_SYSTEM_RAM範圍，這會採用 try_ram_remap（） 捷徑，傳回現有核心直接對應的 __va（位移）。不會建立新的 ioremap VA 或 PAT 項目，因此沒有任何孤立項目。- dGPU 路徑：devm_ioremap_wc（） 將 iounmap（） 註冊為 devres 動作，保證在 device_del（） 時進行清理。也要從 amdgpu_device_unmap_mmio（） 中移除 iounmap（aper_base_kaddr），因為映射現在是 devres 擁有的。v2：移除多餘的 x86_64 guard （Lijo） （從提交 d871e99879cb5fd1fa798b006b488887e63a17a 中挑選的櫻桃） （CVE-2026-68102）

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

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

  - wifi： mac80211：釋放 IRQ 鎖定 ieee80211_do_stop（） 之外的 AP_VLAN bc_buf SKB 在停用 IRQ 的情況下按住 ps->bc_buf.lock 時，從父 AP ps->bc_buf 移除AP_VLAN封包。然後，它會在丟棄鎖定之前呼叫 ieee80211_free_txskb（）。ieee80211_free_txskb（） 不僅僅是一個被動的 SKB 版本。
    對於具有 TX 狀態狀態的 SKB，它可以透過 cfg80211/nl80211 報告丟棄的幀，並且該路徑可以到達網路連結分流傳輸。這與 ieee80211_do_stop（） 中的擱置佇列清理已經取消佇列鎖定下的 SKB 連結並在 IRQ 狀態還原後釋放它們的原因相同。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序： AP_VLAN 管理 TX：AP_VLAN 停止：1。 附加 ACK-status 狀態 1。清除正在運行的狀態 2.將 2 上的多點傳播 SKB 排入佇列。在停用 IRQ 父 ps->bc_buf 的情況下，使用 ps->bc_buf.lock 3.取消連結 AP_VLAN SKB 4。調用 ieee80211_free_txskb（） 在現有鎖定下從 ps->bc_buf 取消連結相符的 AP_VLAN SKB，但將它們移至本機可用佇列。在呼叫 ieee80211_free_txskb（） 之前，刪除鎖定並還原 IRQ 狀態。警告：
    kernel/softirq.c：430 在 __local_bh_enable_ip （CVE-2026-68405）

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

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

  - drm/amdgpu：拒絕將保留的門鈴對應至新佇列 建立使用者佇列時，使用者空間會提供門鈴 BO 控點，以及 bo 內的位移，以取得門鈴。然而，目前的實作使用 xa_store_irq（） 來儲存門鈴，這允許使用相同的 BO 和偏移參數建立的稍後佇列來覆蓋現有佇列和門鈴映射。這可能會導致諸如將柵欄 IRQ 處理錯誤路由到錯誤佇列等問題，並誤導一個佇列的清理過程清除另一個佇列的對應。此提交透過將 xa_store_irq 替換為 xa_insert_irq 來解決此問題，拒絕將保留的門鈴對應到新建立的佇列 （從提交 6244eae22966350db52faf9c1369d3b2ffc5de4e 中挑選） （CVE-2026-68103）

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

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

  - media：sun4i-csi：start_streaming（） 失敗時傳回佇列的緩衝區 vb2 架構在呼叫 start_streaming（） 之前，會透過 buf_queue（） 將緩衝區交給驅動程式。如果 start_streaming（） 傳回錯誤，而沒有先透過 vb2_buffer_done（） 傳回這些緩衝區，則 vb2_start_streaming（） 會觸發 WARN_ON（owned_by_drv_count） 並且佇列的緩衝區會洩漏。sun4i_csi_start_streaming（） 在執行任何設定 （暫存緩衝區配置、管線啟動） 之前，找不到相符的 CSI 格式時傳回 -EINVAL。其餘的錯誤路徑已經收斂在 err_clear_dma_queue 標籤上，該標籤會呼叫 csi->qlock 下的 return_all_buffers（...， VB2_BUF_STATE_QUEUED）。直接跳到該標籤：跳過中間err_disable_device/err_disable_pipeline/err_free_scratch_buffer標籤，這是正確的，因為它們還沒有發生任何可以撤消的事情。這反映了提交 4cf3b6fd54eb 中的 uvcvideo 修正（media：uvcvideo：start_streaming（） 失敗時返回佇列的緩衝區）。（CVE-2026-68209）

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

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

  - drm/amdkfd：修正 CWSR 總大小計算中的 32 位元溢位total_cwsr_size在用作 BO/SVM 配置大小之前以 32 位元計算。當大ctx_save_restore_area_size和debug_memory_size乘以 XCC 計數時，產品可以包裝，從而產生一個過小的 CWSR 儲存區域，韌體稍後會超出這個區域。將total_cwsr_size提升至 u64，並在 kfd_queue_acquire_buffers（） 和 kfd_queue_release_buffers（） 中使用 check_add_overflow（）/ check_mul_overflow（）。（從提交 319f7e13423ae3f486b9aea82f9ad2d6af0ee608 中挑選）（CVE-2026-68257）

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

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

  - media：airspy：在 start_streaming（） 失敗時傳回佇列的緩衝區 vb2 架構在呼叫 start_streaming（） 之前，會透過 buf_queue（） 將緩衝區交給驅動程式。如果 start_streaming（） 傳回錯誤，而沒有先透過 vb2_buffer_done（） 傳回這些緩衝區，則 vb2_start_streaming（） 會觸發 WARN_ON（owned_by_drv_count） 並且佇列的緩衝區會洩漏。當 USB 裝置中斷連線時，airspy_start_streaming（） 提前傳回 -ENODEV （s->udev == NULL），而不傳回 buf_queue（） 已接受的任何緩衝區。首先v4l2_lock並跳到現有的err_clear_bit標籤，該標籤在解鎖前已經通過 vb2_buffer_done（...， VB2_BUF_STATE_QUEUED） 耗盡 s->queued_bufs。這反映了提交 4cf3b6fd54eb 中的 uvcvideo 修正（media：uvcvideo：start_streaming（） 失敗時返回佇列的緩衝區）。（CVE-2026-68231）

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

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

  - 已解決 Linux 核心中的下列弱點：usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnect uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a 'struct completion' for a pre-firmware device (to be waited on in .disconnect()), or a 'struct usbatm_data' for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small 'struct completion' stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to 'struct usbatm_data' and takes instance->serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in
    __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470e2c60 by task kworker/1:2/982 ...
    __mutex_lock+0x152a/0x1b80 usbatm_usb_disconnect+0x70/0x820 uea_disconnect+0x133/0x2c0 usb_unbind_interface+0x1dd/0x9e0 ... which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes to the right of allocated 96-byte region [ffff8880470e2c00, ffff8880470e2c60) Reject such inconsistent descriptors in uea_probe() so that both handlers always make the same pre/post-firmware decision. (CVE-2026-68344)

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

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

  - drm/amdgpu： 修正驅動程式載入失敗期間的核心錯誤 如果驅動程式載入期間 MES init 失敗，避免核心錯誤。KIQ 環被錯誤地標記為就緒，因為使用 MES 的 ASIC，KIQ 歸 MES 所有。錯誤：核心 NULL 指標解除參照，位址：00000000000000000 RIP：0010：gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] 呼叫追蹤：gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280
    __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 （從提交 4623b958dd6da0f4c3026afdf330626a09ecb0f0） （CVE-2026-68105）

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

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

  - 韌體： arm_ffa：修正端點記憶體存取描述元位移計算 使用描述元的「ep_mem_offset」來計算端點記憶體存取陣列的起始點，並符合 FF-A 規格，而不是預設為「sizeof（struct ffa_mem_region）」。這需要在設定流程中較早移動「ffa_mem_region_additional_setup（）」。此外，新增健全性檢查，以確保計算的描述元位移不超過「max_fragsize」。（CVE-2026-68400）

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

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

  - drm/amdgpu/gfx10：將 BUG_ON（） 替換為 WARN_ON（） 在這些情況下，不需要使核心崩潰。
    （從提交 ac6f00beb658239bced4aaed9efbb04a35348d48 中挑選）（CVE-2026-68115）

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

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

  - sched_ext：當可執行的任務在沒有SCX_OPS_ENQ_LAST的情況下下降到較低的sched_class時，put_prev_task_scx（） 會警告 put_prev_task_scx（） 中的核心排程強制閒置，前提是 balance_one（） 會使其保持運行。核心調度打破了這一點：強制閒置的 SMT 同級通過 pick_next_task（） 中的core_pick快速路徑重新調度，該路徑跳過了 pick_task_scx（），因此跳過了 balance_one（），因此可運行的任務可以在未設置的情況下ENQ_LAST空閒。在 sched_cpu_cookie_match（） 上發出警告：cookie 不相符意味著核心調度強制閒置，而匹配（或核心調度關閉）仍然捕獲真正的遺漏ENQ_LAST掉落。（CVE-2026-68421）

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

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

  - 提示：清除 tipc_sk_create（） 中插入失敗路徑上的 sock->sk 當 tipc_sk_create（） 無法插入新通訊端 （tipc_sk_insert（） 傳回非零） 時，其錯誤路徑會使用 sk_free（） 釋放 sk，但會留下 sock->sk 指向釋放的物件： if （tipc_sk_insert（tsk）） { sk_free（sk）; pr_warn（通訊端建立失敗;連接埠號碼已\n耗盡）; return -EINVAL; }這對於普通 socket（） 是無害的：syscall 層在釋放之前會清除 sock->ops，因此永遠不會呼叫 tipc_release（）。它在 accept（） 路徑上並非無害。tipc_accept（） 使用 tipc_sk_create（net， new_sock， 0， kern） 建立預先分配的子通訊端;失敗時，它會留下 new_sock->sk 懸空，而 new_sock->ops 非 NULL，然後 do_accept（） 然後對新檔案進行 fput（），因此 __sock_release（） -> tipc_release（） 在釋放的 sk 上執行 lock_sock（new_sock->sk） -- sk_lock 微調鎖的釋放後使用寫入。tipc_release（） 已經保護了這個完全失敗的 accept（） 釋放了一個預先分配的子案例，if （sk == NULL） return 0;，但保護被繞過，因為 tipc_sk_create（） 留下了 sock->sk 非 NULL（懸空）而不是 NULL。清除 failed-insert 路徑上的 sock->sk，以便觸發現有的 tipc_release（） NULL 檢查並避免釋放後使用。當 per-netns 通訊端 rhashtable 達到其max_size （tsk_rht_params.max_size = 1048576， ~2M 元素） 時，就會發生 tipc_sk_insert（） 失敗 -- 即一旦 netns 持有 ~2M TIPC 通訊端，每個插入都會傳回 -E2BIG。錯誤：KASAN：lock_sock_nested 中的 slab-use-after-free （net/core/sock.c：3839） 透過任務 init/1 在 addr ffff8880047cdc38 寫入大小 8 lock_sock_nested （net/core/sock.c：3839） tipc_release （net/tipc/socket.c：638） __sock_release （net/socket.c：710） sock_close （net/socket.c：1501） __fput （fs/file_table.c：512） 由任務 1 分配： sk_alloc （net/core/sock.c：2308） tipc_sk_create （net/tipc/socket.c：487） tipc_accept （net/tipc/socket.c：2744） do_accept （net/socket.c：2034） 由任務 1 釋放：__sk_destruct （net/core/sock.c：2391） tipc_sk_create （net/tipc/socket.c：504） tipc_accept （net/tipc/socket.c：2744） do_accept （net/socket.c：2034） （CVE-2026-68117）

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

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

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

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

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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
334297	Linux Distros 未修補弱點：CVE-2026-68302	critical
334296	Linux Distros 未修補弱點：CVE-2026-68407	critical
334295	Linux Distros 未修補弱點：CVE-2026-68382	high
334294	Linux Distros 未修補弱點：CVE-2026-68309	low
334293	Linux Distros 未修補弱點：CVE-2026-68300	critical
334292	Linux Distros 未修補弱點：CVE-2026-68315	high
334291	Linux Distros 未修補弱點：CVE-2026-68286	high
334290	Linux Distros 未修補弱點：CVE-2026-68102	medium
334289	Linux Distros 未修補弱點：CVE-2026-68405	medium
334288	Linux Distros 未修補弱點：CVE-2026-68103	high
334287	Linux Distros 未修補弱點：CVE-2026-68209	high
334286	Linux Distros 未修補弱點：CVE-2026-68257	high
334285	Linux Distros 未修補弱點：CVE-2026-68231	medium
334284	Linux Distros 未修補弱點：CVE-2026-68344	medium
334283	Linux Distros 未修補弱點：CVE-2026-68105	medium
334282	Linux Distros 未修補弱點：CVE-2026-68400	high
334281	Linux Distros 未修補弱點：CVE-2026-68115	medium
334280	Linux Distros 未修補弱點：CVE-2026-68421	medium
334279	Linux Distros 未修補弱點：CVE-2026-68117	critical
334278	Linux Distros 未修補弱點：CVE-2026-68114	medium
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

偵測

Nessus 的 Misc. 系列

critical

critical

high

low

critical

high

high

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

critical

medium

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