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

  - ipv4：修正 fib_nhc_update_mtu（） 中的釋放後使用 fib_nhc_update_mtu（） 遍歷 RTNL 下的 nexthop 異常表，但 RTNL 不會使用 PMTU 異常更新序列化此遍歷。遍歷使用具有常數 true 條件的 rcu_dereference_protected（），而不保留 fnhe_lock。因此可能會發生下列交錯： CPU 0 CPU 1 fib_nhc_update_mtu（） update_or_create_fnhe（） 載入 fnhe spin_lock_bh（&fnhe_lock） fnhe_remove_oldest（） 取消連結 fnhe kfree_rcu（fnhe， rcu） <quiescent state> 寬限期後存取 fnhe KASAN 報告： 錯誤： KASAN：fib_nhc_update_mtu+0x3df/0x410 中的 slab-use-after-free 任務 poc/90 在 addr ffff888107d49000 讀取大小 8 呼叫追蹤： fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 同樣的步行更新fnhe_pmtu和fnhe_mtu_locked。這些欄位會形成一對，其他寫入器會用 fnhe_lock 序列化它們。RCU 本身可防止回收，但仍允許並行寫入器離開混合配對。遍歷 RCU 下的資料表，並僅在更新每個例外狀況時取得fnhe_lock。RCU 會讓目前項目保持活動狀態，而短關鍵區段會序列化其配對的 PMTU 欄位。這可避免在掃描每個下一躍點的所有 2048 儲存貯體時保持全域鎖定。（CVE-2026-74656）

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

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

  - net： thunderbolt：在停止環之前拆除 DMA 路徑 tbnet_tear_down（） 會在呼叫 tb_xdomain_disable_paths（） 之前停止兩個環並釋放其框架緩衝區。tb_ring_stop（） 將環的描述元基數歸零，tbnet_free_buffers（） 取消映射並釋放框架所在的頁面，因此
    __tb_path_deactivate_hop（） 輪詢躍點的「擱置」位，任何仍在飛行中的東西都無處可排出。自從新增驅動程式以來，拆卸順序一直按此順序排列。設定路徑沒有：
    commit ff7cd07f3064 （net： thunderbolt： 僅在啟用環後啟用 DMA 路徑） 將啟用路徑移至 tbnet_connected_work（） 的末尾，並記錄原因： /* 兩次登入都成功，因此啟用環、高速 DMA * 路徑並啟動網路裝置佇列。* * 請注意，我們最後啟用 DMA 路徑，以確保在允許任何傳入封包 * 到達之前，我們已啟動 * Rx 環。*/ 拆解從未更新以匹配，因此環和路徑現在以與上升的順序相同的順序下降，而不是反向下降。在 ASMedia ASM4242 主機路由器上，「擱置」位永遠不會清除：每次拆卸都會燃燒完整的 500 毫秒逾時，並且 __tb_path_deactivate_hop（） 傳回 -ETIMEDOUT。將逾時時間提高到 5 秒無濟於事，因此啤酒花的排出速度並不慢，它根本不會排出。故障在雷電核心上方是看不見的。__tb_path_deactivate_hops（） 為 void，僅調用 tb_port_warn（）;tb_path_deactivate（）、tb_tunnel_deactivate（） 和 __tb_disconnect_xdomain_paths（） 也是無效的，tb_disconnect_xdomain_paths（） 以無條件返回 0 結尾。因此，tb_xdomain_disable_paths（） 報告成功，而其下面的 netdev_warn（） 永遠不會觸發。重複的拆卸最終會使 XDomain 控制通道關閉，之後對等節點消失，只有重新啟動電源才能使控制器恢復。
    停用路徑會先修正此問題。在未套用其他修補程式的庫存 v6.17 樹上使用 kretprobes 測量，在已啟動且剛剛承載流量的鏈路上：之前：__tb_path_deactivate_hop（） 為第一跳返回 0，然後為第二個500335返回 -ETIMEDOUT，之後：兩者為 0，相距 525 我們 在三個負載層級上交替兩個排序 ABBA， 每隻手臂四次拆解：每次拆解在更改前都失敗（21 次運行中的 21 次），在更改後沒有一次失敗（0 次中的 24 次）。前臂不足，因為鏈接在中途失效。當介面被束縛而不是僅僅被關閉時，就會出現同樣的分裂，這就是我最初遇到這種情況的原因。變更後的輸送量和延遲時間不變。儘管描述元基底過時，其路由器仍排空躍點的主機看不到功能差異，因為路徑最終會以任何一種方式停用。（CVE-2026-74691）

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

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

  - 跟蹤：修正模組事件快取移除中的 NULL 指標解除參照 當尚未載入 foo 時，僅限模組的事件篩選器 （例如 ：mod：foo） 會以 NULL event_mod->match 快取。如果稍後的寫入嘗試從相同模組中移除特定相符項目，則 remove_cache_mod（） 會將 NULL 快取相符項目傳遞至 strcmp（），從而造成 NULL 指標解除參照。此問題可從使用者空間重現：echo '：mod：trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '！foo_bar：mod：trace_events_kunit_missing' >> /sys/kernel/tracing/set_event 第二次寫入必須是串聯 （>>），以不包含O_TRUNC，因為這會導致 ftrace_clear_events（） 清除快取的模組行。當機在 x86_64 QEMU 上重現，而 KUnit 工作者則在事件追蹤路徑上爭用： 錯誤：核心 NULL 指標解除參照，位址：0000000000000000 #PF：核心模式下的主管讀取存取權 RIP：0010：strcmp+0x10/0x30 呼叫追蹤：__ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f 在比較之前檢查 event_mod->match，與快取系統和事件欄位的現有 NULL 檢查一致。不相符的移除會繼續傳回 -EINVAL;廣泛的快取模組篩選器會使用 ！：mod：<module> 移除。
    (CVE-2026-74633)

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

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

  - smb： client：修正 cifs_try_adding_channels（） 中的釋放後使用 cifs_try_adding_channels（） 在丟棄介面之前會暫時參照介面iface_lock。如果 cifs_ses_add_channel（） 失敗，它會刪除該參照，然後遞增 iface->weight_fulfilled。並行介面清單重新整理可以在通道建立進行時移除清單參照。在此情況下，失敗路徑 kref_put（） 會釋放最後一個參照並釋放 iface。之後更新weight_fulfilled然後存取釋放的記憶體。
    在刪除臨時參照之前遞增 weight_fulfilled，使 iface 在最終存取時保持活動狀態。（CVE-2026-74608）

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

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

  - serial： 8250_of：LPC32xx 上清除卡住的空 FIFO RX 逾時 NXP LPC32xx UART （PORT_LPC3220） 可以在 RX FIFO 為空時鎖定 RX 字元逾時中斷：IIR 報告 UART_IIR_RX_TIMEOUT （0x0c），但 LSR。DR 很清楚。只有透過讀取 RHR 才能清除字元逾時，但 serial8250_rx_chars（） 只有在 LSR 時才會讀取 RHR。DR 已設定，因此沒有任何內容可以清除條件。中斷是層級觸發並立即重新觸發的，因此在單核心 ARM926 上，產生的中斷風暴會使 CPU 活鎖。當使用者空間重複開啟前面板連接埠 （ttyS1） 時，它是可重現的：serial8250_do_set_termios（） 在解鎖時重新啟用中斷，然後處理常式以 iir=0xcc lsr=0x60 ier=0x05 永遠旋轉，從而觸發 serial8250_handle_irq_locked（） 中的軟鎖定偵測器。LPC32xx 沒有專用的 8250 膠水驅動器，它由通用8250_of驅動。為 PORT_LPC3220 新增硬體特定的handle_irq，以與安裝fsl8250_handle_irq相同的方式在 of_platform_serial_setup（） 中連線。處理常式遵循 dw8250_handle_irq（）：在具有空白 FIFO （LSR） 的 RX 逾時時。DR 和 LSR。BI 清除），它會執行一次一次性 RHR 讀取以清除條件，然後呼叫 serial8250_handle_irq_locked（）。不會捨棄任何實際接收的資料，並且對於從不報告 DR 清除逾時的正常 UART 來說，這是無操作的。這是其他 8250 驅動程式中已經解決的同一類錯誤;請參閱提交 424D79183af0 （序列號：8250_dw：避免虛假 rx 逾時中斷造成過多工作），其中報告相同的 iir=0xcc/lsr=0x60。另請參閱 8250_omap 中的UART_RX_TIMEOUT_QUIRK和 8250_bcm7271 中的註釋。（CVE-2026-74653）

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

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

  - drm/v3d：序列化排程器逾時處理常式 V3D 會公開數個獨立的硬體佇列 （BIN、RENDER、TFU 和 CSD），但只有單一全域重設。因此，任何一個佇列上的逾時也必須停止、重設及重新啟動其他佇列的排程器。這使得並行逾時處理常式不安全。'reset_lock' 永遠無法確保它們安全，因為驅動程式側鎖只能覆蓋驅動程式的 &drm_sched_backend_ops.timedout_job 回呼。排程器會處理逾時作業及其擱置清單，位於驅動程式的控制範圍之外，因此一個佇列所觸發的全域重設仍可能干擾另一個佇列，該佇列正在處理自己的逾時。
    因此，如果在 CL 密集型應用程式執行時在 CSD 佇列中發生重設，則當該佇列處理自己的逾時時，廣域重設會停止並重新啟動 CL 佇列的排程器。當 drm_sched_stop（） 和 drm_sched_start（） 減去並新增位於它們所呼叫的排程器擱置清單上的每一個工作的功件時，當 CL 佇列的處理常式同時將其工作從相同的清單中取出並將它放回原處時，停止和開始不再看到同一組工作。CL 佇列在飛行中的積分數量超過其限制： [ 327.302739] ------------[ 切到此處 ]------------ [327.302744] 警告： CPU：2 PID：43 at drivers/gpu/drm/scheduler/sched_main.c：102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU：2 UID：0 PID：43 Comm：kworker/u16：1 未受污染 6.18.39-v8-16k+ #3 搶佔 [ 327.302889] 硬體名稱：Raspberry Pi 5 Model B Rev 1.0 （DT） [327.302893] 工作佇列： v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] 呼叫追蹤：[ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] （P） [ 327.302997] process_scheduled_works+0x180/0x3d0 [327.303010 ] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ 結束追蹤 00000000000000000 ]--- 從那時起，CL 佇列的點數計數就會中斷，導致 GPU 完全懸置和 UI 凍結。DRM 排程器已經提供了一種機制來序列化不同排程器的逾時處理常式：作為 drm_sched_init（） 的 @timeout_wq 參數傳遞的有序工作佇列。依預設，每一個排程器都會在系統工作佇列上將其逾時工作排入佇列，而系統工作佇列會同時執行處理常式。改為為所有佇列提供共用的有序工作佇列，如 DRM 排程器文件所建議的，適用於具有不同佇列但全域重設的硬體。（CVE-2026-74638）

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

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

  - bpf： 修正 conntrack kfuncs 中的 netns 參照不平衡 BPF conntrack kfuncs 的 opts 引數可以指向共用映射值。__bpf_nf_ct_lookup（） 和 __bpf_nf_ct_alloc_entry（） 在取得和釋放網路命名空間參照時分別讀取 opts->netns_id。參照不平衡可能發生如下： CPU 0 CPU 1 讀取 opts->netns_id （-1） 跳過 get_net_ns_by_id（） 寫入 opts->netns_id （id） 讀取 opts->netns_id （id） put_net（net） /* 沒有相符的 get */ 反向轉換會洩漏參照。
    重複不相符的放置可能會破壞即時命名空間並使後續使用者當機。核心報告：哎呀：
    一般保護錯誤，可能用於非規範位址 KASAN：範圍內 null-ptr-deref [0x00000000000000e8-0x00000000000000ef] RIP：0010：bpf_prog_test_run_xdp+0x52c/0x1700 呼叫追蹤：
    __sys_bpf+0x1662/0x50c0 __x64_sys_bpf+0x73/0xb0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f 核心錯誤 - 未同步：嚴重異常 在驗證或使用選項之前，先使用 READ_ONCE（） 對其進行快照。netns_id 快照會讓命名空間 get/put 配對保持平衡，而其他快照則可防止其餘選項在叫用中途變更。個別讀取在並行更新期間仍可觀察到不一致的組合，但每個選取的欄位值對於該呼叫都會保持穩定。（CVE-2026-74715）

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

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

  - 之前的 3.10.2 nltk 版本在 IPIPANCorpusReader 方法中包含一個符號連結型任意檔案讀取弱點，可完全繞過 nltk.pathsec 驗證。攻擊者可以在語料庫根目錄中放置符號鏈接，並通過調用具有符號鏈接文件名的 channels（）、domains（）、categories（） 或 fileids（） 方法來讀取處理程序可訪問的任意文件。（CVE-2026-62383）

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

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

  - mm/ptdump：始終穩定使用init_mm釋放頁面表格 先前的提交已建立在持有 mmap 讀取鎖定init_mm時執行核心頁面表格釋放的不變量，這修正了 ptdump 和核心頁面表格之間的爭用，釋放init_mm。但是，x86 和 arm64 可以通過 ptdump_walk_pgd（） 對 init_mm 以外的 mm 執行 ptdump，並且由於核心內存範圍在非內核 mm 之間共享，這意味著在這些情況下仍然存在爭用。透過取得 ptdump_walk_pgd（） 中 init_mm 的巢狀 mmap 寫入鎖定來修正此問題。這是安全的，因為我們在 mmap 寫入鎖定 mm 之後採用此操作，並且在鎖定任意 mm 之前，沒有任何東西會先取得 init_mm 鎖定，因此不可能發生死鎖。同時更新 walk_page_range_debug（） 以斷言 init_mm 被寫入鎖定，新增註解解釋原因並刪除一些冗餘程式碼，並消除不必要且令人困惑的 walk_kernel_page_table_range（） 叫用。我們可以安全地刪除 walk.mm 的非 NULL 檢查，因為如果是，mmap 鎖斷言將 NULL 指標解除參照（當然沒有調用者這樣做）。ptdump 可以爭用核心頁面表格釋放的第一個點是提交 b6bdb7517c3d （mm/vmalloc：新增介面以釋放未映射的頁面表格），因此我們在 Fixes 標籤中針對此目標。（CVE-2026-74599）

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

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

  - mm/damon/ops-common：在無效移轉 nid damon_pa_migrate（） 和 damos_va_migrate（） 上放回對開本，將對開本隔離到本機清單中，然後呼叫 damon_migrate_pages（）。當target_nid無效時 （包括配置預設 NUMA_NO_NODE / -1），damon_migrate_pages（） 會提前傳回，而不會將作品集放回 LRU。然後，呼叫者會捨棄清單標頭，而這些對開本則保持隔離狀態，並由 folio_isolate_lru（） 取得額外的參照。只要映射存在，頁面就會遠離 LRU （anon active+inactive 計數會下降，而 RSS 則不會），並且剩餘的引用可以在映射消失後固定頁面。將對開本放回 invalid-nid 路徑，讓略過的移轉要求仍會將它們傳回 LRU。（CVE-2026-74644）

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

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

  - net/sched： sch_cake：針對 ACK 篩選器中格式錯誤的封包，丟棄 WARN_ON（1） sch_cake ACK 篩選器會剖析封包以尋找 TCP 標頭，並在流量積壓時篩選重複的 ACK。剖析程式碼包含一個 WARN_ON（1），在某些情況下，它可以由格式錯誤的 IP 標頭觸發。視系統設定而定，這會導致向 dmesg 發送帶有警告的垃圾郵件，或者如果設定了 panic_on_warn，則會導致錯誤。程式碼已經正確地跳過了觸發警告的分支中的違規封包，因此WARN_ON本身並沒有真正起到任何作用。因此，只需將其完全放棄即可，以避免不方便的副作用。（CVE-2026-74704）

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

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

  - TLS：不要保留完整的純文字sk_msg環未推送 當 tls_sw_sendmsg_locked（） 中的複製路徑新增填入純文字sk_msg環的片段時，它不會設定full_record，因此記錄會保持完整且未推送。然後，稍後的 splice（） 會新增至已經完整的環：sk_msg_page_add（） 本身沒有完整度檢查，因此 sg.end 會換行到 sg.start 上，並且環顯示為空。之後新增的片段會覆寫即時項目，並且 sg.size 不再符合 sg.start 和 sg.end 之間可存取的內容，因此推送記錄會從散點清單的末尾執行散佈。無權限的使用者可以在附加了 tls ULP 的回送 TCP 通訊端上觸發此觸發： 錯誤：核心 NULL 指標解除參照，位址：
    0000000000000008 RIP：0010：memcpy_from_scatterwalk+0x32/0xc0 呼叫追蹤：skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0
    __sys_sendto+0x1da/0x1f0 當環已滿時，在複製路徑中設定full_record，並將進入 sendmsg 迴圈時已滿的記錄推送至 sendmsg 迴圈。（CVE-2026-74610）

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

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

  - USB：misc：usbio：根據大量訊息中的rxbuf_len檢查 ibuf_len ibuf_len是大量 IN （接收） 緩衝區大小，但 usbio_bulk_msg（） 中的 EMSGSIZE 簽入會將其與大量 OUT 端點大小txbuf_len進行比較。兩者都是獨立於 usbio_probe（） 中的不同端點取得的，因此當它們不同時，檢查是錯誤的。對 IN 方向使用 rxbuf_len。這會符合實際保存回應資料的緩衝區。（CVE-2026-74681）

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

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

  - ip6_tunnel：清除 ip6ip6_err（） 中的 skb2->cb[] ip6ip6_err（） 複製外部 IPv6 ICMP 錯誤 skb，將其提取到引號內的內部 IPv6 封包，然後將複製傳遞給 icmpv6_send（）。複製仍在 skb->cb 中攜帶外部封包的inet6_skb_parm。如果外部封包具有主位址選項，則 IP6CB（skb2）->dsthao 在 skb_pull（） 之後仍為非零。icmpv6_send（） 稍後會呼叫 mip6_addr_swap（），它會針對引號的內部封包使用過時的 dsthao 偏移量。然後，格式錯誤的內部 destination-options 標頭可能會使 HAO 查詢和位址交換運行超過引號封包的結尾並損壞skb_shared_info。在提取引號的內部 IPv6 封包之前，請清除 skb2->cb[]，以便回覆路徑不會重複使用外部 IPv6 堆疊留下的中繼資料。（CVE-2026-74597）

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

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

  - net/packet：重設封包通訊端傳輸路徑上的 MAC 標頭 packet_parse_headers（） 只會針對通訊端未綁定通訊協定的 SOCK_RAW 框架重設 MAC 標頭。因此，協定綁定的 SOCK_RAW 通訊端、任何SOCK_DGRAM框架和舊版SOCK_PACKET路徑在此處未設定 skb->mac_header。對於透過 __dev_queue_xmit（） 傳送的框架，這是無害的：它會無條件地重設 MAC 標頭。但是封包通訊端PACKET_QDISC_BYPASS路徑使用 dev_direct_xmit（），但沒有，因此框架會在未設定 MAC 標頭的情況下到達 ndo_start_xmit（）。在傳輸時讀取 eth_hdr（skb） 的驅動程式然後解除參照 skb->head + （u16）~0，一個越界存取 ~64 KiB 越過頭部 -- 在提交 f5089008f90c 中為一個消費者固定的相同類別（macsec：不要讀取 macsec_encrypt（）） 中未設定的 MAC 標頭）。
    packet_parse_headers（） 僅在傳輸路徑上運行，其中 skb->data 指向每個封包通訊端類型的 L2 標頭的開頭，無論其長度如何：SOCK_RAW 和 SOCK_PACKET 攜帶使用者提供的標頭，而 SOCK_DGRAM 有一個由 dev_hard_header（） 建置的標頭。無條件地重設 MAC 標頭，鏡像 __dev_queue_xmit（），以便框架也錨定在旁路路徑上。由 0sec （https://0sec.ai） 使用自動來源分析找到;根據來源進行驗證，並與 f5089008f90c 中的 macsec KASAN 報告相符。經過編譯測試。（CVE-2026-74667）

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

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

  - usb：gadget： f_ncm：使用 unsigned int 進行ndp_index變數 ndp_index 宣告為有符號整數，但它儲存了 get_ncm（） 的傳回值，該值是無符號的。惡意主機可以提供較大的偏移量，使已簽名的ndp_index溢位，使其變成負數。由於ndp_index會與無符號邊界進行比較，因此此負值會繞過健全性檢查，並在計算 NDP 區塊位址時導致越界讀取 （ntb_ptr + ndp_index）。透過將 ndp_index 變更為 unsigned int 來修正此問題，以確保整個函式的 unsigned 比較一致。（CVE-2026-74679）

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

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

  - net/sched：拒絕過深的 qdisc 階層 過深的 qdisc 階層會導致 qdisc 樹狀結構遍歷器中過度遞迴，並耗盡核心堆疊。現有迴圈檢查未涵蓋建立及移接路徑，因此仍可透過在已深層的母項下建立新的子 qdisc 來延伸階層。將階層深度儲存在結構 Qdisc 中，並在嫁接 qdisc 時更新它。一旦父項已達到允許的深度上限，就拒絕新的子 qdisc。（CVE-2026-74663）

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

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

  - 跟蹤：修正 update_event_fields 和 event_define_fields 之間的爭用 以下順序可能會導致 event_define_fields（） 和 update_event_fields（） 之間的爭用： CPU0 （載入模組 A） CPU1 （載入模組 B） =============================== =============================== load_module（A） load_module（B） notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock（&event_mutex） trace_event_update_all（） trace_module_add_events（A） down_write（&trace_event_sem） __register_event（call_A）
    __add_event_to_tracers（call_A） event_define_fields（call_A） 對於每個 f： list_for_each_entry（field， list_add（&f->link， &class->fields， link） &class->fields） field = class->fields->next;其中對類別>欄位的存取不受 trace_event_update_all（） 中的event_mutex保護。這會產生下列錯誤： 無法處理核心存取...在虛擬位址0000000000000018電腦：
    update_event_fields+0xf8/0x368 通話追蹤：update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c
    __arm64_sys_finit_module+0x230/0x31c 透過在 trace_event_sem 之前在 trace_event_update_all（） 中進行event_mutex來修正。CVE-2026-74636

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

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

  - ring-buffer：停用調整大小時，防止 subbuf 順序變更 因為 ring_buffer_subbuf_order_set（） 會釋放緩衝區頁面，所以停用調整大小時，我們不能允許它。非耗用式讀取器有釋放後使用 （rb_advance_iter（）） 的風險。在 resize_disabled 上傳回 -EBUSY，符合 ring_buffer_resize（） 行為。
    (CVE-2026-74634)

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

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

  - ptp： ocp：修正板 ID 過度讀取 EEPROM 板 ID 是固定的 13 位元組欄位，不保證包含 NUL 終止符。將其直接傳遞給 devlink_info_version_fixed_put（） 會將其視為 C 字串，並且可能會讀取超出欄位的內容。在報告標識碼之前，最多將 OCP_BOARD_ID_LEN 個位元組格式化為現有的本機緩衝區。使用精確度限制，因為 snprintf（） 輸出大小本身並不會限制來源字串掃描。CVE-2026-74603

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

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

  - vhost-scsi：端點 vhost_scsi_setup_vq_cmds（） 從 VHOST_SCSI_SET_ENDPOINT 執行後拒絕功能變更，並根據確認的 VIRTIO_SCSI_F_T10_PI 位元配置每個命令的保護散佈清單陣列 （prot_sgl）。當VHOST_SET_FEATURES稍後變更時，不會重建命令集區。雖然 virtio 功能位元在功能協商後不得變更，但 vhost_scsi_set_features（） 目前會在端點處於活動狀態並更新acked_features後接受此類請求。因此，在端點設定後啟用 -PI 會 T10保留 prot_sgl NULL，而 I/O 路徑會遵循新功能位。對於 129 頁的保護負載，vhost_scsi_mapal（） 將缺少的第一個區塊傳遞給 sg_alloc_table_chained（）：sg_alloc_table_chained（table， 129， first_chunk=NULL， nents_first_chunk=inline_sg_cnt） sg_pool_index（） 然後命中： BUG_ON（nents > SG_CHUNK_SIZE）;/* 129 > 128 */ 核心報告下列呼叫追蹤和暫存器狀態： 呼叫追蹤： <TASK> ？
    __sg_alloc_table+0x1d8/0x250 ？__pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ？__pfx_sg_pool_alloc+0x10/0x10 ？vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ？
    __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 </TASK> RIP：
    0010：0x4 CR2 = 0x4 RSP：0018：ffffc90000dbf940 EFLAGS：00010202 RAX：ffffffff82396810 RBX：ffff88811dc28b80 RCX：0000000000000000000 RDX：0000000000000000000000 RSI：0000000000000820 RDI：0000000000000081 VHOST_F_LOG_ALL 是虛擬主機特定的執行階段功能，並且仍然是唯一的例外。拒絕在端點處於作用中狀態時對 VHOST_F_LOG_ALL 以外的任何功能的變更。這會保留現有的執行階段記錄切換，同時防止功能相依的命令資源和資料路徑狀態變得不一致。使用者空間必須先清除端點，才能變更任何其他協商功能，然後重新設定端點。（CVE-2026-74702）

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

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

  - net/mlx5e：修正 SQ 重新啟用時的 BQL 重設 mlx5e_queue_start（） 停用並重新啟用所有通道，但僅關閉正在重新啟動的佇列。然後，mlx5e_activate_txqsq（） 無條件調用 netdev_tx_reset_queue（），將保持其飛行中 TX WQE 的通道的 BQL 計數器歸零。然後，下一次完成會過度充電並觸發 dql_completed（） 中的 BUG_ON（）：lib/dynamic_queue_limits.c：99 的核心錯誤！RIP：0010：dql_completed+0x23d/0x280 呼叫追蹤： <IRQ> mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 僅當 SQ 沒有正在傳輸的位元組時重設 BQL （sq->cc == sq->pc）。如果跳過重設，未完成的 WQE 最終會完成並重新平衡 dql。dql->limit 會在整個重設過程中進行。（CVE-2026-74698）

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

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

  - ovl：從另一個使用者命名空間完成掛載時，不要發出警告 fsopen（） 會在 fc->user_ns 中記錄呼叫端的使用者命名空間，並交回一般檔案描述元。沒有任何內容會將呼叫 fsconfig（FSCONFIG_CMD_CREATE） 的作業繫結至建立內容的作業。fd 在 fork（） 和 exec（） 之間繼承，並且可以通過 unix 通訊端傳遞。故意允許從另一個使用者命名空間完成內容。vfs_cmd_create（） 使用 mount_capable（） 授權建立，對於FS_USERNS_MOUNT檢查 ns_capable（fc->user_ns， CAP_SYS_ADMIN），並且對於在 fc->user_ns 的祖先中保存CAP_SYS_ADMIN的任務會成功。因此，無權限的任務可以到達 ovl_fill_super（） 中的 WARN_ON（）：在子項中建立使用者和掛載命名空間，在那裡調用 fsopen（overlay），將 fscontext fd 發送給父項，然後讓父項FSCONFIG_CMD_CREATE發出問題。這兩個命名空間都來自普通的 unshare（1），在任何地方都不需要任何功能： 警告：fs/overlayfs/super.c：1551 在 ovl_fill_super+0x7b9/0x1e20 [overlay] CPU：3 UID：1000 PID：3243376 通訊：fswarn 呼叫追蹤：get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 子項需要掛載命名空間，因為 fsopen（） 本身在 may_mount（） 上門禁， 這會要求在擁有呼叫端掛載命名空間的使用者命名空間中CAP_SYS_ADMIN。fsconfig（） 不會重複此檢查。它是 WARN_ON（） 而不是 WARN_ON_ONCE（），因此可以在迴圈中引發該條件以污染核心並溢流日誌，並且它會使使用 panic_on_warn 啟動的核心出現錯誤。繼續拒絕安裝並停止警告。
    ovl_parse_param（） 已經以這種方式拼寫了使用者命名空間檢查以進行Opt_override_creds。（CVE-2026-74619）

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

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

  - 暫存：rtl8723bs：修正 WMM_param_handler（） 中的 OOB 讀取 WMM_param_handler（） 會從接收的資訊元素中複製固定大小的 WMM 參數元素，而不檢查該元素是否足夠長，從而導致短 WMM IE 的越界讀取。處理常式在 pIE->data + 6 處讀取 sizeof（struct WMM_para_element） （18） 位元組，因此它要求 pIE->length 至少為 24 （WLAN_WMM_LEN），但它永遠不會驗證長度。在呼叫處理常式之前，其三個呼叫端中的兩個只會比對 WMM OUI 之後到達它：rtw_mlme_ext.c 中的 OnAssocRsp（） 會比對 6 位元組的 OUI，而 join_cmd_hdl（） 會比對 4 位元組的 OUI。
    具有 WMM OUI 但長度介於 6 到 23 之間的廠商特定 IE，放置在關聯回應中或交給 join_cmd_hdl（） 的 IE blob 中，通過 OUI 檢查，然後在 pIE->data + 6 讀取過元素結尾時進行 memcmp（） 和 memcpy（）。OnAssocRsp（） 會剖析從 AP 接收的框架，因此可從遠端對等體存取此框架。rtw_wlan_util.c 中的其餘呼叫端已使用 pIE->length == WLAN_WMM_LEN 保護處理常式。將對等檢查移至處理常式本身，以便涵蓋每個呼叫端;同一剖析迴圈中的同級 IE 處理常式 （HT_caps_handler（）、HT_info_handler（）、ERP_IE_handler（）） 同樣以 pIE->length 綁定其存取。（CVE-2026-74650）

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

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

  - net/sched： act_gact， act_police： 範圍檢查後援控制動作 tcf_action_check_ctrlact（） 範圍檢查主要控制動作： if （！opcode） ret = action > TC_ACT_VALUE_MAX ？-EINVAL：0;
    TC_ACT_VALUE_MAX 是TC_ACT_TRAP的，因此無法以這種方式設定其上方的核心內部判定。但 act_gact 和 act_police 各自帶有第二個獨立的控制操作，該操作由使用者空間提供，永遠不會到達該協助程式 - TCA_GACT_PROB.paction 和 TCA_POLICE_RESULT。兩者都只會拒絕TC_ACT_GOTO_CHAIN，因此任何其他值都會逐字儲存，並從動作逐字傳回。特別是使用者空間可以儲存TC_ACT_CONSUMED，這是 TC_ACT_VALUE_MAX + 1，並且故意不屬於 UAPI 值範圍的一部分。該判決告訴每個呼叫者，該操作獲得了 skb 的所有權，因此沒有人釋放它：sch_handle_ingress（）、sch_handle_egress（） 和 tcf_qevent_handle（） 都故意跳過它的釋放。結果是一個洩漏的sk_buff加上每個遍歷過濾器的資料緩衝區，對於鏈上的所有流量（包括核心產生的封包），都是無限的。兩者都是微不足道的確定性。act_gact將tcfg_pval限制為 >= 1，因此當 pval = 1 時，gact_determ（） 會傳回每個封包的後援。act_police 沒有強制速率，因此 rate = 0 會留下 tcfp_mtu = ~0，並且 tcf_police_mtu_check（） 始終通過。TC_ACT_CONSUMED是由提交 720f22fed81b （net：sched：重構重新插入動作） 新增的，在寫入兩個 goto-chain 保護之後：提交 9469f375ab09 （net/sched： act_gact：在後援控制動作上禁止「goto chain」） 和提交 c08f5ed5d625 （net/sched： act_police：在後援控制動作上禁止「goto chain」）。當新判決出現時，兩人的防守都沒有擴大。將 tcf_action_check_ctrlact（） 中的現有範圍測試分解為 tcf_action_valid（），並將其套用至這兩個後援。協助程式無法直接呼叫 tcf_action_check_ctrlact（），因為這也會配置goto_chain，這正是這兩個網站不得執行的動作。在 v7.2-rc6 上重現：kmemleak 報告一個洩露的 232 位元組 skbuff_head_cache 物件，加上每個封包的 704 位元組資料緩衝區。使用此修補程式時，這兩個設定都會被拒絕
    -EINVAL 和 kmemleak 沒有報告。（CVE-2026-74620）

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

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

  - soc：aspeed：lpc-snoop：修正 snoop_file_read put_fifo_with_discard（） 中的使用者複製溢位在 kfifo 上充當生產者和消費者：它從 IRQ 處理常式呼叫 kfifo_skip（） （前進）和 kfifo_put（） （前進），而不與 snoop_file_read（） 同步，而 （） 也透過 kfifo_to_user（） 消費。在 SMP 系統上，此並行存取可能會使 （in - out） 大於環形緩衝區，因此 __kfifo_to_user（） 的 clamp to （in - out） 無效，並且 kfifo_copy_to_user（） 可以嘗試通過 kmalloc-2k 備份儲存區的 copy_to_user（）：usercopy：從 SLUB 物件「kmalloc-2k」（偏移量 0，大小 2049）偵測到核心記憶體暴露嘗試！mm/usercopy.c 的核心錯誤！呼叫追蹤：usercopy_abort
    __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read 使用 IRQ 處理常式 （生產者） 和檔案讀取器 （消費者） 之間共用的每個通道微調鎖，序列化 kfifo 存取。使用 __guarded_by（&lock） 註解@fifo，並將驅動程式選擇加入內容分析，以便編譯器強制所有 FIFO 存取都持有鎖定。（CVE-2026-74729）

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

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

  - hwmon： （ltc4282） 箝位負電流限制 當負值傳遞給 ltc4282_write_curr（） 時，帶正負號的長 val 會直接轉換為 u64： drivers/hwmon/ltc4282.c：ltc4282_write_curr（） { /* 需要以毫伏為單位傳遞 */ u32 in = DIV_ROUND_CLOSEST_ULL（（u64）val * st->rsense， DECA * MICRO）; ... }此轉換會將負輸入轉換為較大的正值。隨後的除法結果使變數中的 u32 溢出，截斷為偽隨機正值。當將其傳遞給 ltc4282_write_voltage_byte（） 時，它被限制為最大限制而不是零。在轉換之前將 val 限制為 0 並達到支援的最大上限，並在除法之前將結果指派給 64 位暫存變數，以避免反向溢位和可能的溢位。（CVE-2026-74685）

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

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

  - net/atm：修正 vcc_setsockopt（） 中的 slab-out-of-bounds 讀取 vcc_setsockopt（） 包含無效的 optlen 檢查：if （__SO_LEVEL_MATCH（optname， level） &; optlen ！= __SO_SIZE（optname）） return -EINVAL;如果
    __SO_LEVEL_MATCH（optname， level） 的評估結果為 false （例如，如果調用方傳遞了不相符的級別），則長度檢查 optlen ！= __SO_SIZE（optname） 被短路並繞過。然後執行失敗到 switch（optname），假設 optval 包含足夠的空間，調用 copy_from_sockptr（）。此外，即使層級相符，cgroup BPF setsockopt 篩選器也可能在輸入後縮小 optlen。由於核心指標上的 copy_from_sockptr（） 使用 memcpy（），因此當 optlen 小於預期的結構大小時，這會導致 KASAN slab-out-of-bounds 讀取。使用 copy_safe_from_sockptr（） 來修正此問題，在複製之前，它會無條件地驗證 optlen 至少是預期的大小。此外，將本機 'value' 變數類型從 'unsigned long' 變更為 'int'，以便 SO_SETCLP 符合其在 64 位元系統上的 sizeof（int） ABI 編碼。（CVE-2026-74689）

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

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

  - mm/vmalloc：在巨大的 vmap 上取得 init_mm 鎖定以避免 ptdump UAF 修補程式系列 mm：修正由 ptdump 和 vmap pgtable 釋放之間爭用引起的 UAF，v6。核心頁面表格走行器分為兩大類：不需要透過 walk_kernel_page_table_range_lockless（） 排除的範圍，以及需要透過 walk_kernel_page_table_range（） 或 walk_page_range_debug（） 排除的範圍。前一個類別僅供在其完全擁有且不同時寫入的範圍內運行的 arm64 arch 代碼使用。
    後一個類別是由核心頁面表格遍歷程式所組成，這些核心頁面表格遍歷程式在全資擁有的範圍上運作 （但需要針對並行寫入器排除）。用於排除的鎖是 mmap 鎖，對於核心範圍，這是 init_mm 上的 mmap 鎖。ptdump 是一種特殊情況，它既是 walk_page_range_debug（） 的唯一用戶，也是它遍歷它不擁有的範圍的唯一情況。這會帶來問題，因為頁面表格可能會在 ptdump 下被釋放。因此，核心中確實存在釋放後使用錯誤，本系列解決了這個問題。vmap 會盡可能將頁面表格提升為大型分葉項目，並在這樣做時釋放較低的頁面表格。它這樣做時沒有針對並行 ptdump 遍歷持有有意義的鎖定。因此，目前可能會發生釋放後使用。本系列透過讓 vmap 大型升級邏輯取得 mmap 讀取鎖定，同時設定大型頁面表格項目和釋放先前的分葉頁面表格來解決這個問題。ptdump 程式碼已經取得 mmap 寫入鎖定，因此透過這樣做，我們可以確保 ptdump walker 只觀察巨大的頁面表格項目或現有的頁面表格項目，並且在其下方沒有釋放任何內容。已針對提交 fa93b45fd397 中的 arm64 套用此問題的緩解措施 （arm64：使用 ptdump 啟用 vmalloc-huge），本系列必須仔細處理。如果 ptdump 正在進行中，此緩解措施會取得 vmap 頁面表格上空閒init_mm mmap 讀取鎖定來解決此問題。但是，如果我們只是將其應用於 arm64 而不還原更改，則此系列中的修復將導致鎖死。這是因為 vmap 可能會在 ptdump 嘗試取得寫入鎖定之前取得讀取鎖定，然後寫入鎖定會排入佇列，而 rwsem 飢餓規則表示 arm64 程式碼中的 （未確認） 巢狀 mmap 讀取鎖定也會封鎖，這表示原始讀取鎖定永遠不會釋放，因此鎖死。本系列透過在 vmap 邏輯中 #ifndef CONFIG_ARM64 mmap 讀取鎖定，然後部分還原提交 fa93b45fd397 （arm64：
    使用 ptdump 啟用 vmalloc-huge），保持對大型 vmap 支援的啟用，並使用部分還原修補程式移除 ifdeffery。本系列也會解決一些相關問題： * x86 頁面屬性邏輯，特別是變更頁面屬性 （CPA），實作一項功能，可將巨大的範圍摺疊成巨大的分葉項目。當與 ptdump 遍歷並行完成時，這同樣會導致 UAF，因此類似地獲取 init_mm mmap 鎖以避免這種情況。* CPA 邏輯允許並行頁面表格操作和 CPA 摺疊，這表示前者有存取頁面表格的風險，後者會釋放。藉由在整個 CPA 摺疊作業中取得 init_mm mmap 寫入鎖定，並在頁面表格操作上取得讀取鎖定，以修正此問題。* x86 和 arm64 允許非核心 mm 的遍歷 （兩者都允許 efi mm 遍歷，在 x86 的情況下允許任意 mm），因此我們透過鎖定 init_mm 以及正在遍歷的 mm 來確保核心映射保持穩定。修補程式的順序是針對嚴格的相依性（特別是必須在 vmap 變更後完成 arm64 部分還原）和邏輯相依性（非核心 mm 修正只有在 vmap/CPA 修正到位後才有意義）建立的。這個補丁（共 3 個）：目前有一個討厭的 ra ---truncated--- （CVE-2026-74672）

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

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

  - 輸入：evdev - 修正 evdev_pass_values（） 中的資訊洩露 在 evdev_pass_values（） 中，input_event結構被分配在核心堆疊上，並逐欄位填入。但是，它永遠不會完全初始化。在結構input_event包含明確或隱含填補的架構上 （例如 32 位元 __pad 欄位 SPARC64on），這些填補位元組會保持未初始化狀態。當此事件結構隨後傳遞至用戶端緩衝區，然後複製到使用者空間時，未初始化的填充位元組會洩漏核心堆疊記憶體，進而可能暴露敏感資訊。類似的問題也存在於以下領域
    __evdev_queue_syn_dropped和__pass_event。透過在填入其欄位之前使用 memset（） 明確將整個事件結構歸零來解決此問題。這可確保在資料越過安全性界限之前清除所有填補位元組。（CVE-2026-74673）

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

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

  - serial： 8250_dma：關機時清除過時的 RX 狀態 serial8250_release_dma（） 會終止 RX DMA 並釋放通道，但保留rx_running設定。如果在 RX 傳輸處於活動狀態時連接埠關閉，則當 rxchan 為 NULL 時，過時狀態會保持不變，直到下次開啟時再次請求通道。提交 a7b9ce39fbe4 新增的 DesignWare BUSY 變通方案 （序列號：8250_dw：確保 BUSY 已取消宣告） 在啟動期間從 LCR 寫入路徑呼叫 serial8250_rx_dma_flush（）。這會在 serial8250_request_dma（） 取得新的 RX 通道之前發生。因此，在重新開啟時，過時的rx_running狀態會使排清路徑將 NULL 通道傳遞給 dmaengine_pause（），從而導致核心 Oops。終止 RX DMA 後清除rx_running，符合 TX 清除。此外，如果 DMA 物件或 RX 通道無法使用，請讓排清協助程式傳回，因此啟動和拆卸路徑無法將 NULL 通道傳遞至 DMAengine API。
    (CVE-2026-74654)

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

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

  - KVM： SVM：使用單獨的鎖定序列化對所有者和鏡像清單的存取 KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM和KVM_CAP_VM_COPY_ENC_CONTEXT_FROM之間的互動可能會導致兩個不同的問題： - 在 sev_migrate_from（） 中，當目的地 KVM 是鏡像時，鏡像項目會從來源的清單移至所有者的mirror_vms清單， 不像擁有者鏡像清單的其他寫入器 （sev_vm_copy_enc_context_from（）， sev_vm_destroy（）） 那樣持有擁有者的鎖定。並行的 COPY 或 destroy 可能會與 sev_migrate_from（） 爭用並損毀清單。- 在 sev_vm_destroy（） 中，*owner* 仍處於作用中狀態，並可能同時收到導致 sev->enc_context_owner 變更的KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM。在此情況下，不正確的 VM 會收到 kvm_put_kvm（）。第二個問題需要特別小心，因為所有者可能會在讀取和鎖定之間完全消失（即使比賽窗口小得不可思議）。因此，如果不將結構 kvm 置於SLAB_TYPESAFE_BY_RCU下，就無法在所有者鎖定下執行檢查（這將允許在 RCU 關鍵區段下進行 kvm_get_kvm_safe（））。只使用全域鎖要簡單得多，因為關鍵區段非常小，而且新鎖始終是葉鎖。（CVE-2026-74607）

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

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

  - 還原 thermal/drivers/hwmon： 稍微清理程式碼樣式 還原提交 030a48b0f6ce （thermal/drivers/hwmon： 稍微清理程式碼樣式），該提交透過移除有效檢查，在 thermal_add_hwmon_sysfs（） 的錯誤路徑中引入釋放後使用。（CVE-2026-74604）

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

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

  - Netty （io.netty：netty-handler） 版本從 4.2.0.Final 到 4.2.16.Final 以及 4.1.136.Final 版本 當使用純 （非擴充） X509TrustManager 且無法使用以不安全為基礎的信任管理員包裝時，停用 SslProvider.OPENSSL 用戶端路徑上的 TLS 主機名稱驗證 （Java 25+）。在此設定中，OpenSSL 用戶端不會執行主機名稱驗證，因此允許中間人攻擊者提供針對不同主機名稱核發的憑證，但該憑證無需驗證即可被接受。
    在 4.2.17.Final 和 4.1.137.Final 中修正。（CVE-2026-62243）

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

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

  - xsk：未要求時間戳記時清除中繼資料指標 使用者空間可以在要求處理後變更中繼資料旗標。因此，在完成期間重新讀取它們可能會使核心寫入提交封包時未要求的時間戳記。除非要求時間戳記完成，否則請在要求處理期間清除中繼資料指標。然後，完成處理可以使用指標本身，而不是重新讀取旗標。在 mlx5 上，WQE 路徑中繼資料會按批次進行評估：
    xsk_tx_metadata_request（） 僅針對啟動工作階段的描述元執行，就像透過共用 WQE 套用一次的總和檢查碼卸載一樣。只會重設該描述元的指標，因此完成處理可以記錄會話其他描述元的時間戳記，而不論其自己的XDP_TXMD_FLAGS_TIMESTAMP位為何。寫入會保留在中繼資料區域內;單一 WQE、其他零拷貝和通用路徑會重設每個描述元的指標，且不受影響。（CVE-2026-74709）

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

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

  - 之前的 NLTK 3.10.0 在 StreamBackedCorpusView 中包含繞過 pathsec 的任意本機檔案讀取弱點。透過直接呼叫 builtins.open（） 而不是 pathsec.open（） 來強制執行。無論 ENFORCE 設定為何，控制 fileid 引數的攻擊者皆可讀取任意本機檔案，包括敏感的系統檔案和應用程式憑證。（CVE-2026-63312）

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

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

  - 已解決 Linux 核心中的下列弱點：ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases. (CVE-2026-74642)

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

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

  - sctp：移除對等時清除new_transport sctp_process_asconf_param（） 會將新加入的對等傳輸儲存在 asoc->new_transport。處理完 ASCONF 區塊中的所有參數之後，sctp_sf_do_asconf（） 會使用此指標將 HEARTBEAT 傳送至新的傳輸。來自遠端 SCTP 對等體的已驗證 ASCONF 可以新增傳輸，然後在同一區塊中使用萬用字元 DEL-IP 參數再次將其移除。萬用字元刪除會保留 ASCONF 到達的傳輸，但會移除透過 sctp_assoc_del_nonprimary_peers（） 新新增的傳輸。移除不會清除 asoc->new_transport，而是將其指向已移除的傳輸。然後，sctp_sf_do_asconf（） 會建立一個 HEARTBEAT，其區塊>傳輸指向已移除的傳輸，而不保留傳輸參照。
    在本機位址取代期間，src_out_of_asoc_ok會讓此活動訊號保持control_chunk_list。RCU 釋放傳輸之後，成功ASCONF_ACK取代位址會釋放佇列的 HEARTBEAT，而 sctp_outq_select_transport（） 會讀取釋放的傳輸狀態。此問題是在對 SCTP 物件進行靜態稽核期間發現的。使用經過身份驗證的對等體，在啟用了 KASAN 的 netdev/main 核心上，重現者在 2 次未修補的執行中觸發了相同的 KASAN 報告： 錯誤：KASAN：在 sctp_outq_select_transport 中釋放後使用，讀取大小為 4，地址為 addr ffff88800b9bd95c，由任務 python3/197 呼叫追蹤：
    sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] 依工作 197 分配：sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] 上次可能相關的工作建立：
    __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] 第一個無效存取是在 net/sctp/outqueue.c：833 上讀取 transport->state 的 4 位元組讀取。相同的再現者使用此變更完成了完整的已驗證 ASCONF 和本機位址取代序列，而沒有 KASAN 報告或 oops。移除對等節點時，先清除new_transport，然後再用來建立活動訊號。（CVE-2026-74586）

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

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

  - xsk：需要至少 16 位元組的 TX 中繼資料，AF_XDP接受小至 8 位元組的 TX 中繼資料長度，但每個支援的要求都需要旗標加上至少一個 8 位元組的要求欄位。這種短的中繼資料也允許核心讀取註冊區域之外的範圍。需要 16 個位元組，而不是 sizeof（struct xsk_tx_metadata），以保留與不使用啟動時間中繼資料的應用程式的相容性。
    (CVE-2026-74710)

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

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

  - ring-buffer：在 rb_allocate_cpu_buffer（） 中初始化閱讀器頁面順序 在 rb_allocate_cpu_buffer（） 中，省略了 bpage->order，將其保留為 0。對於具有大於 PAGE_SIZE 的 subbufs 的環形緩衝區來說，如果釋放時，這是一個問題：free_buffer_page（） 依賴此值。將值與實際配置大小對齊 （buffer：：subbuf_order）。（CVE-2026-74602）

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

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

  - net：usb：ax88179_178a：修正 ax88179_tx_fixup（） 中的 skb 洩漏 當介面啟用了 NETIF_F_SG 並且 skb_linearize（） 在 ax88179_tx_fixup（） 中失敗時，該函數會傳回 NULL，而不釋放 skb。
    usbnet_start_xmit（） 將 tx_fixup（） 的 NULL 傳回視為刪除 （info->flags 未為此驅動程式設定FLAG_MULTI_PACKET），跳到放置標籤，其中執行 'if （skb） dev_kfree_skb_any（skb）'。由於 tx_fixup（） 傳回 NULL，因此 usbnet_start_xmit（） 中的本地 skb 變數為 NULL，因此原始 skb 永遠不會在線性化失敗（即在記憶體壓力下）的每個 TX 幀上釋放記憶體洩漏。在返回之前釋放 skb，以符合相同函式中 pskb_expand_head（） 失敗路徑已使用的錯誤處理。（CVE-2026-74678）

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

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

  - xfs：處理 xfs_buf_free 中的 NULL b_addr 當 xfs_buf_alloc_backing_mem（） 失敗時，會呼叫 xfs_buf_free（），但 bp->b_addr 仍為 NULL。程式碼會落入呼叫 virt_to_folio（NULL） 的folio_put路徑，解除參照無效位址並造成核心損毀。呼叫追蹤：xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 當 bp->b_addr 為 NULL 時，透過跳過 folio_put（） 來解決此問題。（CVE-2026-74728）

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

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

  - bpf： tcp：修正 bpf_iter_tcp_established_batch（） 中的釋放後使用 reqsk_queue_hash_req（） 將TCP_NEW_SYN_RECV request_sock發佈到 ehash 鏈上，刪除儲存桶鎖定，之後才將 rsk_refcnt 設定為 3。無鎖讀取器 （例如 __inet_lookup_established（） 使用 refcount_inc_not_zero（） 來處理此問題，但 bpf_iter_tcp_established_batch（） 在保持儲存桶鎖定時使用普通 sock_hold（），假設鎖定保證 sk_refcnt > 0。此假設不適用於 request_sock： CPU 0 CPU 1 ----- ----- tcp_conn_request（） reqsk_queue_hash_req（） inet_ehash_insert（req） spin_lock（bucket） __sk_nulls_add_node_rcu（req） // rsk_refcnt == 0 spin_unlock（bucket） bpf_iter_tcp_established_batch（） spin_lock（bucket） sock_hold（req） <-- 在 0 spin_unlock（bucket） refcount_set（&req->rsk_refcnt， 3） // clobbers 飽和值，其表面顯示為：refcount_t：在 0 上相加;釋放後使用。警告：lib/refcount.c：25 位於 refcount_warn_saturate+0x48/0x90， CPU#1 呼叫追蹤：
    bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 當發佈 CPU 的 refcount_set（） 覆寫計數時，迭代器的竊取參照會遺失，導致通訊端缺少一個參照。當最後一個合法所有者刪除其引用時，reqsk 將被釋放，同時仍可訪問，從而導致釋放後使用。
    這會在 tcp_syncookies=0 時在幾秒鐘內重現，少數執行緒對本機接聽程式執行 connect（）/close（），而其他執行緒則在緊密迴圈中讀取 iter/tcp 連結。使用 refcount_inc_not_zero（） 並在失敗時跳過通訊端。跳過的通訊端仍然是儲存貯體的一部分，因此請繼續將其計入預期值。重新配置的大小與預期不同，而且當鎖定在最後一個 realloc 上保留時，其參照計數會發佈的要求 sock 必須已經有空間。略過的通訊端會計入預期，但永遠不會批次處理，因此end_sk實際完成的批次上可能會低於預期。根據步行是否留下任何插座來決定完整性。鎖定 realloc 之後的 WARN 會進行相同的檢查，取代end_sk自提交 cdec67a489d4 （bpf：
    tcp：確保 iter->batch 一律包含完整的儲存貯體快照）。如果儲存貯體中每個相符的通訊端都是中間初始化 （refcount 0），則end_sk會維持 0。前進到下一個儲存貯體，而不是傳回本輪從未填滿的批次項目。（CVE-2026-74714）

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

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

  - gpio： pca953x：修正 pca953x_irq_bus_sync_unlock regmap 鎖定 在 regmap 組態中停用鎖定，因為此驅動程式使用自己的鎖定。這表示所有對 regmap 函式 （讀取或寫入） 的呼叫都必須保留i2c_lock。函式 pca953x_irq_bus_sync_unlock（） 沒有執行此動作，因此多個執行緒可能會導致讀取/寫入不正確的暫存器。先前的修補程式部分修正了此問題，但僅保護對中斷遮罩暫存器的寫入，而不保護從方向暫存器的讀取。
    (CVE-2026-74733)

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

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

  - binfmt_misc：當從另一個使用者命名空間完成掛載時，不要發出警告 fsopen（） 會在 fc->user_ns 中記錄呼叫者的使用者命名空間，並交回一個普通的檔案描述元。沒有任何內容會將呼叫 fsconfig（FSCONFIG_CMD_CREATE） 的作業繫結至建立內容的作業。fd 在 fork（） 和 exec（） 之間繼承，並且可以通過 unix 通訊端傳遞。故意允許從另一個使用者命名空間完成內容。vfs_cmd_create（） 使用 mount_capable（） 授權建立，對於FS_USERNS_MOUNT檢查 ns_capable（fc->user_ns， CAP_SYS_ADMIN），並且對於在 fc->user_ns 的祖先中保存CAP_SYS_ADMIN的任務會成功。因此，無權限的任務可以到達 bm_fill_super（） 中的 WARN_ON（）：在子項中建立使用者和掛載命名空間，在那裡調用 fsopen（binfmt_misc），將 fscontext fd 發送給父項，然後讓父項FSCONFIG_CMD_CREATE問題。這兩個命名空間都來自普通的 unshare（1），在任何地方都不需要任何功能： 警告：fs/binfmt_misc.c：938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU：15 UID：1000 PID：3243382 通訊：fswarn 呼叫追蹤：
    get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 子項需要掛載命名空間，因為 fsopen（） 本身會以 may_mount（） 為門禁，而 （） 會要求在擁有呼叫端掛載命名空間的使用者命名空間中進行CAP_SYS_ADMIN。fsconfig（） 不會重複此檢查。它是 WARN_ON（） 而不是 WARN_ON_ONCE（），因此可以在迴圈中引發該條件以污染核心並溢流日誌，並且它會使使用 panic_on_warn 啟動的核心出現錯誤。繼續拒絕安裝並停止警告。bm_fill_super（） 中的任何內容都不依賴於兩個命名空間的匹配，它從 sb->s_user_ns 派生所有內容。
    (CVE-2026-74618)

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

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

  - vdpa/mlx5：修正 create_direct_keys（） 中的緩衝區長度，我們在 CI 中看到了以下 KASAN 訊息：
    錯誤：KASAN：cmd_exec+0x550/0xca0 中的 slab-out-of-bounds [mlx5_core] 任務 qemu-system-s39/82764 在 addr 0000000176795020讀取大小 272 [...][<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...]有錯誤的位址位於分配的 4384 位元組區域內的 4128 位元組 [0000000176794000， 0000000176795120） 因此，本質上我們讀取了超出 4384 位元組分配的 16 位元組。
    create_direct_keys 會計算輸入和輸出緩衝區的指標和長度。in 的大小計算包括整個結構大小 （out + in + mtt[]），但傳遞給 cmd_exec 的指標僅指向「in」欄位，而跳過「out」欄位。這會導致 mlx5_copy_to_msg（） 在複製命令資料時，讀取超出配置的緩衝區 sizeof（out） 位元組。正確計算輸入大小以符合指標和分配大小。（CVE-2026-74712）

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

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

  - serial： amba-pl011：釋放 IRQ RS485 後取消 RS485 hrtimers 觸發 hrtimers 內嵌在 devm 管理的連接埠中，可在釋放後觸發。IRQ 處理常式可以布防計時器，因此請先釋放 IRQ，然後取消兩個計時器。在不布防計時器的情況下完成 RS485 停止，並在 remove（） 中取消暫停然後解除綁定路徑的計時器，其中不會呼叫 shutdown。此問題是由內部靜態分析工具發現的。（CVE-2026-74652）

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

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

  - TLS： RX：在TLS 1.3 樂觀重試之前還原msg_iter tls_decrypt_sg（） 會在樂觀TLS 1.3 零複製路徑的使用者頁面對應時，提前 MSG->msg_iter。如果解密的記錄不是未填充的應用程式資料，則 tls_decrypt_sw（） 會重試核心 skb，但會保留迭代器進階。
    然後，來自 skb 的後續副本會在呼叫端 iovecs 的稍後時間再次寫入解密的位元組，而 recvmsg（） 僅報告重試後長度。TLS 對等可以在接收者啟用 TLS_RX_EXPECT_NO_PAD 之後觸發此動作。依樂觀對應所耗用的位元組數還原迭代器，再在沒有零複製的情況下重試。新增自我測試，以傳送啟用 TLS_RX_EXPECT_NO_PAD 的 TLS 1.3 控制記錄，並驗證 recvmsg（） 不會覆寫超過傳回長度的後續 iovecs。
    (CVE-2026-74611)

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

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

  - net/smc：修正 smc_listen_out（） 和接聽程式關閉之間的 TOCTOU 爭用 smc_listen_out（） 在沒有接聽程式鎖定的情況下讀取 lsmc->sk.sk_state，然後僅在檢查通過後才取得 lock_sock_nested（）。
    這會開啟一個窗口，其中 smc_close_active（） 可以將接聽程式轉換為 SMC_CLOSED、呼叫 smc_close_cleanup_listen（） 以排空接受佇列並釋放鎖定，所有這些都在無鎖定讀取和延遲鎖定取得之間進行：smc_listen_work （smc_hs_wq） smc_close_active（）
    ------------------------------- ------------------------- release_sock（child） if （sk_state == SMC_LISTEN） TRUE lock_sock（接聽程式） sk_state = SMC_CLOSED smc_close_cleanup_listen（） release_sock（接聽程式） flush_work（tcp_listen_work） lock_sock_nested（接聽程式） smc_accept_enqueue（接聽程式，子項） /* 在失效接聽程式上排入佇列的子項 */ smc_close_active（） 僅排清tcp_listen_work。已分派到 CLC 交握smc_hs_wq的工作專案會繼續不受保護地執行。smc_accept_enqueue（） 對永遠不會釋放的子項進行 sock_hold（），因此子項smc_sock、其 clcsock 和參照都會洩漏。在伺服器呼叫 close（） 時開啟 TCP 連線的遠端對等體可能會耗盡核心記憶體。
    將 lock_sock_nested（） 移至sk_state檢查之前，讓測試和佇列在接聽程式鎖定下是不可部分完成的。（CVE-2026-74692）

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

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

  - ipvs：停用計算階段後停止估算器 IPVS 估算器 kthread 0 會從零鏈和刻度限制開始，直到其初始計算階段完成為止。如果網路命名空間拆卸在該階段清除了 ipvs->enable，則 ip_vs_est_calc_phase（） 可以返回而不安裝正限制。然後，kthread 可以繼續進入其主迴圈，並以零 chain_max、tick_max 和 est_max_count 值清空est_temp_list。每個佇列都會耗用一個可用的刻度列，但est_count永遠不會達到零est_max_count值。使用所有資料列之後，資料列查詢會傳回 IPVS_EST_NTICKS，而 ip_vs_enqueue_estimator（） 會寫入經過刻度和tick_len數組。如果 kthread 停止或 IPVS 已停用，則在計算階段結束 kthread 0。這可防止在限制初始化失敗後耗盡臨時估算器。Estimator kthreads 現在可以在拆卸或重新載入停止 kd->task 之前自行退出。建立後保留額外的任務參照，並使用 kthread_stop_put（） 釋放它，因此 kd->task 在停止路徑耗用該參照之前保持有效。（CVE-2026-74670）

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

ID	名稱	嚴重性
338963	Linux Distros 未修補弱點：CVE-2026-74656	high
338962	Linux Distros 未修補弱點：CVE-2026-74691	high
338961	Linux Distros 未修補弱點：CVE-2026-74633	medium
338960	Linux Distros 未修補弱點：CVE-2026-74608	critical
338959	Linux Distros 未修補弱點：CVE-2026-74653	medium
338958	Linux Distros 未修補弱點：CVE-2026-74638	medium
338957	Linux Distros 未修補弱點：CVE-2026-74715	high
338956	Linux Distros 未修補弱點：CVE-2026-62383	medium
338955	Linux Distros 未修補弱點：CVE-2026-74599	medium
338954	Linux Distros 未修補弱點：CVE-2026-74644	medium
338953	Linux Distros 未修補弱點：CVE-2026-74704	high
338952	Linux Distros 未修補弱點：CVE-2026-74610	high
338951	Linux Distros 未修補弱點：CVE-2026-74681	medium
338950	Linux Distros 未修補弱點：CVE-2026-74597	critical
338949	Linux Distros 未修補弱點：CVE-2026-74667	high
338948	Linux Distros 未修補弱點：CVE-2026-74679	high
338947	Linux Distros 未修補弱點：CVE-2026-74663	high
338946	Linux Distros 未修補弱點：CVE-2026-74636	medium
338945	Linux Distros 未修補弱點：CVE-2026-74634	high
338944	Linux Distros 未修補弱點：CVE-2026-74603	high
338943	Linux Distros 未修補弱點：CVE-2026-74702	high
338942	Linux Distros 未修補弱點：CVE-2026-74698	medium
338941	Linux Distros 未修補弱點：CVE-2026-74619	medium
338940	Linux Distros 未修補弱點：CVE-2026-74650	high
338939	Linux Distros 未修補弱點：CVE-2026-74620	medium
338938	Linux Distros 未修補弱點：CVE-2026-74729	high
338937	Linux Distros 未修補弱點：CVE-2026-74685	medium
338936	Linux Distros 未修補弱點：CVE-2026-74689	high
338935	Linux Distros 未修補弱點：CVE-2026-74672	high
338934	Linux Distros 未修補弱點：CVE-2026-74673	medium
338933	Linux Distros 未修補弱點：CVE-2026-74654	medium
338932	Linux Distros 未修補弱點：CVE-2026-74607	high
338931	Linux Distros 未修補弱點：CVE-2026-74604	high
338930	Linux Distros 未修補弱點：CVE-2026-62243	high
338929	Linux Distros 未修補弱點：CVE-2026-74709	high
338928	Linux Distros 未修補弱點：CVE-2026-63312	high
338927	Linux Distros 未修補弱點：CVE-2026-74642	medium
338926	Linux Distros 未修補弱點：CVE-2026-74586	critical
338925	Linux Distros 未修補弱點：CVE-2026-74710	high
338924	Linux Distros 未修補弱點：CVE-2026-74602	high
338923	Linux Distros 未修補弱點：CVE-2026-74678	high
338922	Linux Distros 未修補弱點：CVE-2026-74728	medium
338921	Linux Distros 未修補弱點：CVE-2026-74714	high
338920	Linux Distros 未修補弱點：CVE-2026-74733	high
338919	Linux Distros 未修補弱點：CVE-2026-74618	medium
338918	Linux Distros 未修補弱點：CVE-2026-74712	critical
338917	Linux Distros 未修補弱點：CVE-2026-74652	high
338916	Linux Distros 未修補弱點：CVE-2026-74611	critical
338915	Linux Distros 未修補弱點：CVE-2026-74692	high
338914	Linux Distros 未修補弱點：CVE-2026-74670	high

偵測

Nessus 的 Misc. 系列

high

high

medium

critical

medium

medium

high

medium

medium

medium

high

high

medium

critical

high

high

high

medium

high

high

high

medium

medium

high

medium

high

medium

high

high

medium

medium

high

high

high

high

high

medium

critical

high

high

high

medium

high

high

medium

critical

high

critical

high

high