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

  - RDMA/umem：修正故障路徑中的雙重dma_buf_unpin在 ib_umem_dmabuf_get_pinned_with_dma_device（） 中，對 ib_umem_dmabuf_map_pages（） 的呼叫可能會失敗。如果發生這種情況，dmabuf 會立即取消釘選，但仍會設定 umem_dmabuf->pinned 旗標。然後，當呼叫 ib_umem_release（） 時，它會呼叫 ib_umem_dmabuf_revoke（），後者將再次呼叫 dma_buf_unpin（）。透過在失敗時移除立即取消固定並讓ib_umem_release/撤銷路徑處理它來解決此問題。這也可確保如果 dmabuf_map_pages 呼叫因dma_resv_wait_timeout而失敗，則正確的取消對應解釘選展開順序 （因此具有非 NULL umem_dmabuf->sgt） 。（CVE-2026-43128）

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

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

  - 暫存：rtl8723bs：修正失敗路徑上的記憶體洩漏 cfg80211_inform_bss_frame（） 可能會在失敗時傳回 NULL。在這種情況下，分配的緩衝區「buf」不會被釋放，並且函數會提前返回，從而導致潛在的記憶體洩漏。透過確保在成功和失敗路徑上釋放 'buf' 來解決此問題。
    (CVE-2026-43225)

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

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

  - net： ethernet： ec_bhf：修正錯誤路徑中的 dma_free_coherent（） dma 控點 dma_free_coherent（） 採用 priv->rx_buf.alloc_len 作為 dma 控點。這會導致緩衝區不正確的取消對應。將 dma 控制碼變更為 priv->rx_buf.alloc_phys。CVE-2026-43283

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

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

  - eventpoll：將結構 eventpoll 釋放時間推遲到 RCU 寬限期 在某些情況下，eventpoll.c 中的 ep_free（） 會釋放 epi->ep eventpoll 結構，而該結構仍被另一個並行執行緒使用。將 kfree（） 推遲到 RCU 回呼以防止 UAF。（CVE-2026-43074）

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

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

  - media：i2c/tw9906：修正 tw9906_probe（） 中潛在的記憶體洩漏 在 tw9906_probe（） 的其中一個錯誤路徑中，未釋放 v4l2_ctrl_handler_init（） 和 v4l2_ctrl_new_std（） 中配置的記憶體。透過在該錯誤路徑中的處理常式上呼叫 v4l2_ctrl_handler_free（） 來修正此問題。（CVE-2026-43246）

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

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

  - RedisBloom 是 Redis 的機率資料結構模組。在之前 2.8.20的所有版本的 RedisBloom 中，模組都無法正確驗證透過 Redis RESTORE 命令處理的序列化值。有權在載入 RedisBloom 模組的伺服器上執行 RESTORE 的經過身份驗證的攻擊者可以提供特製的序列化承載，從而觸發無效的記憶體存取並可能導致遠端程式碼執行。因應措施是使用 ACL 規則來限制對 RESTORE 命令的存取。2.8.20 版已修正此問題。(CVE-2026-25589)

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

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

  - netfilter：ctnetlink：確保對主 conntrack 的安全存取 僅保留期望值的參考資料不足，主控 conntrack 物件可能會消失，導致 exp->master 無效。要安全存取 exp->master：- 取得 nf_conntrack_expect_lock，該  會被序列化為 clean_from_lists（），當主控 conntrack 消失時，也會保留此鎖。- 透過 nf_conntrack_find_get（） 保持主 conntrack 的參考。但不太容易，因為現有有問題路徑中找不到主 conntrack 的主元組。這個補丁是為了簡化，將nf_conntrack_expect_lock段延伸以解決這個問題，在下面描述的情況中，這只是稍微延長鎖段。add expectation 指令已經包含來自 ctnetlink_create_expect（） 的主 conntrack 參考。然而，刪除期望指令必須先抓取旋轉鎖，才能查找期望值。擴充現有的旋鎖區段以涵蓋期望查詢。請注意，nf_ct_expect_iterate_net（） 呼叫在迭代期望表時已經抓取了旋轉鎖，這是正確的。get expectation 指令需要抓住 spinlock，以確保主控 conntrack 不會消失。這也擴展了現有的旋轉鎖（spinlock）部分，涵蓋期望查詢。我需要把 netlink skb 配置從 spinlock 移出來，才能保持GFP_KERNEL。對於預期事件，IPEXP_DESTROY事件已經在旋轉鎖下被交付，只要把IPEXP_NEW的傳遞也移到旋轉鎖下方，因為主控 conntrack 事件快取是透過 exp->master 存取的。順便加上 lockdep 的註解，幫助辨識哪些碼路徑需要抓取 spinlock。（CVE-2026-43116）

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

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

  - NFC：s3fwrn5：在消耗位元組之前配置 Rx SKB s3fwrn82_uart_read（） 會向 serdev 核心報告接受的位元組數。目前的程式代碼會取用位元組進入recv_skb，而且可能已經在配置新的接收緩衝區之前傳遞完整的框架。如果該 alloc_skb（） 失敗，回呼會傳回 0，即使它已經耗用了位元組，而且下次接收回呼仍會將 recv_skb 保留為 NULL。這會破壞 receive_buf（） 會計合約，也可能導致下一個 skb_put_u8（） 出現 NULL 解除參照。在取用下一個位元組之前，延遲配置接收 skb。如果配置失敗，請傳回已接受的位元組數。（CVE-2026-43098）

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

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

  - btrfs：在記錄重播後修正具有非零大小的零大小 inode 記錄 inode 存在時，作為記錄新名稱或記錄目錄新目錄項目的一部分，我們一律將記錄的 inode 項目的產生設定為 0。這是為了在記錄重播期間 （在 overwrite_item（） 中） 發出信號，表明我們不應該設定i_size，因為我們只記錄了 inode 的存在，因此必須保留子磁碟區樹狀結構中 inode 的i_size （因為當我們記錄新名稱或 inode 存在時，我們不會記錄範圍）。這運作正常，除非我們已經以完整模式記錄了 inode，或者這是我們第一次記錄在過去交易中建立的 inode，該 inode 的新i_size為 0，然後我們記錄 inode 的新名稱（由於新的硬連結或重新命名）， 在這種情況下，我們記錄 inode 的i_size為 0，生成為 0，這會導致日誌重播程式碼不會將 inode 的i_size更新為 0（在 overwrite_item（） 中）。範例案例： mkdir /mnt/dir xfs_io -f -c pwrite 0 64K /mnt/dir/foo 同步 xfs_io -c 截斷 0 -c fsync /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c fsync /mnt/dir <power fail> 記錄重播後，檔案的大小仍為 64K。這是因為當我們第一次記錄 inode 時，當我們 fsync 檔案 foo 時，我們記錄其目前的 0 i_size，然後當我們建立硬連結時，我們會在存在模式 （LOG_INODE_EXISTS） 下再次記錄 inode，但我們為新增至記錄樹狀結構的 inode 項目設定了 0 代， 因此，在日誌重播期間，overwrite_item（） 看到生成為 0，i_size 為 0，因此我們跳過將 inode 的i_size從 64K 更新為 0。通過確保在 fill_inode_item（） 我們始終記錄 inode 的真實生成來解決此問題，如果它以我們之前記錄的i_size記錄在當前事務中。此外，如果在先前事務中建立的 inode 僅以存在模式登入，請確保我們記錄儲存在提交根目錄的 inode 項目中的i_size，以便如果我們多次記錄 inode 存在，我們會得到正確的i_size。fstests 的測試用例即將推出。（CVE-2026-43118）

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

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

  - drm/vc4：修正懸置狀態錯誤路徑中的記憶體洩漏 當 vc4_save_hang_state（） 遇到提前返回條件時，它會返回而不釋放先前配置的「kernel_state」，從而洩漏記憶體。透過將早期傳回路徑合併到一個地方來新增缺少的 kfree（） 呼叫。（CVE-2026-43104）

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

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

  - l2tp：丟棄帶有 UDP 封裝的大型封包 syzbot 在我的修補程式系列上報告了 WARN [1]。實際問題是 16 位元 UDP 長度欄位溢位，而且它存在於上游程式碼中。我的系列添加了一個帶有溢位檢查的調試 WARN，該檢查暴露了該問題，這就是為什麼 syzbot 在我的補丁上絆倒，而不是在上游代碼上絆倒。syzbot 的重現： r0 = 通訊端$pppl2tp（0x18， 0x1， 0x1） r1 = 通訊端$inet6_udp（0xa， 0x2， 0x0） connect$inet6（r1， &（0x7f00000000c0）={0xa， 0x0， 0x0， @loopback， 0xfffffffc}， 0x1c） connect$pppl2tp（r0， &（0x7f0000000240）=@pppol2tpin6={0x18， 0x1， {0x0， r1， 0x4， 0x0， 0x0， 0x0， {0xa， 0x4e22， 0xffff， @ipv4={'\x00'， '\xff\xff'， @empty}}}}， 0x32） writev（r0， &（0x7f0000000080）=[{&（0x7f0000000000）=ee， 0x34000}]， 0x1） 它基本上會傳送一個帶有 UDP 封裝的超大（0x34000 位元組）PPPoL2TP 封包，並且l2tp_xmit_core在分配 UDP 長度欄位時不會檢查溢位。該值被修剪為 16 位。新增溢位檢查，以丟棄過大的封包，並避免將具有修剪 UDP 長度的封包傳送到網路。syzbot 的堆疊追蹤（套用了我的修補程式）：len >= 65536u 警告：
    ./include/linux/udp.h：38 在 udp_set_len_short include/linux/udp.h：38 [內嵌]， CPU#1： syz.0.17/5957 警告： ./include/linux/udp.h：38 在 l2tp_xmit_core net/l2tp/l2tp_core.c：1293 [內嵌]， CPU#1：
    syz.0.17/5957 警告： ./include/linux/udp.h：38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c：1327， CPU#1： syz.0.17/5957 連結的模組： CPU： 1 UID： 0 PID： 5957 通訊： syz.0.17 未受污染的 syzkaller #0 PREEMPT（完整） 硬體名稱：QEMU 標準電腦 （Q35 + ICH9， 2009）， BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP： 0010：udp_set_len_short include/linux/udp.h：38 [內嵌] RIP： 0010：l2tp_xmit_core net/l2tp/l2tp_core.c：1293 [內嵌] RIP：0010：l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c：1327 代碼：
    0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP：
    0018：ffffc90003d67878 EFLAGS：00010293 RAX：ffffffff8ad985e3 RBX：ffff8881a6400090 RCX：ffff8881697f00000 RDX：0000000000000000000000 RSI：0000000000034010 RDI：000000000000ffff RBP：dffffc00000000000 R08：
    0000000000000003 R09： 0000000000000004 R10： dffffc0000000000 R11： ffffff520007acf00 R12： ffff8881baf20900 R13： 0000000000034010 R14： ffff8881a640008e R15： ffff8881760f7000 FS： 000055557e81f500（0000） GS：ffff8882a9467000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：
    0000200000033000 CR3：00000001612f4000 CR4：00000000000006f0 呼叫追蹤： <TASK> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c：302 sock_sendmsg_nosec net/socket.c：727 [內嵌]
    __sock_sendmsg net/socket.c：742 [內嵌] sock_write_iter+0x503/0x550 net/socket.c：1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c：-1 vfs_writev+0x33c/0x990 fs/read_write.c：1059 do_writev+0x154/0x2e0 fs/read_write.c：1105 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7f636479c629 代碼：ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007ffffd4241c8 EFLAGS：00000246 ORIG_RAX：0000000000000014 RAX：ffffffffffffffda RBX：
    00007f6364a15fa0 RCX：00007f636479c629 RDX：0000000000000001 RSI：0000200000000080 RDI：0000000000000003 RBP：00007f6364832b39 R08： 00000000000000000 R09： 00000000000000000000 R10： 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R11
    0000000000000246 ： 0000000000000000 R13： 00007f6364a15fac R14： 00007f6364a15fa0 R15： 00007f6364a15fa0 </TASK> [1]： https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/(CVE-2026-43080）R12

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Reset register ID for BPF_END value tracking When a register undergoes a BPF_END (byte swap) operation, its scalar value is mutated in-place. If this register previously shared a scalar ID with another register (e.g., after an `r1 = r0` assignment), this tie must be broken. Currently, the verifier misses resetting `dst_reg->id` to 0 for BPF_END. Consequently, if a conditional jump checks the swapped register, the verifier incorrectly propagates the learned bounds to the linked register, leading to false confidence in the linked register's value and potentially allowing out-of-bounds memory accesses. Fix this by explicitly resetting `dst_reg->id` to 0 in the BPF_END case to break the scalar tie, similar to how BPF_NEG handles it via `__mark_reg_known`. (CVE-2026-43070)

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

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

  - ipv4： icmp：修正 icmp_build_probe（） 中的 null-ptr-deref ipv6_stub->ipv6_dev_find（） 可能會傳回 ERR_PTR（-EAFNOSUPPORT） 當 IPv6 堆疊未啟用 （CONFIG_IPV6=m 且未載入） 時，將此錯誤指標傳遞給 dev_hold（） 將導致核心損毀並伴有 null-ptr-deref。相反，請以無訊息方式捨棄要求。RFC 8335 似乎沒有針對 IPv6 介面識別碼在語法上有效但實作無法在運行時執行查詢的情況定義特定回應，並且無訊息地刪除請求可能比誤報無此類介面更安全。（CVE-2026-43099）

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

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

  - Bluetooth： hci_sync：註解 hdev->req_status __hci_cmd_sync_sk（） 設定 hdev->req_lock 下的 hdev->req_status 周圍的資料爭用：hdev->req_status = HCI_REQ_PEND;但是，其他幾個函數在不持有任何鎖定的情況下讀取或寫入 hdev->req_status： - hci_send_cmd_sync（） 讀取 hci_cmd_work 中的req_status （工作佇列） - hci_cmd_sync_complete（） 從 HCI 事件完成讀取/寫入 - hci_cmd_sync_cancel（） / hci_cmd_sync_cancel_sync（） 讀取/寫入 - 連線中止路徑中的 hci_abort_conn（） 讀取，因為
    __hci_cmd_sync_sk（） 在 hdev->req_workqueue 上運行，而 hci_send_cmd_sync（） 在 hdev->workqueue 上運行，這些是可以在不同 CPU 上同時執行的不同工作佇列。純 C 存取構成資料爭用。在對 hdev->req_status 的所有並發存取上新增 READ_ONCE（）/WRITE_ONCE（） 註解，以防止可能影響正確性的潛在編譯器最佳化 （例如，在wait_event條件下載入融合或儲存重新排序）。（CVE-2026-43119）

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

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

  - Redis 是一個記憶體內資料結構儲存區。在具有 Lua 指令碼的所有版本的 redis-server 中，經過身份驗證的攻擊者都可以利用主複本同步機制，在停用或可以停用複本唯讀的複本上觸發釋放後使用，這可能會導致遠端程式碼執行。因應措施是防止使用者執行 Lua 指令碼，或避免使用停用複本唯讀的複本。此問題已在 8.6.3 版中修正。(CVE-2026-23631)

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

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

  - 在 Paramiko 4.0.0 到 a448945 之前，rsakey.py 允許 SHA-1 演算法。（CVE-2026-44405）

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

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

  - ocfs2：修正 ocfs2_write_end_inline 中的越界寫入 KASAN 報告 ocfs2_write_end_inline 中 4086 位元組的釋放後使用寫入，這是在掛載在迴圈裝置上的損毀 ocfs2 檔案系統上進行copy_file_range拼接後援期間從 ocfs2_write_end_nolock 呼叫的。實際的錯誤是越界寫入 inode 區塊緩衝區，而不是真正的釋放後使用。寫入會溢位到相鄰的釋放頁面，KASAN 會將其報告為 UAF。根本原因是ocfs2_try_to_write_inline_data信任磁碟上的id_count欄位來判斷寫入是否適合內嵌資料。在損毀的檔案系統上，id_count可能會超過實體最大內嵌資料容量，導致寫入溢位 inode 區塊緩衝區。呼叫追蹤 （損毀路徑）：vfs_copy_file_range （fs/read_write.c：1634） do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock （fs/ocfs2/aops.c：1949） ocfs2_write_end_inline （fs/ocfs2/aops.c：1915） memcpy_from_folio <-- KASAN：寫入 OOB 因此，在 ocfs2_validate_inode_block（） 中新增id_count上限檢查到現有的i_size檢查旁邊來修復它。（CVE-2026-43075）

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

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

  - Prometheus 是一個開源的監控系統與時間序列資料庫。在版本3.5.33.11.3和之前，Azure AD 遠端寫入 OAuth 配置（storage/remote/azuread）中的 client_secret 欄位是用字串而非 Secret。Prometheus 在透過 /-/config HTTP API 端點提供配置時，會刪除 Secret 類型的欄位。由於欄位是純字串，Azure OAuth 用戶端秘密以明文形式暴露給任何有權限存取該端點的使用者或程序。此問題已在 3.5.3、3.11.3 和 CVE-2026-42151 版本中修正。

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

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

  - RDMA/irdma：修正與rereg_user_mr相關的雙重釋放如果在rereg_user_mr期間設定了IB_MR_REREG_TRANS，則將釋放 umem，並在 irdma_rereg_mr_trans 中分配新的 uem。如果在配置新的 umem 之後，irdma_rereg_mr_trans的任何步驟失敗，則會釋放 umem，但不會將 iwmr->region 設為 NULL。問題是，此失敗會傳播給使用者，然後使用者會呼叫ibv_dereg_mr （因為他們應該如此）。然後，dereg_mr路徑會看到一個非空的 umem，並嘗試再次呼叫ib_umem_release。透過在ib_umem_release後將 iwmr->region 設定為 NULL 來修正此問題。已修正：5ac388db27c4 （RDMA/irdma：新增支援以重新註冊記憶體區域） （CVE-2026-43120）

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

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

  - ixgbevf：將遺漏的 negotiate_features op 新增至 Hyper-V 操作資料表 Commit a7075f501bd3 （ixgbevf：藉由協商支援的功能來修正信箱 API 相容性） 將 .negotiate_features 回呼新增至 ixgbe_mac_operations，並將其填入 ixgbevf_mac_ops，但忘記將其新增至 ixgbevf_hv_mac_ops。這會在 Hyper-V VM 上使函式指標為 NULL。在探測期間，ixgbevf_negotiate_api（） 呼叫 ixgbevf_set_features（），這會無條件地取消參照 hw->mac.ops.negotiate_features（）。在 Hyper-V 上，這會導致 NULL 指標解除參照： 錯誤：核心 NULL 指標解除參照，位址：
    0000000000000000 [...]硬件名稱：Microsoft Corporation 虛擬機/虛擬機 [...]工作佇列：事件work_for_cpu_fn RIP：0010：0x0 [...]呼叫追蹤：ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...]新增傳回 -EOPNOTSUPP 的 ixgbevf_hv_negotiate_features_vf（） ，並將其連線至 ixgbevf_hv_mac_ops。呼叫端已正常地處理 -EOPNOTSUPP。（CVE-2026-43094）

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

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

  - xfrm_user：修正 build_mapping（） 結構中的資訊洩露，xfrm_usersa_id在 proto 欄位後面有一個一個位元組的填充孔，在複製到使用者空間之前，該孔最終永遠不會設定為零。通過在設置單個變量之前將整個結構歸零來解決這個問題。（CVE-2026-43089）

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

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

  - 提交前的 BusyBox 在 42202bf 之前，包含 networking/udhcp/d6_dhcpc.c 中 DHCPv6 用戶端（udhcpc6）DNS_SERVERS選項處理器中的堆積緩衝區溢位漏洞，允許鄰近網路的攻擊者透過發送帶有錯誤D6_OPT_DNS_SERVERS選項的精心設計的 DHCPv6 回應來觸發記憶體損毀。
    攻擊者可利用 option_to_env（） 函式中堆積緩衝區分配計算錯誤，導致拒絕服務，或在未進行堆積強化的情況下實現嵌入系統的任意程式碼執行。
    (CVE-2026-29004)

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

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

  - Jupyter Server 是 Jupyter 網頁應用程式的後端。在版本 2.17.0 及更早版本中，用於簽署認證 Cookie 的秘密會持久化為靜態檔案 ~/.local/share/jupyter/runtime/jupyter_cookie_secret，且使用者更改密碼時不會輪換。在密碼重設並重新啟動伺服器後，任何先前發出的認證 Cookie 在密碼學上仍然有效，因為簽約金鑰未曾更改。攻擊者若透過任何方式取得會話 Cookie，無論後續密碼如何更改，都保有對伺服器的完整認證存取權。這影響使用密碼驗證的部署，特別是共享或公開伺服器，因為憑證輪替預期會撤銷現有會話。2.18.0 版已修正此問題。(CVE-2026-40934)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c .
    d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted a . b, even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (netfilter: nft_set_pipapo: fix range overlap detection) but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map. (CVE-2026-43114)

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

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

  - 在 ProFTPD 到 1.3.9a 之前的 7666224 中，contrib/mod_wrap2_sql.c 的 sqltab_fetch_clients_cb（） 中存在 SQL 注入漏洞，允許遠端攻擊者透過反向 DNS 查詢中存取的自訂網域名注入任意 SQL 指令。啟用 UseReverseDNS 時，攻擊者提供的主機名稱會被傳送到 SQL 查詢中，未逃脫。DNS 名稱的字元限制可能影響可利用性。（CVE-2026-44331）

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

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

  - 已解決 Linux 核心中的下列弱點：ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 (ext4: always allocate blocks only from groups inode can use) restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().
    (CVE-2026-43067)

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

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

  - wifi：wl1251：在編製索引之前驗證封包 ID tx_frames wl1251_tx_packet_cb（） 直接使用韌體完成 ID 來索引固定的 16 個項目 wl->tx_frames[] 陣列。ID 是來自完成區塊的原始 u8，回呼目前不會在取消參照之前驗證它是否適合陣列。拒絕落在 wl->tx_frames[] 之外的完成標識碼，並將現有的 NULL 檢查保留在相同的防護中。這會將修正程式保留在信任邊界的本機位置，並避免觸及完成流程的其餘部分。
    (CVE-2026-43113)

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

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

  - FRRouting （FRR） MP_REACH_NLRI 元件中缺少輸入驗證，stable/10.0 to stable/10.6 允許已認證的攻擊者透過提供精心設計的 UPDATE 訊息，造成拒絕服務（DoS）。
    (CVE-2026-37458)

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

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

  - srcu：使用 irq_work 在 tinny SRCU 中啟動 GP Tiny SRCU 的 srcu_gp_start_if_needed（） 直接呼叫 schedule_work（），後者會取得工作佇列 pool->lock。當調用 call_srcu（） 並持有排程器鎖定時，這會導致 lockdep splat，原因如下： call_srcu（） [holding pi_lock] srcu_gp_start_if_needed（） schedule_work（） -> pool->lock workqueue_init（） / create_worker（） [holding pool->lock] wake_up_process（） -> try_to_wake_up（） -> pi_lock 同時將 irq_work_sync（） 新增至 cleanup_srcu_struct（），以防止在清理開始後觸發佇列的irq_work時釋放後使用。使用 rcutorture SRCU-T 測試，沒有鎖定警告。[感謝 Boqun 在修補程式 rcu 中進行了類似的修復：使用中間irq_work啟動 process_srcu（） ]（CVE-2026-43115）

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

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

  - net： af_key：PF_KEY匯出中零對齊的 sockaddr 尾部PF_KEY在保留 sockaddr 負載空間時使用「pfkey_sockaddr_size（）」，因此 IPv6 位址在網路上佔用 32 個位元組。然而，「pfkey_sockaddr_fill（）」僅初始化「struct sockaddr_in6」的前 28 個位元組，而最後 4 個對齊位元組未初始化。並非每個PF_KEY訊息都會受到影響。狀態和原則轉儲建置器在填入 sockaddr 承載之前，已將整個訊息緩衝區歸零。保留對仍使用純 'skb_put（）' 附加對齊 sockaddr 負載的匯出路徑的修正： - 'SADB_ACQUIRE' - 'SADB_X_NAT_T_NEW_MAPPING' - 'SADB_X_MIGRATE' 透過僅清除 'pfkey_sockaddr_fill（）' 之後對齊的 sockaddr 尾部來修正這些路徑。（CVE-2026-43088）

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

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

  - 藍牙：MGMT：修正指令中 UAF 的損壞與 UAF，完整處理器提交 302a1f674c00（藍牙：
    MGMT：修正可能的 UAFs）引入了 mgmt_pending_valid（），不僅能驗證待處理指令，還會在該指令有效時將其從待處理清單中移除連結。這種語意上的改變需要更新多個完成處理程序，以避免清單損毀及記憶體安全問題。此補丁解決了前述重製遺留的兩個問題：1. 在 mgmt_add_adv_patterns_monitor_complete（），成功路徑上的 mgmt_pending_remove（） 被替換為 mgmt_pending_free（）。由於 mgmt_pending_valid（） 在函式開頭已經解除連結指令，呼叫 mgmt_pending_remove（） 會導致雙重 list_del（） 及隨後的串列損毀或核心恐慌。2. 在 set_mesh_complete（），錯誤路徑中移除了 mgmt_pending_foreach（） 的使用。由於目前指令已經以 mgmt_pending_valid（） 解除連結，這個 foreach 迴圈會錯誤地鎖定其他待處理的網格指令，可能導致它們在同時處理時釋放它們（導致 UAF）。冗餘的 mgmt_cmd_status（） 也簡化為直接使用 cmd->opcode。（CVE-2026-43059）

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

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

  - gobgp v4.3.0 的 ParseIP6Extended 函式（/bgp/bgp.go）中的越界讀取，允許攻擊者透過提供精心設計的 BGP UPDATE 訊息來造成阻斷服務（DoS）。（CVE-2026-37461）

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

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

  - net：lapbether：句柄 NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit（） 預期基礎裝置類型為ARPHRD_ETHER。從 lapbeth_device_event（） 返回NOTIFY_BAD可確保綁定驅動程式無法打破此預期。（CVE-2026-43103）

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary. Add the check to the reassignment so that this does not happen. Also update the comment which still refers to the obsolete offset argument.
    (CVE-2026-43078)

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

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

  - Jupyter Server 是 Jupyter Web 應用程式的後端。在舊版 2.17.0 和更早版本中，REST API 中的路徑遊走弱點允許經驗證的使用者逸出已設定的root_dir，並存取名稱以與root_dir相同首碼開頭的同級目錄。例如，使用名為 test 的root_dir，API 允許使用編碼路徑元件，透過對 /api/contents 端點的特製要求，存取名為 testtest 的同級目錄。攻擊者可以讀取、寫入和刪除受影響同級目錄中的檔案。使用可預測命名配置的多租用戶部署尤其面臨風險，因為目錄名為 user1 的使用者可能會存取 user10 到 user19 及更高版本的目錄。可選擇單一字元資料夾名稱的使用者可能會存取大量同級目錄。版本包含 2.18.0 修正。因應措施是確保資料夾名稱不與任何同級目錄共用通用首碼。（CVE-2026-35397）

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

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

  - Jupyter Server 是 Jupyter Web 應用程式的後端。在版本和更早版本中 2.17.0 ，Origin 標頭驗證使用 Python 的 re.match（） 根據 allow_origin_pat 組態值檢查傳入來源。由於 re.match（） 僅錨定在字串的開頭，不需要完全匹配，因此僅匹配受信任域（例如 trusted.example.com）的模式也將匹配以該域開頭後跟其他字符（例如 trusted.example.com.evil.com）的任何來源。控制此類網域的攻擊者可以繞過 CORS 來源限制，並從不受信任的網站向 Jupyter 伺服器 API 發出跨來源要求。2.18.0 版已修正此問題。(CVE-2026-40110)

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

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

  - wifi： brcmfmac：驗證 IF 事件中的 bsscfg 索引 brcmf_fweh_handle_if_event（） 會在韌體提供的介面索引接觸 drvr->iflist[] 之前驗證它，但它仍然使用原始 bsscfgidx 欄位作為陣列索引，而不進行相符範圍檢查。在為介面陣列編製索引之前，拒絕其 bsscfg 索引不符合 drvr->iflist[] 的 IF 事件。[新增缺少的 wifi 前綴]（CVE-2026-43110）

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

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

  - Prometheus 是一個開源的監控系統與時間序列資料庫。在版本和3.5.33.11.3之前，遠端讀取端點（/api/v1/read）在分配記憶體前，並不會在快速壓縮的請求體中驗證宣告的解碼長度。未經認證的攻擊者可能會發送一個小型有效載荷，導致每個請求分配龐大的堆積。在並行負載下，這可能會耗盡可用記憶體並導致 Prometheus 程序當機。此問題已在 3.5.3 和 3.11.3 版本中修復。
    (CVE-2026-42154)

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

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

  - RedisTimeSeries 是 Redis 的時間序列模組。在 RedisTimeSeries 之前 1.12.14 的所有版本中，模組都無法正確驗證透過 Redis RESTORE 命令處理的序列化值。具有在載入 RedisTimeSeries 模組的伺服器上執行 RESTORE 權限的已驗證攻擊者可以提供特製的序列化承載，以觸發無效的記憶體存取，並可能導致遠端程式碼執行。因應措施是使用 ACL 規則來限制對 RESTORE 命令的存取。這已在版本 1.12.14中修補。（CVE-2026-25588）

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

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

  - btrfs： 追蹤點：在事件 btrfs_sync_file（） 中從 dentry 取得正確的超級區塊 如果在 btrfs 之上使用覆蓋，dentry->d_sb 會轉換為覆蓋的超級區塊，而 fsid 分配將導致損毀。
    使用 file_inode（file）->i_sb 一律取得 btrfs_sb。CVE-2026-43117

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

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

  - fs/smb/client：修正 cifs_sanitize_prepath 中的越界讀取 當使用空字串或僅包含分隔符號的字串 （例如 /） 呼叫 cifs_sanitize_prepath 時，目前邏輯會嘗試檢查
    *（cursor2 - 1） 在 cursor2 前進之前。這會導致越界讀取。此修補程式在去除前面的分隔符號後新增了提前退出檢查。如果沒有路徑內容保留，則函式會傳回 NULL。該錯誤是透過手動審核發現的，並使用使用 AddressSanitizer 編譯的獨立測試案例進行驗證，該測試案例在受影響的輸入上觸發了 SEGV。（CVE-2026-43112）

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

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

  - 透過 OCSP 回應資料，Apache HTTP 伺服器 mod_md 中的無限制或節流資源配置弱點。此問題會影響 Apache HTTP Server 2.4.30 至 2.4.66 (含) 版。建議使用者升級至 2.4.67 版，即可修正此問題。(CVE-2026-29168)

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

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

  - Redis 是一個記憶體內資料結構儲存區。在 redis-server from 7.2.0 until 8.6.3中，重新執行封鎖的命令時，解除封鎖用戶端流程不會處理來自「processCommandAndResetClient」的錯誤傳回。如果在此流程期間撤回封鎖的用戶端，則經過驗證的攻擊者可觸發釋放後使用，進而導致遠端程式碼執行。這已在版本 8.6.3中修補。
    (CVE-2026-23479)

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

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

  - netfilter： nfnetlink_log：在NLMSG_DONE終止符中初始化 nfgenmsg 當批次處理多個 NFLOG 訊息 （inst->qlen > 1） 時，__nfulnl_send（） 會透過 nlmsg_put（） 附加具有 sizeof（struct nfgenmsg） 負載的 NLMSG_DONE 終止符，但絕不會初始化 nfgenmsg 位元組。nlmsg_put（） 協助程式只會在承載之後將對齊填補歸零，而不是承載本身，因此四個位元組的過時核心堆積資料會洩漏到NLMSG_DONE訊息正文中的使用者空間。使用 nfnl_msg_put（） 建立 NLMSG_DONE 終止符，它透過 nfnl_fill_hdr（） 初始化 nfgenmsg 負載，這與 __build_packet_message（） 已經建構NFULNL_MSG_PACKET標頭的方式一致。（CVE-2026-43085）

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

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

  - HID： roccat：修正 roccat_report_event roccat_report_event（） 在裝置>讀取器清單中反覆運算而不保留readers_lock中的釋放後使用。這允許並發 roccat_release（） 在仍在存取閱讀器時刪除並釋放閱讀器，從而導致釋放後使用。使用 readers_lock 互斥保護讀取器清單遊走。（CVE-2026-43111）

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: algif_aead - Fix minimum RX size check for decryption The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length. (CVE-2026-43077)

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

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

  - xfrm：事件大小計算 xfrm_get_ae（） 中的帳戶XFRMA_IF_ID會使用 xfrm_aevent_msgsize（） 配置回覆 skb，然後 build_aevent（） 會在設定 x->if_id 時附加屬性，包括 XFRMA_IF_ID。
    xfrm_aevent_msgsize（） 不包含XFRMA_IF_ID空間。對於具有 if_id 的狀態，build_aevent（） 可能會因 -EMSGSIZE 而失敗，並在 xfrm_get_ae（） 中命中 BUG_ON（錯誤< 0），從而將格式錯誤的網路連結互動變成核心錯誤。在大小計算中無條件考慮XFRMA_IF_ID，並將BUG_ON替換為正常錯誤展開。（CVE-2026-43107）

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

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

  - FRRouting 中的整數下溢（FRR）stable/10.0 to stable/10.6 允許攻擊者透過提供精心設計的 BGP UPDATE 訊息來造成阻斷服務（DoS）。（CVE-2026-37459）

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

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

  - Redis 是一個記憶體內資料結構儲存區。在 之前的 redis-server 8.6.3版本中，RESTORE 命令無法正確驗證序列化值。具有執行 RESTORE 權限的已驗證攻擊者可以提供特製的序列化承載，以觸發無效的記憶體存取，並可能導致遠端程式碼執行。因應措施是使用 ACL 規則來限制對 RESTORE 命令的存取。此問題已在 8.6.3 版中修正。(CVE-2026-25243)

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

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

  - ocfs2：在 inode 讀取期間驗證內嵌資料i_size 從磁碟讀取 inode 時，ocfs2_validate_inode_block（） 會執行各種健全性檢查，但不會驗證內嵌資料的大小。
    如果檔案系統損毀，inode 的i_size可能會超過實際的內嵌資料容量 （id_count）。
    這會導致 ocfs2_dir_foreach_blk_id（） 迭代超出內嵌資料緩衝區，在從釋放的記憶體存取目錄項目時觸發釋放後使用。在 syzbot 報告中： - i_size為 1099511627576 位元組 （~1TB） - 實際內嵌資料容量 （id_count） 通常為 <256 位元組 - 垃圾rec_len （54648） 導致 ctx->pos 越界 - 這觸發了 ocfs2_check_dir_entry（） 中的 UAF，方法是在 ocfs2_validate_inode_block（） 中新增驗證檢查來確保具有內嵌資料的 inode 具有 i_size <= id_count。這會在 inode 讀取期間及早發現損毀，並防止所有下游程式碼在無效資料上運作。（CVE-2026-43076）

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

ID	名稱	嚴重性
312691	Linux Distros 未修補的弱點：CVE-2026-43128	high
312690	Linux Distros 未修補的弱點：CVE-2026-43225	medium
312689	Linux Distros 未修補的弱點：CVE-2026-43283	high
312688	Linux Distros 未修補的弱點：CVE-2026-43074	high
312687	Linux Distros 未修補的弱點：CVE-2026-43246	medium
312644	Linux Distros 未修補的弱點：CVE-2026-25589	high
312643	Linux Distros 未修補的弱點：CVE-2026-43116	high
312642	Linux Distros 未修補的弱點：CVE-2026-43098	medium
312641	Linux Distros 未修補的弱點：CVE-2026-43118	medium
312640	Linux Distros 未修補的弱點：CVE-2026-43104	medium
312639	Linux Distros 未修補的弱點：CVE-2026-43080	medium
312638	Linux Distros 未修補的弱點：CVE-2026-43070	high
312637	Linux Distros 未修補的弱點：CVE-2026-43099	high
312636	Linux Distros 未修補的弱點：CVE-2026-43119	medium
312635	Linux Distros 未修補的弱點：CVE-2026-23631	medium
312634	Linux Distros 未修補的弱點：CVE-2026-44405	low
312633	Linux Distros 未修補的弱點：CVE-2026-43075	high
312632	Linux Distros 未修補的弱點：CVE-2026-42151	high
312631	Linux Distros 未修補的弱點：CVE-2026-43120	high
312630	Linux Distros 未修補的弱點：CVE-2026-43094	medium
312629	Linux Distros 未修補弱點：CVE-2026-43089	medium
312628	Linux Distros 未修補的弱點：CVE-2026-29004	high
312627	Linux Distros 未修補的弱點：CVE-2026-40934	high
312626	Linux Distros 未修補弱點：CVE-2026-43114	high
312625	Linux Distros 未修補的弱點：CVE-2026-44331	high
312624	Linux Distros 未修補的弱點：CVE-2026-43067	critical
312623	Linux Distros 未修補的弱點：CVE-2026-43113	high
312622	Linux Distros 未修補的弱點：CVE-2026-37458	medium
312621	Linux Distros 未修補的弱點：CVE-2026-43115	medium
312620	Linux Distros 未修補的弱點：CVE-2026-43088	medium
312619	Linux Distros 未修補的弱點：CVE-2026-43059	high
312618	Linux Distros 未修補的弱點：CVE-2026-37461	high
312617	Linux Distros 未修補弱點：CVE-2026-43103	medium
312616	Linux Distros 未修補的弱點：CVE-2026-43078	high
312615	Linux Distros 未修補的弱點：CVE-2026-35397	high
312614	Linux Distros 未修補弱點：CVE-2026-40110	high
312613	Linux Distros 未修補弱點：CVE-2026-43110	high
312612	Linux Distros 未修補的弱點：CVE-2026-42154	high
312611	Linux Distros 未修補的弱點：CVE-2026-25588	high
312610	Linux Distros 未修補弱點：CVE-2026-43117	critical
312609	Linux Distros 未修補的弱點：CVE-2026-43112	high
312608	Linux Distros 未修補的弱點：CVE-2026-29168	high
312607	Linux Distros 未修補的弱點：CVE-2026-23479	high
312606	Linux Distros 未修補的弱點：CVE-2026-43085	medium
312605	Linux Distros 未修補弱點：CVE-2026-43111	high
312604	Linux Distros 未修補的弱點：CVE-2026-43077	medium
312603	Linux Distros 未修補弱點：CVE-2026-43107	medium
312602	Linux Distros 未修補的弱點：CVE-2026-37459	high
312601	Linux Distros 未修補的弱點：CVE-2026-25243	high
312600	Linux Distros 未修補弱點：CVE-2026-43076	high

偵測

Nessus 的 Misc. 系列

high

medium

high

high

medium

high

high

medium

medium

medium

medium

high

high

medium

medium

low

high

high

high

medium

medium

high

high

high

high

critical

high

medium

medium

medium

high

high

medium

high

high

high

high

high

high

critical

high

high

high

medium

high

medium

medium

high

high

high