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

  - 不正確的條件檢查環 1 內所有版本的 Intel（R） NPU 驅動程式韌體：
    裝置驅動程式可能允許拒絕服務。具有已驗證使用者的無特權軟體攻擊者，結合低複雜度攻擊，可能會啟用拒絕服務。當沒有特殊內部知識且不需要使用者互動的攻擊需求時，可能會透過本機存取發生此結果。潛在弱點可能會影響易受攻擊系統的機密性 （無）、完整性 （低） 和可用性 （高），進而造成後續的系統機密性 （無）、完整性 （無） 和可用性 （無） 影響。（CVE-2026-20783）

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

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

  - 環 3 內所有版本的 Intel（R） NPU 驅動程式越界讀取：使用者應用程式可能允許拒絕服務。具有已驗證使用者的無特權軟體攻擊者，結合低複雜度攻擊，可能會啟用拒絕服務。當沒有特殊內部知識且不需要使用者互動的攻擊需求時，可能會透過本機存取發生此結果。
    潛在弱點可能會影響易受攻擊系統的機密性 （無）、完整性 （低） 和可用性 （高），進而造成後續的系統機密性 （無）、完整性 （無） 和可用性 （無） 影響。（CVE-2026-20786）

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

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

  - 不當條件檢查環 3 內所有版本的 Intel（R） NPU 驅動程式：使用者應用程式可能允許拒絕服務。具有已驗證使用者的無特權軟體攻擊者，結合低複雜度攻擊，可能會啟用拒絕服務。當沒有特殊內部知識且不需要使用者互動的攻擊需求時，可能會透過本機存取發生此結果。潛在弱點可能會影響易受攻擊系統的機密性 （無）、完整性 （低） 和可用性 （高），進而造成後續的系統機密性 （無）、完整性 （無） 和可用性 （無） 影響。（CVE-2026-20769）

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

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

  - 環 3 中所有版本的 Intel（R） NPU 驅動程式緩衝區限制不當：使用者應用程式可能允許拒絕服務。具有已驗證使用者的無特權軟體攻擊者，結合低複雜度攻擊，可能會啟用拒絕服務。當沒有特殊內部知識且不需要使用者互動的攻擊需求時，可能會透過本機存取發生此結果。潛在弱點可能會影響易受攻擊系統的機密性 （無）、完整性 （低） 和可用性 （高），進而造成後續的系統機密性 （無）、完整性 （無） 和可用性 （無） 影響。（CVE-2026-20731）

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

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

  - Net：：OAuth：：Client 之前的 Perl 版本 0.32 允許服務提供者在 get_request_token 中以無訊息方式將 OAuth 1.0a 降級為 OAuth 1.0 。將回呼傳遞至建構函式會選取 OAuth 1.0a。
    然後，當要求權杖回應省略oauth_callback_confirmed時，get_request_token撤銷該選擇，沒有例外狀況，沒有警告，也沒有要求 1.0a 的選項。存取權杖要求是從 OAuth 1.0 訊息類別建置，該類別沒有驗證程式參數，因此即使已傳遞 get_access_token 參數，也會從要求中捨棄oauth_verifier。 oauth_verifier是 OAuth 1.0a 在授權步驟與權杖交換之間新增的繫結。要求 1.0a 並取得 1.0 的應用程式可接受 OAuth 1.0 會話固定，攻擊者取得要求權杖，讓受害者授權，然後自行完成交換，將受害者的提供者帳戶連結至攻擊者控制的會話。任何攻擊者動作都不會設定降級：未確認回呼的提供者就足夠了。（CVE-2026-72887）

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

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

  - 透過使用 mbedTLS 進行2.7.5的 OpenVPN 2.7_alpha1允許透過忽略已設定的 X.509 使用者名稱身分查詢欄位 （CVE-2026-63650） 來誤識別遠端已驗證使用者

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

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

  - Capstone 是解編架構。在 6.0.0-Alpha9 版之前，Capstone 的公用「cs_insn_name（）」API 會將呼叫端提供的指令 ID 直接轉送至選取的架構後端。大多數後端會在為指令名稱表編製索引之前驗證 ID，但 M68K 和 RISCV 後端缺少或不完整的邊界檢查。在針對 M68K 或 RISCV 開啟的 Capstone 控制碼上，呼叫端控制的無效指令識別碼可能會觸發越界讀取，並使進程損毀。已證明的影響是將指令名稱查閱公開給不受信任 ID 的應用程式或連結中的可用性損失。沒有程式碼執行或資料洩露。6.0.0-alpha9 版修補了此問題。
    (CVE-2026-49282)

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

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

  - Capstone 是解編架構。在 6.0.0-Alpha9 版本之前，Capstone 的 WebAssembly 後端透過公用「cs_disasm（）」和「cs_disasm_iter（）」API 接受攻擊者控制的原始 WASM 指令位元組。對於大型但格式良好的「br_table」指令，WASM 解碼器會在較寬的局部變數中累積即時長度，但會透過「uint16_t」指令大小路徑傳回它。當編碼指令長度恰好為 65,536 位元組時，大小換行為零，並且「cs_disasm（）」可以重複解碼相同的指令而不前進。對於較大的長度，「cs_disasm_iter（）」會進入「br_table」負載的中間，並將目標位元組解碼為後續指令。這是可用性和剖析器完整性問題。6.0.0-alpha9 版修補了此問題。（CVE-2026-49263）

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

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

  - golang.org/x/image/vp8l 中的 VP8L 解碼在處理包含許多未使用的霍夫曼樹組的特製 VP8L 影像時，可能會配置過多的記憶體。這允許遠端攻擊者透過記憶體耗盡造成拒絕服務。（CVE-2026-46603）

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

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

  - net： openvswitch：修正儀表連接失敗時的潛在 UAF 附加新建立的儀表 attach_meter（） 函式會使新儀表對其他 CPU 可見，但之後仍可能發生故障。失敗時，它會將儀表分離回來並傳回錯誤。但是，對於 ovs_meter_cmd_set（） 來說，這是一種意外行為，它會在連接失敗時使用普通 kfree（meter），而不等待 RCU 讀取器停止使用它，假設它永遠不會可見。這對 ovs-vswitchd 來說從來都不是問題，因為它總是在建立任何使用它們的流程之前建立儀表。但是可以使用 uAPI 的自訂應用程式觸發 UAF： 錯誤：KASAN：ovs_meter_execute中的釋放後使用板 （net/openvswitch/meter.c：653） 透過任務 meter/2508 在 addr ffff88810d152650 讀取大小 8 呼叫追蹤：ovs_meter_execute （net/openvswitch/meter.c：653） do_execute_actions （net/openvswitch/actions.c：1407） ovs_execute_actions （net/openvswitch/actions.c：1584） ovs_packet_cmd_execute （net/openvswitch/datapath.c：703） ...
    netlink_sendmsg （af_netlink.c：1900） 由任務 2519 分配：__kasan_kmalloc （mm/kasan/common.c：398 mm/kasan/common.c：415） ovs_meter_cmd_set （net/openvswitch/meter.c：422） ...netlink_sendmsg （af_netlink.c：1900） 由任務 2519 釋放：kfree （mm/slub.c：2705 mm/slub.c：6405 mm/slub.c：6720） ovs_meter_cmd_set （net/openvswitch/meter.c：479） ...netlink_sendmsg （af_netlink.c：1900） 透過確保 attach_meter（） 不會使儀表可見，直到所有檢查完成並且函數不會再失敗來修正此問題。這也可確保在資料表可能調整大小之後計算雜湊值。趨勢科技零時差計畫報告為 ZDI-CAN-31642。（CVE-2026-74465）

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

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

  - tipc：避免輪詢追蹤佇列轉儲 TIPC 通訊端追蹤點透過 tipc_sk_dump（） 轉儲佇列狀態中的釋放後使用。大多數佇列轉儲呼叫網站已經序列化在通訊端鎖定或 sk->sk_lock.slock 下遍歷，但 tipc_poll（） 呼叫 trace_tipc_sk_poll（...， TIPC_DUMP_ALL， ...） 而不保留任何一個鎖定。這可讓輪詢追蹤路徑到達 tipc_list_dump（） 和待辦專案頭/尾傾印，而另一個內容會出列並釋放 skb，讓追蹤協助程式取消參照過時的佇列項目。
    停止解鎖的輪詢追蹤網站要求佇列傾印。其他佇列轉儲追蹤呼叫網站會將其現有輸出保留在已提供的鎖定下，而 poll 仍會發出事件本身，而不會從未鎖定的內容中遍歷即時佇列成員。（CVE-2026-74490）

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

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

  - scsi：scsi_debug：修正 REPORT ZONES alloc_len下溢 OOB 寫入 resp_report_zones（） 會從 CDB 配置長度調整回覆緩衝區大小。v3 修正在派生描述元計數之前使用 ALIGN（） 對alloc_len進行四捨五入：rep_max_zones = （ALIGN（（u64）alloc_len， RZONES_DESC_HD） - RZONES_DESC_HD） >> ilog2（RZONES_DESC_HD）;arr_len = （u64）RZONES_DESC_HD * （rep_max_zones + 1）;對於 0xFFFFFFC1 年的alloc_len。0xFFFFFFFF，ALIGN（） 四捨五入為 0x100000000，因此arr_len為 4 GB。在 32 位元上，kzalloc（） 的size_t是 32 位元，並將 0x100000000 截斷為 0;kzalloc（0） 傳回 ZERO_SIZE_PTR，它通過了 ！arr 檢查，然後 desc = arr + 64 會在迴圈 -> 越界寫入/錯誤中取消參照。將rep_max_zones限制為 devip->nr_zones。迴圈已經在 sdebug_capacity 處停止 （在nr_zones區域之後），因此報告永遠不能包含超過 nr_zones 個描述元;夾子不會改變報告，它只會將arr_len界為 （nr_zones + 1） * RZONES_DESC_HD，這是永遠無法達到0x100000000的真實設備屬性。
    (CVE-2026-74470)

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

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

  - net：pktgen：修正按住 t->if_lock 時，proc 項目釋放後使用 pktgen_change_name（） 取代 pkt_dev->entry。pktgen_remove_device（） 會在 _rem_dev_from_if_list（） 取得該鎖定之前移除相同的項目。
    這允許以下交錯： CPU 0 （NETDEV_CHANGENAME） CPU 1 （kpktgend） if_lock（t） proc_remove（pkt_dev->entry） proc_remove（pkt_dev->entry） pkt_dev->entry = proc_create_data（...） if_unlock（t） 在重新命名路徑釋放後，kthread 可以將過時的proc_dir_entry傳遞給 proc_remove（）。具有擴大爭用視窗的再現器報告： 錯誤：KASAN：proc_remove+0x78/0x80 中的 slab-use-after-free 由任務 kpktgend_0/67 在 addr ffff8881478fea70 讀取大小 8 呼叫追蹤：
    proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 由工作 95 分配：__proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 由工作 28 釋放：kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 有錯誤的位址屬於 ffff8881478fea00 的物件，該物件屬於大小為 192 的快取proc_dir_entry 移動proc_remove（） 放入受if_lock保護的清單移除協助程式中。將其保留在 list_del_rcu（） 之前，以保留 add_device（） 所需的順序。然後，重新命名路徑必須先完成取代項目，才能移除，否則它會觀察到裝置不再在清單中。
    (CVE-2026-74479)

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

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

  - nexthop：在 RTNL 序列化的 nexthop 替換期間，避免解鎖的f6i_list遍歷 nh_rt_cache_flush nh_rt_cache_flush（） 遍歷 nh->f6i_list，而不保留 nh->lock，爭用解鎖的 IPv6 路由 add/delete，以更改 nh->lock 下的列表並釋放fib6_info項目 （nh_rt_cache_flush（） 內聯到 rtm_new_nexthop（））： 錯誤：KASAN：nh_rt_cache_flush 中的 slab-use-after-free （net/ipv4/nexthop.c：2243） 任務 exploit/14 nh_rt_cache_flush 6 在 addr ffff888012953e18 處讀取大小 8 （net/ipv4/nexthop.c：2243） replace_nexthop （net/ipv4/nexthop.c：2610） rtm_new_nexthop （net/ipv4/nexthop.c：3323） rtnetlink_rcv_msg （net/core/rtnetlink.c：7076） 與其他f6i_list遍歷不同， 這個透過 fib6_update_sernum_upto_root（） 碰撞每個路由的 sernum，這需要tb6_lock;採用 nh->lock 會顛倒既定的 tb6_lock -> nh->lock 順序和鎖死。由於唯一的目的是使快取的 dsts 失效，因此請改用 rt_genid_bump_ipv6（） 來提升整個 netns 的 IPv6 sernum，以鏡像上面已經為 IPv4 完成的 rt_cache_flush（）。（CVE-2026-74561）

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

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

  - vxlan：將 pskb_network_may_pull（） 用於傳輸路徑標頭提取 在 vxlan_xmit（）、arp_reduce（） 和 vxlan_mdb_entry_skb_get（） 中，調用 pskb_may_pull（） 來驗證網路層標頭 （ARP、IPv6/ND、IP/IPv6 MDB 金鑰） 的可用性。然而，在傳輸期間，skb->data 指向 MAC 標頭，因此 skb_network_offset（skb） ETH_HLEN（14 位元組）。使用 pskb_may_pull（skb， len） 只會檢查來自 skb->data 的 len 位元組，而不是 skb_network_offset（skb） + len，這可能會將部分網路標頭留在非線性片段中。將這些剩餘的 pskb_may_pull（） 呼叫替換為 pskb_network_may_pull（），以正確考慮 MAC 標頭位移。（CVE-2026-74474）

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

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

  - drm/xe：在 exec IOCTL 中等候外部 BO 核心柵欄 在武裝使用者作業之前，xe_exec_ioctl（） 只會將 VM 的 dma-resv 核心插槽新增為相依性。此插槽涵蓋重新綁定和 VM 私有 BO 的核心作業，但不涵蓋外部 BO （bo->vm == NULL），這些 BO 會在自己的 dma-resv 核心插槽中攜帶核心作業 （逐出、移動等）。DMA_RESV_USAGE_KERNEL 位置是記憶體管理作業的跨驅動程式合約，必須先完成，才能使用 BO 或其備份存放區：任何存取子都必須先等候核心柵欄，才能接觸 resv。透過跳過外部 BO 的核心插槽，exec 路徑違反了該合約，並且可以在 VM 對應的外部 BO 上的核心作業仍在進行時排程使用者工作，與它競爭，並可能讀取或寫入正在移動的記憶體。將僅限 VM 的相依性替換為執行器鎖定的每個物件的反覆運算，並將每個物件的 KERNEL 插槽新增為工作相依性。這涵蓋 VM resv （重新綁定和專用 BO） 以及每個外部 BO，鏡像稍後將工作柵欄發佈至同一組物件的 drm_gpuvm_resv_add_fence（） 呼叫。與以前一樣，長時間運行模式繼續跳過此操作。（從提交 a6b842acf3ddd1efc53a56de9260cfa718fb35e7 中挑選）（CVE-2026-74440）

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

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

  - vxlan：在 route_shortcircuit（） 中使用 neigh_ha_snapshot（） 鄰居硬體位址 n->ha 可由鄰接子系統非同步更新，並受 n->ha_lock seqlock 保護。在不保留 seqlock 迴圈的情況下讀取 n->ha 可能會導致讀取中斷或讀取部分更新的 MAC 位址。使用 route_shortcircuit（） 中的 neigh_ha_snapshot（），在使用 read_seqbegin（）/read_seqretry（） 鎖定保護下安全地複製 n->ha。請注意，arp_reduce（） 和 neigh_reduce（） 似乎有相同的問題留待未來的修補程式。（CVE-2026-74475）

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

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

  - rtase：修正 DMA 映射失敗時雙重釋放多片段 skb 在 rtase_start_xmit（） 中，當 rtase_xmit_frags（） 映射所有片段後頭部緩衝區 DMA 映射失敗時，錯誤路徑會使用 rtase_tx_clear_range（） 清除片段描述元，這會通過最後一個片段槽釋放 skb 並tx_dropped。然後控制落入常見錯誤標籤，該標籤會再次釋放相同的 skb 並再次計數。當 skb 擁有碎片時，清除碎片後立即返回;無碎片外殼仍然會掉落並釋放頭部 SKB 一次。（CVE-2026-74545）

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

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

  - KVM： arm64： vgic： 修正 LPI 發行與重新登錄之間的爭用 修正遞減 LPI 參照計數與從 LPI xarray 逐出該結構之間的潛在爭用。LPI 結構會維護在 VGIC LPI xarray （dist->lpi_xa） 中。當 LPI 結構的參照計數降至零時，vgic_release_lpi_locked（） 會從 xarray 中移除該結構，並在 xarray 鎖定下釋放它。
    不過，LPI 的發行可能會透過另一個 CPU 上的 vgic_add_lpi（） 與具有相同 INTID 的並行 LPI 重新註冊競爭，因為參照計數下降和 xarray 逐出不會在單一原子步驟中執行。例如，如果客體發出 DISCARD，而 LPI 仍從 vCPU 的作用中擱置清單 （ap_list） 參照，並且透過 MAPTI 重新映射相同的 INTID，則可能會發生這種情況。特別是，vgic_release_lpi_locked（） 是從兩個不同的路徑呼叫的：透過 vgic_put_irq（） 的直接發布，以及透過 vgic_release_deleted_lpis（） 的延遲發布。在直接發行期間，此問題可能會導致從 xarray 中刪除新註冊的 LPI： CPU0 （釋放 LPI） CPU1 （新增 LPI） ==================== ===================== vgic_put_irq（） __vgic_put_irq（） refcount_dec_and_test（） vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（old_irq） == false 插入新的 IRQ -->
    __xa_store（..， intid， ..） xa_unlock_irqrestore（） xa_lock_irqsave（）;vgic_release_lpi_locked（）
    __xa_erase（..， irq->intid） <-- 錯誤：新的 IRQ 被刪除 kfree_rcu（old_irq） 在延遲發布路徑期間，舊的 IRQ 可能會洩漏： CPU0 （釋放 LPI） CPU1 （新增 LPI） ==================== ===================== vgic_put_irq_norelease（） __vgic_put_irq（） refcount_dec_and_test（） irq->pending_release = true vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（oldirq） == false 錯誤：舊的 IRQ 被覆寫 --> __xa_store（..， intid， ..） xa_unlock_irqrestore（） vgic_release_deleted_lpis（） xa_lock_irqsave（） xa_for_each（） { .. } <-- pending_release = true 的舊 IRQ 已經消失，因此無法釋放 要修復直接釋放路徑，請將參照計數刪除移動到 xarray 鎖定內， 確保 vgic_add_lpi（） 永遠不會遇到即將發布的 LPI。在延遲釋放路徑中，參照計數卸除必須在原始微調鎖定下發生，因此無法抓取 xarray 鎖定，而且相同的解決方案不起作用。相反地，更新 vgic_add_lpi（），這樣如果它從 xarray 中逐出 LPI，它就會承擔釋放它的責任。因此，在延遲發行捨棄參照計數之後，LPI 現在可能會同時釋放，因此存取 pending_release 欄位不再安全，免於釋放後使用。刪除旗標的所有使用，並更新 vgic_release_deleted_lpis（） 以純粹根據孤立的 LPI 的參照計數來識別孤立的 LPI。（CVE-2026-74568）

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: mac80211: fix tid_tx use-after-free on BA session stop ieee80211_stop_tx_ba_cb() hands tid_tx to kfree_rcu() through ieee80211_remove_tid_tx(), and then reads tid_tx->ndp after dropping sta->lock:
    ieee80211_remove_tid_tx(sta, tid); /* kfree_rcu(tid_tx, rcu_head) */ ... spin_unlock_bh(&sta->lock); if (start_txq) ieee80211_agg_start_txq(sta, tid, false); if (send_delba) ieee80211_send_delba(..., tid_tx->ndp); That read is not covered by an RCU read-side critical section, and it runs in preemptible process context: both callers hold the wiphy mutex, reaching it either from the ieee80211_ba_session_work() wiphy work or from ieee80211_sta_tear_down_BA_sessions() during station teardown. Softirqs can run in that window too, both from the local_bh_enable() that ends ieee80211_agg_start_txq() and from any interrupt exit, so the RCU callback can free tid_tx before the read. Driving the function from a test module with the grace period forced into that window, KASAN reports the read, and the free arrives on the ordinary RCU softirq path: BUG: KASAN: slab-use-after-free in ieee80211_stop_tx_ba_cb+0x3cd/0x400 Read of size 1 at addr ffff888002b9f52e by task kworker/0:1/10 [...] Freed by task 57: __kasan_slab_free+0x47/0x70 __rcu_free_sheaf_prepare+0x70/0x250 rcu_free_sheaf_nobarn+0x18/0x40 rcu_core+0x426/0x1310 handle_softirqs+0x144/0x590
    __irq_exit_rcu+0xea/0x150 irq_exit_rcu+0x9/0x20 sysvec_apic_timer_interrupt+0x6b/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 send_delba is only set when tx_stop is set, which happens for AGG_STOP_LOCAL_REQUEST alone, so this is reached on local teardown - session idle timeout, PTK rekey, suspend, HW reconfig - and not from a peer's DELBA. Read ndp into a local before the session is freed, while sta->lock is still held. tid_tx->ndp has a single writer, in ieee80211_tx_ba_session_handle_start(), which cannot run concurrently here: both paths are serialised by the wiphy mutex, and the session is already marked HT_AGG_STATE_STOPPING at this point. tid_tx->ndp is also the only tid_tx dereference left after ieee80211_remove_tid_tx() in this function. [move/change the comment a bit to be more general not just on ndp, initialize ndp directly] (CVE-2026-74489)

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

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

  - drm/vmwgfx DRAW_PRIMITIVES：在除法 vmw_cmd_draw（） 計算 maxnum = （header->size - sizeof（cmd->body）） / sizeof（*decl）;其中 header->size 是 u32，直接取自使用者提供的命令資料流。當 header->size 小於 sizeof（cmd->body） 時，無符號減法會換行至近 4 GiB，從而產生巨大的 maxnum。然後，任何使用者控制的 cmd->body.numVertexDecls 都會傳遞界限，並且迴圈會遠遠超過核心命令反彈緩衝區的末尾 decl[i]，從而產生核心記憶體的越界讀取。預先拒絕尺寸過小的標頭。
    (CVE-2026-74444)

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

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

  - ALSA：usb-audio：隱含回饋模式 snd_usb_handle_sync_urb（） 中的限制框架大小會依傳送者的步幅調整接收到的同步封包大小，並將結果直接儲存在 out_packet->packet_size[i] 中。如果連線的 USB 裝置傳送過大的同步封包，則此畫面計數可能會超過 ep->maxframesize。然後，未限制的幀計數會傳播到播放端點佇列，從而可能驅動超出端點硬體幀限制的封包傳輸。根據 snd_usb_handle_sync_urb（） 中的 ep->maxframesize 限制計算的幀計數，以防止過大的封包進入播放佇列。（CVE-2026-74497）

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

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

  - wifi： mwifiex：剖析 A-MSDU TDLS 框架時使用子幀長度 mwifiex_11n_dispatch_amsdu_pkt（） 將 A-MSDU 與 ieee80211_amsdu_to_8023s（） 分割並遍歷產生的子幀。對於每個子幀，它將子幀資料指標傳遞給 mwifiex_process_tdls_action_frame（），但將其與 skb->len（A-MSDU 父項的長度）配對，而不是 rx_skb->len：rx_skb = __skb_dequeue（&list）;rx_hdr = （struct rx_packet_hdr *）rx_skb->data;if （ISSUPP_TDLS_ENABLED（priv->adapter->fw_cap_info） &; ntohs（rx_hdr->eth803_hdr.h_proto） == ETH_P_TDLS） { mwifiex_process_tdls_action_frame（priv， （u8 *）rx_hdr， skb->len）; }父項不是該緩衝區的有效描述，而且可能根本不是有效的記憶體。
    ieee80211_amsdu_to_8023s（） 結尾為 if （！reuse_skb） dev_kfree_skb（skb）;而且它只會在父項是線性、不是head_frag，且作為「最後一個」子畫面使用時設定reuse_skb。因此，當父項不符合重複使用的條件時，它已經被釋放，而 skb->len 的讀取是釋放後使用。重複使用時，skb->len 是最後一個子幀的長度，應用於每個較早的子幀，每當較早的子幀較短時，它就會誇大緩衝區。被呼叫者無法吸收錯誤的長度，因為它會從給定的值衍生出自己的上限。每個框架類型計算 ies_len = len - sizeof（struct ethhdr） - TDLS_*_FIX_LEN;然後，元素遍歷完全以該上限為界，因為 （end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]） { u8 ie_len = pos[1]; if （pos + 2 + ie_len > end） break ;因此，太大的 len 會移動末端越過子框架的末端，並且遍歷會讀取並複製到子框架的末端之外。A-MSDU 佈局由發送者選擇，這使得最後一個子幀和較短的較早子幀之間的差異可以遠程選擇。要達到此目標，需要韌體中的 TDLS 支援，以及子框架上的 TDLS 乙太類型。另一個調用方 mwifiex_process_rx_packet（） 是正確的：它傳遞描述 RX 緩衝區相同區域的指標和長度。傳遞 rx_skb->len，實際剖析的子畫面長度。(CVE-2026-74488)

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

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

  - scsi：mpi3mr：修正從故障監視程式執行的 mpi3mr_fault_uevent_emit mpi3mr_fault_uevent_emit（） 中的潛在鎖死，並重設主機 I/O 可能已遭到封鎖的路徑。此處的GFP_KERNEL分配，無論是本機 kzalloc_obj（） 還是 kobject_uevent_env（） 本身內部的分配，都可以觸發等待該阻塞的 I/O 和鎖死的回收。使用 memalloc_noio_save（）/restore（） 來涵蓋整個呼叫，而不僅僅是本機分配。（CVE-2026-74526）

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

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

  - i2c：jz4780：在探測時快取主機時鐘速率以防止 CCF prepare_lock鎖死 修正通用時鐘架構 （CCF） 和 I2C 適配器鎖定之間的嚴重 AB/BA 鎖死，當 I2C 控制的時鐘產生器用戶端 （如 Si5351） 在 CCF 下註冊或修改時觸發。在 i2c 用戶端時鐘 （產生器） 頻率變更期間，CCF 會取得其全域「prepare_lock」互斥，而驅動程式會呼叫 i2c_transfer（） 來更新用戶端的晶片暫存器，因配接器的 I2C 匯流排鎖定而停止。同時，同一匯流排上的獨立並行傳輸 （例如，處理 LED 的 GPIO 擴展器） 可以保持 I2C 適配器鎖定。在此並行傳輸路徑中，jz4780_i2c_set_speed（） 呼叫主機控制器輸入時鐘上的 clk_get_rate（） 來計算匯流排時序。此呼叫會嘗試取得封鎖的 CCF「prepare_lock」，建立凍結系統的循環相依性。jz4780 主機控制器時鐘本身是靜態的，在運行時永遠不會改變。不過，在作用中傳輸路徑內呼叫 clk_get_rate（） 會引入對 CCF 內部鎖定的不必要的相依性。透過在 jz4780_i2c_probe（） 期間在私有jz4780_i2c結構內快取靜態主機周邊時鐘速率一次，從作用中傳輸路徑消除此同步 clk_get_rate（） 呼叫。更新 jz4780_i2c_set_speed（） 以使用此快取值，安全地將作用中的 I2C 交易與 CCF 內部鎖定分離，而不會產生任何過時計時的風險。由基於網絡的 Google AI 輔助（查明錯誤並編寫消息）。（CVE-2026-74463）

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

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

  - can： peak_usb： peak_usb_start（）：修正 URB 提交錯誤上的雙重釋放傳輸緩衝區 在 peak_usb_start（） 中，每個 RX URB 傳輸緩衝區都會使用 kmalloc（） 配置，並將 URB 標記為URB_FREE_BUFFER，以便最終的 usb_free_urb（） 也會釋放傳輸緩衝區。如果 usb_submit_urb（） 失敗，錯誤路徑會使用 kfree（buf） 明確釋放緩衝區，然後呼叫 usb_free_urb（urb）。
    因為設定了URB_FREE_BUFFER，所以 usb_free_urb（） -> urb_destroy（） 第二次釋放相同的緩衝區，即傳輸緩衝區的雙重釋放。錯誤：KASAN：usb_free_urb.part.0+0x91/0xb0 中的雙重釋放 任務 trigger.sh/285 釋放 addr ffff8881069ccb80 呼叫追蹤：kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 刪除冗餘的 kfree（buf）;usb_free_urb（） 已釋放傳輸緩衝區。這鏡像提交 03819abbeb11 （net：usb：lan78xx：修正中斷緩衝區配置的雙重釋放問題）。
    (CVE-2026-74456)

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: harden runlist realloc size calculations Add a shared helper to safely convert runlist element counts to byte sizes using overflow checks, and use it in both ntfs_rl_realloc() and ntfs_rl_realloc_nofail(). (CVE-2026-74570)

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

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

  - Bluetooth： ISO：避免 iso_sock_timeout iso_sock_timeout（） 中的鎖死需要lock_sock，因此在按住該鎖定時停用計時器可能會鎖死。iso_sock_timeout（） 也可能與 iso_conn_del（） 同時執行，這會導致 UAF [任務 1] [任務 hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del '------------> iso_conn_put呼叫端釋放 hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL;/* UAF */ 透過移除 lock_sock 區段中的停用來修正鎖死。將計時器從 iso_conn 移至 iso_pinfo，以將其與可能需要在lock_sock區段中釋放的iso_conn分離。將部分clear_timer轉換為disable_timer。（CVE-2026-74535）

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

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

  - ALSA： usb-audio：修正 snd_usbmidi_akai_output（） 中的 OOB 寫入 snd_usbmidi_akai_output（） 計算其填充迴圈界限 buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;作為帶正負號的 int，因此小型裝置通告的大量 OUT max_transfer會使buf_end為負數。然後，迴圈防護將 u32 urb->transfer_buffer_length 與負 int 進行比較：通常的算術轉換會將buf_end轉換為較大的無符號值，因此防護保持 true，並且每次迭代都會不斷附加 SysEx 框架和有效負載位元組，超過 URB 傳輸緩衝區的末尾，該緩衝區只有 max_transfer 位元組長。因此，當處理程序寫入建立的 /dev/snd/midiC*D* 節點時，通告小型大量輸出端點的 USB 裝置可能會觸發攻擊者長度和內容控制的堆積越界寫入。當連一個 SysEx 都沒有空間時，請儘早返回，因此迴圈永遠不會以換行的界限進入。迴圈是函數的最後一個語句，因此救助相當於它沒有運行。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74499）

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

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

  - 藍牙：L2CAP：修正 l2cap_le_connect_rsp l2cap_le_connect_rsp（） 中的 UAF 透過以下方式取得通道
    __l2cap_get_chan_by_ident（），但既不持有參照，也不在鎖定和操作之前使用 l2cap_chan_hold_unless_zero（）。由遠端中斷連線觸發的並行 l2cap_chan_del（） 可以釋放查詢和 l2cap_chan_lock（） 之間的通道，從而導致釋放後使用。BR/EDR 對應的 l2cap_connect_rsp（） 和同級處理常式 l2cap_le_command_rej（） 已使用 l2cap_chan_hold_unless_zero（） 來安全地保存參照，但 l2cap_le_connect_rsp（） 未受到保護。
    透過在 ident 查詢之後新增 l2cap_chan_hold_unless_zero（） 並在退出路徑上新增 l2cap_chan_put（） 來修正，這與其他 L2CAP 回應處理常式一致。（CVE-2026-74540）

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

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

  - riscv：mm：修正記憶體熱移除期間的越界頁面表格遍歷 remove_pud_mapping（） 和 remove_p4d_mapping（） 取得具有 pud_offset（p4dp， 0） 和 p4d_offset（pgd， 0） 的子表庫，然後新增 addr 的索引。RISC-V 在運行時折疊頁面表格級別。當層級摺疊時，其位移協助程式會傳回父專案本身，但索引仍可為非零。新增它會經過父資料表。Sv48 會摺疊 P4D，而 Sv39 會同時摺疊 P4D 和 PUD，因此記憶體熱移除可能會下降到不相關的記憶體中，並將無效的頁面傳遞給 __free_pages（）。這可能會觸發：include/linux/mm.h：1810！VM_BUG_ON_PAGE（page_ref_count（page） == 0） arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c 只有在啟用對應的頁面表格層級且符合 p4d_offset（） 和 pud_offset（） 時才新增索引。（CVE-2026-74524）

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

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

  - drm/vmwgfx：根據字尾指標 vmw_cmd_dma（） 繫結 DMA 命令內文大小，將 DMA 字尾位於 （無符號長） &cmd->body + header->size - sizeof（*suffix），而不檢查 header->size 是否足夠大，可以同時包含 cmd->body 和字尾。標頭大小過小會使尾碼指標反向溢位回退回緩衝區中的上一個命令。驗證程式稍後會寫入 suffix->maximumOffset，以破壞先前已重新定位的命令的已驗證欄位 -- 裝置可見命令資料流上的 TOCTOU，可讓一個命令重寫另一個命令的 GMR 識別碼、表面識別碼或其他已驗證的欄位。
    如果主體太小而字尾無法容納，則拒絕該命令。（CVE-2026-74443）

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

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

  - qede：同步復原路徑中 qede_lock 之外的 udp_tunnel 連接埠 在設定了 VXLAN/GENEVE 通道連接埠的 qede NIC 上，TX 逾時會楔入整部機器的 rtnetlink 控制平面： NETDEV 看門程式：ens6f1 （qede）：傳輸佇列 2 逾時 10226 毫秒 [qede_tx_timeout：586（ens6f1）]佇列 2 上的 TX 逾時！[qede_recovery_handler：2665（ens6f0）]啟動復原程序 驅動程式自己的互斥體上的復原路徑鎖死：qede_sp_task rtnl_lock（） mutex_lock（&edev->qede_lock） <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock（&edev->qede_lock） <- 相同的任務：鎖死 互斥體不是遞迴的，因此 kworker 會以 rtnl_lock 保留來封鎖自身，並且這兩個鎖定都不會釋放。之後調用 rtnl_lock（） 的每個任務 （ip、ovs-vswitchd、lldpad、IPv6 addrconf、sshd） 都會在節點仍回應 ping 時永久封鎖。在受影響生產節點的 vmcore 中，rtnl_mutex.owner 解碼為上面最裡面的 mutex_lock（） 封鎖的 kworker。刪除內部鎖定後，從 qede_sp_task（） 重新同步通道連接埠，仍根據 udp_tunnel API 的要求處於rtnl_lock狀態。這反映了 qede_open（），它在沒有內部鎖定的情況下呼叫 rtnl 下的 udp_tunnel_nic_reset_ntf（）。qede_recovery_handler（） 現在會傳回是否已成功重新載入開啟的裝置，而呼叫端只會在此情況下重新同步埠。這完全保留了舊的門控：已關閉或復原失敗的裝置傳回 false，因為這些路徑之前從未到達過 udp_tunnel_nic_reset_ntf（） 呼叫。這是 qede_lock（）/qede_unlock（） 協助程式的唯一使用者，因此請將其移除。（CVE-2026-74523）

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

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

  - mm/page_reporting：使用 system_freezable_wq 修復暫停期間的 UAF 在 PM 凍結期間（例如 S3 暫停或 S4 休眠），設備驅動程式 （如 virtio_balloon） 會重設其底層 virtio 裝置，並透過 vdev->config->del_vqs（） 刪除其 virtqueue。不過，頁面報告工作 （page_reporting_process） 已排程在全域system_wq上。由於system_wq缺少WQ_FREEZABLE標誌，因此 PM 冷凍機會跳過它，從而在暫停期間保持page_reporting_process活動狀態。如果頁面在暫停時被釋放到好友配置器中（例如，當核心 MM 在 S4 休眠影像儲存期間呼叫氣球縮減器時），頁面報告會在已刪除的 virtqueue 上觸發 virtballoon_free_page_report（），導致釋放後使用/一般保護錯誤： [ 196.795226] 一般保護錯誤，可能用於非規範位址 0xaa1436fe70dae6df：0000 [#1] SMP NOPTI [ 196.825967] 工作佇列：事件page_reporting_process [196.831038] RIP： 0010：virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 透過將頁面報告工作切換為 system_freezable_wq 來解決此問題。這可確保 PM freezer 在裝置驅動程式破壞其報告 virtqueue 之前暫停page_reporting_process。由於報告工作程式已凍結，記憶體回收/釋放 （例如透過壓縮器執行） 可以在凍結期間安全地將頁面傳回給 MM，而不會在已刪除的 virtqueue 上觸發未凍結的報告工作。這與駕駛員現有的設計一致。virtballoon_freeze（） 中的註解指出： /* * 在呼叫此 * 函式之前，工作佇列已由 PM 核心凍結。*/ 測試：我已經使用 Google 的虛擬化基礎設施驗證了這些修復，方法是運行連續的暫停/恢復迭代（40+ 週期），同時使用 stress-ng（'stress-ng --vm 4 --vm-bytes 60% --timeout 1'）攪動記憶體，不斷為好友分配器建立空閒頁面。我們還將「page_reporting_order」參數設定為 0，以使頁面報告工作角色高度敏感，強制其選擇任何 4K 免費頁面。這證實了 UAF 崩潰不再可重現。（CVE-2026-74481）

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

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

  - s390/zcrypt： 關閉推測性記憶體讀取可能性 當即將傳送 CPRB 時，會從指定的 CCA 或 EP11 ioctl 結構中擷取網域值。因此，這是使用者控制的值。在某些特殊條件 （使用自訂裝置節點、系統管理負載） 下，此值會在邊界檢查之後用作陣列索引，但沒有推測障礙。新增缺少的 array_index_nospec（） 呼叫，以防止使用此網域值時進行推測執行。（CVE-2026-74466）

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

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

  - s390/qeth：檢查私有 ioctl 的CAP_NET_ADMIN 使用 SIOCDEVPRIVATE ioctl 命令 SIOC_QETH_ADP_SET_SNMP_CONTROL、SIOC_QETH_GET_CARD_TYPE 和 SIOC_QETH_QUERY_OAT 進行CAP_NET_ADMIN檢查，以確保無特權的使用者無法叫用它們。（CVE-2026-74467）

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

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

  - net/smc：修正連結群組終止期間的通訊端釋放後使用 __smc_lgr_terminate（） 在 LGR->conns_all 中找到連線後，但在參照其通訊端之前，但會丟棄conns_lock。連線內嵌在通訊端中，其登錄參照只會在連線保留在樹狀結構中時保護它。並行關閉可以取消註冊連接並刪除該參照，從而在終止工作程式到達 sock_hold（） 之前釋放通訊端。當緊密重疊連結群組終止時，可連線爭用。本機壓力測試重現了釋放後使用，KASAN 報告了： 錯誤： KASAN：__smc_lgr_terminate.part.0 中的 slab-use-after-free [smc] 按任務 kworker/3:3 工作佇列寫入大小為 4：事件 smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] 通訊端由 smc_create（） 配置，透過 slab_free_after_rcu_debug（） 釋放，後面接著：refcount_t：0 上新增;釋放後使用。
    __smc_lgr_terminate.part.0 [smc] 獲取通訊端參照，同時conns_lock仍保護樹狀結構項目。
    然後，取消註冊路徑無法刪除最後一個參照，直到終止使用通訊端為止。
    (CVE-2026-74493)

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

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

  - can： etas_es58x： es58x_read_bulk_callback（）：修正 URB 重新提交失敗時的 RX 緩衝區洩漏 es58x_read_bulk_callback（） 在處理收到的封包後重新提交 RX URB。如果重新提交成功，URB 會保持錨定狀態，而且會由一般 RX 路徑或卸除來處理。不過，如果 usb_submit_urb（） 失敗，回呼會取消錨定 URB，然後直接傳回。這會跳過現有的free_urb路徑，因此不會釋放使用 usb_alloc_coherent（） 配置的一致傳輸緩衝區。重新提交失敗後重複使用現有的free_urb路徑，以便在離開回呼之前釋放 RX 相干緩衝區。（CVE-2026-74459）

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

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

  - thunderbolt：防止 XDomain 在中斷連線時因釋放後使用而延遲工作 tb_xdp_handle_request（） 在 system_wq 上執行，並透過三個要求處理常式中的 queue_delayed_work（） 將 xd->state_work 排入佇列：
    PROPERTIES_CHANGED_REQUEST、UUID_REQUEST（透過 start_handshake）和LINK_STATE_CHANGE_REQUEST。同樣地，當本機屬性變更時，update_xdomain（） 會將 xd->properties_changed_work 排入佇列。同時，tb_xdomain_remove（） 調用 stop_handshake（），它對兩個延遲的工作都執行 cancel_delayed_work_sync（）。
    稍後，tb_xdomain_unregister（） 呼叫 device_unregister（），最終釋放 xdomain。由於提交 559c1e1e0134 （霹靂：在系統工作佇列中執行 tb_xdp_handle_request（） ） 將要求處理常式移出 tb->wq，因此處理常式和移除路徑不再序列化。如果 queue_delayed_work（） 在 cancel_delayed_work_sync（） 之後但在釋放 xdomain 之前執行，則延遲的工作會在釋放的物件上觸發。在呼叫 stop_handshake（） 之前，新增 xd->removing 該 tb_xdomain_remove（） 集在 xd->lock 下。
    每個外部佇列網站都會保留相同的鎖定，並在呼叫 queue_delayed_work（） 之前檢查移除。這會提供所需的相互排除：佇列網站會先取得鎖定，並將後續取消會看到的工作排入佇列，或移除路徑會先取得鎖定，而佇列網站會觀察到移除 == true 並略過佇列。（CVE-2026-74575）

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

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

  - 藍牙：hci_sync：修正廣告資料 UAF hci_find_adv_instance（） 傳回僅在保留 hdev->lock 時有效的adv_info指標。通告命令同步路徑會在沒有鎖定的情況下執行執行個體查詢，在某些情況下，會在等候控制器回應時保留指標。因此，廣告終止事件可以交錯如下： hci_cmd_sync_work hci_rx_work hci_find_adv_instance（） __hci_cmd_sync_status（） 等待控制器回覆 hci_dev_lock（） hci_remove_adv_instance（） kfree（adv） adv->scan_rsp_changed = false KASAN 報告： 錯誤： KASAN：hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 中的 slab-use-after-free 任務 kworker/u17：0/88 在 addr ffff88810a45d21d 寫入大小 1 的工作佇列： hci0 hci_cmd_sync_work 呼叫追蹤：hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 由作業 87 分配：
    hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 由任務 89 釋放：kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 保護擴充通告、掃描回應和定期通告資料路徑中的執行個體查詢和承載建構。
    在 hdev->lock 下快照廣告參數，但在等待控制器之前釋放鎖定。在發出命令之前清除廣告資料的髒位，並在失敗後使用新的查詢還原它們。同樣地，在參數命令完成後，透過全新查詢來更新報告的發射功率。然後，任何adv_info指標都不會在 HCI 命令等待中存活。（CVE-2026-74509）

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

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

  - wifi：ath12k：修正 ath12k_mac_dp_peer_cleanup（） 中的越界clear_bit ath12k_mac_dp_peer_cleanup（） 會以 dp_peer->peer_id 為點陣圖編製索引，以清除 free_ml_peer_id_map 點陣圖上的 ML 對等 ID 插槽。這是錯誤的：MLO 對等體的 dp_peer->peer_id 始終攜帶 ATH12K_PEER_ML_ID_VALID 位元 （BIT（13）），因此 clear_bit（） 以索引 >= 0x2000 調用，該索引遠遠超出 ATH12K_MAX_MLO_PEERS （256） 位元的點陣圖，並損壞了與 ah->free_ml_peer_id_map 相鄰的記憶體。預期的點陣圖項目也永遠不會被清除，因此後續的 ath12k_peer_ml_alloc（） 呼叫最終會用完 ID。沒有 VALID 位元的 ID 是 ath12k_peer_ml_alloc（） 傳回的 ID，並儲存在 ahsta->ml_peer_id 中。請改用它。同時，將 ahsta->ml_peer_id 重設為ATH12K_MLO_PEER_ID_INVALID，以便點陣圖和 ahsta->ml_peer_id保持同步。測試對象： WCN7850 hw2.0 PCI WLAN。HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 （CVE-2026-74554）

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

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

  - USB：typec：ucsi：修正連接埠取消註冊中的爭用情形和排序 在連接埠取消註冊期間存在同步處理問題，其中擱置中的合作夥伴工作專案可能會與工作佇列損毀爭用，進而導致釋放後使用狀況： cros_ec_ucsi cros_ec_ucsi.3.auto：錯誤 -ETIMEDOUT：PPM 初始化失敗 錯誤：核心 NULL 指標解除參照，位址：00000000000000000 RIP：0010：__queue_work+0x83/0x4a0 呼叫追蹤： <IRQ> __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 透過確保在拆卸期間嚴格排序和正確的序列化來解決此問題： 1. 將 ucsi_unregister_partner（） 移至拆卸序列的開頭，並在連接器互斥鎖定下保護它。2. 確保在工作佇列被銷毀之前，所有擱置中的合作夥伴任務都已明確排清並完成。3. 從 mod_delayed_work（） 切換到 cancel_delayed_work（） 和 queue_delayed_work（） 序列。這可以保證目前標記為待處理的項目不會被安排額外的時間，從而防止資源的雙重釋放導致以下當機： 哎呀：一般保護錯誤，可能是非標準位址0xdead000000000122：
    0000 [#1] SMP NOPTI 工作佇列：cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP：
    0010：ucsi_poll_worker+0x65/0x1e0 呼叫追蹤： <TASK> process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 若要確保這些規則在一般拆卸和 ucsi_init（） 錯誤路徑中以相同方式套用，請將清理邏輯合併到新的協助程式 ucsi_unregister_port（） 中。（CVE-2026-74441）

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

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

  - nexthop：在替換檢查中採用 nh->lock 進行f6i_list遍歷，並通知 fib6_check_nh_list（） 和
    __nexthop_replace_notify（） 在 RTNL 序列化的 nexthop 取代期間遍歷 nh->f6i_list，而不保留 nh->lock。IPv6 RTM_NEWROUTE/RTM_DELROUTE 在沒有 RTNL 的情況下運行，並在 nh->lock （fib6_add_rt2node_nh（）、fib6_purge_rt（）） 下更改該清單，因此兩個遍歷都會爭用並發路由刪除，以取消連結並釋放fib6_info： 錯誤：KASAN：rt6_fill_node.isra.0 中的 slab-use-after-free （net/ipv6/route.c：5799） 透過 task exploit/14 rt6_fill_node 3 讀取 addr ffff888014607e64 的大小 4 （net/ipv6/route.c：5799） fib6_rt_update （net/ipv6/route.c：6412） __nexthop_replace_通知 （net/ipv4/nexthop.c：2542） rtm_new_nexthop （net/ipv4/nexthop.c：2554） rtnetlink_rcv_msg （net/core/rtnetlink.c：7076） 錯誤： KASAN：fib6_check_nh_list中的 slab-use-after-free （net/ipv4/nexthop.c：1605） 透過 task exploit/142 fib6_check_nh_list在 addr ffff888014a7d068 讀取大小 8 （net/ipv4/nexthop.c：1605） rtm_new_nexthop （net/ipv4/nexthop.c：2575） rtnetlink_rcv_msg （net/core/rtnetlink.c：7076） 兩次遍歷都只讀取項目，不採取任何tb6_lock， 因此，請使用 NH->lock 保護它們;fib6_rt_update（） 使用 gfp_any（），它傳回鎖定下的GFP_ATOMIC。（CVE-2026-74562）

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

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

  - ALSA： ump：修正 rawmidi 錯誤上的雙重釋放out_cvts 錯誤 snd_ump_attach_legacy_rawmidi（） 配置舊版轉換陣列 ump->out_cvts，並在 snd_rawmidi_new（） 錯誤路徑上使用 kfree（） 釋放它，但讓 ump->out_cvts 指向釋放的記憶體。當端點稍後被拆除時，snd_ump_endpoint_free（） 會第二次釋放 ump->out_cvts，從而產生雙重釋放。主機 snd-usb-audio 驅動程式會附加任何 USB MIDI 2.0 （UMP） 裝置的舊版 rawmidi，因此造成 snd_rawmidi_new（） 失敗的裝置會在列舉時到達此路徑。在錯誤路徑上釋放 ump->out_cvts 後清除它，以便在拆卸期間不會再次釋放它。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74502）

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

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

  - 藍牙：ISO：在iso_conn_ready中正確按住 sk iso_conn_ready sk 解除參照必須在 conn->lock 下完成，或按住參照計數，以避免並行關閉。conn->sk 目前可以在沒有以下任一的情況下存取： [任務 1] [任務 2] iso_sock_release iso_conn_ready sk = conn->sk lock_sock（sk） conn->sk = NULL lock_sock（sk） release_sock（sk） iso_sock_kill（sk） sk deref 上的 UAF 透過在 iso_conn_ready（） 中保留 sk refcount 來修正可能的 UAF。lock_sock後也請重新檢查通訊端是否仍然有效。調整鎖定，以便僅在lock_sock下清除 conn->sk。（CVE-2026-74537）

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

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

  - um： vector：修正 vector_mmsg_rx（） 中的釋放後使用 當 vector_mmsg_rx（） 捨棄覆蓋標頭失敗 verify_header（） 的封包時，它會釋放 skb 並繼續循環： if （header_check < 0） {dev_kfree_skb_irq（skb）; vp->estats.rx_encaps_errors++; 繼續; }正常和短封包路徑會落入迴圈主體的底部，這會清除已消耗的插槽並推進游標：
    （*skbuff_vector） = 空;mmsg_vector++;skbuff_vector++;< 0 路徑的 verify_header（） 會透過 continue 跳過該路徑，因此釋放的 skb 會留在裡面 skbuff_vector[] ，而且游標不會前進。下一次迭代讀取相同的插槽，獲取釋放的 skb，然後再次釋放它，從而在 RX 路徑中產生引用計數下溢/釋放後使用。在繼續之前，請以與其他路徑相同的方式捨棄插槽。只有 verify_header（） 可以傳回負數的傳輸才會受到影響：GRE 和 L2TPv3 會在 cookie/session-id 不相符的情況下執行此操作（raw/tap 不會），因此此類傳輸上的任何對等體都可以在不進行身份驗證的情況下觸發它。
    (CVE-2026-74478)

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

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

  - binfmt_misc：將 exe_file_deny_write_access（） 用於解譯器複製 對於MISC_FMT_OPEN_FILE條目 load_misc_binary（） 會複製已註冊的解譯器檔案，並透過純 deny_write_access（） 拒絕對複製的寫入存取權。複製會以 bprm->interpreter 的形式安裝，稍後由執行機器透過 exe_file_allow_write_access（） 釋放，這會跳過設定有FMODE_FSNOTIFY_HSM檔案的i_writecount增量。因此，當預內容監視正在發揮作用時，拒絕和允許方可能會得出不同的結論：如果在註冊後將預內容監視添加到解釋器中，則通過該條目的每個後續執行器都會對從未與寫入允許配對的克隆進行寫入拒絕，從而使解釋器 inode 的i_writecount隨著每個執行器進一步向下移動，並且即使在條目及其所有用戶都消失後，解釋器也無法寫入。通過 exe_file_deny_write_access（） 進行寫入拒絕，因此配對的雙方都基於相同的文件模式做出決定，並傳播失敗而不是默默地忽略它：同時開放寫入的解釋器現在使用 ETXTBSY 使執行失敗，就像通過 open_exec（） 新打開的解釋器一樣。
    (CVE-2026-74486)

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

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

  - hwmon：（nct6775-core） 防止存取不支援的權重暫存器 Sashiko 報告： 在初始化 nct6116 晶片期間，驅動程式將 data->pwm_num 設定為 5。不過，它會將數 NCT6106 個暫存器陣列 （例如 NCT6106_REG_WEIGHT_DUTY_STEP、NCT6106_REG_WEIGHT_TEMP_SEL 和 NCT6106_REG_WEIGHT_TEMP_*） 指派給 data->REG_PWM 和 data->REG_WEIGHT_TEMP。這些陣列僅包含 3 個元素。在 nct6775_update_pwm（） 中，驅動程式會反覆運算至資料>pwm_num。如果資料>has_pwm設定了位元 3 或 4 （這在結構上對於 nct6116 來說是可能的） ，則迴圈會嘗試從這些 3 元素陣列讀取索引 3 和 4 的元素。這會導致全域越界讀取，而 KASAN 可能會捕獲該讀取。
    此外，驅動程式會使用這些垃圾越界值作為後續讀取和寫入作業的硬體暫存器位址。這會導致無效的硬體暫存器訪問，可能導致硬體配置錯誤或系統崩潰。根本問題是該晶片確實支援多達五個風扇控制通道，但只有前三個支援重量控制。藉由使用零欄位擴充受影響的權重暫存器陣列來修正問題。驅動程式會使用歸零的暫存器位址來判斷是否支援暫存器，並略過不支援暫存器的存取。
    (CVE-2026-74549)

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

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

  - ALSA： usb-audio：修正 RME Digiface 狀態中的堆疊資訊洩露 snd_rme_digiface_read_status（） 會從裝置讀取四個字的狀態區塊，將未初始化的堆疊上 __le32 buf[4] 讀取，並且每當供應商 control-IN 傳輸未傳回負錯誤時，就會將所有四個字複製到呼叫者的 status[] 中。
    不論資料階段實際傳遞多少位元組，snd_usb_ctl_msg（） 都會將完整要求的大小複製回呼叫端的緩衝區： buf = kmemdup（data， size， GFP_KERNEL）;err = usb_control_msg（dev， pipe， request， requesttype， value， index， buf， size， timeout）;memcpy（data， buf， size）;usb_control_msg（） 在短 control-IN 上傳回傳輸的長度，這是一個非負值，並且只寫入該數量的位元組。複製回的其餘部分是調用方緩衝區的 kmemdup（） 映像，因此以短資料階段回應的裝置會留下 buf[] 的尾隨字，其中包含剩餘的核心堆疊。調用方中唯一的守衛是 err < 0，因此這些單詞存儲在 status[] 中。然後，它們會到達使用者空間：
    snd_rme_digiface_get_status_val（） 根據控制項的 reg/mask 選擇一個 16 位半字的 status[]，並且八個 Digiface 狀態控制項一起將整個 16 位元組框架公開給無權限的 /dev/snd/controlC* 讀取器。零初始化緩衝區，讓短讀取產生零，而不是堆疊殘留。這反映了 snd_rme_get_status1（），它已經在相同類型的供應商讀取之前清除了其輸出字。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74500）

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

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

  - xsk：xsk_build_skb（） 中溢位後排空延續 descs） 當封包太大 （描述元計數超過 MAX_SKB_FRAGS） 或片段封包中包含無效描述元時，修正通用 xmit 路徑多緩衝區邏輯。引入 xdp_sock：:d rain_cont 並對此旗標採取行動 — 設定後，請繼續從 Tx 環AF_XDP使用描述元，並將它們直接放在 Cq 上。以前，這些描述符被悄無聲息地丟失了，再也無法聯繫到。（CVE-2026-74559）

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

ID	名稱	嚴重性
335913	Linux Distros 未修補弱點：CVE-2026-20783	medium
335912	Linux Distros 未修補弱點：CVE-2026-20786	medium
335911	Linux Distros 未修補弱點：CVE-2026-20769	medium
335910	Linux Distros 未修補弱點：CVE-2026-20731	medium
335909	Linux Distros 未修補弱點：CVE-2026-72887	critical
335906	Linux Distros 未修補弱點：CVE-2026-63650	low
335905	Linux Distros 未修補弱點：CVE-2026-49282	medium
335904	Linux Distros 未修補弱點：CVE-2026-49263	low
335903	Linux Distros 未修補弱點：CVE-2026-46603	high
335890	Linux Distros 未修補弱點：CVE-2026-74465	high
335889	Linux Distros 未修補弱點：CVE-2026-74490	high
335888	Linux Distros 未修補弱點：CVE-2026-74470	high
335887	Linux Distros 未修補弱點：CVE-2026-74479	high
335886	Linux Distros 未修補弱點：CVE-2026-74561	high
335885	Linux Distros 未修補弱點：CVE-2026-74474	critical
335884	Linux Distros 未修補弱點：CVE-2026-74440	high
335883	Linux Distros 未修補弱點：CVE-2026-74475	critical
335882	Linux Distros 未修補弱點：CVE-2026-74545	critical
335881	Linux Distros 未修補弱點：CVE-2026-74568	critical
335880	Linux Distros 未修補弱點：CVE-2026-74489	high
335879	Linux Distros 未修補弱點：CVE-2026-74444	high
335878	Linux Distros 未修補弱點：CVE-2026-74497	high
335877	Linux Distros 未修補弱點：CVE-2026-74488	high
335876	Linux Distros 未修補弱點：CVE-2026-74526	medium
335875	Linux Distros 未修補弱點：CVE-2026-74463	medium
335874	Linux Distros 未修補弱點：CVE-2026-74456	high
335873	Linux Distros 未修補弱點：CVE-2026-74570	critical
335872	Linux Distros 未修補弱點：CVE-2026-74535	high
335871	Linux Distros 未修補弱點：CVE-2026-74499	high
335870	Linux Distros 未修補弱點：CVE-2026-74540	high
335869	Linux Distros 未修補弱點：CVE-2026-74524	high
335868	Linux Distros 未修補弱點：CVE-2026-74443	high
335867	Linux Distros 未修補弱點：CVE-2026-74523	high
335866	Linux Distros 未修補弱點：CVE-2026-74481	high
335865	Linux Distros 未修補弱點：CVE-2026-74466	high
335864	Linux Distros 未修補弱點：CVE-2026-74467	high
335863	Linux Distros 未修補弱點：CVE-2026-74493	critical
335862	Linux Distros 未修補弱點：CVE-2026-74459	high
335861	Linux Distros 未修補弱點：CVE-2026-74575	high
335860	Linux Distros 未修補弱點：CVE-2026-74509	high
335859	Linux Distros 未修補弱點：CVE-2026-74554	high
335858	Linux Distros 未修補弱點：CVE-2026-74441	medium
335857	Linux Distros 未修補弱點：CVE-2026-74562	high
335856	Linux Distros 未修補弱點：CVE-2026-74502	medium
335855	Linux Distros 未修補弱點：CVE-2026-74537	high
335854	Linux Distros 未修補弱點：CVE-2026-74478	critical
335853	Linux Distros 未修補弱點：CVE-2026-74486	high
335852	Linux Distros 未修補弱點：CVE-2026-74549	high
335851	Linux Distros 未修補弱點：CVE-2026-74500	high
335850	Linux Distros 未修補弱點：CVE-2026-74559	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

critical

low

medium

low

high

high

high

high

high

high

critical

high

critical

critical

critical

high

high

high

high

medium

medium

high

critical

high

high

high

high

high

high

high

high

high

critical

high

high

high

high

medium

high

medium

high

critical

high

high

high

medium