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 的判定取決於廠商所報告的套件是否存在。

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

  - net/openvswitch：檢查 key_extract（） 中的乙太網路標頭長度 當封包到達 ARPHRD_NONE 裝置 （例如 TUN） 時，ovs_flow_key_extract（） 信任使用者提供的 skb->protocol 欄位：如果是 ETH_P_TEB，則封包被歸類為 MAC_PROTO_ETHERNET 並呼叫 key_extract（），而不確保 skb 具有 ETH_HLEN （14） 位元組的線性資料。key_extract（） 無條件地為 MAC 位址拉取 2 * ETH_ALEN 位元組，而 parse_ethertype（） 再拉取 2 個位元組，當線性區域太小時，這兩種情況都會觸發 __skb_pull（） 中的核心錯誤。核心錯誤位於 include/linux/skbuff.h：2848！RIP：0010：key_extract+0xa7e/0xd90 net/openvswitch/flow.c：933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 透過在存取乙太網路標頭之前呼叫 key_extract（） 中的 check_header（） 來修正。（CVE-2026-74701）

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

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

  - ipv4：修正 RTA_VIA nexthops 的 fib_nlmsg_size（），fib_nlmsg_size（） 仍會估計 nexthop 空間，就好像每個閘道都編碼為 IPv4 RTA_GATEWAY屬性一樣。IPv4 路由也可以攜帶 IPv6 閘道，該閘道會fib_nexthop_info（） 轉儲為RTA_VIA。因此，路由通知可能會配置太小的 skb。然後 fib_dump_info（） 會以 -EMSGSIZE 失敗，而 rtmsg_fib（） 會命中將此類失敗標記為 fib_nlmsg_size（） 錯誤的 WARN_ON（）。設定panic_on_warn後，這會變成核心錯誤。在 fib_nlmsg_size（） 中鏡像實際的 nexthop 轉儲配置：考慮傾印為 RTA_VIA 的 IPv6 nexthop 網關、RTA_MULTIPATH 內部使用的無標頭 rtnexthop 配置，以及僅在實際存在時才考慮RTA_FLOW。
    (CVE-2026-74657)

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

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

  - fsverity：修正 bpf_get_fsverity_digest（） dynptr 假設 BPF 驗證程式和 dynptr 抽象概念可確保 dynptr 參照的記憶體空間保持有效。但是，它們不提供記憶體內容穩定的任何保證。即使發生並行修改，kfuncs 也應保持記憶體安全。bpf_get_fsverity_digest（） 沒有遵循這一點：如果同時修改 arg->digest_size，它可能會崩潰。改用已知良好的值 hash_alg->digest_size 來修正此問題。同時將 'dynptr_sz' 和 'out_digest_sz' 擴大為 u64，以符合
    __bpf_dynptr_size（）。目前似乎實際上不會超過 INT_MAX（因為
    __bpf_dynptr_data_rw（） 排除檔案型指標），但也可以使用正確的類型。
    (CVE-2026-74590)

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

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

  - 暫存：rtl8723bs：修正 rtw_get_wpa_ie（） 中的 OOB 讀取 rtw_get_wpa_ie（） 會以固定位移將位元組讀取到廠商特定資訊元素中，而不檢查元素是否足夠長，導致短尾端 IE 的越界讀取。此函式會使用 rtw_get_ie（） 找出廠商特定的 IE （EID 221），然後比較 pbuf + 2 處的 4 位元組 OUI+類型，並讀取 pbuf + 6 處的 2 位元組版本字。這些存取需要 IE 本文至少為 6 個位元組，但 rtw_get_ie（） 僅保證元素適合緩衝區;它不強制執行最小主體長度。因此，長度位元組為 0 到 5 的廠商特定 IE 會放置在緩衝區結尾，因此會讓這些讀取經過 IE 的結尾，並經過緩衝區本身的結尾。緩衝區會保存從收到的管理框架和傳遞至 rtw_cfg80211_set_wpa_ie（） 的 IE blob 取得的資訊元素，其會 kmemdup 到其確切長度，因此讀取可以在配置結束時執行。此檔案中的同級協助程式 rtw_get_sec_ie（）、rtw_get_wapi_ie（） 和 rtw_get_wps_ie（） 已經在其 OUI memcmp（） 之前拒絕太短的供應商特定 IE;
    rtw_get_wpa_ie（） 從未與它們保持一致，並且由於版本詞的原因，至少需要 6 個位元組而不是 4 個位元組。新增缺少的長度檢查。（CVE-2026-74651）

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

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

  - devlink：修正重新載入 devlink_nl_reload_doit（） 呼叫 devlink_netns_get（） 中的網路命名空間參照洩漏，其傳回具有保留參照的網路。當要求的名稱空間與目前的名稱空間不同，且重新載入動作未DRIVER_REINIT時，函數會傳回 -EOPNOTSUPP，而不釋放參照。
    在此錯誤路徑上新增缺少的 put_net（）。（CVE-2026-74718）

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

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

  - 透過元素 ID [fedora-all]CVE-2026-77682 （） 中未清理的 CSS 選擇器在自動填充中插入 JavaScript 程式碼

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

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

  - PDFio 之前 1.6.5 在字典字串格式化函式中包含懸空指標弱點，該弱點會在文件字典中儲存堆疊本機緩衝區的指標，而不複製字串值。
    在多執行緒或集區要求環境中，攻擊者或並行使用者可以觸發跨要求的堆疊記憶體重複使用，藉由以另一個呼叫端的資料無訊息覆寫一個呼叫端的字典字串值，從而導致跨租用戶文件內容損毀。（CVE-2026-77220）

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

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

  - ninenines cowlib 中的輸出編碼不當或逸出弱點允許透過 cow_link：link/1 中的未逸出特殊字元走私連結標頭指令。cowlib 中的 cow_link：do_link/1 會將目標 URI、rel 值和屬性索引鍵直接內插到序列化的 Link： 標頭值中，而不進行逸出或標記文法驗證。目標中的 > 位元組會過早關閉 URI 插槽，攻擊者可使用攻擊者選擇的 rel 指令附加其他連結項目。rel 中的 A 或 \ 會逸出引號字串並開啟新參數。屬性索引鍵中包含空格、= 和的任何位元組都會逐字發出。因為瀏覽器會作用於 Link： 指令 （例如 rel=preconnect、 rel=preload和 rel=prerender），所以攻擊者可以影響應用程式中的這些欄位，而該應用程式透過 cow_link：link/1 來回穿越剖析的 Link 標頭，因此可以強制受害瀏覽器與攻擊者控制的來源建立頻外連線。此問題會影響 cowlib：從之前2.20.0開始2.9.0。（CVE-2026-43971）

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

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

  - FORT 驗證器是資源公開金鑰基礎結構 （RPKI） 信賴方驗證器，可產生已驗證的路由來源資料。FORT Validator 版本 1.6.7 在其 RRDP 處理中包含來源驗證錯誤：相同信任錨定位器 （TAL） 下的委派 CA 可以引用受害者 CA 的公共 RRDP 通知和快照 URL，導致 FORT 的基於 URL 的下載快取在刪除受害者的本機快照後報告成功。在例行的受害者發布之後，這可能會從 FIT 的輸出中默默地刪除受害者的 VRP 和其他簽名對象，從而可能導致路由劫持或失去可訪問性。版本包含1.6.8拒絕跨來源 RRDP 快照和差異 URL 的修補程式;因應措施是系統管理員可以使用 停用enabled=false HTTP/RRDP--http，同時保持啟用 rsync，但在不支援 rsync 的情況下，這可能會導致資料無法使用或過時。（CVE-2026-53499）

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

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

  - Miniflux 2 是一個開源提要閱讀器。在之前， 2.3.1internal/urllib/url.go 中的 IsRelativePath 接受包含反斜線的重新導向目標，因為 Go URL 剖析會將它們視為路徑字元。瀏覽器反斜杠正規化將它們轉換為正斜線。未經驗證的攻擊者可向登入流程提供此類redirect_url值、繞過相對路徑和主機檢查，並將受害者重新導向至攻擊者控制的外部網站。2.3.1 版已修正此問題。(CVE-2026-55185)

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

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

  - kin-openapi 是一個用於處理 OpenAPI 檔案的 Go 專案。From 0.124.0 until 0.142.0，openapi3filter/req_resp_decoder.go 中的 openapi3filter.sliceMapToSlice 透過將項目從零到提供的最大索引分配，將攻擊者控制的疏鬆索引從 deepObject 查詢參數轉換為密集切片，之後 buildResObj 會建立另一個相同長度的切片。此配置會在結構描述驗證之前發生，因此 maxItems 不會阻止它。未經驗證的用戶端可能會將 param[items][50000000]=x 等小型查詢傳送至其 deepObject 結構描述包含陣列的端點，強制執行數 GB 堆積配置，並造成 OOM 終止或重新啟動迴圈。其他不產生括弧整數索引的要求內文編碼和樣式參數不受影響。0.142.0 版已修正此問題。(CVE-2026-77354)

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

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

  - GNU Emacs 之前 31.0.91 在 PBM/PPM/PGM 影像載入器中包含整數溢位，攻擊者可以透過提供具有大尺寸和提高最大色彩指數的特製影像來洩漏堆積記憶體內容。圖像加載器使用帶正負號的整數算術乘以圖像尺寸和通道數;針對足夠大的值，結果會換行為負數，繞過界限檢查，並導致圖元讀取器存取超過配置緩衝區結尾的堆積記憶體。過度讀取的內容會解譯為像素色彩值，並在螢幕上轉譯。（CVE-2026-77219）

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

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

  - sh 提供 Python 進程啟動。在之前 2.2.4，sh.py 中的_uid選項會在 Linux 和類 Unix 系統上執行不完整的權限下降。當 sh 從提高許可權的處理程序執行並啟動命令時，並將 _uid 設為無特權使用者時，子項會變更其 UID，但可以保留父處理程序的補充群組，因為特權捨棄序列未完全建立目標使用者的 UID、主要 GID 和補充群組。因此，子系可以保留對授予特權群組 （例如 root、docker、disk、shadow 或 sudo） 的檔案或資源的存取權，違反預期的
    _uid權限界限。2.2.4 版已修正此問題。(CVE-2026-54552)

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

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

  - Tie：：Hash：：Regex 之前的 Perl 版本 2.0.0 會在無法解析的查詢鍵上擲回異常。FETCH、EXISTS 及 DELETE 方法會在格式錯誤的規則運算式上擲回例外狀況。當金鑰尚未儲存在雜湊中時，每個方法都會回歸到正則運算式比對，使用裸 qr// 編譯呼叫端的金鑰，而沒有評估防護。不是有效規則運算式模式的索引鍵 （例如單一不相符的括弧） 會消失。在繫結雜湊中查詢外部提供字串的應用程式會在無效的金鑰上終止。（CVE-2026-77781）

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

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

  - kin-openapi 是一個用於處理 OpenAPI 檔案的 Go 專案。From 0.10.0 until 0.141.0， openapi3filter/validation_error_encoder.go 中的 openapi3filter.convertParseError 會解除參照 e.Parameter.In，而不檢查 e.Parameter 是否為 nil。multipart/form-data 要求內文中格式錯誤的非字串純量欄位會產生具有 nil RequestError.Parameter 的巢狀 ParseError，以及透過 openapi3filter 轉譯驗證錯誤的應用程式。ConvertErrors 或 ValidationErrorEncoder 錯誤。當應用程式缺少復原界限時，未經驗證的用戶端可以重複傳送這類要求來拒絕服務。不使用這些錯誤轉譯協助程式的 JSON 要求內文和應用程式不會受到影響。0.141.0 版已修正此問題。(CVE-2026-76905)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。在版本之前 8.18.3，定義異常自訂 libvips 來源並使用它們來處理不受信任的未壓縮 PPM 影像的應用程式可能會觸發 libvips/iofuncs/source.c 中vips_source_read_to_memory的最大/最小錯誤。此函式在選取剩餘讀取大小時，會使用 VIPS_MAX 而不是 VIPS_MIN，允許在配置的堆積緩衝區之外寫入最多 4032 個位元組，並導致記憶體損毀或處理程序損毀。8.18.3 版已修正此問題。(CVE-2026-70654)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。在版本之前 8.18.3，在沒有 libtiff 支援但支援 ImageMagick 的情況下構建的 libvips 在透過 VipsForeignLoadMagick 載入精心製作的多頁 TIFF 時可能會溢出組合的框架高度。libvips/foreign/magick6load.c 和 libvips/foreign/magick7load.c 中的易受攻擊的計算會將每頁 Ysize 乘以n_frames，而沒有檢查邊界，這可能會導致堆積緩衝區過度讀取和處理程序損毀。大多數套件管理員組建都包含 libtiff，並且不會使用此受影響的後援路徑。8.18.3 版已修正此問題。
    (CVE-2026-70651)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。在版本之前 8.18.3，透過 VipsForeignLoadTiff 處理的特製多頻段 TIFF 可能會規避 libvips/iofuncs/image.c 中的掃描行驗證，並導致 vips_image_sanity 中的整數溢位。產生的緩衝區計算可以存取攻擊者控制的 mmap-resident 分配中的負偏移，從而允許讀取或寫入其他影像資料、可能透過未壓縮的 .v 輸出洩露資料，以及可能的處理程序崩潰。遠端程式碼執行尚未示範，但不能排除。8.18.3 版已修正此問題。
    (CVE-2026-69242)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。在版本之前 8.18.3，當管線在透過 VipsForeignSaveUhdr 編碼增益對應之前，將傳入的 JPEG 放大為非常大的輸出時，以 libultrahdr 支援建置的 libvips 可能會在 vips_foreign_save_uhdr_set_raw_hdr內錯誤地調整 libvips/foreign/uhdrsave.c 中的輸出緩衝區大小。配置過小可能會導致堆積緩衝區過度讀取，進而洩漏相鄰資料或當機進程。8.18.3 版已修正此問題。
    (CVE-2026-70652)

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

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

  - vhost：在 vring 重新配置時重設 vring 中繼資料快取 vq->meta_iotlb[] 會快取支援每個 vring 中繼資料區域的vhost_iotlb_map，並且 iotlb_access_ok（） 會在快取命中時儘早傳回，將命中視為該區域已通過驗證的證明：if （vhost_vq_meta_fetch（vq， addr， len， type）） 傳回 true;快取會在 VHOST_IOTLB_UPDATE 和 VHOST_IOTLB_INVALIDATE、裝置 IOTLB （重新）初始化和 vq 重設時重設，但在 VHOST_SET_VRING_ADDR 取代 vq->desc、vq->avail 和 vq->used 時，以及 VHOST_SET_VRING_NUM 變更區域大小時不會重設。連接裝置 IOTLB 後，當 vq 處於活動狀態時，會接受兩個 ioctl，並且都不會在 ioctl 時驗證位址：vq_access_ok（） 和 vq_log_used_access_ok（） 會提前傳回 true，因為位址是 GIOVA，因此會將驗證延遲到預先擷取時間。一旦填入快取，延遲驗證就不再執行 -- vq_meta_prefetch（） 會命中過時的項目並傳回 true -- 並且 vhost_vq_meta_fetch（） 會繼續將舊的對應轉換為 map->addr + addr - map->start 對於對應不再涵蓋的位址。
    vhost_copy_to_user（） 和 vhost_copy_from_user（） 會使用 __copy_to_user（） 和
    __copy_from_user（），也不會檢查它，因此後續使用的環更新或描述元擷取會存取 IOTLB 實際映射區域之外的記憶體。每當重新設定 vring 時，重設中繼資料快取，以便透過 iotlb_access_ok（） 的慢速路徑推送新位址。（CVE-2026-74580）

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

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

  - Capstone 是解編架構。在 6.0.0-Alpha9 和更早版本中，Capstone 的 arch/SH/SHDisassembler.c SH 浮點解碼器 （例如 opFADD、opFMUL 和 opFSUB） 使用 sh_info.op.op_count 調用 set_reg（） 和 set_reg_n（），而不檢查固定大小的運算元[] 陣列。透過 cs_disasm_iter（） 或 cs_disasm （） 處理的重複特製指令 （CS_ARCH_SH、CS_MODE_SH2A 或 CS_MODE_SH4A、CS_MODE_SHFPU 和 CS_OPT_DETAIL） 可以增加運算元計數超過 176 位元組sh_info配置，並執行 4 位元組堆緩衝區溢位寫入。損毀可能會使進程當機，並可能根據堆積配置啟用程式碼執行。此問題已在 6.0.0-Alpha10 版中修正。（CVE-2026-55893）

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

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

  - Capstone 是解編架構。在 6.0.0-Alpha9 和更早版本中，Capstone 的 arch/SH/SHDisassembler.c sh_disassemble（） 函數從原始 16 位元指令計算 idx 值，而不確保它位於活動模式特定的 decode[] 函數指標表內。使用具有 CS_MODE_SH2A 或 CS_MODE_SH4A 和 CS_MODE_SHFPU 的 CS_ARCH_SH 的應用程式可以透過 cs_disasm_iter（） 或 cs_disasm（） 傳遞特製的位元組碼，導致 decode[idx] 測試讀取表格外部，並因分割錯誤而終止處理程序。沒有程式碼執行或資訊洩露。此問題已在 6.0.0-Alpha10 版中修正。（CVE-2026-55894）

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

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

  - libre 是一個通用庫，用於具有非同步輸入和輸出支持的實時通信。在之前 4.8.1，src/websock/websock.c 中的 websock_decode（） 函式在驗證使用 64 位元擴充長度編碼的遮罩 WebSocket 框架時包含整數溢位。當 hdr->len 接近UINT64_MAX時，表達式 4 + hdr->len 可以換行，導致 mbuf_get_left（） 邊界檢查通過。
    後續的 XOR 取消遮罩迴圈接著寫入堆積緩衝區之外。使用 websock_accept（） 或 websock_accept_proto（） 實作 WebSocket 伺服器的應用程式會受到影響，而且在 HTTP WebSocket 升級交握後，惡意利用可能會導致攻擊者控制的堆積損毀或拒絕服務。4.8.1 版已修正此問題。(CVE-2026-50161)

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

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

  - SPIP 之前 4.4.21 允許未經身份驗證的遠端攻擊者執行任意程式碼，正如 2026 年 8 月在野外被利用的那樣。這與透過 X-Spip-Filtre HTTP 要求標頭插入程式碼有關，而 analyse_resultat_skel 處理不當。（CVE-2026-77806）

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

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

  - mod_auth_openidc 是一個 OpenID 認證的驗證與授權模組，適用於實作了 OpenID Connect Relying Party 功能的 Apache 2.x HTTP 伺服器。在之前 2.4.19.4，「mod_auth_openidc」的狀態 cookie 剖析器中存在越界讀取和一個位元組越界寫入。此問題已在版本 2.4.19.4 中修正，方法是在字串終止字元處停止掃描，因此拒絕無值權杖。沒有可用的產品內因應措施。作為權宜之計，拒絕或正規化格式錯誤的「Cookie」標頭 （缺少「=」的權杖） 的上游反向 Proxy 或 WAF 可以減少風險，但建議的補救措施是升級。（CVE-2026-54789）

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

ID	名稱	嚴重性
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
338863	Linux Distros 未修補弱點：CVE-2026-74701	high
338862	Linux Distros 未修補弱點：CVE-2026-74657	medium
338861	Linux Distros 未修補弱點：CVE-2026-74590	high
338860	Linux Distros 未修補弱點：CVE-2026-74651	high
338859	Linux Distros 未修補弱點：CVE-2026-74718	high
338851	Linux Distros 未修補弱點：CVE-2026-77682	high
338850	Linux Distros 未修補弱點：CVE-2026-77220	high
338849	Linux Distros 未修補弱點：CVE-2026-43971	medium
338848	Linux Distros 未修補弱點：CVE-2026-53499	high
338847	Linux Distros 未修補弱點：CVE-2026-55185	medium
338846	Linux Distros 未修補弱點：CVE-2026-77354	high
338845	Linux Distros 未修補弱點：CVE-2026-77219	medium
338844	Linux Distros 未修補弱點：CVE-2026-54552	high
338843	Linux Distros 未修補弱點：CVE-2026-77781	high
338842	Linux Distros 未修補弱點：CVE-2026-76905	high
338817	Linux Distros 未修補弱點：CVE-2026-70654	medium
338815	Linux Distros 未修補弱點：CVE-2026-70651	medium
338814	Linux Distros 未修補弱點：CVE-2026-69242	high
338809	Linux Distros 未修補弱點：CVE-2026-70652	low
338807	Linux Distros 未修補弱點：CVE-2026-74580	high
338806	Linux Distros 未修補弱點：CVE-2026-55893	high
338805	Linux Distros 未修補弱點：CVE-2026-55894	medium
338804	Linux Distros 未修補弱點：CVE-2026-50161	critical
338803	Linux Distros 未修補弱點：CVE-2026-77806	critical
338802	Linux Distros 未修補弱點：CVE-2026-54789	high

偵測

Nessus 的 Misc. 系列

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

high

medium

high

high

high

high

high

medium

high

medium

high

medium

high

high

high

medium

medium

high

low

high

high

medium

critical

critical

high