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

  - OpenFlow v6 通訊協定剖開 Wireshark 4.6.04.4.144.6.44.4.0 中的無限迴圈，以允許拒絕服務 （）CVE-2026-6520

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

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

  - GStreamer 專案報告了該 1.28.2 版本中修正的多個安全漏洞： 解決了多個安全漏洞，包括： 這些漏洞可能導致應用程式崩潰、記憶體耗盡或潛在的任意程式碼執行。（CVE-2026-5056）

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

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

  - Incus 是一個系統容器和虛擬機器管理器。在之前的 7.0.0版本中，儲存貯體匯入邏輯中缺少驗證邏輯，可讓具有儲存貯體功能存取權的已驗證使用者導致 Incus 精靈當機。此弱點存在於備份中繼資料處理邏輯中，其中常駐程式會處理匯入封存中的 index.yaml 檔案，並存取剖析備份組態的成員，而不需要先驗證組態物件是否已初始化。省略組態區塊的惡意或格式錯誤的 index.yaml 會在儲存貯體匯入作業期間造成 nil 指標解除參照，並終止精靈。重複使用此問題可用於使 Incus 保持離線狀態，從而導致拒絕服務。7.0.0 版已修正此問題。(CVE-2026-40195)

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

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

  - 加密：ccp：若 PSP 指令失敗，請勿嘗試將 PDH 憑證複製至 userspace。在取得 PDH 憑證時，若韌體指令失敗，則不要嘗試將 blobs 複製到 userspace。若因長度無效，即使用者空間緩衝區+長度過小，則複製位元組數
    _firmware_ 需要 會溢出核心分配的緩衝區，並將資料洩漏到使用者空間。蟲子：卡桑：
    instrument_copy_to_user 的板子界外....../include/linux/instrumented.h：129 [內嵌] 錯誤：KASAN：
    _inline_copy_to_user 的板狀界外....../include/linux/uaccess.h：205 [內嵌] 錯誤：KASAN：_copy_to_user+0x66/0xa0 ../lib/usercopy.c：26 任務 syz.0.186/21033 讀取 2084 大小 於 addr ffff8885c4ab8aa0 由任務 syz.0.186/21033 CPU： 51 UID： 0 PID： 21033 通訊： syz.0.0.186 受污染： G U O 7.0.0-smp-DEV #28 PREEMPTLAZY 受污染： [U]=USER， [O]=OOT_MODULE 硬體名稱：Google， Inc. Arcadia_IT_80/Arcadia_IT_80， BIOS 34.84.12-0 2025/11/17 通話追蹤： <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c：120 print_address_description ../mm/kasan/report.c：378 [內嵌] print_report+0xbc/0x260 ../mm/kasan/report.c：482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c：595 check_region_inline../mm/kasan/generic.c：-1 [內嵌] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c：200 instrument_copy_to_user ../include/linux/instrumented.h：129 [內嵌] _inline_copy_to_user ../include/linux/uaccess.h：205 [內嵌] _copy_to_user+0x66/0xa0 ../lib/usercopy.c：26 copy_to_user ../include/linux/uaccess.h：236 [內嵌] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c：2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c：2568 vfs_ioctl ../fs/ioctl.c：51 [內嵌]
    __do_sys_ioctl....../fs/ioctl.c：597 [內文] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c：583 do_syscall_x64 ../arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 如果驅動程式顯示指令成功，但韌體錯誤代碼卻顯示相反，則 WARN __sev_do_cmd_locked（） 預期會在任何 firwmware 錯誤中回傳 -EIO。（CVE-2026-31698）

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

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

  - RPKI-Router 通訊協定將 Wireshark 4.6.04.6.4 中的無限迴圈分割至 和 4.4.0 to 4.4.14 允許拒絕服務 （CVE-2026-6522）

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

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

  - 藍牙：hci_event：將喚醒原因儲存移入驗證事件處理程序 hci_store_wake_reason（） 在剝除 HCI 事件標頭後，但 hci_event_func（） 強制執行每個事件最小有效載荷長度之前，從 hci_event_packet（） 呼叫hci_ev_table。這表示一個短的 HCI 事件幀可以在任何邊界檢查執行前就達到 bacpy（）。與其在 hci_store_wake_reason（） 內重複 skb 解析與每事件長度檢查，不如在現有事件長度驗證成功後，將喚醒位址儲存移入各個事件處理程序。將 hci_store_wake_reason（） 轉換成一個小型輔助器，只儲存已驗證過的 bdaddr，而呼叫者則持有 hci_dev_lock（）。在 hci_event_func（） 後使用同一助手搭配 NULL 位址，以保留現有的意外喚醒回備語語，當沒有經過驗證的事件處理程序記錄喚醒位址時。在輔助器上標註為
    __must_hold（&hdev->lock），並加上 lockdep_assert_held（&hdev->lock），讓未來的呼叫路徑保持鎖定合約明確。呼叫助手時，請從 hci_conn_request_evt（）、hci_conn_complete_evt（）、hci_sync_conn_complete_evt（）、le_conn_complete_evt（）、hci_le_adv_report_evt（）、hci_le_ext_adv_report_evt（）、hci_le_direct_adv_report_evt（）、hci_le_pa_sync_established_evt（）和 hci_le_past_received_evt（）。（CVE-2026-31771）

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

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

  - bpf：修正因原子取指精確追蹤而產生的錯誤剪枝。當backtrack_insn遇到帶有 BPF_ATOMIC 和 BPF_FETCH 的 BPF_STX 指令時，src 暫存器（或 r0 表示 BPF_CMPXCHG）也作為目的地，從記憶體位置接收舊值。目前的回溯邏輯並未考慮到這點。它將原子擷取操作視為一般儲存，僅將 src 暫存器視為輸入。這會導致backtrack_insn無法將精確度傳遞到堆疊位置，導致堆疊位置無法被標記為精確！之後，驗證者的路徑剪枝可能會錯誤地將兩個狀態視為等價，當它們在堆疊狀態上不同時。也就是說，兩個分支可以被視為等價，因此在不該被視為這樣的情況下卻被修剪。修正方式如下：在 backtrack_insn 中擴展 BPF_LDX 處理，也透過 is_atomic_fetch_insn（） 輔助工具涵蓋原子擷取操作。當擷取 DST 暫存器被追蹤精度時，清除它，並將精度傳遞到堆疊插槽。對於非堆疊記憶體，精確步走在原子指令處停止，與一般BPF_LDX相同。
    這涵蓋了所有撿球變體。之前：0：（b7） r1 = 8;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3：（db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=fp0 5： （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= before 4： （bf） r3 = r10 mark_precise：
    Frame0： regs=r2 stack= 3之前： （dB） R2 = atomic64_fetch_add（（U64 *）（R10 -8）， R2） mark_precise： frame0：
    regs=r2 堆疊=在 2 之前：（b7） r2 = 0 6： R2=8 R3=fp8 6： （b7） r0 = 0;R0=0 7：（95） 結束 之後：0：（b7） r1 = 8 ;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3：（db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=fp0 5：
    （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= before 4： （bf） r3 = r10 mark_precise： frame0： regs=r2 stack= before 3： （db） r2 = atomic64_fetch_add（（u64 *）（r10 -8）， r2） mark_precise： frame0： regs= stack=-8 before 2： （b7） r² = 0 mark_precise： Frame0： regs= stack=-8 前 1： （7b） *（U64 *）（R10 -8） = R1 mark_precise： frame0： regs=r1 stack= before 0： （b7） r1 = 8 6： R2=8 R3=FP8 6： （B7） R0 = 0 ;R0=0 7： （95） 出口 （CVE-2026-43009）

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

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

  - f2fs：修正因 f2fs_write_end_io（） 中 sbi->nr_pages[] 遞減而引起的 UAF。xfstests 案例 generic/107 與 syzbot 均報告過 NULL 指標去參照。觸發恐慌的同時發生情境如下：F2FS_WB_CP_DATA 寫回調 umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages（sbi， F2FS_WB_CP_DATA） - blk_mq_end_request - bio_endio - f2fs_write_end_io：
    dec_page_count（sbi， F2FS_WB_CP_DATA） ： wake_up（&sbi->cp_wait） - kill_f2fs_super - kill_block_super - f2fs_put_super ： iput（sbi->node_inode） ： sbi->node_inode = NULL ： f2fs_in_warm_node_list - is_node_folio // sbi->node_inode 為 NULL 且 panic 根本原因是 f2fs_put_super（） 呼叫 iput（sbi->node_inode），並將 sbi->node_inode 設為 NULL，而 sbi->nr_pages[F2FS_WB_CP_DATA] 是減為零。因此，f2fs_in_warm_node_list（） 在檢查 folio 是否屬於節點 inode 時，可能會取消參照 NULL node_inode，導致恐慌。此補丁透過在遞減 sbi->nr_pages[F2FS_WB_CP_DATA]前呼叫 f2fs_in_warm_node_list（） 來解決此問題，從而避免使用後自由狀態。
    (CVE-2026-31715)

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

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

  - IPv6：ICMP：清除 SKB2->cb[] 在 ip6_err_gen_icmpv6_unreach（） 中 Sashiko AI 審查指出：在 ip6_err_gen_icmpv6_unreach（） 中，SKB 是一個外部 IPv4 ICMP 錯誤封包，其 cb 包含一個 IPv4 inet_skb_parm。當 skb 被複製到 skb2 並傳遞給 icmp6_send（） 時，會使用 IP6CB（skb2）。IP6CB 將 IPv4 inet_skb_parm解讀為一個inet6_skb_parm。inet_skb_parm.opt 中的 cipso 偏移量與 inet6_skb_parm 中的 dsthao 在偏移 18 直接重疊。如果攻擊者發送偽造的 ICMPv4 錯誤，且 CIPSO IP 選項，dsthao 將是非零偏移量。在 icmp6_send（）， mip6_addr_swap（） 中稱為 ipv6_find_tlv（skb， opt->dsthao， IPV6_TLV_HAO）。這會從該偏移量開始掃描由攻擊者控制的內部 IPv6 封包，可能會回傳假的 TLV，卻未檢查剩餘封包長度是否能容納完整的 18 位元組結構ipv6_destopt_hao。mip6_addr_swap（） 是否可以執行一個 16 位元組的交換，並將資料包資料的末端延伸到 skb_shared_info？是否也應該在 ip6_err_gen_icmpv6_unreach（） 和 ip6ip6_err（） 中清除 CB 陣列以防止這種情況？這個補丁實現了第一個建議。我不確定ip6ip6_err（） 是否需要更改。不過另外的補丁會更好。
    (CVE-2026-43038)

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

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

  - Incus 是一個系統容器和虛擬機器管理器。在之前的 7.0.0版本中，儲存磁碟區匯入邏輯中缺少驗證邏輯，可讓具有儲存磁碟區功能存取權的已驗證使用者導致 Incus 常駐程式損毀。自訂磁碟區備份匯入子系統在匯入作業期間包含 nil-pointer 解除參照弱點。在快照匯入迴圈中，常駐程式會反覆運算來自「srcBackup.Config.VolumeSnapshots」的項目，並假設每個切片元素都已初始化，然後取消參照「Name」、「Config」、「Description」、「CreatedAt」和「ExpiresAt」等欄位，而無需先驗證元素本身。由於 yaml 封送處理程式會接受來自攻擊者控制的 index.yaml 的明確 null 陣列元素，並將其轉換為配量內的 nil 指標，因此攻擊者可以提供 volume_snapshots 陣列中包含 null 項目的備份封存。這會在自訂磁碟區匯入期間造成 nil 指標解除參照，並終止常駐程式，進而在受影響的節點上造成拒絕服務。重複使用此問題可用於使 Incus 保持離線狀態，從而導致拒絕服務。7.0.0 版已修正此問題。(CVE-2026-40197)

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

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

  - comedi：dt2815：新增硬體偵測以防止當機 dt2815 驅動程式在連接至 I/O 連接埠時會當機，而沒有實際硬體。發生這種情況是因為 syzkaller 或使用者可以透過 ioctl 將驅動程式附加至任意 I/O 位址COMEDI_DEVCONFIG。當指定埠上不存在硬體時，inb（） 操作會傳回 0xff （浮動匯流排），但 outb（） 操作可能會因為未定義的行為而觸發頁面錯誤，尤其是在爭用條件下： 錯誤：無法處理位址：000000007fffff90 的頁面錯誤 #PF：核心模式下的主管寫入存取權 #PF：error_code（0x0002） - 不存在頁面 RIP：
    0010：dt2815_attach+0x6e0/0x1110 在嘗試任何寫入作業之前，先讀取狀態暫存器，以新增硬體偵測。如果讀取傳回0xff，請假設不存在硬體，並使用
    -埃諾德夫。這可以防止在不存在的硬體上進行 outb（） 操作而當機。（CVE-2026-31751）

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

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

  - smb：server：在傳輸配置失敗時修復洩漏active_num_conn提交 77ffbcac4e56（smb：伺服器：
    ksmbd_tcp_new_connection（）） 中的 Fix Leak of active_num_conn 解決了 kthread_run（） 故障路徑。同一函式中早期的 alloc_transport（） == NULL 路徑具有相同的洩漏，且可透過任何 TCP 連接至 445 埠前透過驗證前抵達，且在 UML 上（ARCH=um， v7.0-rc7）上經驗重現：
    少量強制配置失敗足以使 KSMBD 進入一個狀態，之後的每次連線嘗試都被拒絕，直到開機結束。ksmbd_kthread_fn（） 在呼叫 ksmbd_tcp_new_connection（） 前會先遞增 active_num_conn 並丟棄回傳值，因此當 alloc_transport（） 回傳 NULL 時，套接字會被釋放，而 -ENOMEM 則返回而不遞減計數器。每次失敗都會永久佔用max_connections池中的一個槽位;一旦累積失敗達到上限，atomic_inc_return（）在每次後續接受時都會達到門檻，且所有新連線都會被拒絕。計數器只有在模組重新載入時才會重置。未經認證的遠端攻擊者可透過保留長至 MAX_STREAM_PROT_LEN（0x00FFFFFF）的開啟連線 RFC1002 ，將伺服器推向導致 alloc_transport（） 失敗的記憶體壓力;而載入主機上的自然暫態配置失敗則會造成相同的漂移較慢。在 ksmbd_kthread_fn（）： 中鏡像現有回滾模式，alloc_transport（） 故障路徑，遞減active_num_conn server_conf.max_connections 進行門控。重製細節：補丁還原後，強制alloc_transport（） NULL回傳洩漏的計數器槽及後續連線嘗試——包括強制失敗視窗關閉後發出的合法連線——都被以限制最大連線數拒絕。使用此補丁後，相同的連接序列不會產生拒絕，計數器在每次接受時都能乾淨地在零與一之間循環。（CVE-2026-31711）

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

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

  - wifi： iwlwifi： mvm：修正 iwl_mvm_nd_match_info_handler（） 中潛在的越界讀取 memcpy 函式假設動態陣列 notif->matches 至少與要複製的位元組數一樣大。
    否則，結果>比對可能包含不需要的資料。為確保安全性，請在其中一個檢查中擴充驗證，以確保有足夠的封包長度。由 Linux Verification Center (linuxtesting.org) 和 SVACE 發現。(CVE-2026-31779)

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

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

  - smb： client：在 cifsacl 中重寫整個 DACL 之前，先驗證它 build_sec_desc（） 和 id_mode_to_cifs_acl（） 從伺服器提供的 dacloffset 衍生 DACL 指標，然後使用傳入的 ACL 重建 chmod/chown 安全描述元。原始修正僅在讀取 dacl_ptr->size 或 dacl_ptr->num_aces之前檢查結構smb_acl標頭是否適合。這可避免立即標頭欄位 OOB 讀取，但重寫協助程式仍會根據 pdacl->num_aces 遍歷 ACE，而沒有對傳入 DACL 本文進行結構驗證。惡意伺服器可以傳回仍包含標頭的截斷 DACL、宣告一或多個 ACE，然後在比較或複製攻擊者控制的 ACE 時，驅動 replace_sids_and_copy_aces（） 或 set_chmod_dacl（） 通過已驗證的範圍。將 DACL 結構檢查分解為 validate_dacl（），將它們擴展以根據 DACL 邊界驗證每個 ACE，並在 chmod/chown 重建路徑之前使用共享驗證器。parse_dacl（） 重複使用相同的驗證器，因此讀取端剖析器和寫入端重寫路徑就格式正確的傳入 DACL 的構成達成一致。
    (CVE-2026-31709)

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

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

  - OpenFlow v5 協定將 Wireshark 4.6.04.4.144.6.44.4.0 中的無限迴圈剖析為允許拒絕服務 （）CVE-2026-6521

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

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

  - net：使用 skb_header_pointer（） 進行 TCPv4 GSO frag_off檢查 Syzbot 在 gso_features_check（） 中回報 KMSAN uninit 值警告，該警告來自 netif_skb_features（） [1]。gso_features_check（） 讀 IPH->frag_off 以決定是否清除mangleid_features。透過 ip_hdr（）/inner_ip_hdr（） 存取 IPv4 標頭，可以依賴 skb 標頭偏移量，但這些偏移量並不總是安全，無法直接引用從PF_PACKET路徑注入的封包。使用 skb_header_pointer（） 來檢查 TCPv4 frag_off，確保標頭讀取在資料已經是線性還是需要複製時都能保持穩健。[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036）

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

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

  - NET：MACB：正確未註冊固定速率時鐘 以 clk_register_fixed_rate（） 分配的額外資源需以 clk_unregister_fixed_rate（） 釋放，否則將失去。
    (CVE-2026-43014)

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

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

  - Wireshark 4.6.0 中的 SDP 通訊協定剖析器損毀，以 4.6.4 允許拒絕服務 （CVE-2026-5655）

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

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

  - WiFi：mac80211：檢查 ieee80211_tdls_oper 中的 TDLS 標誌 當呼叫 NL80211_TDLS_ENABLE_LINK 時，代碼僅檢查該站是否存在，但不檢查是否為 TDLS 站。這使得非 TDLS 站點也能繼續操作，但會產生如在失敗前修改頻道上下文和 HT 保護等意外副作用。在ENABLE_LINK情況早期，在出現副作用前，先檢查 sta->sta.tdls，以確保該操作只允許實際的 TDLS 對等端使用。（CVE-2026-43052）

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

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

  - net/x25：修正 skb 的電位雙重 當 alloc_skb 在 x25_queue_rx_frame 失敗時，會在第 48 行呼叫 kfree_skb（skb），並回傳 1（錯誤）。此錯誤會透過通話鏈回傳：
    x25_queue_rx_frame 返回 1 |V x25_state3_machine 接收回傳值 1，並在第 278 行取 else 分支，設定 queued=0 並回傳 0 |V x25_process_rx_frame 回傳佇列=0 |V x25_backlog_rcv在第 452 行看到 queued=0，再次呼叫 kfree_skb（skb）。這會釋放同一個 SKB 兩次。看著x25_backlog_rcv：net/x25/x25_in.c：x25_backlog_rcv（） { ...排隊 = x25_process_rx_frame（SK， SKB）;...如果（！queued） kfree_skb（skb）;} （CVE-2026-43011）

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

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

  - 橋接：br_nd_send：驗證ND期權長度 br_nd_send（） 依據選擇權提供的期限走訪ND期權。錯誤的選項可能導致解析器超越計算的選項範圍，或使用過短的原始碼 LLADDR 選項有效載荷。在推進前，先以剩餘的 NS 選項區域驗證選項長度，只有當選項足夠大以提供乙太網路位址時，才讀取原始 LLADDR。
    (CVE-2026-31752)

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

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

  - NetFilter：nf_tables：立即拒絕NF_QUEUE判決nft_queue總是從使用者空間的 NFTABLE 中執行 NF_QUEUE 判定。用戶空間 NFT 工具絕不會立即發出NF_QUEUE判決，因此請拒絕立即NF_QUEUE判決。ARP 家族不提供佇列支援，但這種即時判斷仍然可得。全球拒絕立即NF_QUEUE判決來解決此問題。（CVE-2026-43024）

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

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

  - USB： gadget： u_ether：修正 gether_disconnect 和 eth_stop 之間的爭用 gether_disconnect（） 和 eth_stop（） 之間的爭用情形會導致 NULL 指標解除參照。具體而言，如果在 gether_disconnect（） 拆除端點時同時觸發 eth_stop（），則 eth_stop（） 會嘗試存取已清除的端點描述元，從而造成下列 NPE： 無法處理核心 NULL 指標解除參照 呼叫追蹤：__dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 由於 eth_stop（） 在保留 dev->lock 時當機， 執行 gether_disconnect（） 的執行緒無法取得相同的鎖並永遠旋轉，導致硬鎖定： core - 硬鎖定的偵錯資訊 core（7） 呼叫追蹤：
    queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 根本原因是 gether_disconnect（） 中的 dev->port_usb 的清除延遲到函數結束。將 dev->port_usb 的清除移至 gether_disconnect（） 的開頭，同時按住 dev->lock。這會立即切斷鏈接，確保 eth_stop（） 將 dev->port_usb 視為 NULL 並安全地退出。（CVE-2026-31728）

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

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

  - USB： ulpi：修正 ulpi_register_interface（） 錯誤路徑中的雙重釋放 當 device_register（） 失敗時，ulpi_register（） 會呼叫 ulpi->dev 上的 put_device（）。裝置釋放回呼 ulpi_dev_release（） 會捨棄 OF 節點參照並釋放 ulpi，但 ulpi_register_interface（） 中的目前錯誤路徑會再次呼叫 kfree（ulpi），造成雙重釋放。讓 put_device（） 透過 ulpi_dev_release（） 處理清理，並避免在 ulpi_register_interface（） 中再次釋放 ulpi。（CVE-2026-31759）

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

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

  - USB： gadget： f_ecm：修正net_device生命週期 具有 device_move net_device 會在函式執行個體建立期間配置，並在繫結階段註冊，並將小工具裝置作為其 sysfs 父項。當函式解除綁定時，父裝置會被破壞，但net_device仍然存在，導致懸空的 sysfs 符號連結： console：/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console：/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls： .../gadget.0/net/usb0： 沒有這樣的檔案或目錄 使用 device_move（） net_device跨綁定和取消綁定循環。在最後解除綁定期間，呼叫 device_move （NULL） 會在小工具裝置遭到破壞之前，將net_device移至虛擬裝置樹狀結構。重新綁定時，device_move（） 會將裝置重新父系到新小工具下，確保正確的 sysfs 拓撲和電源管理順序。為了維持與舊版複合驅動程式 （例如 multi.c） 的相容性，繫結旗標可用來指出在舊版驅動程式的繫結階段期間，是否共用和預先註冊網路裝置。（CVE-2026-31725）

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

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

  - NET：QRTR：以 XARRAY 取代 qrtr_tx_flow radix_tree 以修復記憶體洩漏 __radix_tree_create（） 一個一個分配並連結中間節點到樹中。若後續配置失敗，已連結的節點仍留在樹中，無對應葉節點條目。這些孤立的內部節點永遠不會被回收，因為 radix_tree_for_each_slot（） 只會造訪包含葉節點值的槽位。radix_tree API 已被棄用，取而代之的是 xarray。如 Matthew Wilcox 建議，應該將qrtr_tx_flow從 radix_tree 遷移到 xarray，而不是修復 radix_tree 本身 [1]。xarray 正確處理內部節點的清理 xa_destroy（） 在釋放 qrtr_node 時釋放所有內部 xarray 節點，防止洩漏。[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/ （CVE-2026-43041）

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

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

  - Incus 是一個系統容器和虛擬機器管理器。在之前的 7.0.0版本中，儲存磁碟區匯入邏輯中缺少驗證邏輯，可讓具有儲存磁碟區功能存取權的已驗證使用者導致 Incus 常駐程式損毀。備份還原子系統包含一個越界錯誤弱點，此弱點是由在為快照中繼資料陣列編製索引時，無效的邊界檢查所造成，而且移轉路徑中也會出現相同的缺陷模式。反覆運算備份封存中提供的實體快照時，迴圈會使用索引在剖析的「Config.Snapshots」和「Config.VolumeSnapshots」切片中查詢對應的中繼資料。保護條件「len（slice） >= i-1」不正確，因為當後續 slice[i] 存取越界時，它仍然可以評估為 true。攻擊者可提交包含實體快照目錄的備份封存，同時提供具有空白或截斷的快照中繼資料陣列的竄改「index.yaml」，導致常駐程式索引超出中繼資料切片結尾並損毀。重複使用此問題可用於使 Incus 保持離線狀態，從而導致拒絕服務。7.0.0 版已修正此問題。(CVE-2026-40251)

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

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

  - ksmbd：修正在 smb2_get_ea（） 中寫入的越界，EA 對齊 smb2_get_ea（） 在寫入每個 EA 項目後，透過 memset（） 套用 4 位元組的對齊填充。buf_free_len 的界線檢查會在 memcpy 值之前執行，但對齊 memset 之後會無條件觸發，且未檢查剩餘空間。
    當 EA 值正好填滿剩餘緩衝區（buf_free_len == 0 減去值後），對齊記憶體會寫入 1-3 個 NUL 位元組，越過 buf_free_len 邊界。在複合請求中，回應緩衝區在多個指令間共享，第一個指令（例如 READ）可能會佔用大部分緩衝區，剩餘部分則是QUERY_INFO EA 回應的緊繃剩餘部分。對齊記憶體集接著會覆蓋 kvmalloc 的物理配置到相鄰的核心堆積記憶體中。在對齊記憶體集前加一個邊界檢查，確保buf_free_len能容納填充位元組。這也是同樣的錯誤模式，已被 commit beef2634f81f（ksmbd：fix get_file_all_info（） 中的 compound 請求的 potencial OOB）和 commit fda9522ed6af（ksmbd：fix OOB write in QUERY_INFO for compound request）所修正的錯誤模式，兩者都增加了在QUERY_INFO回應處理程序中無條件寫入前的界限檢查。（CVE-2026-31705）

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

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

  - HID：多點點觸控：檢查報告回應是否符合請求。惡意（或笨拙）裝置可能會使用完全不同的報告 ID 回應特定報告的功能請求。
    這可能導致 HID 核心混淆，導致像 OOB 寫入等不良副作用。再加一個檢查，確保回應中的報告ID與所要求的ID相符。如果沒有，就省略原始事件，提前回來。（CVE-2026-43047）

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

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

  - Bluetooth： SCO：修正 sco_sock_connect（） sco_sock_connect（） 檢查中的爭用情形，sk_state和sk_type，而不按住通訊端鎖定。同一通訊端上的兩個並行 connect（） 系統調用都可以通過檢查並輸入 sco_connect（），從而導致釋放後使用。有錯誤的案例涉及三個參與者，並透過額外的記錄檢測得到確認： 執行緒 A （連線）： HCI 中斷連線： 執行緒 B （連線）：sco_sock_connect（sk） sco_sock_connect（sk） sk_state==BT_OPEN sk_state==BT_OPEN （通過，無鎖定） （通過，無鎖定） sco_connect（sk）：sco_connect（sk）：hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock（sk） sco_chan_add： conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del： lock_sock（sk） sco_chan_del： sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock （未封鎖） hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock（sk） sco_chan_add： sk->conn=conn2 sk_state= BT_CONNECT // 殭屍 sk！release_sock hci_dev_unlock 執行緒 B 將一個 BT_CLOSED + SOCK_ZAPPED 通訊端復活回 BT_CONNECT。
    後續的清理會觸發雙重 sock_put（） 和釋放後使用。同時，conn1 被洩露，因為它在 sco_conn_del（） 清除關聯時成為孤立的。透過以下方式解決此問題： - 在 sco_sock_connect（） 中進行 sk_state/sk_type 檢查之前移動 lock_sock（） 以序列化並發連接嘗試 - 修正 sk_type ！= SOCK_SEQPACKET 檢查以實際傳回錯誤而不僅僅是分配錯誤 - 在 lock_sock（） 之後的 sco_connect（） 中新增狀態重新檢查，以捕捉鎖定之間視窗期間的狀態變更 - 在 sco_chan_add（） 中新增 sco_pi（sk）->conn 檢查以防止通訊端的雙重連接至多個連線 - 在 sco_chan_add 失敗時新增 hci_conn_drop（） 以防止 HCI 連線洩漏 （CVE-2026-43023）

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

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

  - Incus 是一個系統容器和虛擬機器管理器。在版本 7.0.0之前，經過驗證的使用者上傳大量資料可能會導致 Incus 伺服器耗盡磁碟空間，進而導致主機系統癱瘓。對於使用 storage.images_volume 和 storage.backups_volume 的任何人來說，這裡的影響有限，因為這些使用者將有大量上傳儲存在這些磁碟區上，而不是直接儲存在主機檔案系統上。這是 IncusOS 上的預設行為。此問題已在 7.0.0 版中修正。
    (CVE-2026-41685)

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

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

  - ALSA： ctxfi：檢查索引對應的錯誤 ctxfi 驅動程式盲目地假設 daio_device_index（） 傳回的正確值，但不總是正確。新增適當的錯誤檢查以處理函式的錯誤。（CVE-2026-31777）

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

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

  - MPTCP：修正 mptcp_recvmsg（） 軟鎖定問題，Syzbot 報告在 mptcp_recvmsg（） [0] 中出現軟鎖定。當接收資料時MSG_PEEK |MSG_WAITALL旗標時，SKB 不會從 sk_receive_queue 中移除。這會導致 sk_wait_data（） 總是找到可用資料，卻從未真正執行等待，導致軟性鎖定。解決方法是新增一個「最後」參數來追蹤最後一次偷看的 SKB。這讓 sk_wait_data（） 能做出有根據的等待決策，並在使用 MSG_PEEK 時避免無限迴圈。[0]：看門狗：BUG：軟鎖定—— CPU#2 卡在156秒！[伺服器：1963]連結模組：CPU：2 UID：0 PID：1963 通訊：伺服器 未受污染 6.19.0-rc8 #61 搶佔（無） 硬體名稱：QEMU 標準 PC（i440FX + PIIX，1996），BIOS 1.15.0-1 2014/04/01 RIP ：0010：sk_wait_data+0x15/0x190 代碼：80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e FA 41 56 41 55 41 54 49 49 89 f4 55 48 89 d5 53 4889 FB <48> 83 EC 30 65 48 8b 05 17 A4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP： 0018：ffffc900000603ca0 EFLAGS： 00000246 RAX： 000000000000000000000000000000000000000 RBX：
    ffff888102bf0800 RCX：0000000000000001 RDX：0000000000000000 RSI：ffffc900000603d18 RDI：ffff888102bf0800 RBP：0000000000000000 R08： 0000000000000002 R09：0000000000000101 R10：0000000000000000 R11：
    0000000000000075 R12： ffffc900000603d18 R13： ffff888102bf0800 R14： ffff888102bf0800 R15： 0000000000000000000000 FS： 00007f6e38b8c4c0（0000） GS： ffff8881b877e000（0000） knlGS：0000000000000000 CS： 0010 DS： 0000 ES： 0000 CR0： 0000000080050033 CR2： 000055aa7bff1680 CR3： 00000000105cbe0000 CR4： 0000000000006f0 通話追蹤： <TASK> mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c：2329 inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c：891 sock_recvmsg+0x94/0xc0 net/socket.c：1100 __sys_recvfrom+0xb2/0x130 net/socket.c：2256
    __x64_sys_recvfrom+0x1f/0x30 net/socket.c：2267 do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S：131 RIP：0033：0x7f6e386a4a1d 代碼：0f 1f 84 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 0000 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP：
    002b：00007ffc3c4bb078 EFLAGS：00000246 ORIG_RAX：000000000000002d RAX：ffffffda RBX：
    000000000000861e RCX：00007f6e386a4a1d RDX：0000000000000003ff RSI：00007ffc3c4bb150 RDI：0000000000000004 RBP：00007ffc3c4bb570 R08：000000000000000000000000000000000000 R09R10： 0000000000000103 R11：
    0000000000000246 R12： 00005605dbc00be0 R13： 00007ffc3c4bb650 R14： 0000000000000000000 R15： 000000000000000000000 </TASK>CVE-2026-43029（）

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

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

  - netfilter：ctnetlink：在新期望中忽略明確的幫助者 使用現有的主 conntrack 輔助工具，其他功能其實不太支援，只會讓驗證更複雜，所以就忽略 helper 用戶空間對此期望的建議。此問題是在透過使用者空間提供的與現有主 conntrack 輔助工具不同的 Assistant 驗證 CTA_EXPECT_CLASS 時發現的：BUG： KASAN： slab-out-of-bounds in in the slab-out-of-bounds in in the s nf_ct_expect_related_report+0x2479/0x27c0 任務 poc/102 讀取為 addr ffff88880043fe408 由任務 poc/102 讀取 呼叫追蹤：nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350 允許讀取核心記憶體位元組超出預期邊界。CTA_EXPECT_HELP_NAME 仍被用來透過 netlink dump 向使用者空間提供輔助名稱。（CVE-2026-43025）

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

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

  - RDP 協定剖析器在 Wireshark 4.6.04.6.4 中崩潰，允許4.4.144.4.0拒絕服務及可能的程式碼執行（CVE-2026-5405）

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

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

  - ksmbd：使用 check_add_overflow（） 防止 u16 DACL 大小溢位 set_posix_acl_entries_dacl（） 與 set_ntacl_dacl（） 累積 u16 變數中的 ACE 大小。當檔案有多個 POSIX ACL 條目時，累積大小可能會繞過 65535，導致指標運算 （char *）pndace + *size 落在已寫入的 ACE 內。後續寫入會覆蓋先前的條目，pndacl->size 會獲得截斷值。在每個累積點使用 check_add_overflow（） 來偵測包裹，避免緩衝區損壞，這與 smbacl.c 其他地方現有的 check_mul_overflow（） 使用方式一致。（CVE-2026-31704）

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

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

  - Wireshark 4.6.04.4.144.6.44.4.0 中的設定檔匯入路徑遊走，以允許拒絕服務和可能的程式碼執行 （）CVE-2026-5656

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

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

  - Incus 是一個系統容器和虛擬機器管理器。在之前的 7.0.0版本中，OVN 資料庫連線邏輯中損毀的 TLS 驗證邏輯可能允許連線至攻擊者的 OVN 資料庫。OVN 用戶端實作會停用 Go 標準 TLS 伺服器驗證，並將其取代為自訂對等憑證驗證邏輯。該替代驗證程式不會錨定對已設定的 CA 憑證的信任。相反地，它會從交握期間對等提供的憑證建構驗證根集，因此會剖析已設定的 CA，但不會用作最終驗證決策的信任錨點。在使用這些 SSL 資料庫連線路徑的啟用 OVN 的部署中，能夠模擬或攔截管理網路上 OVN 端點的攻擊者可能會提供流氓自我簽署憑證鏈，而 Incus 會接受此憑證為有效。此問題會破壞 OVN 資料庫連線的預期 CA 型信任模型，並允許作用中攻擊者在適當的網路位置模擬端點。7.0.0 版已修正此問題。(CVE-2026-40243)

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

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

  - net/mlx5：延遲：在建立除錯前檢查 LAG 裝置 __mlx5_lag_dev_add_mdev（） 即使錯誤處理得很順利，也可能回傳 0（成功）。因此，即使沒有有效的 LAG 上下文，初始化流程仍會繼續呼叫 mlx5_ldev_add_debugfs（）。mlx5_ldev_add_debugfs（） 盲目建立 debugfs 目錄與屬性。這會暴露出依賴有效 ldev 指標的介面（如 members 檔案），若在 ldev 為 NULL 時存取，可能導致 NULL 指標被取消參照。在嘗試建立 debugfs 條目前，請加入檢查以驗證 mlx5_lag_dev（dev） 是否回傳有效的指標。（CVE-2026-43013）

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

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

  - comedi：me4000：修正韌體緩衝區「me4000_xilinx_download（）」的潛在溢位，載入「request_firmware（）」要求的韌體。它可能會溢位來源緩衝區，因為它盲目信任檔案格式。它從前 4 個位元組將資料流長度讀取到變數「file_length」中，並從位移 16 開始讀取長度為「file_length」的資料流內容。新增測試，以確保提供的韌體足夠長，足以包含標頭和資料串流。失敗時，記錄錯誤並傳回「-EINVAL」。注意：在提交 ac584af59945 之前，韌體載入已完全中斷（暫存：comedi：me4000：修正韌體下載），但這是此修正最明智的目標。（CVE-2026-31747）

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

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

  - FRRouting before 10.5.3 包含一個整數溢位漏洞，出現在七個 OSPF 流量工程與區段路由 TLV 解析器函式中，uint16_t累加器變數截斷了 TLV_SIZE（）巨集 回傳的uint32_t值，導致迴圈終止條件失敗，而指標推進則未被檢查。擁有既定 OSPF 鄰接關係的攻擊者，可以發送帶有惡意 Type 10 或 Type 11 不透明 LSA 的精心設計的 LS Update 封包，觸發越界記憶體讀取，並使 OSPF 區域內所有受影響的路由器或自治系統當機。（CVE-2026-28532）

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

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

  - netfilter：ctnetlink：當 Zero 期望 NAT 欄位CTA_EXPECT_NAT 缺席 ctnetlink_alloc_expect（） 透過 nf_ct_expect_alloc（） 分配非歸零 Slab 快取的期望值。當 netlink 訊息中不存在 CTA_EXPECT_NAT 時，saved_addr 和 saved_proto 永遠不會被初始化。前一個石板使用者的過時資料可透過 ctnetlink_exp_dump_expect（） 轉入使用者空間，檢查這些欄位以決定是否發出CTA_EXPECT_NAT。封包路徑使用的安全兄弟節點 nf_ct_expect_init（） 會明確將這些欄位歸零。else 分支中為零 saved_addr、saved_proto 和 dir，並由 IS_ENABLED（CONFIG_NF_NAT） 保護，因為這些欄位只有在啟用 NAT 時才存在。透過先對預期板塊注入帶有 NAT 的期望值、釋放它們、建立新期望而無需CTA_EXPECT_NAT，並觀察到 ctnetlink 傾倒會發出包含先前配置過時資料的虛假CTA_EXPECT_NAT來確認。（CVE-2026-43026）

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

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

  - NET：MACB：修正 PCI 膠合驅動程式移除時的 CLK 處理問題 platform_device_unregister（） 可能仍希望在執行時續接回用時使用已註冊的 CLK。請注意有一個提交 d82d5303c4c5（網路：macb：
    修正 RMMOD 免費後的使用問題），這個問題解決了 CLK 與平台裝置取消註冊的類似問題，但只是把錯誤移到另一個地方。將指向 clks 的指標存到本地變數，方便平台裝置取消註冊後重用。錯誤：KASAN：在 clk_prepare+0x5a/0x60 在 addr ffff888104f85e00 由任務 modprobe/597 讀取大小為 8 CPU：2 PID：597 通訊：modprobe 未受 6.1.164污染 + #114 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009）， BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org04/01/2014 通話追蹤： <TASK> dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0
    __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 </TASK> 任務519分配：
    kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0
    __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8任務597釋放：kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180
    __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 （CVE-2026-43015）

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

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

  - netfilter：x_tables：確保名稱為 nul-終止 拒絕缺少 \0 字元的名稱，然後再送入預期 c 字串的函式。Fixes 標籤是最近一個需要這個變更的提交。
    (CVE-2026-43028)

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

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

  - crypto：af-alg - 修正 scatterwalk 中的 NULL 指標去參考 AF_ALG 介面在鏈接新 af_alg_tsgl 結構時，無法解除標記散點/收集清單（SGL）的末尾。如果 sendmsg（） 正好填滿 SGL 至 MAX_SGL_ENTS，則最後一個條目標記為結束。後續的 sendmsg（） 會分配一個新的 SGL 並串接它，但未能清除前一個 SGL 最後一個資料條目的結束標記。這會導致加密散點步道提前結束，sg_next（）回傳 NULL，並在去參照時引發核心恐慌。在執行 af_alg_alloc_tsgl（） 中執行 sg_chain（） 時，明確取消標記前一個 SGL 的結尾來解決這個問題。（CVE-2026-43043）

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

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

  - 加密：ccp：若 PSP 指令失敗，請勿嘗試將 ID 複製到 userspace。在為 CPU 取得 ID 時，若韌體指令失敗，請勿嘗試將 ID blob 複製到 userspace。若因長度無效，即使用者空間緩衝區+長度過小，則複製位元組數
    _firmware_ 需要 會溢出核心分配的緩衝區，並將資料洩漏到使用者空間。蟲子：卡桑：
    instrument_copy_to_user 的板子界外....../include/linux/instrumented.h：129 [內嵌] 錯誤：KASAN：
    _inline_copy_to_user 的板狀界外....../include/linux/uaccess.h：205 [內嵌] 錯誤：KASAN：_copy_to_user+0x66/0xa0 ../lib/usercopy.c：26 任務 syz.0.906/24388 讀取 addr ffff8881867f5960 大小為 64 的讀取 CPU：130 UID：0 PID：24388 通訊：syz.0.906 受污染：G U O 7.0.0-smp-DEV #28 PREEMPTLAZY 受污染：[U]=USER， [O]=OOT_MODULE 硬體名稱：Google， Inc. Arcadia_IT_80/Arcadia_IT_80，BIOS 12.62.0-0 2025/11/19 通話追蹤： <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c：120 print_address_description ../mm/kasan/report.c：378 [內嵌] print_report+0xbc/0x260 ../mm/kasan/report.c：482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c：595 check_region_inline../mm/kasan/generic.c：-1 [內嵌] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c：200 instrument_copy_to_user ../include/linux/instrumented.h：129 [內嵌] _inline_copy_to_user ../include/Linux/uaccess.h：205 [內嵌]
    _copy_to_user+0x66/0xa0../lib/usercopy.c：26 copy_to_user ../include/linux/uaccess.h：236 [內嵌] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c：2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c：2575 vfs_ioctl ../fs/ioctl.c：51 [線上] __do_sys_ioctl ../fs/ioctl.c：597 [內文] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c：583 do_syscall_x64 ../arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 如果驅動程式顯示指令成功，但韌體錯誤代碼卻顯示相反，則 WARN __sev_do_cmd_locked（） 預期會在任何 firwmware 錯誤中回傳 -EIO。（CVE-2026-31697）

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

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

  - Bluetooth： MGMT：驗證網狀傳送通告有效負載長度 mesh_send（） 目前由命令總長度MGMT_OP_MESH_SEND界，但它永遠不會驗證為彈性 adv_data[] 陣列提供的位元組是否確實符合內嵌的 adv_data_len 欄位。MGMT_MESH_SEND_SIZE僅涵蓋固定標頭，因此截斷的命令仍然可以通過現有的 20..50 位元組範圍檢查，然後驅動非同步網格傳送路徑超過佇列命令緩衝區的末尾。繼續拒絕零長度和過大的廣告承載，但明確驗證adv_data_len，並要求命令長度與彈性陣列大小完全相符，再將要求排入佇列。（CVE-2026-43017）

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

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

  - bpf：在連接時拒絕可睡眠的kprobe_multi程式，kprobe.multi 程式在原子/RCU 環境中執行，無法進入睡眠。然而，bpf_kprobe_multi_link_attach（） 並未驗證所附加程式是否設定了可睡眠標誌，允許像 bpf_copy_from_user（） 這類可睡眠的輔助工具從非可睡眠上下文中被調用。這會產生一個來自無效上下文 splat 的睡眠函數：BUG：
    睡眠函式從 ./include/linux/uaccess.h：169 的無效上下文呼叫 in_atomic（）： 1， irqs_disabled（）： 0， non_block： 0， pid： 1787， name： sudo preempt_count： 1， expected： 0 RCU 巢穴深度： 2， expected： 0 請在 bpf_kprobe_multi_link_attach（） 前拒絕可睡眠程式，然後再進行任何處理。（CVE-2026-43010）

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

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

  - usb：usbtmc：在usbtmc_release中沖洗錨定的 URB usbtmc_release 呼叫  時，必須清除或終止待定錨定的 URB，以防止使用後錯誤（例如 HCD 回傳路徑中）。請呼叫 usbtmc_draw_down（） 以允許完成錨定的 URB。（CVE-2026-31758）

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

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

  - 加速/QAIC：若擁有者離開，處理 DBC 停用。當 DBC 被釋放時，裝置會透過 QAIC_CONTROL MHI 通道向主機發送QAIC_TRANS_DEACTIVATE_FROM_DEV交易。QAIC 透過呼叫 decode_deactivate（） 來釋放分配給該 DBC 的資源來處理此事。由於該處理是在 qaic_manage_ioctl（） 上下文中進行，若使用者在收到並處理停用前離開，主機將與可用資料庫控制器不同步，且除非移除裝置，否則資料庫資源不會被釋放。若另一使用者載入並請求啟用網路，該裝置將相同的 DBC 指派給該網路，QAIC 將無限期等待 dbc->in_use = false，導致使用者程序當機。作為解決方案，處理用戶離開後收到的QAIC_TRANS_DEACTIVATE_FROM_DEV交易。（CVE-2026-43007）

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

ID	名稱	嚴重性
311698	Linux Distros 未修補的弱點：CVE-2026-6520	high
311697	Linux Distros 未修補的弱點：CVE-2026-5056	critical
311696	Linux Distros 未修補的弱點：CVE-2026-40195	high
311695	Linux Distros 未修補的弱點：CVE-2026-31698	high
311694	Linux Distros 未修補的弱點：CVE-2026-6522	medium
311693	Linux Distros 未修補的弱點：CVE-2026-31771	high
311692	Linux Distros 未修補的弱點：CVE-2026-43009	high
311691	Linux Distros 未修補的弱點：CVE-2026-31715	high
311690	Linux Distros 未修補的弱點：CVE-2026-43038	critical
311689	Linux Distros 未修補的弱點：CVE-2026-40197	high
311688	Linux Distros 未修補的弱點：CVE-2026-31751	medium
311687	Linux Distros 未修補的弱點：CVE-2026-31711	high
311686	Linux Distros 未修補的弱點：CVE-2026-31779	high
311685	Linux Distros 未修補的弱點：CVE-2026-31709	high
311684	Linux Distros 未修補的弱點：CVE-2026-6521	medium
311683	Linux Distros 未修補的弱點：CVE-2026-43036	medium
311682	Linux Distros 未修補的弱點：CVE-2026-43014	medium
311681	Linux Distros 未修補的弱點：CVE-2026-5655	high
311680	Linux Distros 未修補的弱點：CVE-2026-43052	high
311679	Linux Distros 未修補的弱點：CVE-2026-43011	critical
311677	Linux Distros 未修補的弱點：CVE-2026-31752	medium
311676	Linux Distros 未修補的弱點：CVE-2026-43024	medium
311675	Linux Distros 未修補的弱點：CVE-2026-31728	medium
311674	Linux Distros 未修補的弱點：CVE-2026-31759	high
311673	Linux Distros 未修補的弱點：CVE-2026-31725	medium
311672	Linux Distros 未修補的弱點：CVE-2026-43041	medium
311671	Linux Distros 未修補的弱點：CVE-2026-40251	high
311670	Linux Distros 未修補的弱點：CVE-2026-31705	critical
311669	Linux Distros 未修補的弱點：CVE-2026-43047	high
311668	Linux Distros 未修補的弱點：CVE-2026-43023	high
311667	Linux Distros 未修補的弱點：CVE-2026-41685	medium
311666	Linux Distros 未修補的弱點：CVE-2026-31777	medium
311665	Linux Distros 未修補的弱點：CVE-2026-43029	high
311664	Linux Distros 未修補的弱點：CVE-2026-43025	high
311663	Linux Distros 未修補的弱點：CVE-2026-5405	high
311662	Linux Distros 未修補的弱點：CVE-2026-31704	medium
311661	Linux Distros 未修補的弱點：CVE-2026-5656	high
311660	Linux Distros 未修補的弱點：CVE-2026-40243	low
311659	Linux Distros 未修補的弱點：CVE-2026-43013	medium
311658	Linux Distros 未修補的弱點：CVE-2026-31747	high
311657	Linux Distros 未修補的弱點：CVE-2026-28532	medium
311656	Linux Distros 未修補的弱點：CVE-2026-43026	medium
311655	Linux Distros 未修補的弱點：CVE-2026-43015	high
311654	Linux Distros 未修補的弱點：CVE-2026-43028	high
311653	Linux Distros 未修補的弱點：CVE-2026-43043	medium
311652	Linux Distros 未修補的弱點：CVE-2026-31697	high
311651	Linux Distros 未修補的弱點：CVE-2026-43017	medium
311650	Linux Distros 未修補的弱點：CVE-2026-43010	medium
311649	Linux Distros 未修補的弱點：CVE-2026-31758	high
311648	Linux Distros 未修補的弱點：CVE-2026-43007	high

偵測

Nessus 的 Misc. 系列

high

critical

high

high

medium

high

high

high

critical

high

medium

high

high

high

medium

medium

medium

high

high

critical

medium

medium

medium

high

medium

medium

high

critical

high

high

medium

medium

high

high

high

medium

high

low

medium

high

medium

medium

high

high

medium

high

medium

medium

high

high