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

  - crypto：atmel-sha204a - 修正移除路徑中潛在的 UAF 和記憶體洩漏 取消註冊 hwrng 以防止新的 ->read（） 呼叫，並在拆卸前排清 Atmel I2C 工作佇列，以防止在移除裝置時執行佇列的回呼時可能發生 UAF。刪除提前返回，以確保移除 sysfs 項目並釋放 ->hwrng.priv，防止記憶體洩漏。（CVE-2026-46075）

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

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

  - ext4：修正 ext4_ext_shift_extents（） 中的記憶體洩漏 在 ext4_ext_shift_extents（） 中，如果 while 迴圈中的範圍為 NULL，則函數會立即返回而不釋放透過 ext4_find_extent（） 獲得的路徑，從而導致記憶體洩漏。透過跳到輸出標籤來修正此問題，以確保路徑已正確釋放。（CVE-2026-45948）

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

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

  - RDMA/rxe：修正 rxe_srq_from_init 中的雙重釋放 在 rxe_srq_from_init（） 中，佇列指標 'q' 在將 SRQ 編號複製到使用者空間之前，會指派給 'srq->rq.queue'。如果 copy_to_user（） 失敗，則函式會呼叫 rxe_queue_cleanup（） 以釋放佇列，但會將現在無效的指標保留在 'srq->rq.queue' 中。rxe_srq_from_init（） （rxe_create_srq） 的呼叫者最終在收到錯誤後呼叫 rxe_srq_cleanup（），這會觸發同一記憶體上的第二個 rxe_queue_cleanup（），從而導致雙重釋放。呼叫追蹤如下所示：kmem_cache_free+0x.../0x...rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] 透過在copy_to_user之後移動「srq->rq.queue = q」來修正此問題。（CVE-2026-45852）

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

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

  - 藍牙：hci_event：修正 SSP 通行金鑰處理常式中潛在的 UAF，hci_conn hci_user_passkey_notify_evt（） 和 hci_keypress_notify_evt（） 中的 hdev 鎖定必須涵蓋查詢和欄位存取，否則可能會同時釋放連線。擴充 hci_dev_lock 關鍵區段，以涵蓋兩個處理常式中的所有 conn 使用方式。透過一般解除鎖定路徑遞送提前結束，讓現有按鍵通知行為不變。（CVE-2026-46056）

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

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

  - ext4：不要在分割範圍期間快取範圍 在分割處理程序期間快取範圍有風險，因為這可能會導致狀態樹狀結構中保留過時的範圍。此外，在大多數情況下，對應的範圍區塊項目可能在分割發生之前就已經快取，因此此處快取並不是特別有用。假設我們有一個不成文的範圍，然後 DIO 寫入前半部分。
    [UUUUUUUUUUUUUUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUUUUUUUUUUUU] 範圍狀態樹狀結構 |<- ->|----> dio 寫入此範圍首先，當 ext4_split_extent_at（） 分割此範圍時，它會截斷現有範圍，然後插入一個新的範圍。在此過程中，此範圍狀態項目可能會縮小，並且可能會呼叫 ext4_find_extent（） 和 ext4_cache_extents（），這可能會將截斷的範圍作為漏洞插入範圍狀態樹狀結構中。分割完成後，此孔不會替換為正確的狀態。[嗚嗚嗚嗚嗚|UUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUU|HHHHHHH] 範圍狀態樹狀結構 H：孔 然後，外部呼叫函式也不會更正這個剩餘的孔範圍。
    最後，如果我們對後一部分執行延遲緩衝區寫入，它會重新插入延遲範圍並導致空間計費錯誤。此外，如果在分割期間未縮減未寫入的範圍快取，則在快取範圍時，ext4_cache_extents（） 也會與現有範圍衝突。將來，我們將在快取範圍時新增檢查，這會觸發警告。因此，請勿快取正在分割的範圍。（CVE-2026-45912）

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

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

  - ntfs3：修正 run_unpack（） 磁碟區邊界檢查中的整數溢位 磁碟區邊界檢查「lcn + len > sbi->used.bitmap.nbits」使用原始加法，可以針對較大的 lcn 和 len 值進行換行，繞過驗證。使用 check_add_overflow（），就像對相鄰prev_lcn所做的那樣 + dlcn 和 vcn64 + 提交 3ac37e100385 新增的 len 檢查 （ntfs3： 修正 run_unpack（）） 中的整數溢位。透過使用原始碼修補的工具 （LibAFL + QEMU） 進行模糊測試找到。（CVE-2026-46062）

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

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

  - SPI：修正裝置設定失敗時的資源洩漏 如果 spi_setup（） 在註冊裝置時失敗，請務必呼叫控制器 cleanup（），以避免洩漏 setup（） 配置的任何資源。（CVE-2026-46083）

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

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

  - bonding： alb：在綁定上/下綁定期間修復rlb_arp_recv中的 UAF ALB RX 路徑可以在綁定拆解的同時存取rx_hashtbl。在快速綁定上/下週期期間，rlb_deinitialize（） 會在 RX 處理常式仍在執行時釋放rx_hashtbl，導致 KASAN 偵測到空指標解除參照。然而，根本原因是將 recv_probe 設定為 NULL 後仍然可以存取 rlb_arp_recv（），這實際上是一個釋放後使用（UAF）問題。這就是在 Fixes 標籤中使用參照提交的原因。[ 214.174138] 哎呀：一般保護錯誤，可能是非規範位址0xdffffc000000001d：
    0000 [#1] SMP KASAN PTI [ 214.186478] KASAN：範圍 [0x00000000000000e8-0x00000000000000ef] 內的 null-ptr-deref [ 214.194933] CPU：30 UID：0 PID：2375 通訊：ping kdump：已載入 未受污染 6.19.0-rc8+ #2 PREEMPT（自願） [ 214.205907] 硬體名稱：Dell Inc. PowerEdge R730/0WCJNT， BIOS 2.14.0 01/14/2022 [ 214.214357] RIP：0010：rlb_arp_recv+0x505/0xab0 [bonding] [214.220320] 代碼：0f 85 2b 05 00 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP： 0018：ffffc900073d8870 EFLAGS： 00010206 [ 214.247116] RAX： dffffc00000000000 RBX：
    ffff888168556822 RCX：ffff88816855681e [ 214.255082] RDX：000000000000001d RSI：dffffc00000000000 RDI：
    0000000000000000e8 [ 214.263048] RBP： 000000000000000000000000000000000 ： R080000000000000002 R09： ffffed11192021c8 [214.271013] R10： ffff8888c9010e43 R11： 0000000000000001 R12： 1ffff92000e7b119 [ 214.278978] ： R13
    ffff8888c9010e00 R14： ffff888168556822 R15： ffff888168556810 [ 214.286943] FS： 00007f85d2d9cb80（0000） GS：ffff88886ccb3000（0000） knlGS：000000000000000000 [ 214.295966] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [ 214.302380] CR2： 00007f0d047b5e34 CR3： 00000008a1c2e002 CR4： 00000000001726f0 [214.310347] 呼叫追蹤： [ 214.313070] <IRQ> [ 214.315318] ？ __pfx_rlb_arp_recv+0x10/0x10 [bonding] [214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ？ __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ？
    __pfx_arp_process+0x10/0x10 [ 214.343775] ？ sched_balance_find_src_group+0x98/0x630 [ 214.349513] ？
    __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ？ arp_rcv+0x307/0x690 [ 214.360311] ？
    __pfx_arp_rcv+0x10/0x10 [ 214.364499] ？ __lock_acquire+0x58c/0xbd0 [ 214.368975]
    __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ？ __pfx___netif_receive_skb_one_core+0x10/0x10 [214.380743] ？ lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ？ process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ？ __pfx_net_rx_action+0x10/0x10 [ 214.408193] ？ lock_acquire.part.0+0xbd/0x260 [ 214.413058] ？ sched_clock_cpu+0x6c/0x540 [ 214.417540] ？ mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ？
    __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ？ __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> 此問題可透過在接收 ARP 訊息時重複執行 ip link set bond0 up/down 來重現，其中 rlb_arp_recv（） 可能會與 rlb_deinitialize（） 爭用並取消參照釋放的 rx_hashtbl 項目。透過將 recv_probe 設定為 NULL，然後呼叫 synchronize_net（） 以等待任何並行的 RX 處理完成來修正此問題。這可確保在 bond_alb_deinitialize（） 中釋放後，任何 RX 處理常式都無法存取 rx_hashtbl。（CVE-2026-45970）

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

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

  - ALSA： caiaq：正確處理探查錯誤 caiaq 驅動程式中 setup_card（） 的探查程序不會正常地處理錯誤情況，例如來自 snd_card_register（） 呼叫 snd_card_free（） 的錯誤，但會繼續發生。這將導致 UAF 用於像 snd_usb_caiaq_control_init（） 這樣的進一步調用，正如 Berk 在下面連結中的另一個補丁中建議的那樣。然而，問題不僅如此;一般來說，此函數會刪除所有錯誤處理（因為它是 void 函數），儘管其調用方可以將錯誤傳播到 snd_probe（），最終調用 snd_card_free（） 作為適當的錯誤路徑。也就是說，我們應該處理 setup_card（） 中的每個錯誤情況，並立即傳回錯誤代碼，然後將其作為 snd_probe（） 中的致命錯誤進行處理。此修補程式透過變更 setup_card（） 以傳回錯誤代碼來實現這一點。此外，多餘的 snd_card_free（） 調用也被刪除。請注意，在傳回錯誤時仍可安全地設定 card->private_free。card_free（） 中所有被呼叫的函式都會檢查未指派的資源或 NULL 檢查。（CVE-2026-46004）

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

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

  - fbdev：au1200fb：修正 au1200fb_drv_probe（） 中的記憶體洩漏 在 au1200fb_drv_probe（） 中，當 platform_get_irq fails（） 時，它直接從函數返回錯誤代碼，從而導致記憶體洩漏。將其替換為 goto 標籤以確保正確清理。（CVE-2026-45954）

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

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

  - ibmasm：修正 command_file_write 中由於缺少大小檢查而導致的 OOB 讀取 command_file_write（） 處理常式會配置一個精確計數位元組的核心緩衝區，並將使用者資料複製到其中，但在將緩衝區傳遞給 get_dot_command_size（） 和 get_dot_command_timeout（） 之前，不會根據 dot 命令通訊協定驗證緩衝區。由於配置大小 （計數） 和標頭欄位 （command_size、data_size） 都是獨立的使用者控制，因此攻擊者可導致 get_dot_command_size（） 傳回超出配置的值，從而觸發 get_dot_command_timeout（） 中的 OOB 讀取，以及將核心堆積記憶體洩漏給服務處理器的越界 memcpy_toio（）。使用兩個防護措施進行修正：在分配之前拒絕小於 sizeof（struct dot_command_header） 的寫入，然後在複製使用者資料後拒絕緩衝區小於標頭 （sizeof（header） + command_size + data_size） 所宣告的總大小的命令。這可確保所有後續標頭和承載欄位存取都保留在緩衝區內。（CVE-2026-45994）

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

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

  - selinux：修正 overlayfs、mmap（） 和 mprotect（） 存取檢查 overlayfs 的現有 SELinux 安全性模型是，如果目前任務能夠存取頂層檔案 （使用者檔案），且裝載程式的憑證足以存取較低層級檔案 （備份檔案），則允許存取。
    遺憾的是，目前的程式碼並未針對 overlayfs 檔案系統上的 mmap（） 和 mprotect（） 作業正確執行這些存取控制。此修補程式會利用新建立的 security_mmap_backing_file（） LSM 勾點，為 mmap（） 作業提供缺少的備份檔強制執行，並利用備份檔 API 和新的 LSM blob 提供必要的資訊，以正確強制執行 mprotect（） 存取控制。（CVE-2026-46054）

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

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

  - power： supply： cpcap-battery： 修正 power_supply_changed（） 中的釋放後使用 'devm_' 變體來請求 IRQ _before_ 用於配置/註冊 'power_supply' 句柄的 'devm_' 變體，意味著 'power_supply' 句柄將在中斷處理常式之前 _ 解除配置/取消註冊 （因為 'devm_' 自然地以相反的分配順序解除配置）。這表示在移除期間，會發生爭用情形，即中斷可能會在 'power_supply' 控制碼被釋放之後觸發，*但是* 就在 IRQ 處理常式的對應取消註冊執行之前。這將導致 IRQ 處理常式呼叫具有釋放的 'power_supply' 句柄的 'power_supply_changed（）'。這通常會使系統崩潰或以其他方式無聲地損壞記憶體... 請注意，在「probe（）」期間也可能發生類似的情況;在註冊 'power_supply' 控制碼之前_中斷觸發的可能性。這將導致在「power_supply_changed（）」中使用「power_supply」句柄*未初始化*的惡劣情況。透過確保在註冊 'power_supply' 控制碼之後 _ 請求 IRQ，來修正此 racy 釋放後使用。（CVE-2026-45885）

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

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

  - FastNetMon Community Edition through 具有 1.2.9 越界記憶體存取，因為它錯誤地剖析了已設定擴充長度旗標的 BGP 路徑屬性。在 src/bgp_protocol.hpp 中，parse_raw_bgp_attribute（） 函式會正確識別何時設定 extended_length_bit 並將 length_of_length_field 設為 2，但隨後僅讀取屬性值長度的單一位元組 （第 173 行的 attribute_value_length = value[2]）。根據 RFC 4271 區段 4.3，設定擴充長度位元時，屬性長度欄位為兩個八位元組，且值應從 value[2] 和 value[3] 讀取為 16 位元大端整數。因此，任何長度超過 255 位元組的屬性都會以無訊息方式截斷為低位元組 （例如，300 位元組 = 0x012C 會讀取為 0x2C = 44 位元組）。然後，剩餘的 256 個位元組被誤解為後續屬性，導致級聯剖析失敗和潛在的越界記憶體存取。（CVE-2026-48685）

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

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

  - SUNRPC： auth_gss：修正 XDR 解碼錯誤路徑中的記憶體洩漏 gssx_dec_ctx（）、gssx_dec_status（） 和 gssx_dec_name（） 函式透過呼叫 kmemdup（） 的 gssx_dec_buffer（） 配置記憶體。當後續解碼作業失敗時，這些函式會立即傳回，而不會釋放先前配置的緩衝區，進而造成記憶體洩漏。gssx_dec_ctx（） 中的洩漏特別相關，因為調用方 （gssp_accept_sec_context_upcall） 將多個緩衝區長度欄位初始化為非零值，從而導致記憶體分配：struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz， .mech.len = GSS_OID_MAX_LEN， .src_name.display_name.len = GSSX_max_princ_sz， .targ_name.display_name.len = GSSX_max_princ_sz };例如，如果 gssx_dec_name（） 對 src_name 成功，但對 targ_name 失敗，則配置給 exported_context_token、mech 和 src_name.display_name 的記憶體將保持未參照且無法回收。使用以 goto 為基礎的清除新增錯誤處理，以在傳回錯誤之前釋放任何先前配置的緩衝區。（CVE-2026-45870）

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

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

  - FastNetMon Community Edition 透過 1.2.9 /tmp 中可預測的檔案路徑，容易受到本機符號連結攻擊。統計資料檔案路徑預設為「/tmp/fastnetmon.dat」（src/fastnetmon.cpp第 159 行）。
    print_screen_contents_into_file（） 函式 （src/fastnetmon_logic.cpp 第 2186 行） 使用 std：：ios：：trunc 開啟此路徑，而不檢查符號連結或使用 O_NOFOLLOW。此外，無論傳遞了哪個 file_path 參數，第 2190 行的 chmod（） 呼叫始終在cli_stats_file_path上運行（一個套用錯誤權限的錯誤），並且在精靈化期間 umask 設定為 0（src/fastnetmon.cpp 第 1821 行），使所有建立的檔案都可以寫入世界。本機攻擊者可利用此弱點，以 FastNetMon 處理程序使用者 （通常是 root） 的身分覆寫任意檔案。（CVE-2026-48693）

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

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

  - hfsplus：當節點已存在於 hfs_bnode_create 時傳回錯誤 當 hfs_bnode_create（） 發現節點已經雜湊 （在正常操作中不應發生） 時，它目前會傳回現有節點，而不會增加其參照計數。這會導致參照計數不一致，導致節點稍後在 hfs_bnode_put（） 中釋放時出現核心錯誤：fs/hfsplus/bnode.c：676！BUG_ON（！atomic_read（&node->refcnt）） 當 hfs_bmap_alloc（） 嘗試配置已在使用的節點時（例如，當節點 0 的點陣圖位元被錯誤地取消設定時）或由於檔案系統損毀時，可能會發生這種情況。從建立路徑傳回現有節點不是正常作業。透過傳回 ERR_PTR（-EEXIST） 而不是已經雜湊的節點來修正此問題。這會正確地向呼叫端發出錯誤狀況訊號，呼叫端已檢查 IS_ERR（） 傳回值。（CVE-2026-45960）

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

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

  - ibmasm：修正 ibmasm_send_i2o_message（） 中的堆積過度讀取 ibmasm_send_i2o_message（） 函數使用 get_dot_command_size（） 來計算 memcpy_toio（） 的位元組計數，但此值衍生自dot_command_header中的使用者控制欄位 （command_size： u8， data_size： u16） ，而且永遠不會根據實際配置大小進行驗證。root 使用者可以寫入具有膨脹標頭欄位的小緩衝區，導致 memcpy_toio（） 在分配結束後讀取最多 ~65 KB 的內容到相鄰的核心堆積中，然後透過 MMIO 將其轉送至服務處理器。以無訊息方式限制副本大小是不夠的：
    如果標頭欄位宣告的大小大於緩衝區，則 SP 會收到一個 dot 命令，其自己的標頭與 I2O 訊息長度不一致，這可能會導致 SP 不同步。傳回失敗，直接拒絕這類命令。在呼叫 get_mfa_inbound（） 之前驗證command_size，以避免洩漏 I2O 訊息框架：讀取INBOUND_QUEUE_PORT會從控制器的可用集區中出列硬體框架，而在沒有對應 set_mfa_inbound（） 呼叫的情況下返回將永久耗盡它。此外，將command_size限制在 memcpy_toio（） 之前的 I2O_COMMAND_SIZE，以便 MMIO 寫入保留在 I2O 訊息框架內，這與 outgoing_message_size（） 已針對標頭欄位執行的限制一致。（CVE-2026-46064）

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

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

  - drm/nouveau：修正 pushbuf 重新定位邊界檢查中的 u32 溢位 nouveau_gem_pushbuf_reloc_apply（） 使用 if （r->reloc_bo_offset + 4 > nvbo->bo.base.size） 驗證每次重新定位，但reloc_bo_offset是__u32 （uapi/drm/nouveau_drm.h），整數常值 4 升級為無符號 int，因此加法以 32 位執行，並在與 size_t bo 大小進行比較之前換行。轉換為 u64，以便以 64 位算術進行加法。[ 新增修正： 標籤。- 達尼洛 ] （）CVE-2026-46006

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

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

  - spi： imx：修正解除綁定時的釋放後使用 SPI 子系統會在取消註冊過程中釋放控制器和任何子系統配置的驅動程式資料 （除非配置是裝置管理） 。在取消註冊控制器之前，先進行另一個參考，以便在驅動程式完成驅動程式資料之前不會釋放驅動程式資料。
    (CVE-2026-45996)

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

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

  - smack： /smack/doi：接受先前使用的值 寫入 /smack/doi 過去曾經寫入過的值會停用非環境標籤的網路。例如 # cat /smack/doi 3 # netlabelctl -p cipso list 已配置的 CIPSO 映射 （1） DOI 值：3 映射類型：PASS_THROUGH # netlabelctl -p 映射列表 已配置的 NetLabel 域映射 （3） 域：_ （IPv4） 協議：未標記域：默認 （IPv4） 協議：CIPSO，DOI = 3 域：默認 （IPv6） 協議：未標記 # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 位元組來自 10.1.95.12：icmp_seq=1 ttl=64 時間=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 來自 10.1.95.12 64 位元組： icmp_seq=1 ttl=64 time=0.956 ms 未知選項 86 # echo 4 >/smack/doi # echo 3 >/smack/doi ！> [ 214.050395] smk_cipso_doi：691 cipso add rc = -17 # echo 3 >/smack/doi ！> [ 249.402261] smk_cipso_doi：678 移除 rc =
    -2 ！> [ 249.402261] smk_cipso_doi：691 cipso 新增 rc = -17 # ping -c1 10.1.95.12 ！！> ping： 10.1.95.12
    不支援主機名稱的位址系列 # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 10.1.95.12位元組來自：icmp_seq=1 ttl=64 time=0.617 ms 發生這種情況是因為 Smack 保留已停用的 DOI，未能重新新增它們，因此拒絕新增預設網域映射： # netlabelctl -p cipso list 已配置的 CIPSO 映射 （2） DOI 值：3 映射類型：PASS_THROUGH DOI 值： 4 映射類型：PASS_THROUGH # netlabelctl -p 映射列表 已配置的 NetLabel 域映射 （2） domain：_ （IPv4） protocol： UNLABELED ！> （此處沒有預設域的 ipv4 映射） domain： DEFAULT （IPv6） protocol： UNLABELED 通過清除已停用的 DOI 定義並使用新鎖序列化並行 DOI 更新來修復。
    另外： - 允許 /smack/doi 處於未配置狀態，因為新增映射 （netlbl_cfg_cipsov4_map_add） 可能會失敗。
    CIPSO_V4_DOI_UNKNOWN（0） 表示未配置的 DOI - 在移除舊的預設映射之前添加新的 DOI，因此如果添加失敗，舊映射仍會保留 （2008-02-04， Casey Schaufler） （CVE-2025-71304）

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

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

  - ceph：只有 d_add（） 負 dentry 未雜湊時 Ceph 可以在主要 dcache 雜湊中已存在的負 dentry 上呼叫 d_add（dentry， NULL）。在當前的 VFS 中，這是不安全的。
    d_add（） 經過 __d_add（） 到 __d_rehash（），這會無條件地將 dentry->d_hash 重新插入 hlist_bl 儲存桶。如果 dentry 已雜湊，則重新插入相同的節點可能會損毀儲存區，包括建立自我迴圈。一旦發生這種情況，__d_lookup（） 可以在hlist_bl遍歷中永遠旋轉，通常僅在 d_name.hash 不匹配檢查時循環，並最終觸發 RCU 停止報告，如下所示： rcu： INFO：rcu_sched CPU 上自我偵測到的停止 rcu：87-....：（此 GP 為 2100 個 tick） idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu：（t=2101 jiffies g=79058445 q=698988 ncpus=192） CPU： 87 UID：2952868916 PID：3933303 通訊：php-cgi8.3 未受污染 6.18.17-i1-amd #950 無 硬體名稱：Dell Inc. PowerEdge R7615/0G9DHV， BIOS 1.6.6 09/22/2023 RIP：0010：__d_lookup+0x46/0xb0 代碼：c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f348 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP：
    0018：ff745a70c8253898 EFLAGS：00000282 RAX：ff26e470054cb208 RBX：ff26e470054cb208 RCX：000000006e958966 RDX：ff26e48267340000 RSI：ff745a70c82539b0 RDI：ff26e458f74655c0 RBP：000000006e958966 R08：
    0000000000000180 R09： 9cd08d909b919a89 R10： ff26e458f74655c0 R11： 000000000000000000 R12： ff26e458f74655c0 R13： ff745a70c82539b0 R14： d0d0d0d0d0d0d0 R15： 2f2f2f2f2f2f2f2f FS： 00007f5770896980（0000） GS：ff26e482c5d88000（0000） knlGS：00000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：
    00007f5764de50c0 CR3： 000000a72abb5001 CR4： 0000000000771ef0 PKRU： 55555554 呼叫追蹤： <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e 重複使用的快取負齒列可實現此目的。Ceph 查詢或atomic_open可以傳遞一個已經雜湊的負 dentry，然後 fs/ceph/dir.c 命中兩個路徑之一，這些路徑錯誤地假設負也意味著未雜湊： - ceph_finish_lookup（）：MDS 回覆為 -ENOENT，沒有追蹤 -> d_add（dentry， NULL） - ceph_lookup（）：具有共用上限的完整目錄的本機 ENOENT 快速路徑 -> d_add（dentry， NULL） 因此，兩條路徑都可以重新新增已雜湊的負 dentry。Ceph 已在其他地方使用正確的模式：
    ceph_fill_trace（） 僅在 d_unhashed（dn） 為 true 時呼叫 d_add（dn， NULL） 以取得負 null-dentry 回覆。
    以相同的方式修正兩個 fs/ceph/dir.c 網站：僅在負 dentry 實際未雜湊時呼叫 d_add（）。如果負 dentry 已雜湊，請將其保留在原處並按原樣重複使用。這會保留未雜湊 dentry 的現有行為d_hash同時避免重複使用的雜湊負值的清單損毀。（CVE-2026-46052）

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

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

  - rbd：當 device_add_disk（） 失敗時，修正 null-ptr-deref do_rbd_add（） 會在呼叫 device_add_disk（） 之前使用 device_add（） 發佈裝置。如果 device_add_disk（） 在 device_add（） 成功後失敗，則錯誤路徑會直接呼叫 rbd_free_disk（），然後失敗至 rbd_dev_device_release（），後者會再次呼叫 rbd_free_disk（）。這種雙重拆卸可能會使 blk-mq 清理在無效狀態下運行，並在 __blk_mq_free_map_and_rqs（） 中觸發 null-ptr-deref，從 blk_mq_free_tag_set（） 到達。請遵循正常的移除順序來修正此問題：當 device_add_disk（） 在 device_add（） 之後失敗時，在 rbd_dev_device_release（） 之前呼叫 device_del（）。如此可保持拆卸順序一致，並避免透過錯誤路徑重新進入磁碟清理。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。我們在 v7.0 上重現了這個錯誤，使用真正的 Ceph 後端和啟用 KASAN 和 CONFIG_FAILSLAB 啟動的 QEMU x86_64客體。再現器將 failslab 注入限制在 __add_disk（） 範圍內，並在透過 /sys/bus/rbd/add_single_major 映射 RBD 映像時注入 fail-nth。在未修補的核心上，fail-nth=4 可靠地觸發了錯誤：哎呀：
    一般保護錯誤，可能用於非規範位址 0xdffffc0000000000： 0000 [#1] SMP KASAN NOPTI KASAN： null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU： 0 UID： 0 PID： 273 Comm： bash 未受污染 7.0.0-01247-gd60bc1401583 #6 搶佔（延遲） 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009）， BIOS 1.15.0-1 04/01/2014 RIP： 0010：__blk_mq_free_map_and_rqs+0x8c/0x240 代碼： 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 0000 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP：0018：ff1100000ab0fac8 EFLAGS：00000246 RAX：dffffc00000000000 RBX：ff1100000c4806a0 RCX：000000000000000000 RDX：0000000000000002 RSI：
    000000000000000000 RDI：ff11000000c4806f4 RBP：00000000000000000000 R08：0000000000000001 R09：ffe21c000189001b R10：ff1100000c4800df R11：ff1100006cf37be0 R12：00000000000000000 R13：0000000000000000：000000000000000：000000000000000 R14：000000000000000：000000000000000：0000000000000000：000000000000：0000000000000：000000000000：000000000000：000000000000：0000000000000：000000000000：00000000000000：000000000000000：00000000000000：0000000000000：000000000000：0000000000000：0000000000000：00000000000：000000000
    ff1100000c480700 R15： ff1100000c480004 FS： 00007f0fbe8fe740（0000） GS：ff110000e5851000（0000） knlGS：00000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00007fe53473b2e0 CR3：
    0000000012eef000 CR4： 00000000007516f0 PKRU： 55555554 呼叫追蹤： <TASK> blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ？ __pfx_do_rbd_add+0x10/0x10 ？ lock_acquire+0x18c/0x300 ？ find_held_lock+0x2b/0x80 ？ sysfs_file_kobj+0xb6/0x1b0 ？ __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ？ expand_files+0x51f/0x850 ？
    __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ？__pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：0033：0x7f0fbea15907 代碼：10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 4889 54 24 18 48 89 74 24 RSP：002b：00007ffe22346ea8 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：ffffffffffffffda RBX：0000000000000058 RCX：00007f0fbea15907 RDX：
    0000000000000058 RSI：0000563ace6c0ef0 RDI：0000000000000001 RBP：0000563ace6c0ef0：0000563ace6c0ef0R09：6b6435726d694141R10：5250337279762f78R11：0000000000000246R12：0000000000000058R13：R08
    00007f0fbeb1c780 R14： ff1100000c480700 R15： ff1100000c480004 </TASK> 套用此修正後，在 fail-nth=1..256 上重新執行轉發器不會產生任何 KASAN 報告。[ idryomov：重新命名 err_out_device_del -> err_out_device ]（CVE-2026-46079）

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

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

  - KVM： nSVM：在 L2 的 VMRUN 之後，將中斷影子同步到快取的 vmcb12 在客體模式下進行 VMRUN 之後，nested_sync_control_from_vmcb02（） 會將 CPU 寫入的欄位從 vmcb02 同步到快取的 vmcb12。這是因為快取的 vmcb12 會用作某些控制項的授權複本，並且是儲存/還原巢狀狀態時的承載。int_state也由 CPU 寫入，特別是位元 0 （即
    SVM_INTERRUPT_SHADOW_MASK） 中，但不會同步至快取的 vmcb12。如果還原路徑中KVM_SET_NESTED_STATE先於KVM_SET_VCPU_EVENTS，這不會造成問題，因為中斷陰影會正確還原至 vmcb02 （KVM_SET_VCPU_EVENTS會覆寫KVM_SET_NESTED_STATE在 int_state 中還原的內容）。但是，如果 KVM_SET_VCPU_EVENTS 先於KVM_SET_NESTED_STATE，則中斷陰影將還原至 vmcb01 而非 vmcb02。這對於 L1 （延遲中斷） 來說大多是良性的，但對於 L2 則不然。對於 L2，vCPU 可能會停擺 （例如，如果喚醒中斷在 HLT 之前傳遞，而 HLT 本應處於中斷陰影中）。將int_state同步至 nested_sync_control_from_vmcb02（） 中快取的 vmcb12 以避免此問題。這樣，KVM_SET_NESTED_STATE還原正確的中斷影子狀態，如果KVM_SET_VCPU_EVENTS隨後，它會用相同的值覆蓋它。（CVE-2026-45987）

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

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

  - net： bridge：在 RCU 讀取器中使用穩定的 FDB dst 快照 「fdb_delete_local（）」可以就地重寫本機 FDB 項目，「（）」會將「f->dst」更新到另一個連接埠或「NULL」，同時保持項目處於活動狀態。
    數個橋接器 RCU 讀取器會透過 'brforward_read（）' sysfs 路徑檢查 'f->dst'，包括 'br_fdb_fillbuf（）'。這些讀取器目前會多次載入「f->dst」，因此可以在檢查和稍後的解除參照中觀察到不一致的值。在 'br_fdb_fillbuf（）' 中，這表示並行的 local-FDB 更新可以在 NULL 檢查之後和 'port_no' 解除參照之前變更 'f->dst'，從而導致 NULL-ptr-deref。透過在每個受影響的 RCU 讀取器中拍攝「f->dst」的單一「READ_ONCE（）」快照，並將該快照用於其餘的存取序列來解決此問題。此外，在 'fdb_delete_local（）' 中使用 'WRITE_ONCE（）' 發佈就地 'f->dst' 更新，讓讀取器和寫入器使用相符的存取模式。
    (CVE-2026-46086)

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

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

  - crypto： authencesn - 在執行個體建立期間拒絕短 ahash 摘要 authencesn 需要零驗證大小或至少 4 個位元組的驗證大小，因為 ESN 加密/解密路徑一律會在已驗證資料的結尾移動 4 個位元組的高階序號資料。雖然 crypto_authenc_esn_setauthsize（） 已經拒絕 1..3 範圍內的明確非零 authsizes，但 crypto_authenc_esn_create（） 仍然將 auth->digestsize 複製到 inst->alg.maxauthsize 中，而不進行驗證。然後，AEAD 核心會從該值初始化 tfm 的預設驗證大小。因此，選取摘要大小為 1..3 的 ahash （例如 cbcmac（cipher_null） 會暴露預設驗證大小無效的 authencesn 執行個體，即使 setauthsize（） 會拒絕相同的值。然後，AF_ALG可能會使用太短的標籤觸發 ESN 尾部處理並擊中越界存取。拒絕 ahash 摘要大小在無效非零範圍 1..3 中的 authencesn 執行個體，以便任何 tfm 都無法繼承不支援的預設驗證大小。（CVE-2026-46033）

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

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

  - iio： sca3000：修正 sca3000_probe（） spi->irq 中的資源洩漏問題，此問題來自 iio_device_register（） 失敗時未釋放的 request_threaded_irq（）。新增傳回值檢查，並在 iio_device_register（） 失敗時跳至常見錯誤處理常式。（CVE-2026-45883）

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

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

  - KVM：nSVM：如果還原主機 CR3 在巢狀 #VMEXIT 上失敗，則發生三重錯誤 如果在巢狀 #VMEXIT 上載入 L1 的 CR3 失敗，則 nested_svm_vmexit（） 會傳回大多數呼叫端忽略的錯誤碼，並繼續以損毀狀態執行 L1。在此情況下，無法進行合理的復原，而硬體行為會導致關機。改為注入三重錯誤，並且不要提前從 nested_svm_vmexit（） 返回。繼續清理 vCPU 狀態 （例如清除擱置中的例外狀況），以盡可能正常地處理失敗。來自 APM：#VMEXIT 時，處理器會執行下列動作，以返回主機執行內容：...if （載入非法主機狀態，或載入主機狀態時出現異常） shutdown else 執行 VMRUN 之後的第一條主機指令 移除 nested_svm_vmexit（） 的傳回值，無論如何，該傳回值大多未選中。（CVE-2026-46032）

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

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

  - FastNetMon Community Edition through 在 1.2.9 NetFlow v9 資料流程集處理器中包含越界讀取弱點。在 src/netflow_plugin/netflow_v9_collector.cpp 中，資料範本分支 （行 1695-1702） 會反覆運算流程記錄，而不針對封包端點執行每次反覆運算的邊界檢查。相反地，選項範本分支 （行 1709-1719） 會在每次反覆運算之前正確檢查「if （pkt + offset + field_template->total_length > packet_end）」。「資料」分支會完全省略此檢查。由於範本定義是由網路對等體傳送 （並且是未經驗證的 UDP），因此攻擊者可以製作範本，使剖析器讀取通過封包緩衝區的任意記憶體。這可能會洩漏敏感記憶體內容或導致當機。（CVE-2026-48683）

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

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

  - zram：不要忘記對部分捨棄要求進行 endio 正如 Qu Wenruo 和 Avinesh Kumar 所報告的那樣，以下 getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 實際上需要很長時間才能完成。zram 不支援部分捨棄，只是立即返回，在這種情況下不執行任何捨棄工作。
    問題是我們在離開時忘記了 endio，所以 blkdiscard 永遠沉睡在 submit_bio_wait（） 中。
    透過跳轉到標籤來解決此問題end_bio標籤，該標籤會執行 bio_endio（）。（CVE-2026-46089）

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

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

  - ASoC： nau8821： 取消元件移除的延遲工作 在千斤頂偵測工作擱置時嘗試卸載驅動程式，可能會在最終排定執行核心時當機： [1984.896308] 錯誤：無法處理位址的頁面錯誤： ffffffffc10c2a20 [...][ 1984.896388] 硬體名稱：Valve Jupiter/Jupiter，BIOS F7A0131 01/30/2024 [ 1984.896396] 工作佇列：事件nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP：0010：__mutex_lock+0x9f/0x11d0 [...][ 1984.896504] 呼叫追蹤： [1984.896511] <TASK> [ 1984.896524] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ？ srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 取消排程外的jdet_work，或等待其執行完成後再移除元件驅動程式。CVE-2026-45963）

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

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

  - media：amphion：修正 m2m job_abort 和 device_run 之間的爭用 修正由爭用情形引起的核心錯誤，其中 v4l2_m2m_ctx_release（） 釋放m2m_ctx而 v4l2_m2m_try_run（） 即將呼叫具有相同上下文的 device_run。爭用序列：v4l2_m2m_try_run（）：v4l2_m2m_ctx_release（）：鎖定/解鎖 v4l2_m2m_cancel_job（） job_abort（） v4l2_m2m_job_finish（） kfree（m2m_ctx） <- 釋放 ctx device_run（） <- 0x538 時釋放後使用當機 當機追蹤：無法處理從虛擬位址 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 的不可讀記憶體讀取核心 amphion vpu 驅動程式不依賴 m2m 架構的device_run回呼來執行編碼/解碼作業。透過完全阻止 m2m 架構工作排程來修正爭用：- 新增傳回 0 的job_ready回呼 （沒有為 m2m 架構準備的工作）
    - 移除job_abort回呼以避免爭用情形 （CVE-2026-46058）

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

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

  - ALSA： control：在 snd_ctl_elem_init_enum_names（） 中 strnlen（） 之前驗證 buf_len snd_ctl_elem_init_enum_names（） 將指標 p 推進 names 緩衝區，同時遞減 buf_len。如果buf_len達到零，但項目仍然存在，則下一次反覆運算會呼叫 strnlen（p， 0）。雖然 strnlen（p， 0） 傳回 0 並會命中現有的 name_len == 0 錯誤路徑，但 CONFIG_FORTIFY_SOURCE 的強化 strnlen（） 會先針對 __builtin_dynamic_object_size（） 檢查 maxlen。當 Clang 在迴圈內遺失 p 的物件大小時，這會在檢查傳回值之前觸發 BRK 例外狀況錯誤。在迴圈項目新增 buf_len == 0 防護，以防止在耗盡的緩衝區上呼叫強化的 strnlen（）。透過小米智慧型手機進行核心模糊測試發現。（CVE-2026-46088）

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

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

  - netfilter： nf_conncount：將連接清理限制增加到 64 在優化為每次僅執行一次 GC 之後，引入了一個新問題。如果快速追蹤超過 8 個新連線，則清單的清理速度不夠快，可能會錯誤地達到限制。為了防止此問題，只有在GC已在同一瞬間觸發，且增量低於清理限制時，才跳過GC。此外，將清理限制增加到 64 個連線，以避免過於頻繁地觸發 GC，並執行更有效的 GC。這已使用 HTTP 伺服器和數個效能工具進行測試，同時設定了 nft_connlimit/xt_connlimit 或 OVS 限制。52000 個連線時的 slowhttptest + OVS 限制的輸出：第 340 秒的慢速 HTTP 測試狀態：初始化中：0 擱置中：432 已連接：51998 錯誤：0 關閉：0 可用服務：是 （CVE-2026-45860）

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本在 BGP AS_PATH 屬性編碼器中包含整數溢位。在 src/bgp_protocol.hpp 中，IPv4UnicastAnnounce::get_attributes() 函式會按照 sizeof(bgp_as_path_segment_element_t) + this->as_path_asns.size() * sizeof(uint32_t) 計算 attribute_length，並將其存入一個 uint8_t 欄位 (第 600-605 行)。由於 uint8_t 只能保存 0-255 的值，因此包含超過 63 個 ASN 的 AS_PATH (2 + 64*4 = 258 > 255) 會導致無訊息截斷。截斷的長度用於緩衝區大小調整，而實際寫入的資料是完整的未截斷量，因此會導致堆積緩衝區溢位。類似地，第 621 行的 path_segment_length 欄位也是 uint8_t 類型，當 ASN 超過 255 個時會被截斷。(CVE-2026-48691)

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

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

  - drm/display/dp_mst：新增針對 0 vcpi 的保護：釋放時隙時，如果 delayed_destroy_work 在 DP 2.1 監視器中斷連線後最終發揮作用，導致 vcpi 變為 0，則我們可能會因溢位而產生錯誤的有效負載遮罩，然後我們嘗試使有效負載 = ~BIT（vcpi - 1），這是一個負偏移。VCPI ID 永遠不應該真正為 0，因此如果 VCPI 為 0，則跳過變更負載遮罩。否則會導致 <7> [515.287237] xe 0000：03：00.0：
    [drm：drm_dp_mst_get_port_malloc [drm_display_helper]] 連接埠 ffff888126ce9000 （3） <4> [515.287267]
    -----------[ 從此處剪下 ]----------- <3> [515.287268] UBSAN：../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 處發生移位越界 <3> [515.287271] 移位指數 -1 為負數 <4> [515.287275] CPU：7 UID：0 PID：3108 通訊：kworker/u64:33 已污染：G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT（自願）<4> [515.287279] 已污染：[S]=CPU_OUT_OF_SPEC，[U]=使用者 <4> [515.287279] 硬體名稱：ASUS 系統產品名稱/PRIME Z790-P WIFI，BIOS 1645 2024/03/15 <4> [515.287281] 工作佇列：drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] 呼叫追蹤：<4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 (CVE-2025-71305)

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

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

  - mm/vmalloc：可以從兩個路徑同時叫用 Shrinker decay_va_pool_node（） 中的 take vmap_purge_lock：清除集區時的 __purge_vmap_area_lazy（），以及透過 vmap_node_shrink_scan（） 的 Shrinker。
    然而，decay_va_pool_node（） 並發運行並不安全，而且縮減器路徑目前缺乏序列化，導致爭用和可能的洩露。透過在壓縮器路徑中進行vmap_purge_lock來保護 decay_va_pool_node（），以確保與清除使用者一起序列化。（CVE-2026-46093）

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

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

  - ata： libata-scsi：避免非 NCQ 指令匱乏 當執行 NCQ 指令時發出非 NCQ 指令時，ata_scsi_qc_issue（） 會向 SCSI 層指示應傳回 SCSI_MLQUEUE_XXX_BUSY 來延遲發出指令。此命令延遲是正確的，並且符合ACS規範的規定，因為NCQ和非NCQ命令不能混合使用。但是，在使用多個提交佇列的主機配接卡的情況下，當目標裝置處於 NCQ 命令的持續負載下時，無法保證稍後會執行將非 NCQ 命令重新排入佇列，並且可能會重複延遲，因為其他提交佇列可能會不斷地在非 NCQ 命令之前從不同的 CPU 發出 NCQ 命令。這可能會導致非 NCQ 命令的執行延遲很長，甚至在最壞的情況下完全耗盡這些命令。由於區塊層和 SCSI 層不區分可排入佇列 （NCQ） 和不可排入佇列 （non-NCQ） 命令，因此 libata-scsi SAT 實作必須確保在存在 NCQ 指令流量的情況下，非 NCQ 指令的前送進度。
    這類似於具有硬體/韌體型 SAT 實作的 SAS HBA 所做的事情。透過限制來自 ata_scsi_qc_issue（） 的非 NCQ 命令重新排隊來實作此類前向進度保證：當收到非 NCQ 命令且 NCQ 命令正在進行中時，不要透過傳回 SCSI_MLQUEUE_XXX_BUSY 來強制非 NCQ 命令重新排隊，而是傳回 0 以表示命令已被接受，但使用 struct ata_port 的新 deferred_qc 欄位保留 qc。一旦所有進行中的命令完成，就會使用工作項目deferred_qc_work執行函式 ata_scsi_deferred_qc_work （） 發出此延遲的 qc，並使用埠 qc_defer（） 回呼傳回值進行檢查，指出不需要進一步延遲。此檢查是使用從 ata_scsi_qc_complete（） 呼叫的協助函式 ata_scsi_schedule_deferred_qc（） 來完成的。因此，這會從 ATA EH 發出的所有內部非 NCQ 命令中排除此機制。當埠deferred_qc為非空時，亦即埠具有等待裝置佇列清空的命令，則會使用一般忙碌機制延遲發出所有傳入命令 （NCQ 及非 NCQ）。這簡化了程式碼，還可以避免在使用者發出過多非 NCQ 命令時潛在的拒絕服務問題。最後，每當排程 ata EH 時，無論原因為何，延遲的 qc 一律會重新排入佇列，以便在 EH 完成後重試。這是透過從 ata_eh_set_pending（） 呼叫函數 ata_scsi_requeue_deferred_qc（） 來完成的。這避免了在 NCQ 錯誤、鏈路或設備重置或設備逾時的情況下對延遲的 qc 進行任何特殊處理。
    (CVE-2026-45855)

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

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

  - apparmor：修正未設定export_binary時對 rawdata 的無效解除參照 如果在執行階段停用 export_binary 參數，則在此之前載入的設定檔仍會將其原始資料儲存在 apparmorfs 中，並在原則目錄上提供指向原始資料的符號連結。替換其中一個設定檔時，rawdata 會設定為 NULL，但當嘗試解析該設定檔的 rawdata 的符號連結時，當 profile->rawdata 現在為 NULL 時，它會嘗試取消參照 profile->rawdata->name ，從而導致 oops。透過檢查是否設定了 rawdata 來修復它。[ 168.653080] 錯誤：核心 NULL 指標解除參照，位址：
    0000000000000088 [ 168.657420] #PF：核心模式下的主管讀取存取權 [ 168.660619] #PF：
    error_code（0x0000） - 不存在頁面 [ 168.663613] PGD 0 P4D 0 [ 168.665450] 哎呀：哎呀：0000 [#1] SMP NOPTI [ 168.667836] CPU：1 UID：0 PID：1729 通訊：ls 未受污染 6.19.0-rc7+ #3 PREEMPT（自願） [168.672308] 硬體名稱：QEMU Ubuntu 24.04 PC （i440FX + PIIX， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP： 0010：rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] 代碼： 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 4883 EC 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP：
    0018：ffffcdcb8200fb80 EFLAGS： 00010282 [ 168.690871] RAX： ffffffffaee74ec0 RBX： 0000000000000000000 RCX：
    ffffffffb0120158 [ 168.692251] RDX：ffffcdcb8200fbe0 RSI：ffff88c187c9fa80 RDI：ffff88c186c98a80 [168.693593] RBP：ffffcdcb8200fbc0 R08： 0000000000000000 R09： 000000000000000000 [ 168.694941] R10：
    0000000000000000000 R11： 000000000000000000 R12： ffff88c186c98a80 [ 168.696289] R13： 00007fff005aaa20 R14：
    0000000000000080 R15： ffff88c188f4fce0 [ 168.697637] FS： 0000790e81c58280（0000） GS：ffff88c20a957000（0000） knlGS：00000000000000000 [ 168.699227] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [ 168.700349] CR2：
    0000000000000088 CR3： 000000012fd3e000 CR4： 0000000000350ef0 [ 168.701696] 呼叫追蹤： [ 168.702325] <TASK> [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] ] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ？ do_statx+0x72/0xb0 [168.711109] ？ putname+0x3e/0x80 [ 168.711845] ？ __x64_sys_statx+0xb7/0x100 [ 168.712711] ？ x64_sys_call+0x10fc/0x26b0 [ 168.713577] ？ do_syscall_64+0xbf/0x500 [ 168.714412] ?do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ？ irqentry_exit+0xb2/0x740 [ 168.716359] ？ exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-45965）

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

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

  - net： caif：拆卸時清除用戶端服務指標 'caif_connect（）' 可以在遠端關機後呼叫 'caif_disconnect_client（）' 後接 'caif_free_client（）' 來卸除現有用戶端。
    'caif_free_client（）' 會釋放 'adap_layer->dn' 所引用的服務層，但會讓該指標保持過時狀態。當通訊端稍後遭到破壞時，'caif_sock_destructor（）' 會再次呼叫 'caif_free_client（）' 並解除參照釋放的服務指標。釋放服務物件之前，請先清除用戶端/服務連結，讓重複的拆卸變得無害。（CVE-2026-46098）

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

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

  - ALSA： usb-audio：停止剖析 MAX_NR_RATES parse_uac2_sample_rate_range（） 處的 UAC2 速率會將列舉速率的數量限制為 MAX_NR_RATES，但它只會跳出目前的速率迴圈。具有額外三元組的格式錯誤的 UAC2 RANGE 響應繼續解析剩餘的三元組，並在探針仍保持register_mutex時重複打印無效的 uac2 速率。一旦達到上限，就停止整個剖析，並傳回目前收集的費率數目。（CVE-2026-46018）

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

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

  - net： strparser：修正 strp_abort_strp（） 中的skb_head洩漏 當資料流剖析器中止時 （例如在訊息組合逾時之後），它仍然可以在 strp->skb_head 中保留對部分組合訊息的參照。該 skb 不會在 strp_abort_strp（） 中釋放，這會洩漏部分組合的訊息，並且可以重複觸發以耗盡記憶體。透過釋放 strp->skb_head 並在中止路徑中重設剖析器狀態來修正此問題。保持 strp_stop（） 不變，以便在工作和計時器同步後仍會在 strp_done（） 中進行最終清理。（CVE-2026-46102）

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

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

  - ext4：修正 ext4_xattr_inode_dec_ref_all（） 中缺少的 brelse（） 提交 c8e008b60492 （ext4：忽略過去的 xattrs） 在 block_csum 為 false 時引入了參照計數洩漏。ext4_xattr_inode_dec_ref_all（） 呼叫 ext4_get_inode_loc（） 來取得 iloc.bh，但從不使用 brelse（） 釋放它。（CVE-2026-46046）

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本的 BGP NLRI (網路層可達性資訊) 解碼器中包含一個堆疊型緩衝區溢位弱點。src/bgp_protocol.cpp 中的函式 decode_bgp_subnet_encoding_ipv4_raw() 直接從 BGP 封包 (第 99 行) 讀取prefix_bit_length，而不驗證 IPv4 前置詞是否 <= 32。此值會被傳遞至 how_much_bytes_we_need_for_storing_certain_subnet_mask()，該函式會計算 ceil(prefix_bit_length / 8)，導致對於 prefix_bit_length 為 255 的情況最多返回 32 個位元組。這個返回值會被用作 memcpy() 的長度引數 (第 106 行)，而 memcpy() 會將數據複製到大小為 4 位元組的 uint32_t 堆疊變數 (prefix_ipv4) 中。這會導致最多 28 位元組發生堆疊緩衝區溢位，而攻擊者則可藉此來執行任意程式碼。此外，未經驗證的 prefix_bit_length 會被傳遞至 convert_cidr_to_binary_netmask_local_function_copy() (第 111 行)，其中當 cidr > 32 時，(32 - cidr) 的移位會導致未定義的行為。(CVE-2026-48686)

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

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

  - rxrpc： 修正 conn 層級封包處理以取消共用 RESPONSE 封包 驗證 RESPONSE 封包的安全作業會就地解密其中的位元 - 但是，sk_buff可能會與封包嗅探器共用，這會導致嗅探器看到明顯損毀的封包 （實際上已解密）。如果封包已複製，請將封包副本交給特定安全性處理常式，以修正此問題。
    (CVE-2026-46000)

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

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

  - ext4：分割範圍失敗時捨棄範圍快取 當分割範圍失敗時，我們可能會讓某些範圍仍在處理中，並直接傳回錯誤，這會導致過時的範圍項目保留在範圍狀態樹狀結構中。因此，如果分割失敗，請捨棄所有剩餘的潛在過時範圍。（CVE-2026-45899）

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

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

  - Ceph：修正加密配置失敗時的 num_ops 差一錯誤 move_dirty_folio_in_page_array（） 如果檔案已加密、已變更的對開本不是批次中的第一個，且無法配置退回緩衝區來保存密文，則可能會失敗。發生這種情況時，ceph_process_folio_batch（） 只會重新弄髒對開本並排清目前批次 -- 它可以在未來的批次中重試該對開本。但是，如果這個失敗的對開本與最後一個進入批次的對開本不相鄰，則 ceph_process_folio_batch（） 已經遞增了「ceph_wbc->num_ops」;因為它沒有跟進並將不連續的作品集添加到陣列中，所以 ceph_submit_write（） -- 它期望 'ceph_wbc->num_ops' 準確地反映回寫中連續範圍的數量 （因此所需的寫入範圍操作數量） -- 會使核心恐慌：BUG_ON（ceph_wbc->op_idx + 1 ！= req->r_num_ops）;此問題可在受影響的核心上重現，方法是以 4KiB 寫入/4KiB 跳過/重複模式寫入已啟用 fscrypt 的 CephFS 檔案 （檔案大小總大小無關緊要），並逐漸增加系統的記憶體壓力，直到反彈緩衝區配置失敗為止。當 move_dirty_folio_in_page_array（） 失敗時，將 'ceph_wbc->num_ops' 遞減回正確值，但對開本已開始計算新的 （亦即仍為空白） 範圍，藉此修正此損毀。此修補程式更正的缺陷自 2022 年以來一直存在（請參閱第一個「修正：」），但另一個錯誤直到最近才阻止多對開加密回寫（請參閱第二個「修正：」）。第二次提交進入 6.18.16了 、 6.19.6和 7.0-rc1，揭開了這些版本中的錯誤。因此，此修補程式修正了由 cac190c7674f 引入的迴歸 （錯誤）。（CVE-2026-46066）

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

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

  - drm/exynos： vidi：修正以避免直接解除參照使用者指標 在 vidi_connection_ioctl（） 中，vidi->edid（使用者指標） 在核心中直接解除參照。這允許從使用者空間存取任意核心記憶體，因此我們應該修改它，而不是直接存取核心中的使用者指標，而是使用 copy_from_user（） 將 edid 複製到核心記憶體並使用它。（CVE-2026-45958）

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

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

  - mfd：亞利桑那州：修正 wm5102_clear_write_sequencer（） 失敗時的調節器資源洩漏 wm5102_clear_write_sequencer（） 協助程式可能會傳回錯誤並返回，繞過清理序列並導致調節器保持啟用狀態，從而導致資源洩漏。將直接返回變更為跳至err_reset標籤，以適當釋放資源。（CVE-2026-45875）

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

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

  - ipv4： icmp：使用 icmp_pointers 之前先驗證回覆類型 延伸回應回覆會使用 ICMP_EXT_ECHOREPLY 作為出埠回覆類型。該值超出了 所涵蓋 icmp_pointers[]的範圍，它僅描述了最多 NR_ICMP_TYPES 的傳統 ICMP 類型。避免諮詢 icmp_pointers[] 超出該範圍的回覆類型，並使用 array_index_nospec（） 進行其餘的範圍內查詢。一般 ICMP 回覆會維持其現有行為不變。（CVE-2026-46037）

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

ID	名稱	嚴重性
317233	Linux Distros 未修補的弱點：CVE-2026-46075	high
317232	Linux Distros 未修補弱點：CVE-2026-45948	medium
317231	Linux Distros 未修補弱點：CVE-2026-45852	high
317230	Linux Distros 未修補弱點：CVE-2026-46056	high
317229	Linux Distros 未修補弱點：CVE-2026-45912	medium
317228	Linux Distros 未修補弱點：CVE-2026-46062	high
317227	Linux Distros 未修補的弱點：CVE-2026-46083	medium
317226	Linux Distros 未修補弱點：CVE-2026-45970	high
317225	Linux Distros 未修補的弱點：CVE-2026-46004	high
317224	Linux Distros 未修補的弱點：CVE-2026-45954	medium
317223	Linux Distros 未修補弱點：CVE-2026-45994	high
317222	Linux Distros 未修補弱點：CVE-2026-46054	high
317221	Linux Distros 未修補的弱點：CVE-2026-45885	high
317220	Linux Distros 未修補的弱點：CVE-2026-48685	medium
317219	Linux Distros 未修補弱點：CVE-2026-45870	medium
317218	Linux Distros 未修補的弱點：CVE-2026-48693	medium
317217	Linux Distros 未修補的弱點：CVE-2026-45960	medium
317216	Linux Distros 未修補弱點：CVE-2026-46064	high
317215	Linux Distros 未修補弱點：CVE-2026-46006	high
317214	Linux Distros 未修補弱點：CVE-2026-45996	high
317213	Linux Distros 未修補弱點：CVE-2025-71304	medium
317212	Linux Distros 未修補的弱點：CVE-2026-46052	high
317211	Linux Distros 未修補的弱點：CVE-2026-46079	medium
317210	Linux Distros 未修補的弱點：CVE-2026-45987	medium
317209	Linux Distros 未修補弱點：CVE-2026-46086	medium
317208	Linux Distros 未修補的弱點：CVE-2026-46033	high
317207	Linux Distros 未修補弱點：CVE-2026-45883	medium
317206	Linux Distros 未修補弱點：CVE-2026-46032	medium
317205	Linux Distros 未修補的弱點：CVE-2026-48683	medium
317204	Linux Distros 未修補弱點：CVE-2026-46089	medium
317203	Linux Distros 未修補的弱點：CVE-2026-45963	medium
317202	Linux Distros 未修補弱點：CVE-2026-46058	high
317201	Linux Distros 未修補的弱點：CVE-2026-46088	medium
317200	Linux Distros 未修補弱點：CVE-2026-45860	high
317199	Linux Distros 未修補弱點：CVE-2026-48691	critical
317198	Linux Distros 未修補弱點：CVE-2025-71305	medium
317197	Linux Distros 未修補的弱點：CVE-2026-46093	high
317196	Linux Distros 未修補的弱點：CVE-2026-45855	medium
317195	Linux Distros 未修補弱點：CVE-2026-45965	medium
317194	Linux Distros 未修補弱點：CVE-2026-46098	medium
317193	Linux Distros 未修補的弱點：CVE-2026-46018	medium
317192	Linux Distros 未修補弱點：CVE-2026-46102	high
317191	Linux Distros 未修補的弱點：CVE-2026-46046	medium
317190	Linux Distros 未修補弱點：CVE-2026-48686	critical
317189	Linux Distros 未修補弱點：CVE-2026-46000	medium
317188	Linux Distros 未修補的弱點：CVE-2026-45899	medium
317187	Linux Distros 未修補的弱點：CVE-2026-46066	medium
317186	Linux Distros 未修補弱點：CVE-2026-45958	high
317185	Linux Distros 未修補弱點：CVE-2026-45875	medium
317184	Linux Distros 未修補弱點：CVE-2026-46037	high

偵測

Nessus 的 Misc. 系列

high

medium

high

high

medium

high

medium

high

high

medium

high

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

medium

medium

high

medium

high

critical

medium

high

medium

medium

medium

medium

high

medium

critical

medium

medium

medium

high

medium

high