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

  - 之前 3.10.0 的 NLTK 版本在 pathsec.py 中預設為 ENFORCE=False，導致所有安全性驗證函式發出警告，而不是引發例外狀況。攻擊者可以利用僅在手動啟用時才會啟用的已停用安全性控制來繞過路徑遊走和 pickle 反序列化保護。（CVE-2026-62388）

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

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

  - tcp：修正跨 reuseport 移轉的 TFO max_qlen帳戶 接聽程式的TCP_FASTOPEN max_qlen不再準確，並允許通過比設定的多得多的擱置快速開啟要求。這只會在聽眾遷移SO_REUSEPORT出現，其中關閉接聽器會將其仍在等待的 TFO 子項移交給倖存的子項。fastopenq.qlen 在建立子系時以 tcp_fastopen_create_child（） 收費，交握完成時在 reqsk_fastopen_remove（） 中取消收費。uncharge 遵循子項指向的請求的rsk_listener，並且 inet_reqsk_clone（） 已將子項重新指向新接聽程式擁有的新請求，因此 ++ 和 -- 位於兩個不同的通訊端上。新接聽程式的 qlen 為負漂移，且其限制不再綁定。在移轉期間向新接聽程式收費，就像 reqsk_queue_migrated（） 已針對 queue->young 和 queue->qlen 所做的那樣。（CVE-2026-74696）

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

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

  - rqspinlock： 在鎖死時保留佇列時重設尾部 目前，在偵測到鎖死的情況下，rqspinlock 會抑制捨棄等候者佇列。鎖死檢查相對頻繁地發生 （AA 在進入時，ABBA 在 1 毫秒內），而且服務員執行緒可能不會參與涉及鎖死的鎖定案例。因此，在我們偵測到鎖死並退出後，不要排清佇列並讓其他服務員嘗試取得鎖定是很有用的。然而，我們需要遵循與之前對waitq_timeout標籤所做的相同的邏輯：重置尾部，如果我們不能，則適當地向下一個服務員發出信號。在發生鎖死的情況下，此訊號只會將 MCS 節點標記為已解鎖，而在逾時的情況下，它會發出RES_TIMEOUT_VAL訊號。因此，差異在於傳播的值，它決定佇列是保持作用中還是被排清。不進行尾部重置並等待下一個服務員可能會導致我們是最後一個服務員的情況，因此沒有下一個服務員到達，從而導致這條路徑間歇性停滯。一旦下一位服務員加入，我們就會被解鎖。在理論上，當下一個服務員從未加入時，我們就有可能無限期地拖延。這只會發生在 ABBA 鎖死時，因為進入等候佇列會受到 AA 檢查的保護。導致此案例的精確執行順序可以是： CPU 0 持有鎖定 A、CPU 1 持有鎖定 B、CPU 2 嘗試鎖定 B、成為 B 的擱置等候器、CPU 0 嘗試鎖定 B、B 已設定鎖定 + 擱置位元，因此 CPU 0 佇列。CPU 1 嘗試鎖定 A。 CPU 0 偵測到 ABBA 鎖死。一旦 CPU 0 發生鎖死偵測，它就會等待佇列中的下一個等候程式填入 node->next，這會遇到延遲，直到這類等候程式到達為止。透過調整檢查waitq_timeout標籤之前的鎖死邏輯來修正此問題。合併這兩種情況的程式碼並使用 'ret' 來區分正在傳播的值是有意義的，但這將作為未來重構任務的練習，以避免此修補程式中的差異雜訊。（CVE-2026-74686）

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

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

  - sctp：保持 chunk->transport 與其排入佇列的清單同步 __sctp_outq_flush_rtx（） 將間隙確認的區塊移動到另一個傳輸的傳輸清單上，而不更新 chunk->transport： if （chunk->tsn_gap_acked） { list_move_tail（&chunk->transmitted_list， &transport->transmitted）; 繼續; }然後，該區塊位於即時傳輸的清單中，而區塊>傳輸仍會命名不同的傳輸。如果從 ASCONF Delete-IP 中移除該傳輸 - sctp_assoc_rm_peer（） - sctp_transport_free（） RCU 會釋放它，並且區塊會留下一個懸空的指標。sctp_assoc_rm_peer（） 清理對等>傳輸和 asoc->outqueue.out_chunk_list，但區塊都不在兩者上。設定指標時不會遵循指標tsn_gap_acked。在 TSN 上違背的 SACK 會清除旗標，下一個 SACK 會到達 tchunk->transport->flight_size -= sctp_data_size（tchunk）;在釋放的運輸工具內。KASAN 報告 sctp_check_transmitted（） 中的 slab-use-after-free 讀取，從 sctp_assoc_rm_peer（） 中釋放。移除和 SACK 都來自關聯對等。在移動時設定區塊>傳輸。普通的重新傳送路徑不需要任何東西：只有在 sctp_packet_append_chunk（） 傳回 SCTP_XMIT_OK 之後，它才會到達其 list_move_tail（），並且 __sctp_packet_append_chunk（） 屆時已經反彈了區塊。由 XBOW 發現，由 Baul Lee 分類 <baul.lee@xbow.com> (CVE-2026-74588)

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

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

  - net： prestera： validate firmware header length prestera_fw_hdr_parse（） 會先讀取韌體標頭，然後再檢查韌體映像是否包含該標頭。在解碼 magic 和 version 欄位之前，拒絕短於結構prestera_fw_header的影像。（CVE-2026-74693）

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

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

  - xsk：驗證啟動時間中繼資料大小 啟動時中繼資料超出結構xsk_tx_metadata的前 16 個位元組。當已註冊的中繼資料區域不包含完整欄位時，拒絕要求。
    為通用傳輸路徑建立已驗證旗標的快照，並將該快照用於要求和完成處理，避免在使用者空間同時變更旗標時做出不一致的決策。請注意，只有xsk_skb_metadata正確使用旗標，__xsk_buff_get_metadata會忽略它們。下一個提交解決了這個問題。（CVE-2026-74708）

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

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

  - misc： fastrpc：在中斷的叫用時移動 mmap 時採取 fl->lock 當叫用被訊號中斷時，wait_for_completion_interruptible（） 傳回 -ERESTARTSYS，而 fastrpc_internal_invoke（） 將每個緩衝區從 fl->mmaps 移動到 cctx->invoke_interrupted_mmaps。此 list_del（）/list_add_tail（） 遍歷在不保留 fl->lock 的情況下運行，該鎖在其他任何地方序列化 fastrpc_req_mmap（） 和 fastrpc_req_munmap（） 中的 fl->mmaps。在移動過程中採用 fl->lock，匹配所有其他 fl->mmaps 存取子。（CVE-2026-74646）

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

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

  - ipv6：修正路由資訊選項長度驗證 rt6_route_rcv（） 會針對前置詞長度驗證路由資訊選項 （RFC 4191） 長度，但這兩個檢查都差一。rinfo->length 是以 8 個八位元組為單位的 ND 選項長度，它*包括*8 位元組的選項標頭，因此帶有 N 位元組前綴的選項的長度 == 1 + N/8。RFC 4191 部分 2.3 要求當前置詞長度大於 64 時長度為 3，當前置詞長度大於 0 時，要求長度為 2 或 3。程式碼分別接受長度 >= 2 和長度 >= 1。然後，ipv6_addr_prefix（） 會從 rinfo-> 字首複製 prefix_len/8 位元組，因此具有 （prefix_len=128， length=2） 或 （prefix_len=64， length=1） 的路由器通告會使核心讀取選項結尾後最多 8 個位元組。這些位元組最終位於所安裝路由的前綴中，因此它們對使用者空間可見： # 帶有路由資訊選項的 RA （prefix_len=128，長度=2） # 後面接著來源連結層位址選項， 01 01 de ad be ef ca fe $ ip -6 route show 2001：db8：dead：beef：101：dead：beef：café via fe80：：1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^下一個選項，越界讀取 當路由資訊選項是封包中的最後一個選項時，這八個位元組會改為來自 skb 尾部房間。拒絕 RFC 4191 不允許的選項長度。
    (CVE-2026-74598)

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

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

  - xsk：處理要求時驗證中繼資料零複製路徑會在取得描述元內容時驗證 TX 中繼資料，然後稍後在準備硬體要求時再次讀取它。使用者空間可以變更這些作業之間的中繼資料，並繞過原始驗證。驗證 xsk_tx_metadata_request（） 中的中繼資料，並將產生的旗標快照用於每個功能檢查。讀取要求欄位一次，讓所有零複本驅動程式只處理成功驗證後觀察到的值。
    (CVE-2026-74707)

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

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

  - net： smc：修正 smc_rx_splice smc_rx_splice（） 中的拼接項目存留期不平衡，在獲取涵蓋每個拼接項目存留期的參照之前，將頁面傳遞給 splice_to_pipe（）。在 VM 支援的 RMB 路徑中，splice_to_pipe（） 可能會透過 smc_rx_spd_release（） 刪除未排入佇列的項目，而排入佇列的項目稍後會透過管道緩衝區回呼釋放。舊的拼接後帳戶也會從建置描述元時變異的偏移量衍生佇列的 VM 頁面數，而多頁拼接會將一個 sock_hold（） 與多個 sock_put（） 呼叫配對。在 splice_to_pipe（） 之前獲取每個候選項目的頁面和通訊端參照，並從 smc_rx_spd_release（） 中刪除從未排入佇列的條目匹配的私有狀態、頁面參照和套接字參照。這修正了參照計數不平衡的問題，該問題可能會使頁面參照計數不足，並觸發釋放後使用。（CVE-2026-74631）

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

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

  - 暫存：rtl8723bs：修正缺少的共用金鑰驗證挑戰長度檢查 WEP 共用金鑰驗證處理常式會使用挑戰文字元素的攻擊者控制長度，而不針對固定的 128 位元組chg_txt緩衝區進行檢查。在 OnAuthClient（） 中，rtw_get_ie（） 的長度 （最多 255） 用於對 128 位元組的 pmlmeinfo->chg_txt 執行 memcpy（），因此傳送格式錯誤的 WLAN_EID_CHALLENGE 元素的惡意 AP 最多可溢位/不足chg_txt 127 位元組。在共用金鑰驗證期間，在關聯之前，可以透過無線方式存取它。在溢位的情況下，驅動程式可以寫入越界。在填充不足的情況下，驅動程式可以回應過時的緩衝區記憶體。挑戰文字被定義為恰好是 128 個八位元組，這已經按照WLAN_AUTH_CHALLENGE_LEN定義提供;要求元素在使用前正好是該長度。（CVE-2026-74649）

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

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

  - net： usb： ipheth：修正中斷連接時的 carrier_work UAF ipheth_sndbulk_callback（） 重新武裝任何非零 URB 狀態的 carrier-check 工作：else schedule_delayed_work（&dev->carrier_work， 0）;沒有任何東西將其與正在啟動的介面聯繫起來，因此可以在 ipheth_close（） 已經耗盡工作後再次武裝工作，並保持武裝狀態，直到嵌入它的私人區域的 netdev 被釋放。在使用正在傳輸的 TX URB 拔除插頭時，ipheth_disconnect（） 會透過 unregister_netdev（） -> ipheth_close（） -> cancel_delayed_work_sync（） 清空工作，然後才呼叫 ipheth_kill_urbs（） 。usb_kill_urb（） 使用 -ENOENT 完成飛行中的 TX URB，因此 ipheth_sndbulk_callback（） 在排水和重新布防carrier_work之後運行。如果介面僅在 TX URB 正在飛行時關閉，並且 ipheth_carrier_check_work（） 會每秒重新排隊一次，則相同的完成也會重新武裝工作。unregister_netdev（） 不會為已經關閉的介面呼叫 ipheth_close（），因此在稍後拔下時也不會耗盡它。在這兩種情況下，free_netdev（） 會在 netdev 仍處於擱置狀態時釋放 netdev carrier_work，而 ipheth_carrier_check_work（） 會解除參照釋放的記憶體。將工作繫結至介面狀態，而不是追蹤完成：在 ipheth_close（） 中停用它，並在 ipheth_open（） 中啟用它，因此每當介面未啟動時，來自 URB 完成的 schedule_delayed_work（） 都是無操作。disable_delayed_work_sync（） 也會等待正在執行的執行個體，因此它會完全取代它所取代的 cancel_delayed_work_sync（）。工作在 ipheth_probe（） 中開始停用，因此啟用/停用從第一次開啟開始計算餘額。在 linux-next （next-20260731） 上的 KASAN 下重現，dummy_hcd 和 raw-gadget 代替裝置，驅動上面的第二條路徑（介面已經關閉，因此 unregister_netdev（） 不會呼叫 ipheth_close（））：15 個未修補的啟動中有 15 個報告了 __run_timers（） 中的釋放後 slab-use-free，由 ipheth_disconnect（） 釋放，並透過 queue_delayed_work_on（） 從 ipheth_sndbulk_callback（） 重新武裝。僅此修補程式不同的核心上的相同觸發器報告 0 （共 15 個），並且載波檢查在開啟/關閉週期中仍然有效。再現者需要一個連接的 USB 設備來停止耗盡大量 OUT，以及一個以 root 驅動並拔出的鏈路。這不是特權邊界交叉，也沒有開發任何利用原語。在 0 秒 （）https://0sec.ai 之前找到。（CVE-2026-74677）

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

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

  - ipv6：防止 in6_dev_get（） 復活 inet6_dev in6_dev_get（） 在 RCU 下讀取 dev->ip6_ptr，然後無條件地增加其參照計數。裝置拆卸可以清除指標，並刪除這些作業之間的最後一個參照。然後，增量會還原其 RCU 可用空間已排入佇列的物件，因此呼叫端可以在釋放之後使用它。使用 refcount_inc_not_zero（） 並在物件已經達到零時傳回 NULL。RCU 會透過嘗試的參照擷取來保持記憶體的存取，而成功的增量會為呼叫端釘選物件。在完全未修補的 6f5156d7a31a （v7.2-rc3） 核心上獨立執行，將無效的參照擷取重現為 UID 1000：
    refcount_t：在 0 上加法;釋放後使用。ip6_mc_source+0xef4/0x17e0 後面是 ip6_mc_source（） 中對應的參照溢位。來自相同未修補修訂版的追蹤記錄也額外顯示 RCU 讀取端區段結束後的存取： 錯誤：KASAN：mutex_lock+0x76/0xe0 中的 slab-use-after-free 由任務 poc/1219 在 addr ffff888015b50240 寫入大小 8 錯誤由 OpenAI Security Research 發現並分類，並由 Trail of Bits 驗證。（CVE-2026-74630）

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

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

  - 暫存：RTL8723bs：驗證監視器傳輸框架長度 rtw_cfg80211_monitor_if_xmit_entry（） 會移除 RadioTap 標頭，然後讀取 802.11 影格控制欄位，而不檢查基底 802.11 標頭是否保留。資料路徑也會提取計算出 802.11的 、 QoS 和 SNAP 標頭範圍，然後再確認 skb 包含它。因此，截斷的框架可能會導致越界讀取，或留下不足的資料進行乙太網路位址寫入。拒絕不包含基底 802.11 標頭的框架，以及不包含其完整計算標頭範圍的資料框架。（CVE-2026-74648）

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

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

  - mm：修正直接頁表回收中不正確的排清位址 當 zap_pte_range 回收頁表時，它會執行： pte_free_tlb（tlb， pmd_pgtable（pmdval）， addr）;這是無條件錯誤的：如果執行此程式碼，addr *always* 會指向表格所涵蓋範圍的末尾。addr 參數用於排清 TLB（實際上是分頁結構快取）以刪除對待釋放表的引用，任何關心該參數的架構都會排清錯誤的位址。（但他們仍然會釋放正確的頁面）。我認為值得思考為什麼內核可以工作。如果我們擊中有問題的代碼行，我們將首先清除 PMD 條目（第 1954 行，zap_empty_pte_table），然後如果設置了 force_flush，我們將發出待處理的刷新（tlb_flush_mmu_tlbonly（tlb）），然後我們將跳過第 1979 行的重試（呸！），然後我們將進行有問題的pte_free_tlb調用。*或者* 我們將在pte_free_tlb之前清除 PMD 條目（第 1983 行，zap_pte_table_if_empty 行）。如果我們在清除 PMD 條目時有任何待處理的刷新（即我們實際上刪除了任何最後一級條目），那麼刷新確實應該刷新對表的所有引用（Linus 似乎肯定認為它會在所有架構上 [0]）。我們在清除時沒有累積的沖洗的條件非常複雜（整個zap_pte_range函數具有荒謬複雜的控制流程）。如果我們確實遇到壞情況，那麼我們最終將在上次刷新範圍後清除 PMD 項目，並且任何 CPU 都可以自由地快取對（空）頁面表的引用。如果這是由於普通的讀取或寫入而發生的，則會發生段錯誤，因此這種情況很少見。但緩存也可能被推測地填滿。然後我們將排清錯誤的位址，然後釋放並可能重複使用該表。在 x86 上，即使排清錯誤的位址也適用於非 KPTI Intel 系統，因為 INVLPG 會排清「所有」分頁結構快取，而不僅僅是目標位址的排清快取。
    但 INVPCID 沒有，如果有的話，flush_tlb_one_user會使用 INVPCID。然後我們乾杯。AMD 系統更容易受到影響：我們設定了 EFER。TCE 位元，這使得即使是 INVLPG 也只能排清目標位址。我認為這可能會解決此處報告的 ripgrep 中的一個問題：
    https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u(CVE-2026-74674）

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

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

  - vsock/virtio：避免在拆卸後重新填充 RX 佇列 提交 b917507e5ad9 （vsock/virtio：在 .remove（） 期間停止工作角色） 使 RX 工作角色在清除時跳轉到其通用退出rx_run。當緩衝區計數較低時，該退出仍會重新填充 RX 佇列，因此跨 virtio_vsock_vqs_del（） 排入佇列的工作可以在刪除 virtqueue 後新增緩衝區。錯誤：KASAN：任務 kworker/0:1 工作佇列讀取大小為 4 的 virtqueue_add_sgs 中的 slab-use-after-free：virtio_vsock virtio_transport_rx_work 呼叫追蹤：
    virtqueue_add_sgs （drivers/virtio/virtio_ring.c：2796） virtio_vsock_rx_fill （net/vmw_vsock/virtio_transport.c：332） virtio_transport_rx_work （net/vmw_vsock/virtio_transport.c：701） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） ... 由任務 141 釋放： kfree （mm/slub.c：6566） vp_del_vq （drivers/virtio/virtio_pci_common.c：259） vp_del_vqs （drivers/virtio/virtio_pci_common.c：285） virtio_vsock_freeze （net/vmw_vsock/virtio_transport.c：912） virtio_device_freeze （drivers/virtio/virtio.c：658） virtio_pci_freeze （drivers/virtio/virtio_pci_common.c：601） pci_pm_freeze （drivers/pci/pci-driver.c：1098） device_suspend （drivers/base/power/main.c：1968） 核心錯誤 - 不同步： KASAN：panic_on_warn套...... 當rx_run清除時，跳到禁止補充的出口，離開正常出口以補充正在運行的隊列。（CVE-2026-74613）

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

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

  - 當輸入行正好是緩衝區長度時，src/filehandling.c 中 hashcat 的 fgetl（） 函式會在呼叫端緩衝區後一個位元組處寫入空終止符。攻擊者可以透過提供包含正好 HCBUFSIZ_LARGE 位元組行的雜湊檔案、potfile 或 wordlist 來觸發此越界堆積寫入。
    (CVE-2026-68767)

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

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

  - veth：修正 XDP 片段調整後的 skb 長度統計 veth 會透過 xdp_buff 公開非線性 skb 片段。如果 XDP 程式調整片段區域，veth_xdp_rcv_skb（） 會xdp_frags_size複製回 skb->data_len，但會留下包含舊片段貢獻的 skb->len。片段縮小後，這會使 skb_headlen（） 大於實際線性區域。在重現的 UDP 接收路徑中，
    __skb_datagram_iter（） 從結構 skb_shared_info 開始，將 1024 位元組複製到使用者空間，越過實際線性尾部。複製的位元組包括受影響 skb 的nr_frags、xdp_frags_size，以及來自 skb_shinfo（skb）->frags[0] 的核心指標。實際封包資料被置換了相同數量，並在最後被截斷。在替換之前減去舊data_len，然後添加新data_len，保持 skb->len 和 skb->data_len 同步。此外，bpf_xdp_pull_data（） 可以推進data_end，同時保留片段。然後 skb 仍然是非線性的，因此舊的 __skb_put（skb， off） 會觸發 SKB_LINEAR_ASSERT（）。請改用 skb_set_tail_pointer（），並在 bpf_prog_run_generic_xdp（） 之後明確更新 skb->len。與 __skb_put（） 不同，skb_set_tail_pointer（） 不需要線性 skb。具有 MTU 64000 的 veth 對上的 60000 位元組 UDP 資料包從其片段區域縮短了 1024 位元組。
    在修正之前，所有 10 次執行都產生損毀的承載。修正後，所有 10 次執行都完全符合預期的承載。強制尾室再現器也會在片段仍然存在的情況下練習 bpf_xdp_pull_data（）;
    舊程式碼會觸發 SKB_LINEAR_ASSERT（），而此修正會傳遞 10/10 次執行。（CVE-2026-74612）

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

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

  - ima： 實例化 file_truncate 和 path_truncate 勾點 實例化 file_truncate 和 path_truncate LSM 勾點，以便在要求截斷時立即重設動作快取旗標 （IMA_DONE_MASK），以便根據原則，在下次存取時重新收集、重新測量、重新稽核和重新評估檔案。
    (CVE-2026-74592)

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

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

  - ipvs：變基後清除 IPv4 選項 通道 ICMP 錯誤 ip_vs_in_icmp（） 會將 skb 從外部 ICMP 封包變基底為引號的原始要求，然後再將其傳遞給 icmp_send（）。不過，IPCB（skb）->opt 仍會描述外部 IPv4 標頭。因此，外部標頭中的時間戳記選項可以在重新基底後留下指向引號傳輸標頭的偏移量。__ip_options_echo（） 會將該過時位置的位元組視為選項長度，並將其複製到 __icmp_send（） 堆疊上的固定大小選項儲存中，從而造成堆疊越界寫入。重設網路標頭後，清除過時的選項中繼資料。
    保留其餘的控制區塊欄位，包括 ICMP 回應路徑所使用的輸入介面。
    (CVE-2026-74669)

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

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

  - hashcat 在 src/outfile.c 的 outfile_write（） 函式中包含堆積型緩衝區溢位 （越界寫入）。將輸出組合到固定大小的緩衝區 （HCBUFSIZ_LARGE，~16 MB） 時，函式會透過 memcpy 依序附加使用者名稱、分隔符號、雜湊和純文字，而不驗證累積長度是否保持在緩衝區容量內。當針對 --username --show 包含幾乎填滿緩衝區的過大使用者名稱的特製雜湊檔案執行時，組合的輸出總量會超過緩衝區，導致堆積緩衝區溢位，進而損毀記憶體並損毀處理程序。
    (CVE-2026-68768)

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

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

  - net： atlantic：ring deinit aq_vec_deinit（） 上的釋放擱淺 TX 緩衝區會使用單一 aq_ring_tx_clean（） 呼叫耗盡 TX 環，最多釋放 AQ_CFG_TX_CLEAN_BUDGET （256） 個描述元並在 hw_head 處停止，一旦 aq_vec_stop（） 停止硬體和 NAPI，該描述項就不再移動。超出預算的已完成描述符以及仍發佈在 [hw_head， sw_tail） 中的所有內容在介面出現故障時保留其 skb 或 xdp_frame：然後 aq_vec_ring_free（） 釋放緩衝環，引用將永遠丟失。
    今天，這是在 TX/XDP_TX 負載下每個接口上的無聲內存洩漏。隨著 RX 路徑轉換為為 net-next 發布的page_pool，它變得更加明顯：XDP_TX幀在 RX 環的page_pool上攜帶片段引用，因此單個擱淺幀將池的飛行計數永遠保持在零以上。然後，page_pool_destroy（） 永遠不會完成，集區連同其頁面一起洩露，並且從該點開始，每次 ifdown、XDP 分離或環在負載下調整大小時，每 60 秒都會發出 page_pool_release_retry（） 停止的集區關閉警告XDP_TX。恢復 aq_ring_tx_deinit（） 之前的狀態，並再次使用它進行拆卸，並有一個擴展：現在 TX 環可以容納xdp_frames，所以也釋放它們。它們會與 xdp_return_frame（） 一起傳回，因為這會在處理程序內容中執行。
    (CVE-2026-74623)

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

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

  - ipvs：避免越界寫入 ip_vs_nat_icmp Sashiko 警告本機攻擊者可在 IPVS 處理封包時修改封包。有些地方會多次讀取 IP ihl 欄位，這可能會導致越界存取。其中一個地方是我們可以在經過驗證的區域之後書寫的ip_vs_nat_icmp。透過提供 ciph 引數來修正它，就像對 IPv6 所做的那樣，並使用 ciph->len 作為內嵌傳輸標頭的偏移量。修改某些 IPv4 標頭檢查時，只需讀取一次 ihl 欄位即可。（CVE-2026-74724）

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

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

  - netfilter： nf_flow_table：在 skb_dst_set_noref（） 之前捨棄現有的 skb dst，通過 netfilter 流程表卸載勾點 （或 XFRM 卸載路徑） 的傳入 skb 可能已經攜帶在較早的 RX 或路由步驟中指派的 ref-counted dst_entry。當 skb 已經持有 ref-counted dst 時呼叫 skb_dst_set_noref（） 會覆寫 skb->_skb_refdst，洩露先前的 dst_entry 參照計數，並在 skb_dst_check_unset（） 中觸發DEBUG_NET_WARN_ON_ONCE判斷提示： 警告：skb_dst_check_unset include/linux/skbuff.h：1170 警告：skb_dst_set_noref include/linux/skbuff.h：1234 警告： 在 nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c：864 在設定非參照流程表目的地之前，刪除任何帶有 skb_dst_drop（skb） 的現有dst_entry參照。（CVE-2026-74695）

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

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

  - net/mlx5： fw_tracer，在建立錯誤時傳回 NULL 追蹤器建立可能會因傳回 NULL 或 ERR_PTR 而失敗。傳回值會儲存而不檢查裝置，而且使用者會以相同的方式對待 ERR_PTR 和 NULL。這也會導致核心轉儲邏輯損毀，其中缺少ERR_PTR檢查並最終取消參照，如下面的追蹤所示。將追蹤器建立切換為僅在失敗時傳回 NULL，因此呼叫端只需要單一 NULL 檢查。內部錯誤：哎呀：0000000096000006 [#1] SMP 模組連結於：
    mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU：1 UID：0 PID：12 Comm：kworker/u16：0 未受 6.19.7 #1 污染 PREEMPT（無） 工作佇列：mlx5_health0001：01：00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate：a3400009 （NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--） pc：mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr： mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp：ffff800081cf3c40 x29：
    ffff800081cf3c90 x28： 00000000000000000 x27： 000000000000000000 x26： ffff000080018828 x25： 00000000000000000 x24： ffff000080304a05 x23： ffff800081cf3d80 x22： ffff0000847e01a0 x21： 00000000000000000 x20：
    ffff0000847e01a0 x19： ffffffffffa1 x18： ffff80008310bbf0 x17： ffff800080119650 x16： ffff80008010df54 x15： ffff80008010d4ac x14： ffff800079c202e4 x13： ffff80008002fe60 x12： ffff800080119650 x11：
    ffff80008010df54 x10： ffff80008010d4ac x9 ： ffff800079c203d8 x8 ： ffff800081cf3c88 x7 ： 00000000000000000 x6 ： 0000000000000000 x5 ： 00000000000000000 x4 ： 0000000000000008 x3 ： 0000000000000030 x2 ：
    0000000000000008 x1 ： 0000000000000000 x0 ： 000000000c5c4000e 呼叫追蹤：
    mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] （P） mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 程式碼： b9400000 5ac00800 7a401800 540003ca （3940a260） ---[ end trace 000000000000000000 ]--- 核心錯誤 - 未同步： 哎呀：重大異常 SMP：停止輔助 CPU 核心偏移：停用 CPU 功能：0x000000,00078031,75fce5a1,35fffe67 記憶體限制：無 ---[ end 核心錯誤 - 未同步：哎呀：嚴重異常 ]--- （CVE-2026-74717）

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

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

  - net/sched： cls_api：破壞鎖定的分類器時始終獲取 rtnl_lock 解鎖過濾器的另一個挑戰。tc_new_tfilter中有一個短暫的窗口，可以在其中找到一個tcf_proto，並被一個完全不相關的解鎖分類器請求簡要引用並引起爭用。Feng 創建了一個 poc，它用兩個線程創建了這場競賽，一個創建了一個 u32 過濾器，另一個在同一鏈/prio 中創建了一個花過濾器：1. 兩個線程都進入tc_new_tfilter，都發現鏈是空的，都掉filter_chain_lock 2。u32 先完成 tcf_proto_create（u32），呼叫 tcf_chain_tp_insert_unique（） -> 將u32_tp插入鏈 3。flower 稍後完成 tcf_proto_create（flower），調用 tcf_chain_tp_insert_unique（） -> tcf_chain_tp_find（） 現在看到已經存在u32_tp，對其進行引用，銷毀 Flower 自己的tp_new並將u32_tp返回給調用方。然後，Flower 會進行種類不相符檢查 （因為它要求 kind flower，但 tp->ops->kind 是 u32），並通過在 u32_tp 上呼叫 tcf_proto_put（） 的錯誤路徑。如果 u32 執行緒已經經歷了自己的錯誤（其 change（） 呼叫在 PoC 的空選項上失敗）並刪除了其建立和插入參考，則 flower 的 put 是最後一個錯誤，並將 u32_tp 的 refcnt 降至零。此時，tp->ops->destroy（） 在從未rtnl_lock過的上下文中運行。發生這種情況時，可能會導致如下所示的 UAF （由 PoC 說明）： [ +0.000710] 錯誤：KASAN：u32_init 中的 slab-use-after-free （net/sched/cls_u32.c：393） [ +0.000281] 由任務 poc_feng_xue/524 在 addr ffff888120022f00 讀取大小 8 調用追蹤：u32_init （net/sched/cls_u32.c：393） tc_new_tfilter （net/sched/cls_api.c：2378） 由任務 526 分配： u32_init （net/sched/cls_u32.c：378） tc_new_tfilter （net/sched/cls_api.c：2378） 由任務 522 釋放： kfree u32_destroy （net/sched/cls_u32.c：662） tcf_proto_destroy （net/sched/cls_api.c：446） tcf_proto_put （net/sched/cls_api.c：459） tc_new_tfilter （net/sched/cls_api.c：2459） 透過讓 tcf_proto_destroy（） 在未持有 rtnl 時針對鎖定的分類器進行 tp->ops->destroy（） 周圍rtnl_lock來解決此問題。為了解釋為什麼我使用臨時變數not_lockless我想指出一個關於rtnl_held與TCF_PROTO_OPS_DOIT_UNLOCKED的半相關註釋（如果認為有必要，請在此處添加以供將來清理）：rtnl_held 參數和 TCF_PROTO_OPS_DOIT_UNLOCKED 標誌是是否持有rtnl_lock的冗餘事實來源。在九個分類器中，破壞（..rtnl_held..）回呼時，只有 flower 會查閱它傳播到 tc_setup_cb_destroy（） 和 tc_setup_cb_call（） 的 rtnl_held 參數。其他八個（u32、flow、bpf、cgroup、route、basic、fw、mall）完全忽略它;->那些調用 tc_setup_cb_destroy（） （u32、bpf、mall）的總是硬編碼 true，而不是轉發參數。未來的清除應該完全從銷毀回呼簽章中移除 rtnl_held 參數，並讓呼叫端只依賴其是否在解鎖內容中執行的知識。
    (CVE-2026-74700)

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

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

  - drm/xe：修正 exec_queue_set_hang_replay_state（） 中的記憶體洩漏 q->replay_state 被盲目覆寫，這可能會洩漏先前由 vmemdup_user（） 配置的記憶體。如果 q->replay_state 不是空白，則傳回錯誤。使用 Intel 產品安全性確認的 AI 輔助靜態分析發現。（從提交 f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e 中挑選）（CVE-2026-74699）

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

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

  - bnge：修正輔助裝置版本中的 NULL 指標解除參照 如果在輔助裝置設定期間auxr_dev分配失敗，錯誤路徑會呼叫 auxiliary_device_uninit（），最終呼叫 bnge_aux_dev_release（）。發行回呼會無條件地解除參照 aux_priv->auxr_dev->pdev 以擷取父bnge_dev。由於尚未在此故障路徑上配置auxr_dev，因此取消參照會導致 NULL 指標異常 從輔助裝置的父bnge_dev而不是auxr_dev擷取父，並且只有在成功配置時才釋放auxr_dev。這可讓釋放回呼正確清理部分初始化的輔助裝置。（CVE-2026-74706）

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

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

  - 輸入：evdev - 擷取事件遮罩時清理事件類型索引 傳遞給 EVIOCGMASK / EVIOCSMASK ioctls 的使用者提供的事件類型索引可用來索引 evdev_get_mask_cnt（） 中的靜態計數陣列和 evdev_get_mask（） 中的用戶端 evmasks 陣列。雖然事件類型在架構上受EV_CNT限制，但推測執行可能會錯誤預測邊界檢查並執行越界載入。使用 array_index_mask_nospec（） 以無分支方式清理 evdev_get_mask_cnt（） 中的事件類型索引。這會將索引限制為 0 以進行安全的陣列存取，並在索引越界時強制傳回的計數為 0。
    我們不需要在 evdev_get_mask（） 中進行額外的 array_index_nospec（） 呼叫，因為 evdev_get_mask_cnt（） 推測地將越界類型的計數 （和產生的xfer_size） 強制為 0，從而防止對用戶端 evmasks 陣列進行任何推測記憶體存取。（CVE-2026-74683）

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

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

  - mm/damon/lru_sort：如果目標值為零，則 >10000 active_mem_bp damos_quota_score（） 的錯誤可能會觸發除以零。DAMON_LRU_SORT可讓使用者透過active_mem_bp參數設定熱記憶體配置的目標值。如果參數值為零，則避免將其設定為目標值。不過，它也會使用計算為「10000 - active_mem_bp + 2」的目標值來設定冷記憶體配置。
    因此，如果使用者設定active_mem_bp 10002，則冷記憶體配置的配額目標目標值可以為零。
    結果，可以觸發除以零。當使用者嘗試以 >10000 active_mem_bp參數值啟動 DAMON 時，傳回錯誤來修正。將active_mem_bp設定為 10002 是沒有意義的。它還需要模組參數寫入權限才能重現問題。也就是說，後果是相當糟糕的。重現此問題的一種可靠方法如下所示： # cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y >啟用 # dmesg -w [...][ 597.421247] 哎呀：除法錯誤：0000 [#1] SMP NOPTI [ 597.428848] RIP：0010：damos_quota_score+0x6f/0x480 此問題由 Sashiko 發現 [1]。（CVE-2026-74645）

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

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

  - mm/huge_memory：修正huge_zero_pfn爭用 修補程式系列 mm/huge_memory：修正huge_zero_pfn爭用，v2。在參照計數huge_zero_folio實作中存在微妙的爭用。快速路徑原子邏輯無法解釋這樣一個事實：在爭用 get_huge_zero_folio（） 安裝有效值後，縮減器（刪除最終huge_zero_refcount引腳）可能會用 shrink_huge_zero_folio_scan（） 中的 ~0UL 哨兵值覆蓋huge_zero_pfn。這會導致 huge_zero_folio 被正確設置，但huge_zero_pfn設置不正確，因此 is_huge_zero_pfn（） 和 is_huge_zero_pmd（） 會將巨大的零對開本錯誤地識別為普通的 THP 對開本。這可能會導致巨大的零對開本被分割，並以其他方式被錯誤處理。解決這個問題的方法非常微妙，因為存在原子快速路徑，因此必須非常謹慎地對待弱有序架構中的排序。第一次提交透過在 huge_zero_[pfn， folio， refcount] 寫入周圍引入微調鎖定來解決此問題，並仔細考慮在快速路徑中載入/儲存排序。它首先放置並保持盡可能小，以便它可以自行反向移植。第二次提交是純粹的清理，它會重新設計CONFIG_PERSISTENT_HUGE_ZERO_FOLIO邏輯，以更好地將持久性邏輯與動態配置的邏輯分開。此修補程式 （共 2 個）： 如果 ！CONFIG_PERSISTENT_HUGE_ZERO_FOLIO，則huge_zero_folio由 huge_zero_refcount 引用，並由 mm_get_huge_zero_folio（） 傳回。當呼叫端完成巨大的零頁時，其參照計數會遞減。只有縮減器可以將參照計數設為零。不幸的是，縮減器將參照計數遞減為零與並行頁面錯誤之間可能會發生爭用。這是因為如果非常不幸，shrink_huge_zero_folio_scan（） 可能會在將 huge_zero_refcount 設定為零和寫入無效值之間被搶佔。在此期間，get_huge_zero_folio（） 可以在 shrink_huge_zero_folio_scan（） 恢復之前寫入huge_zero_pfn。在這種情況下，巨大的零對開本將持續被錯誤識別，導致為巨大的零對開本輸入不適當的 THP 代碼路徑：CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan（） |atomic_cmpxchg（） 將 refcount 設定為 0 |xchg（） 將 huge_zero_folio 設定為 NULL |get_huge_zero_folio（） | |atomic_inc_not_zero（） -> 零被搶佔很長時間 |分配新的巨大零對開本 | |寫入有效的 huge_zero_folio v |寫入有效huge_zero_pfn 用 ~0UL 覆寫huge_zero_pfn <--- 無效的覆寫！這會導致 is_huge_zero_pfn（） 和 is_huge_zero_pmd（） 錯誤地為巨大的零頁面傳回 false，這可能會導致巨大的零對開本被錯誤分割等問題。
    請注意，問題出在huge_zero_pfn不huge_zero_folio，因為 get_huge_zero_folio（） 使用 cmpxchg（） 在重試迴圈為 NULL 的huge_zero_folio上進行門控，而 shrink_huge_zero_folio_scan（） 使用 xchg（） 來設定huge_zero_folio。透過引入微調鎖定 huge_zero_lock 來解決此問題，以防止並行寫入 huge_zero_folio、huge_zero_pfn 和 huge_zero_refcount。這裡需要非常小心以確保正確性：get_huge_zero_folio（） 中的快速路徑使用 atomic_inc_not_zero（），它位於關鍵部分之外，這意味著巨大的零分配被限制在零huge_zero_refcount上。快速路徑不使用 huge_zero_lock，因此關鍵區段與其無關。因此需要不變量 - huge_zero_refcount 必須： * 僅在huge_zero_lock關鍵區段中設定，以確保 huge_zero_pfn、huge_zero_folio 和 ---truncated--- （CVE-2026-74632） 的序列化

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

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

  - ALSA：us144mkii：重新提交時重新錨定捕獲 URB capture_urb_complete（） 重新提交每個捕獲 URB 而不錨定它：usb_get_urb（urb）;ret = usb_submit_urb（urb， GFP_ATOMIC）;錨定是提交的屬性，而不是 URB 的屬性。送還路徑會在 urb->complete（） 之前呼叫 usb_unanchor_urb （） ，因此從其自己的完成處理常式重新提交的 URB 會偏離錨點。捕獲 URB 在流開始時錨定一次，因此從第一次完成開始，tascam->capture_anchor 是空的。tascam_free_urbs（）、tascam_disconnect（）、tascam_suspend（） 和停止工作路徑都會呼叫 usb_kill_anchored_urbs（&tascam->capture_anchor） ，以便在釋放任何內容之前收穫捕獲 URB。當錨點空白時，這些呼叫會立即傳回，而 URB 會保持在主機控制器上排入佇列。
    然後，tascam_free_urbs（） 會傳回具有 usb_free_coherent（） 的擷取傳輸緩衝區，而 snd_card_free（） 會釋放內嵌 tascam 的 snd_card 分配 （card->private_data）。之後控制器會完成佇列的 URB，將裝置提供的資料寫入釋放的傳輸緩衝區，而 capture_urb_complete （） 會解除參照釋放的驅動程式物件。7.2.0-rc5 （arm64） 上的 KASAN： 錯誤： KASAN：dummy_timer 中的 slab-use-after-free 寫入，大小為 512，地址為 addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq 由任務 64 分配：usb_alloc_coherent tascam_alloc_urbs tascam_probe 由任務 170 釋放：usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface 錯誤：KASAN：capture_urb_complete 中的 slab-use-after-free 讀取，地址為 addr ffff0000170ee878 大小為 4 由任務 170 釋放：
    release_card_device snd_card_free tascam_disconnect 還原參照計數增加和重新提交之間的usb_anchor_urb（）。這也使處理常式的 usb_unanchor_urb（） 故障臂再次變得有意義，並將 usb_kill_anchored_urbs（） 還原為中斷連線、暫停和停止工作路徑上的屏障。
    刪除錨定的前提是 URB 已經從初始提交中錨定，一旦第一次回歸運行，該提交就不再成立。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74639）

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

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

  - net/x25：修正計時器對通訊端的釋放後使用 x25 計時器配備 mod_timer（） 並使用 timer_delete（） 取消，因此擱置計時器不會在通訊端上保留任何參照，並且取消不會等待已經在另一個 CPU 上運行的回呼。x25_heartbeat_expiry（） 也會無條件重新武裝，因此它可以在 __x25_destroy_socket（） 過了取消點後重新安裝 sk->sk_timer。以下內容
    __sock_put（） 會在計時器仍排入佇列時釋放通訊端，而下一次到期時會使用釋放的記憶體。
    KASAN 會報告 close（） 釋放的 kmalloc-2k 物件上的 slab-use-after-free。此處不能使用 timer_delete_sync（）：x25_heartbeat_expiry（） 和 x25_timer_expiry（） 都通過 __x25_destroy_socket（） 和 x25_disconnect（） 從它們將等待的計時器內部到達取消。使用 sk_reset_timer（） 武裝計時器，並使用 sk_stop_timer（） 取消計時器，讓武裝計時器擁有參照，並在兩個到期處理常式中釋放它。僅在 sk_hashed（sk） 仍為 true 時重新武裝活動訊號，因為
    __x25_destroy_socket（） 會在刪除通訊端之前取消連結該通訊端。以相同的方式武裝延遲的銷毀計時器，並在 x25_destroy_timer（） 中刪除其參照。使用 KASAN 在網絡上重現，心跳週期縮短，因此窗口重複出現。使用此修補程式後，再現程式不再觸發報告，並且 /proc/net/x25 會清空。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74628）

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

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

  - xdp：拒絕超出 Tailroom xdpf_clone（） 的複製skb_shared_info將廣播副本複製到單一頁面中，並將frame_sz設為PAGE_SIZE。__xdp_build_skb_from_frame（） 稍後會將該頁面視為一般 XDP 框架，並預期緩衝區末端有通常的 skb_shared_info 尾部空間。目前的檢查只會拒絕線性xdp_frame標頭、餘量和封包資料超過 PAGE_SIZE 的框架。由較大配置支援的來源框架仍然可以滿足該檢查，同時延伸至複製所需的共用資訊區域。當這類複製轉換回 skb 時，build_skb_around（） 會將 skb_shared_info 放在即時封包位元組上，之後的寫入可能會損毀 XDP 傳回中繼資料。拒絕複製，除非其線性區域適合 SKB_WITH_OVERHEAD（PAGE_SIZE） 內，符合 XDP 到 skb 轉換路徑已強制執行的尾室要求。（CVE-2026-74616）

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

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

  - netfilter： ebt_nflog：釘選 NFLOG 後端 nf_log_unregister（） 在每網拆解後執行，因此其最終的 RCU 寬限期也會耗盡從每網綁定取得記錄器的讀取器。但是，與 xt_NFLOG 和 nft_log 前端不同，ebt_nflog 將明確的 ULOG 日誌類型傳遞給 nf_log_packet（），而不保留所選記錄器模組上的引用。因此，當卸載 nfnetlink_log 時，ebtables nflog 規則可以保持可呼叫狀態。產生的交錯為： CPU 0 CPU 1 nfnetlink_log_fini（） unregister_pernet_subsys（） kfree（nfnl_log_pernet（net）） ebt_nflog_tg（） nf_log_packet（） nfulnl_log_packet（） instance_lookup_get_rcu（） 全域 ULOG 記錄器此時仍處於註冊狀態狀態，因此 CPU 0 釋放 per-net 狀態後，CPU 1 會取消參照它。KASAN 報告： 錯誤：KASAN：在 instance_lookup_get_rcu 中釋放後使用 slab-use-after-free 透過任務 poc/92 在 addr ff110001052e6210 讀取大小 8 呼叫追蹤：
    instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 由工作 90 分配：
    __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 由工作 93 釋放：kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] 驗證 ebt_nflog 規則時取得 ULOG 記錄器模組參照，並在規則被銷毀時釋放它。需要時，為舊版呼叫者請求 NFLOG 後端，與xt_NFLOG相符。這可防止模組拆卸，直到所有ebt_nflog規則都停止使用記錄器。
    (CVE-2026-74660)

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

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

  - misc：fastrpc：在取消對應作業之前從清單中移除緩衝區 fastrpc_req_munmap_impl（） 以取消對應任何緩衝區。緩衝區從DSP取消對應後，會從清單中移除緩衝區。如果多個執行緒同時叫用取消對應，這可能會產生潛在的爭用情形，其中一個執行緒可能會在另一個執行緒的取消對應作業仍在進行時，從清單中移除項目。在呼叫取消對應作業之前，先從清單中移除緩衝區項目，以修正此問題。如果取消映射失敗，則項目將重新添加到列表中，以便用戶空間可以重試取消映射，或者，當 DSP 進程被拆除並且所有 DSP 端映射與列表中的剩餘緩衝區一起釋放時，將在設備釋放期間清理緩衝區。（CVE-2026-74647）

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

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

  - net：修正通用 XDP 片段調整後的 skb 長度統計 通用 XDP 透過xdp_buff公開非線性 skb 片段。如果 XDP 程式調整片段區域，bpf_prog_run_generic_xdp（） 會xdp_frags_size複製回 skb->data_len，但會留下包含舊片段貢獻的 skb->len。
    片段縮小後，這會使 skb_headlen（） 大於實際線性區域。在重現的 UDP 接收路徑中，__skb_datagram_iter（） 從結構 skb_shared_info 開始，將 1024 位元組複製到使用者空間，越過實際的線性尾部。複製的位元組包括受影響 skb 的nr_frags、xdp_frags_size和來自 skb_shinfo（skb）->frags[0] 的核心指標。實際封包資料被置換了相同數量，並在最後被截斷。在替換之前減去舊data_len，然後添加新data_len，保持 skb->len 和 skb->data_len 同步。具有 MTU 64000 的 veth 對上的 60000 位元組 UDP 資料包從其片段區域縮短了 1024 位元組。在修正之前，所有 10 次執行都產生損毀的承載。修正後，所有 10 次執行都完全符合預期的承載。（CVE-2026-74665）

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

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

  - accel/amxdna：修正 amdxdna_insert_pages（） 中的頁面插入錯誤 amdxdna_insert_pages（） 中有兩個錯誤路徑，稱為 vma->vm_ops->close（vma），然後再將錯誤代碼傳回給呼叫端。這是不正確的：amdxdna_gem_obj_mmap（） 在呼叫 amdxdna_insert_pages（） 之前註冊一個 HMM 間隔通知程式，並且在出現硬錯誤時，它會跳轉到 hmm_unreg 以撤銷該註冊。手動調用 vm_ops->close（） 會刪除 shmem pages_pin_count和在 mmap 系統調用傳回之前支援 VMA 的 GEM 物件參照，會導致在 VMA 仍處於活動狀態時釋放這些資源。當處理程序稍後取消映射範圍時，核心 VMA 拆解將第二次呼叫 vm_ops->close（），從而產生參照計數反向溢位。將這兩個硬錯誤傳回取代為延遲錯誤方法，讓 VMA 保持運作狀態，並透過 HMM 範圍錯誤路徑重試頁面插入。
    (CVE-2026-74721)

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

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

  - netfilter： bridge：在非 IP 路徑上釋放範本 ct 橋接器 nftables ct 區域集規則可以在 nf_ct_bridge_pre（） 看到之前將 conntrack 範本附加到 skb。對於非 IPv4 和非 IPv6 EtherTypes，nf_ct_bridge_pre（） 目前會以 IP_CT_UNTRACKED 覆寫 skb->_nfct，而不會釋放現有的範本參照。這使得每個 cpu 模板以及配置用於並發使用的任何臨時模板都無法訪問並丟失內存，直到主機用完 slab 為止。在將框架標示為未追蹤之前，先重設 skb conntrack 狀態，以便將現有範本參照丟棄在非 IP 路徑上。
    (CVE-2026-74625)

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

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

  - net/ncsi：修正NCSI_CMD_SEND_CMD負載長度中的堆積 OOB 讀取 ncsi_send_cmd_nl（） 從帶內封包標頭的攻擊者控制的 ncsi_pkt_hdr.length 欄位中獲取要複製的位元組數，而來源緩衝區是可讀大小為 nla_len（） - sizeof（ncsi_pkt_hdr） 的 NCSI_ATTR_DATA netlink 屬性。這兩個長度來源永遠不會交叉檢查：僅強制執行 nla_len（） >= sizeof（struct ncsi_pkt_hdr）。當 hdr->length 設定大於屬性負載時 （最多 65535，最多可讀位元組 2032），ncsi_cmd_handler_oem（） 會使用 unsafe_memcpy（） 複製過網路連結屬性緩衝區的末尾，將最多 ~64KB 的核心堆記憶體洩漏到傳輸的 NCSI 命令封包中。目的地 skb 的大小取決於宣告的承載，因此寫入端不會溢位 - 這是純 OOB 讀取/資訊洩漏，可在具有已註冊 NCSI 裝置的系統上透過CAP_NET_ADMIN存取 （例如
    Aspeed BMC SoC 上的 OpenBMC，其中 NET_NCSI=y 是標準）。拒絕宣告的承載超出資料屬性結尾的命令。該問題由 Tencent Yunding Lab 的 autokbug 動態核心模糊器發現。CVE-2026-74694

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

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

  - s390/ism：修正 ism_dev_exit（） 期間 sba 和 ieq 的 UAF ism 中斷處理常式可以與 ism_dev_exit（） 並行活動，存取釋放的資料結構。unregister_ieq（） 之後不會產生新的中斷。在釋放 ism 資料結構之前，透過 free_irq（） 清空正在進行的中斷處理常式。
    (CVE-2026-74690)

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

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

  - Netty （io.netty：netty-codec-socks） 版本 4.2.0.Final 至 4.2.16.Final 和 4.1.x 4.1.136.Final 在 SOCKS4 （Socks4ClientEncoder） 和 SOCKS5 （Socks5ClientEncoder） 用戶端編碼器中包含空位元組、CRLF 和憑證插入弱點，無法驗證網域位址和驗證 （使用者名稱/密碼） 欄位。能夠控制這些欄位的攻擊者可插入空位元組或 CRLF 字元來截斷或變更值，進而可能啟用網域詐騙、SOCKS4 使用者識別碼截斷、驗證資料插入和通訊協定混淆。在 4.2.17.Final 和 4.1.137.Final 中修正。（CVE-2026-62380）

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

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

  - 封包：將壓力清除與環重新配置同步 packet_set_ring（） 更新 sk_receive_queue.lock 下的 RX 環狀態，但用於在釋放該鎖定後透過 po->prot_hook.func 發布 tpacket 接收模式。然後，packet_poll（） 和 packet_recvmsg（） 可以在清除環後執行壓力清除路徑，同時仍看到tpacket_rcv，導致 __packet_rcv_has_room（） 取消參照過時或空環儲存體。將現有的接收勾點指派移至與通道狀態更新相同的 sk_receive_queue.lock 區段。保持指派不變，包括在 TX 通道重新設定時，以避免新增修正程式不需要的行為變更。只有在觀察到PACKET_SOCK_PRESSURE之後，才會序列化使用相同佇列鎖定的 packet_recvmsg（） 壓力清除。如果標誌清晰且通訊端已遠離 tpacket_rcv，則 packet_set_ring（） 已經分離通訊端並等待 synchronize_net（），因此沒有新的封包輸入可以再次設定該標誌。packet_poll（） 已經持有 sk_receive_queue.lock，因此它直接使用新的解鎖協助程式。
    (CVE-2026-74666)

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

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

  - btrfs： lzo：拒絕沒有有效標頭的內嵌範圍 [錯誤] 對於特製的 btrfs 影像，讀取內嵌 lzo 壓縮檔案範圍時，可能會觸發下列 KASAN： 錯誤： KASAN：lzo_decompress+0x57d/0x700 中的 slab-out-of-bounds 依任務 btrfs_lzo_inlin/77 在 addr ffff888006f2e644 讀取大小 4 呼叫追蹤： <TASK> dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110
    __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_讀取+0xf8/0x1d0
    __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> [原因] 對於內嵌 lzo 壓縮檔案範圍，應一律有一個 lzo 標頭，記錄壓縮資料的總長度，後面接著一個區段標頭，記錄壓縮的 lzo 承載。但是，如果特製的內嵌 lzo 壓縮檔範圍僅包含 lzo 標頭，而沒有區段標頭或承載，則 lzo_decompress（） 仍會嘗試讀取區段標頭，導致讀取超出項目界限。此外，如果內嵌 lzo 壓縮檔範圍是分葉的第一個項目，則它會位於範圍緩衝區界限。上述邊界外讀取將超出範圍緩衝邊界，觸發上述 KASAN 報告。[修復]驗證內嵌 lzo 壓縮檔案範圍的總長度，以確保至少有一個 LZO 標頭和一個區段標頭，以及非零承載。[ 重構提交訊息以移除 slop ]（CVE-2026-74723）

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

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

  - 監控程式：at91sam9_wdt：在拆卸期間防止計時器重新武裝 at91_ping（） 會從其回呼中重新武裝監控程式計時器。timer_delete（） 既不會等待執行中的回呼，也不會阻止其重新武裝計時器，因此探查失敗或驅動程式移除可能會讓計時器在釋放後存取 devm 配置的 at91wdt。在兩個拆卸路徑上使用 timer_shutdown_sync（）。它會等候執行中的回呼，並拒絕回呼重新武裝計時器的任何嘗試。（CVE-2026-74687）

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

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

  - 封包：在傳送路徑中使用一致的hard_header_len TX_RING tpacket_snd（） 讀取 dev->hard_header_len，以進行 tpacket_fill_skb（） 中的 skb 分配和標頭建構。因此，並行網路裝置重新配置可能會使保留的餘量小於稍後推送的量，或使 copylen - hard_header_len負數。在處理環形框架之前hard_header_len一次快照，並將其用於幀限制、餘量分配、副本長度和 skb 構造。將快照傳遞至 tpacket_fill_skb（）。此處未解決 hard_header_len 和 header_ops->create 之間的單獨SOCK_DGRAM一致性問題。（CVE-2026-74668）

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

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

  - futex：進一步防止穩健的 futex 退出爭用 穩健的 futex 解鎖會在整個 futex 值中儲存 0
    - 擦拭FUTEX_WAITERS - 並喚醒一個服務員。該喚醒是一次性通知：協議依賴其接收者獲取 futex（並最終在意識到剩餘爭用時解鎖）或在再次休眠之前重新布防FUTEX_WAITERS。如果喚醒的服務員在執行任何一項操作之前就被殺死，則核心必須跳入並喚醒下一個任務。這是 futex 通訊協定的已知複雜問題，先前在提交 ca16d5bee598 中進行了部分修正 （futex：防止健全的 futex 退出爭用）。不幸的是，該修復還不夠。如果第三個工作同時透過未爭用的快速路徑重新取得 futex，則通知會遺失：健全的結束處理會看到它由另一個作業擁有，而且什麼都不做，而新擁有者在解除鎖定且沒有喚醒任何人時看不到任何FUTEX_WAITERS。剩下的服務員永遠睡在一個免費的 futex 後面：A 擁有 futex，B 和 C 睡在 FUTEX_WAIT uval == A |FUTEX_WAITERS 健壯的解鎖：儲存 0，FUTEX_WAKE（1） 喚醒 B uval == 0 D 快速路徑 取得：cmpxchg（0 -> D） uval == D，沒有 FUTEX_WAITERS B 在喚醒 B 退出行走之前被殺死，待處理 op：owner D ！= B -> 無操作 D 解鎖：無FUTEX_WAITERS -> 無喚醒 C 永遠沉睡這顯然是實作中的一個缺點， 無法保持FUTEX_WAITERS位一致。藉由增強健全清單結束處理程序來解決此問題，如果 futex 字由另一個執行緒擁有，但未設定 futex 字也執行額外的喚醒FUTEX_WAITERS。這並不能解決非爭用接管/釋放和釋放序列的問題，這個問題已經討論了多年，並已透過提交 3ca9595d9fb6（futex：新增對解鎖健壯 futex 的支援）和後續更改解決，但未能考慮到上述問題。在此變更的背景下，已經討論了基於爭用健壯 futex 的核心解鎖的更完整的解決方案，並且應該遲早會出現在主線上。[ tglx：稍微修改更改日誌並修正編碼樣式 ]（CVE-2026-74658）

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

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

  - eventfs：將子欄位用於 rcu 頭並新增記憶體屏障 當 eventfs inode 被釋放時，它會設定 ei->is_freed，然後使用其 ei->list 將其新增至 srcu 連結清單，因為 list 欄位是與 rcu 清單頭的聯集。由於 ei->list 用於迭代受 SRCU 保護的列表而不進行eventfs_mutex，因此沒有什麼可以阻止對該列表進行迭代以查看 ei->rcu 而不是 ei->list，並且它將讀取損壞的目標。若要修正此問題，請變更 rcu 清單標頭與子清單的並集。釋放 eventfs inode 時，請設定 is_free 並執行 smp_wmb（），然後再將 eventfs inode 新增至 SRCU 清單。在迭代 ei->children 清單時，在開始時執行 smp_rmb（），然後讀取 ei 的is_freed以查看子清單是否仍然有效。如果設定了is_freed，則讀取ei_child無效，迴圈應該立即結束。（CVE-2026-74605）

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

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

  - fbdev： bitblit：bit_cursor（） 中的界限檢查字形索引 bit_cursor（） 擷取游標下的字形，C = scr_readw（vc_pos）;src = vc_font.data + （（c &; charmask） * w * 高度）;其中，設定 vc_hi_font_mask 時0x1ff charmask。螢幕緩衝區值直接來自 scr_readw（），並且可能大於目前字型的字形計數。Syzkaller 透過 vcs_write（） 觸發此觸發。呼叫追蹤顯示 vc_screen.c 中的 vcs_write（） 使用 writev（） 將任意 16 位元值寫入 /dev/vcsa，而 vc_screen.c 中的 vcs_write_buf（） 透過 vcs_scr_writew（） 儲存，而不檢查字元計數。儲存的值稍後會在 bitblit.c 的 bit_cursor（） 中讀取。當字型從具有 512 個字元的字型變更為具有 256 個字元的字型時，螢幕緩衝區可以保留具有先前模式設定高位的字元，這也可能會產生相同的越界存取。錯誤：KASAN：soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor 中的全域越界。 c：70 在 addr ffff800086c57970 讀取大小 16 呼叫追蹤：soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c：70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c：365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c：1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c：883 update_region+0x100/0x18c drivers/tty/vt/vt.c：669 vcs_write+0x8ec/0xaf0drivers/tty/vt/vc_screen.c：685 bit_putcs_aligned（） 和 bit_putcs_unaligned（） 已將字形索引限制為 vc_font.charcount。在擷取屬性和遮罩之後，在為字體資料編製索引之前，在 bit_cursor（） 中套用相同的限制。此修正完成了在提交 18c4ef4e765a （fbdev：bitblit：bit_putcs* 中的界限檢查字形索引） 中開始的邊界檢查，該索引遺漏了游標路徑。此更改應該是安全的，因為 clamp 重複使用了 fbcon 中的現有合約：charcount 在 con_font_set（） 和 fbcon_font_set（） 中的 console_lock 下維護，並且在從 512 個字形切換到 256 個字形時hi_font_mask被清除。當字型切換後仍保留具有高位元的過時螢幕資料時，或當 vcs_write（） 儲存任意值時，將索引限制為 0 可防止越界讀取，而不會變更bit_putcs使用的相同後援游標語意。（CVE-2026-74635）

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

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

  - fs，fsverity：移除檢查 setattr_prepare（） 中啟用的 fsverity：此處不需要檢查核心中是否可用的 fs-verity。即使未啟用 fs-verity，檔案系統也可能有 fsverity 檔案。在這種情況下，截斷 fsverity 文件將成功，此檢查試圖防止這種情況。（CVE-2026-74596）

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

ID	名稱	嚴重性
338913	Linux Distros 未修補弱點：CVE-2026-62388	high
338912	Linux Distros 未修補弱點：CVE-2026-74696	high
338911	Linux Distros 未修補弱點：CVE-2026-74686	medium
338910	Linux Distros 未修補弱點：CVE-2026-74588	critical
338909	Linux Distros 未修補弱點：CVE-2026-74693	high
338908	Linux Distros 未修補弱點：CVE-2026-74708	high
338907	Linux Distros 未修補弱點：CVE-2026-74646	high
338906	Linux Distros 未修補弱點：CVE-2026-74598	high
338905	Linux Distros 未修補弱點：CVE-2026-74707	high
338904	Linux Distros 未修補弱點：CVE-2026-74631	high
338903	Linux Distros 未修補弱點：CVE-2026-74649	high
338902	Linux Distros 未修補弱點：CVE-2026-74677	high
338901	Linux Distros 未修補弱點：CVE-2026-74630	high
338900	Linux Distros 未修補弱點：CVE-2026-74648	high
338899	Linux Distros 未修補弱點：CVE-2026-74674	high
338898	Linux Distros 未修補弱點：CVE-2026-74613	high
338897	Linux Distros 未修補弱點：CVE-2026-68767	medium
338896	Linux Distros 未修補弱點：CVE-2026-74612	critical
338895	Linux Distros 未修補弱點：CVE-2026-74592	high
338894	Linux Distros 未修補弱點：CVE-2026-74669	critical
338893	Linux Distros 未修補弱點：CVE-2026-68768	medium
338892	Linux Distros 未修補弱點：CVE-2026-74623	medium
338891	Linux Distros 未修補弱點：CVE-2026-74724	high
338890	Linux Distros 未修補弱點：CVE-2026-74695	high
338889	Linux Distros 未修補弱點：CVE-2026-74717	high
338888	Linux Distros 未修補弱點：CVE-2026-74700	high
338887	Linux Distros 未修補弱點：CVE-2026-74699	medium
338886	Linux Distros 未修補弱點：CVE-2026-74706	medium
338885	Linux Distros 未修補弱點：CVE-2026-74683	high
338884	Linux Distros 未修補弱點：CVE-2026-74645	medium
338883	Linux Distros 未修補弱點：CVE-2026-74632	high
338882	Linux Distros 未修補弱點：CVE-2026-74639	high
338881	Linux Distros 未修補弱點：CVE-2026-74628	critical
338880	Linux Distros 未修補弱點：CVE-2026-74616	critical
338879	Linux Distros 未修補弱點：CVE-2026-74660	high
338878	Linux Distros 未修補弱點：CVE-2026-74647	high
338877	Linux Distros 未修補弱點：CVE-2026-74665	critical
338876	Linux Distros 未修補弱點：CVE-2026-74721	high
338875	Linux Distros 未修補弱點：CVE-2026-74625	high
338874	Linux Distros 未修補弱點：CVE-2026-74694	high
338873	Linux Distros 未修補弱點：CVE-2026-74690	high
338872	Linux Distros 未修補弱點：CVE-2026-62380	medium
338871	Linux Distros 未修補弱點：CVE-2026-74666	high
338870	Linux Distros 未修補弱點：CVE-2026-74723	critical
338869	Linux Distros 未修補弱點：CVE-2026-74687	high
338868	Linux Distros 未修補弱點：CVE-2026-74668	high
338867	Linux Distros 未修補弱點：CVE-2026-74658	medium
338866	Linux Distros 未修補弱點：CVE-2026-74605	high
338865	Linux Distros 未修補弱點：CVE-2026-74635	high
338864	Linux Distros 未修補弱點：CVE-2026-74596	medium

偵測

Nessus 的 Misc. 系列

high

high

medium

critical

high

high

high

high

high

high

high

high

high

high

high

high

medium

critical

high

critical

medium

medium

high

high

high

high

medium

medium

high

medium

high

high

critical

critical

high

high

critical

high

high

high

high

medium

high

critical

high

high

medium

high

high

medium