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

  - 輸入：ims-pcu - 修正非同步更新中的韌體洩漏 如果驗證失敗，則不會釋放韌體物件。使用 __free（韌體）確保韌體一律釋放。（CVE-2026-72077）

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

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

  - wifi：ieee80211：驗證 MLE 通用資訊長度 ieee80211_mle_common_size（） 使用第一個通用資訊八位元組作為所有已知 MLE 類型的通用資訊長度。但是，ieee80211_mle_size_ok（） 僅驗證基本、探查請求和 TDLS MLE 的八位元組。重新配置 MLE 在計算最小通用大小時也跳過了長度八位元組，而優先存取 MLE 跳過了通告通用資訊長度的驗證。考慮重新設定通用資訊長度八位元組，並驗證所有已知 MLE 類型的通告通用資訊長度。保持未知類型處理不變。[立即刪除誤導性評論]（CVE-2026-68471）

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

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

  - afs： 修正 net->cells_outstanding 錯位的 inc 修正在檢查 idr_alloc_cyclic（） 失敗之前遞增的 net->cells_outstanding，使計數在錯誤時遞增。（CVE-2026-72376）

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

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

  - netfilter： nft_set_pipapo：不要將錯誤的複製洩漏到未來的事務中 當記憶體配置失敗時，複製的nft_pipapo_match可能會進入錯誤狀態： - 某些欄位可以調整其查詢表的大小，而其他欄位則不能 - 位元可能已被切換 - 暫存映射可能過小，這也意味著 m->bsize_max 可能低於所需的大小 這意味著同一批次中的下一次插入可能會觸發越界寫入。此外，第一個失敗可能會導致錯誤的複製洩漏到下一個交易中，因為在此情況下永遠不會執行中止回呼 （上層看到錯誤，且未嘗試配置交易式要求）。記錄nft_pipapo_match結構的狀態： - 新 （原始複製） - MOD （具有良好狀態的修改複製） - ERR （潛在的虛假內容） 然後，當複製進入 ERR 狀態時，刪除和插入會失敗。如果第一次插入嘗試導致錯誤，請立即釋放複製。
    (CVE-2026-72252)

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

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

  - ipvs：在 head 重新分配 __ip_vs_get_out_rt（） 調用 skb_ensure_writable（） 後重新載入 IP 標頭，這可能會重新配置 skb->head。（CVE-2026-68476）

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

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

  - scsi：目標：繫結 PR-OUT TransportID 剖析至接收的緩衝區 core_scsi3_decode_spec_i_port（） 和 core_scsi3_emulate_register_and_move（） 將原始 PERSISTENT RESERVE OUT 參數緩衝區交給 target_parse_pr_out_transport_id（），而不告知其有多少位元組有效。對於 iSCSI TransportID （FORMAT CODE 01b），iscsi_parse_pr_out_transport_id（） 會以不受限制的 strstr（） 找到 ，i，0x ISID 分隔符號 （並在錯誤路徑上列印具有進一步不受限制的 %s 的名稱）。起始端可以提交 iSCSI 名稱既不包含 ，i，0x 子字串也不包含 NUL 終止字元的 TransportID，將參數清單填入結尾，讓掃描從緩衝區結尾執行。當參數清單跨越多個頁面時，緩衝區是多頁 vmap （transport_kmap_data_sg（）），因此過度讀取會進入尾隨的 vmalloc 保護頁面並哎呀 （KASAN：strstr 中的 vmalloc-out-of-bounds）。任何將 PR OUT 傳送到透過 iSCSI TPG 匯出的裝置的光纖 （包括透過 vhost-scsi 的客體） 都可以存取它。
    將收到的位元組數向下傳遞至剖析器，並預先驗證 iSCSI TransportID 自己的自我描述長度 （ADDITIONAL LENGTH + 4） 一次：如果它低於 spc4r17 最小值或大於接收的緩衝區，則拒絕它，然後按該長度綁定分隔符號搜尋、ISID 遍歷和名稱副本。這是調用方在剖析 （core_scsi3_decode_spec_i_port（） 將 tid_len 與 tpdl 進行比較，core_scsi3_emulate_register_and_move（） 根據 data_length 驗證它） 之後執行的長度檢查，在掃描之前移動。同時刪除未終止名稱的無限 %s。在複製到 i_str 之前，新增每個格式的明確名稱長度檢查，而不是使用 min_t 無訊息地截斷：對於格式代碼 00b，如果描述元內文 （tid_len - 4 位元組） 無法容納在 i_str[TRANSPORT_IQN_LEN] 中，則拒絕;對於格式代碼 01b，如果名稱部分（從 &buf[4] 到分隔符號）無法容納，則拒絕。這兩項檢查都會使每個格式分支的邊界意圖明確。在這裡，也拒絕 FORMAT CODE 01b TransportID，其 ，i，0x 分隔符號位於描述元的最後：
    這會留下一個空的 ISID，並將傳回的連接埠連結指標指向 buf + tid_len，一個經過描述元，然後註冊碼 （__core_scsi3_locate_pr_reg（） __core_scsi3_alloc_registration（）） 將其取消參照為 ISID 字串 -- 格式錯誤的描述元的參數緩衝區的相同過度讀取。（CVE-2026-72084）

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

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

  - fbcon：修正當 framebuffer 的模式清單變更時，不執行 vc_data fbcon_new_modelist（） 的主控台的 NULL 指標解除參照。對於每個對應到它的控制台並設定了 fb_display[i].mode，它會讀取 vc_cons[i].d 並將vc_num傳遞給 fbcon_set_disp（）。這假設具有模式集的主控台具有 vc_data，但它可以是 NULL。fbcon_set_disp（） 在檢查 vc_data 之前設定 fb_display[i].mode，而 fbcon_deinit（） 在釋放 vc_data 後保留設定的模式。然後fbcon_new_modelist（） 取消參照 NULL vc_data。只有在主控台有vc_data時，才設定 fb_display[i].mode。在 fbcon_set_disp（） 中設定模式之前檢查vc_data，並在 fbcon_deinit（） 中清除模式。然後，fbcon_new_modelist（） 中的現有模式檢查會略過此類主控台。（CVE-2026-74424）

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

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

  - 平台/x86：dell-laptop：修正 init 錯誤路徑中缺少的清理 dell_init（） 會在 dell_setup_rfkill（） 之後初始化數個資源，包括選用的觸控板 LED、鍵盤背光 LED、電池掛鉤、debugfs 目錄和 dell-laptop 通知程式。如果稍後的 LED 或背光登錄失敗，錯誤路徑只會撕毀電池掛鉤和 rfkill 資源。這會在 dell_init（） 傳回錯誤後註冊通知程式、debugfs 目錄、鍵盤背光 LED 和選用觸控板 LED。
    在拆卸 rfkill 之前添加缺少的清理呼叫。（CVE-2026-72144）

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

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

  - i3c：mipi-i3c-hci：修正 i3c_hci_addr_to_dev（） 中的爭用 i3c_hci_addr_to_dev（） 遍歷 bus->devs.i3c，受 bus.lock （rwsem） 保護。不過，它是從 MIPI I3C HCI IRQ 處理常式叫用的，該處理常式無法採用 bus.lock。這允許在 I3C 核心中並行新增/刪除裝置，以在周遊清單時修改清單，可能導致釋放後使用或當機。移除對匯流排裝置清單的相依性，並引入專用的查詢表。新增由 ibi_devs[] DAT 項目編製索引的陣列，並在 hci->lock 下維護。啟用或停用 IBI 時更新陣列，使其一律反映允許產生 IBI 的裝置集。還要在釋放 IBI 時進行更新，以涵蓋釋放 IBI 而未先停用時的極端情況（例如 i3c_master_add_i3c_dev_locked（）） 中的 oldedev）。將 i3c_hci_addr_to_dev（） 移至 core.c，使用新陣列重新實作它，並新增 lockdep 判斷提示以強制調用方持有 hci->lock。將 PIO 和 DMA IBI 處理中的訊息從錯誤降級為偵錯訊息，因為當狀況正常出現時，會有爭用視窗。（CVE-2026-72454）

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

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

  - mips： sched：修正 CPUMASK_OFFSTACK 記憶體損毀 此修補程式解決了嚴重的記憶體管理缺陷。啟用CONFIG_CPUMASK_OFFSTACK時，cpumask_var_t 是指標。因此，sizeof（new_mask） 的評估結果為指標大小，導致 copy_from_user（） 破壞遮罩指標。此外，舊邏輯在配置遮罩之前執行 copy_from_user（）。先配置new_mask來修正此問題。若要正確處理可變大小的使用者遮罩，請使用 cpumask_size（） 截斷過大的使用者遮罩，或用零填充大小過小的遮罩，然後再將資料直接複製到分配的緩衝區中。（CVE-2026-72181）

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

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

  - 跟蹤：使用 seq_buf 繫結合成欄位字串 合成欄位協助程式會在固定MAX_FILTER_STR_VAL緩衝區中建置前置詞的合成變數名稱和產生的 hist 命令。目前的程式碼會以原始 strcat（） 附加這些字串，因此長索引鍵清單、欄位名稱或已儲存的篩選器可以越過暫存緩衝區的結尾。使用 seq_buf 建立這兩個字串，如果合成變數名稱或產生的命令超過 MAX_FILTER_STR_VAL，則傳播 -E2BIG。這會保留現有的跟蹤端限制，同時使用用於有界命令建構的協助程式。[ sdr： 移動結構 seq_buf *s 以用於顛倒的聖誕樹格式 ]（CVE-2026-74391）

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

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

  - 提示：限制佇列追蹤點中的通訊端佇列傾印 tipc_sk_enqueue （） 會在通訊端由使用者內容擁有時保留 sk->sk_lock.slock 執行。微調鎖定會保護此路徑中的待辦專案佇列，但不會針對取用或清除sk_receive_queue的通訊端擁有者序列化。KASAN 報告：CPU：
    14 UID： 0 PID： 1050 通訊： tipc3 未受污染 7.1.0-rc6+ #126 搶佔（延遲） 硬體名稱：QEMU 標準 PC （i440FX + PIIX， 1996）， BIOS 1.15.0-1 04/01/2014 呼叫追蹤： <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c：123 print_report+0xce/0x5b0 mm/kasan/report.c：482 kasan_report+0xc6/0x100 mm/kasan/report.c：597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c：380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c：73 tipc_list_dump+0x208/0x2e0net/tipc/trace.c：187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c：3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h：188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c：2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c：1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c：1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c：1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c：825 splice_to_socket+0x7f9/0x1010 fs/splice.c：884do_splice+0xe21/0x2330 fs/splice.c：936 __do_splice+0x153/0x260 fs/splice.c：1431
    __x64_sys_splice+0x150/0x230 fs/splice.c：1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c：41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c：63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S：130 RIP：0033：0x71624e8aafe2 代碼：08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP：002b：0000716157ffed68 EFLAGS：00000246 ORIG_RAX：
    0000000000000113 RAX：ffffffffffffffda RBX：0000716157fff6c0 RCX：000071624e8aafe2 RDX：000000000000005f RSI：00000000000000000 RDI：0000000000000066 RBP：0000716157ffed90 R08：0000000000008000 R09：
    0000000000000001 R10： 000000000000000000 R11： 0000000000000246 R12： ffffffffffff00 R13： 0000000000000021 R14： 00000000000000000 R15： 00007fff89799c40 </TASK> tipc_sk_enqueue（） 中的TIPC_DUMP_ALL追蹤點也會傾印sk_receive_queue，因此可以取消參照通訊端擁有者已出佇列或釋放的 skb。將這些傾印限制為 TIPC_DUMP_SK_BKLGQ，以符合保留的微調鎖定所保護的佇列。將變更限制在佇列路徑內，當通訊端由使用者內容擁有時，可連線不安全的佇列傾印。（CVE-2026-72299）

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

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

  - net/sched： act_pedit：修正 tc 卸載中的 TOCTOU 堆積 OOB 寫入 在調整 flow_rule 緩衝區大小和填充緩衝區之間，花無鎖定方法存在 TOCTOU 爭用情形。zdi-disclosures@trendmicro.com 報告： cls_flower 分類器以 TCF_PROTO_OPS_DOIT_UNLOCKED 運作 （fl_change 在沒有 RTNL 的情況下執行），而 RTM_NEWACTION 則持有 RTNL，因此獨立的鎖定網域使爭用在實踐中可連線。KASAN 確認： 錯誤： KASAN：tcf_pedit_offload_act_setup+0x81b/0x930 中的 slab-out-of-bounds 由任務 poc-toctou/312 在 addr ffff888001f27520 寫入大小為 4 錯誤位址位於已配置的 288 位元組區域右側 0 位元組處 [ffff888001f27400， ffff888001f27520） （快取 kmalloc-512） 注意： 結果是堆積 OOB 將攻擊者控制的內容寫入相鄰的 slab 物件 （需要 CAP_NET_ADMIN）。此修正在所有地方使用 tcf_pedit_nkeys_locked（） 取代舊的 tcf_pedit_nkeys（） 在所有地方引入了 act->tcfa_lock 下的讀取tcfp_nkeys。此外，我們透過更仔細的會計來關閉大小讀取和填充讀取之間的剩餘 TOCTOU 視窗。如果剩餘容量為零或先前動作耗用，我們不會以無訊息方式截斷金鑰計數，這會導致不正確的動作語意卸載至硬體和次要 OOB 寫入，而是強制執行剩餘容量檢查，並在所需空間超過剩餘容量時傳回 -ENOSPC。（CVE-2026-72338）

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

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

  - can： bcm：在裝置移除後修正過時的 rx/tx 操作 RX：現有操作的RX_SETUP更新 （！） 無條件地跳過 can_rx_register（），即使並行NETDEV_UNREGISTER已經拆除其註冊 （op->rx_reg_dev == NULL）。這不會以無訊息方式重新啟用該更新篩選器的框架傳遞。在這種情況下，bcm_rx_setup（） 現在會重新註冊，同時保留 ifindex = 0（所有 CAN 設備）的rx_ops，這些設備永遠不會按原樣攜帶跟踪rx_reg_dev註冊。TX：bcm_notify（） 只處理 NETDEV_UNREGISTER 上的 bo->rx_ops，讓tx_ops有一個主動循環傳輸無限期地重新布防其 hrtimer 以執行 bcm_tx_timeout_handler（）。取消 hrtimer 可以防止失控計時器和任何插入到以後重複使用的 ifindex 中，因為在明確的 TX_SETUP 更新重新武裝它之前，沒有其他任何東西會呼叫 bcm_can_tx（） 用於操作。與 bcm_rx_unreg（） 不同，（） 會清除追蹤的rx_reg_dev以進行rx_ops，ifindex 故意保持不變以供tx_ops使用。bcm_tx_setup（） 總是拒絕 ifindex 0，因此清除它會擱淺 op：後來的TX_SETUP （bcm_find_op（）） 和 TX_DELETE （bcm_delete_tx_op（）） 都無法再次找到它，因為兩者都需要完全匹配的 ifindex。（CVE-2026-72116）

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

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

  - ipv4：igmp：修正 igmp_mod_timer（） 和 igmp_stop_timer（） 中潛在的記憶體洩漏 當計時器被刪除且未在 igmp_mod_timer（） 中重新布防，或在 igmp_stop_timer（） 中停止時，程式碼目前會使用 refcount_dec（&im->refcnt） 遞減多點傳送清單項目的參照計數器@im。不過，這兩個函式都可以從 RCU 讀取器路徑呼叫： - igmp_mod_timer（） 透過 igmp_heard_query（） -> for_each_pmc_rcu（） - igmp_stop_timer（） 透過 igmp_rcv（） -> igmp_heard_report（） 如果群組 im 被 ip_mc_dec_group（） 從清單中同時移除，則其參照計數可能已經遞減為 1。在此情況下，timer_delete（） 會成功，而 refcount_dec（） 會將參照計數從 1 遞減到 0。由於 refcount_dec（） 在物件達到 0 時不會釋放物件 （與 ip_ma_put（） 不同），因此 im 結構會洩漏。使用 ip_ma_put（im） 而非 refcount_dec（&im->refcnt） 來修正此問題，並將放置推遲到釋放微調鎖定之後。（CVE-2026-72321）

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

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

  - locking/rt：修正 rt_spin_unlock（） 中不正確的 RCU 保護 rt_spin_unlock（） 會在解鎖鎖定之前釋放 RCU 保護。這為以下 UAF 場景打開了大門：T1 T2 spin_lock（&p->lock）;rcu_read_lock（）;無效（p）;p = rcu_dereference（ptr）;rcu_assign_pointer（ptr， NULL）;if （！p） return;spin_unlock（&p->lock）;spin_lock（&p->lock） lock（&lock->lock）;rcu_read_lock（）;
    kfree_rcu（p）;rcu_read_unlock（）;....spin_unlock（&p->lock） rcu_read_unlock（）;結束寬限期 rcu_do_batch（） kfree（p）;UAF -> rt_mutex_cmpxchg_release（&lock->lock...）常規的旋轉鎖定在整個解鎖操作中使搶佔保持禁用狀態，這提供了完整的 RCU 保護，但 RT 替換無法類似於此。這同樣適用於 rwlock 替換。將 rcu_read_unlock（） 叫用移過解除鎖定作業，以符合非 RT 語意。這使得它與 rt_xxx_lock（） 不對稱，但這是無害的，因為調用者需要在整個鎖定操作中保持 RCU 讀取鎖定。migrate_enable（） 呼叫會保留在解除鎖定作業之前，因為解除鎖定路徑中沒有每個 CPU 作業，這需要將移轉保持停用狀態。(CVE-2026-72069)

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

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

  - md/raid10：修正寫入要求失敗時的writes_pending洩露 raid10_make_request（） 會在分派寫入要求之前使用 md_write_start（） 取得writes_pending參照。raid10_write_request（） 中的多個故障路徑完成 bio 並返回，而沒有到達正常的寫入完成路徑，導致對應的 md_write_end（） 被跳過。使 raid10_write_request（） 傳回一個狀態，指示寫入請求是否已成功排入佇列。這允許 raid10_make_request（） 在寫入請求失敗時使用 md_write_end（） 釋放writes_pending參照。（CVE-2026-72439）

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

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

  - perf/x86/amd/core：避免從 SVM 重新載入路徑啟用 BRS 分支取樣 （BRS） 和上次分支記錄 （LBR） 是互斥的硬體功能，兩者的使用者都會透過 cpuc->lbr_users 進行追蹤。
    在 CPU 上切換 SVM 時、會重新編程主機效能事件、以更新 HostOnly 篩選位元 （啟用虛擬化時設定、停用時清除）。在支援 PerfMonV2 的處理器上，此重新編程是透過呼叫 amd_pmu_enable_all（） 來重寫事件選擇器來執行。但是，amd_pmu_enable_all（） 也會調用 amd_brs_enable_all（），每當 cpuc->lbr_users > 0 時，它就會啟用 BRS。
    在具有 LBR 但沒有 BRS 的處理器上，具有作用中的 LBR 事件會滿足此門控。然後，核心會嘗試在 DebugExtnCfg （MSR 0xc000010f） 中設定 BRS 啟用位。由於該位在此類硬體上已被棄用，因此寫入會導致 #GP： 呼叫追蹤： <IRQ> amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410
    __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 RIP：0010：cpuidle_enter_state+0xc4/0x450 ？ cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b </TASK> 透過確保即使在 cpuc-> 時也不會從事件選擇器重新編程路徑啟用 BRS 來解決此問題lbr_users > 0。（CVE-2026-72325）

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

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

  - RDMA/mlx5：釋放硬體提供的 UAR 索引，而不是軟體索引釋放硬體傳回的 UAR 索引。（CVE-2026-74296）

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

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

  - ntfs：在fill_super失敗時釋放全磁碟區資源 ntfs_fill_super（） 的err_out_now路徑僅透過 kfree（vol） 釋放磁碟區結構，在每次掛載失敗時留下數個 vol 擁有的配置： - vol->nls_map，由 ntfs_init_fs_context（） 透過 load_nls_default（） 載入 （或由 ntfs_parse_param（） 中的明確 nls= 選項取代）， 永遠不會unload_nls（）'d。 - 一旦 name 屬性被剖析， $Volume 由 load_system_files（） 到 ntfs_ucstonls（） 分配的 vol->volume_label 不會由 load_system_files（） 自己的錯誤標籤釋放，也不是由僅在 d_make_root（） 失敗時執行的 fill_super（） 內嵌清理釋放。load_system_files（） 內部的任何後續故障都會洩漏它。- vol->lcn_empty_bits_per_page 在 unl_upcase_iput_tmp_ino_err_out_now 中沒有清除指標的情況下被 kvfree（） 處理，因此無法將其折疊成單一通用清理。因為故障路徑從不呼叫 ntfs_volume_free（） 並且永遠不會到達 d_make_root（） 內聯清理區塊（它位於標籤上方並被 load_system_files（） / kvmalloc 失敗 goto 跳過），所以這些資源會在每次失敗的掛載嘗試中累積，除了卸載模組之外沒有恢復的機會。這是一個無訊息洩漏：失敗之前載入的 inode 保持雜湊狀態，但當 sb->s_root 未設定時，generic_shutdown_super（） 會跳過 evict_inodes（），因此也不會發出CHECK_DATA_CORRUPTION警告。將每個磁碟區的釋放量向下移至err_out_now，並從上方標籤中刪除lcn_empty_bits_per_page kvfree（），以便在每個故障路徑上只執行一次清理。使用無條件的 kvfree（） / kfree（） / unload_nls（） 是安全的，因為它們都接受 NULL，並且之前釋放nls_map的上部標籤（d_make_root（） 內聯清理）已經清除了指標。（CVE-2026-72205）

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

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

  - s390/perf_cpum_cf：將遺漏的 array_index_nospec（） 新增至 __hw_perf_event_init（） ev 變數是透過 event->attr.config 控制的使用者空間，並在邊界檢查後用作陣列索引，但沒有推測障礙。新增缺少的 array_index_nospec（） 呼叫以防止推測執行。
    (CVE-2026-72236)

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

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

  - dmaengine： dw-edma：新增微調鎖以保護DONE_INT_MASK和ABORT_INT_MASK DONE_INT_MASK和ABORT_INT_MASK暫存器由所有 DMA 通道共用，修改它們需要讀取-修改-寫入順序。因為此作業不是不可部分完成的，所以如果兩個通道同時更新這些暫存器，則對 dw_edma_v0_core_start（） 的並行呼叫可能會引入爭用情形。新增微調鎖定以序列化對這些暫存器的存取，並防止爭用情形。[den：更新 dw_edma.lock 註解]（CVE-2026-72148）

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

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

  - ext4：修正 ext4_write_inline_data_end 中的核心錯誤 使用 mount 選項時 data=journal ，ext4_journalled_write_end（） 函式會錯誤地呼叫 ext4_write_inline_data_end（），而不檢查 inode 上是否仍設定 EXT4_STATE_MAY_INLINE_DATA 旗標。如果先前嘗試將內嵌資料轉換為範圍失敗 （例如，由於 ENOSPC） ，則會清除EXT4_STATE_MAY_INLINE_DATA旗標，但 EXT4_INODE_INLINE_DATA 旗標仍會保持設定。在此案例中，下次呼叫 ext4_write_begin（） 不會準備內嵌資料 xattr 進行寫入，但 ext4_journalled_write_end（） 會錯誤地嘗試寫入它，觸發 ext4_write_inline_data（） 中的 BUG_ON（pos + len > EXT4_I（inode）->i_inline_size），因為 i_inline_size 未展開。透過確保 ext4_journalled_write_end（） 僅在設定了 EXT4_STATE_MAY_INLINE_DATA 標誌時呼叫 ext4_write_inline_data_end（），以鏡像 ext4_write_end（） 和 ext4_da_write_end（） 的行為來解決此問題。（CVE-2026-74308）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: grow index root value before reparent header update ntfs_ir_reparent() moves the resident index root entries into an index block and leaves a small root stub containing the child VCN. That root stub can be larger than the existing resident value. For example, an empty root with value_length 48 has an index area of 32 bytes, while the large-index root stub needs index_length and allocated_size of 40 bytes. The current code publishes the larger index.index_length and index.allocated_size before resizing the resident value. If the resize returns
    -ENOSPC, the recovery path can call ntfs_inode_add_attrlist(), which looks attributes up again while the root header says allocated_size 40 but the resident value still only provides 32 bytes of index area.
    Lookup-time $INDEX_ROOT validation then correctly rejects that transient layout as corrupt. This reproduces as a generic/013 failure under qemu. In the failing run, the transient root had value_len=48, index_size=32, index_length=40, and allocated_size=40, and ntfsprogs-plus ntfsck reported Corrupt index root in MFT record 1177. When the root stub grows, resize the resident value before publishing the larger root header. If the resize fails, the old root remains valid for recovery lookups. Keep the existing header-before-resize ordering for shrink or same-size cases so the resident value never temporarily exposes an allocated_size beyond its bounds. (CVE-2026-72211)

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

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

  - net/sched： act_ct：保留碎片整理 tcf_ct_handle_fragments（） 呼叫 nf_ct_handle_fragments（） 中的tc_skb_cb，而不儲存和還原 skb->cb。重組協助程式會清除 IPCB/IP6CB，這會別名 tc_skb_cb/qdisc_skb_cb 控制緩衝區。因此，透過 act_ct 的片段化流量會遺失 qdisc 中繼資料 （例如 pkt_segs），並在啟用 panic_on_warn 時觸發 qdisc_pkt_segs（） 中的 WARN_ON_ONCE（）。儲存並還原 nf_ct_handle_fragments（） 周圍的完整tc_skb_cb，與 ovs_ct_handle_fragments（） 使用的模式相符。（CVE-2026-72057）

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

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

  - dm-integrity：不要將 hash_offset 遞增兩次hash_offset已經在迴圈中遞增 （i = 0; i < to_copy; i++， ts--）。不要再次遞增。（CVE-2026-72099）

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

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

  - scsi： xen： scsiback： 釋放未提交的命令，而不是重複放置它 scsiback_get_pend_req（） 取得命令標籤並傳回一個vscsibk_pend，其嵌入se_cmd僅被 memset 為 0，因此其cmd_kref為 0;se_cmd 只會在稍後在成功的 VSCSIIF_ACT_SCSI_CDB 路徑上初始化 （kref_init target_init_cmd（） scsiback_cmd_exec（） 中。在提交命令之前，scsiback_do_cmd_fn（） 中的兩個錯誤路徑 （失敗的 scsiback_gnttab_data_map（） 和未知的 ring_req.act ） 呼叫 transport_generic_free_cmd（&pending_req->se_cmd， 0），其 kref_put（） 的參照計數為 0。這會使它下溢 （refcount_t：underflow;use-after-free），並且由於未執行 release 函式，因此會洩漏命令標籤。
    影響：pvSCSI 客體可透過提交具有錯誤授權參照或未知要求類型的要求，洩漏 LUN 工作階段的每個命令標籤，從而停止 LUN;在panic_on_warn下，參照計數反向溢位會使主機陷入恐慌。新增一個協助程式，該協助程式僅傳回帶有 target_free_tag（） 的標籤並傳送錯誤回應。它會在 v2p 參照仍釘選工作階段時釋放標籤，並事先對回應欄位進行快照，因為釋放標籤可以讓另一個環重複使用 pending_req 插槽。
    (CVE-2026-72085)

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

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

  - riscv： probes：將原始 sp 儲存在 rethook trampoline 中 從 kretprobe 中的堆疊讀取單字會導致 risc-v 核心損毀。$ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable 無法處理虛擬位址0000000200000128的核心分頁要求 ...
    [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] tty_write+0x1a/0x30 在 regs_get_kernel_stack_nth 中，regs->sp 包含任意值。arch_rethook_trampoline 會將探測函式的暫存器儲存在結構pt_regs中。sp 未儲存。相反地，sp 會針對 arch_rethook_trampoline 的本機堆疊遞減。修正此損毀，並將原始 sp 與其他暫存器一起儲存。使用 a0 作為臨時暫存器，無論如何都會被覆蓋。
    [pjw@kernel.org：已新增 Fixes 標籤;抄送穩定版]（CVE-2026-72028）

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

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

  - ipv6： fib6：修正多批次轉儲時 fib6_walk_continue（） 中的 NULL 解除參照 inet6_dump_fib（） 將其進度儲存在 cb->args[1] 中，作為目前雜湊鏈中的位置索引。在批次之間，並發 fib6_new_table（） 可以在鏈頭插入新表，從而移動所有現有條目。然後，儲存的索引會落在不同的表上，導致 fib6_dump_table（） 將 w->root 設定為錯誤的表，而 w->node 仍指向前一個表。fib6_walk_continue（） 解除參照 w->node->parent （NULL） 並發生錯誤：
    錯誤：核心 NULL 指標解除參照，位址：0000000000000008 RIP：0010：fib6_walk_continue+0x6e/0x170 呼叫追蹤： <TASK> fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 透過將 tb->tb6_id 儲存在 cb->args[1] 中而不是位置索引來修正。在繼續時，跳過項目，直到 ID 相符為止;並行 head-insert 永遠無法比對已儲存的 ID，因此步行程式一律會在正確的表格上繼續。
    (CVE-2026-72392)

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

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

  - net/mlx5e：修正 priv->channel_stats[] 的發佈爭用 mlx5e_channel_stats_alloc（） 將新項目發佈到 priv->channel_stats[] ，然後將 priv->stats_nch 遞增為發佈權杖，但這兩個儲存區都不帶有任何記憶體屏障：priv->channel_stats[ix] = kvzalloc_node（...）; if （！priv->channel_stats[ix]） return -ENOMEM; priv->stats_nch++;並發讀取器計算從 priv->stats_nch 綁定的迴圈，然後使用純存取解除參照 priv->channel_stats[i]，例如 for （i = 0; i < priv->stats_nch; i++） { struct mlx5e_channel_stats *cs = priv->channel_stats[i]; ...cs->rq.packets ...
    } 在弱排序架構 （ARM、PowerPC、RISC-V） 上，對 channel_stats[ix] 和 stats_nch 的寫入可能會不按程式順序對其他 CPU 可見。讀取器可以觀察到 stats_nch == N，同時仍看到 channel_stats[N-1] == NULL，導致 channel_stats 迴圈中出現 NULL 指標解除參照。這在 BlueField-3 DPU （arm64） 的生產環境中觀察到，其中 ovs-vswitchd 在 NIC 啟動期間透過 netlink 查詢 netdev 統計資料，在另一個 CPU 上爭用 mlx5e_open_channel（） -> mlx5e_channel_stats_alloc（）：
    無法處理虛擬位址處的核心 NULL 指標解除參照 0x840 硬體名稱：BlueField-3 DPU 電腦：mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] 呼叫追蹤：mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] dev_get_stats+0x50/0xc0 ovs_vport_get_stats+0x38/0xac [openvswitch] ovs_vport_cmd_fill_info+0x194/0x290 [openvswitch] ovs_vport_cmd_get+0xbc/0x10c [openvswitch] genl_family_rcv_msg_doit+0xd0/0x160 genl_rcv_msg+0xec/0x1f0 netlink_rcv_skb+0x64/0x130 genl_rcv+0x40/0x60 netlink_unicast+0x2fc/0x370 netlink_sendmsg+0x1dc/0x454 ... __arm64_sys_sendmsg+0x2c/0x40 在 en.h 中新增 mlx5e_stats_nch_write（） 和 mlx5e_stats_nch_read（） 協助程式，以包裝 stats_nch 上的 smp_store_release（）/smp_load_acquire（） 對。發布/獲取對建立合約：stats_nch == N => channel_stats[0..N-1] 可見且非 NULL。透過寫入器中的 mlx5e_stats_nch_write（） 發布stats_nch增量 （mlx5e_channel_stats_alloc（）），並透過所有讀取器中的 mlx5e_stats_nch_read（） 讀取stats_nch：mlx5e RX/TX 佇列統計資料、mlx5e_get_base_stats（）、ethtool 通道統計資料、IPoIB 統計資料、sw_stats 折疊和 HV VHCA 統計代理程式。（CVE-2026-72341）

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

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

  - netfilter： nf_queue：當 NFQUEUE 持有假 dst 時，pin 橋接裝置 br_netfilter假 rtable 內嵌在結構net_bridge中，並使用 skb_dst_set_noref（） 附加到橋接封包。如果此類封包排入 NFQUEUE，__nf_queue（） 會使用 skb_dst_force（） 升級該假 dst。此時，佇列的 skb 可以在橋接器拆卸開始後保留真正的 dst 參照。問題不在於每個橋接資料包都需要自己的dst引用。問題在於，在取消註冊開始後，NFQUEUE 可以保持網橋私有假 dst 處於活動狀態。透過保持網橋假 dst 模型不變，並僅在資料包位於 NFQUEUE 中時固定網橋主機裝置來解決此問題。當佇列的 skb 攜帶橋接器假 dst 時，以 nf_queue_entry 記錄橋接器裝置，取得佇列存留期的裝置參照，並在佇列項目釋放時將其丟棄。此外，請確保在該網橋裝置關閉時收穫佇列的條目，並從虛假的 dst 檢測中刪除冗餘 nf_bridge_info_exists（） 測試。這會使 netdev_priv（br->dev） 保持活動狀態，直到判決完成，因此無法從 dst_release（） 下釋放內嵌的假 rtable 及其指標支援儲存。它還可以避免恆定的參照計數增加，並避免對 IPv6 橋接器流量使用 ipv4 特定的 dst 協助程式。（CVE-2026-72255）

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

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

  - RDMA/bnxt_re：韌體拆卸後釋放 SRQ 切換頁面 只有在韌體拆卸完成後才釋放切換頁面，以便 bnxt_qplib_destroy_srq（） 期間到達的 NQ 中斷不會將切換值寫入已釋放的頁面。在 bnxt_qplib_destroy_srq（） 之後移動 free_page（）。（CVE-2026-72500）

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

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

  - soundwire：修正了 syzkaller 發現的 sdw_add_element_group_count 中的錯誤sdw_add_element_group_count：當 i == num. for （i = 0; i <= num; i++） { if （rate == group->rates[i] &; lane == group->lanes[i]） ... 為了修正此錯誤，函數現在會在新增之前使用 for 迴圈檢查群組中現有的速率/車道條目（函數參數）。除了此修正之外，沒有功能變更。（CVE-2026-72488）

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

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

  - riscv： cacheinfo：修正 populate_cache_leaves 中的節點參照洩漏 目前，while 迴圈會在每次迭代中刪除對 prev 的參照。如果迴圈因中斷而提前終止，則最終of_node_put （np） 會正確刪除對目前節點的參照。不過，如果迴圈因為 np == NULL 而自然終止，則呼叫 of_node_put（np） 是無操作。這會讓最後一個有效節點儲存在 prev 中，而不會刪除其參照，從而導致節點參照洩漏。透過將最後的「of_node_put（np）」變更為「of_node_put（prev）」來修正此問題。（CVE-2026-72179）

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

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

  - 在之前 38.0.1的 OpenStack Ironic 中，使用自動偵測部署介面註冊或變更為自動偵測部署介面後，自動偵測部署介面可能無法立即執行清理。（CVE-2026-74250）

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

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

  - tipc：修正 cleanup_bearer（） 中由於過早 dst_cache_destroy（） 造成的 UAF，TIPC UDP 媒體承載拆解呼叫 dst_cache_destroy（） 在其複寫快取上，然後再呼叫 synchronize_net（） 以等待並行 RCU 讀取器（發射器）完成： static void cleanup_bearer（struct work_struct *work） { ...
    list_for_each_entry_safe（rcast， tmp， &ub->rcast.list， list） { dst_cache_destroy（&rcast->dst_cache）;
    list_del_rcu（&rcast->list）;kfree_rcu（rcast、rcu）;} ...dst_cache_destroy（&ub->rcast.dst_cache）;
    udp_tunnel_sock_release（ub->sk）;synchronize_net（）;... }這是非常有錯誤的，因為 dst_cache_destroy（） 會立即釋放每個 CPU 的快取記憶體 （free_percpu（）），並在不進行任何同步的情況下釋放快取的 dst 項目。如果並發發射器（例如 tipc_udp_xmit（））在 RCU 保護下的另一個 CPU 上運行，它可以同時調用 dst_cache_get（），從而導致： 1. 每個 CPU 快取指標本身的釋放後使用（當機）。2. rcuref - 如果 put（） 嘗試釋放由 dst_cache_destroy（） 同時釋放的 DST，則發出不平衡的警告。此外，在 synchronize_net（） 之後立即呼叫 kfree（ub），而不先關閉通訊端 （或在關閉通訊端後等待），會留下一個窗口，其中並發接收器 （tipc_udp_recv（）） 可以在 synchronize_net（） 之後啟動，存取 ub，並在 kfree（ub） 執行時遭受 UAF。要解決此問題，我們必須推遲 dst_cache_destroy（） 和 kfree（ub），直到我們確保不再有讀取器可以看到承載/通訊端並且所有現有讀取器都完成之後： 1. 使用 call_rcu_hurry（） 將 rcast 項目銷毀（dst_cache_destroy（） 和 kfree（））推遲到 RCU 回呼。
    使用 call_rcu_hurry（） 可確保快速釋放 dst 項目。2. 使用 udp_tunnel_sock_release（） 釋放承載通訊端 （停止新的接收讀取器）。3. 呼叫 synchronize_net（） 以等待所有未完成的 RCU 讀取器 （傳輸和接收） 完成。4. 現在安全了，在主承載快取上呼叫 dst_cache_destroy（），並釋放 ub。注意：3） 和 4） 可以稍後在 net-next 中更改，也可以使用 call_rcu_hurry（） 並消除 synchronize_net（） 延遲。(CVE-2026-72404)

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

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

  - dax/kmem：在移除時考慮部分不連續的資源 當 dev_dax_kmem_probe（） 部分成功 （至少映射一個範圍） 但後續範圍失敗 request_mem_region（） 或 add_memory_driver_managed（） 時，探查會以無訊息方式繼續，最終傳回成功，但對應的範圍資源為 NULL。dev_dax_kmem_remove（） 會反覆運算所有dax_device範圍，而不論基礎資源是否存在。稍後呼叫 remove_memory（） 時，它會傳回 0，因為從未新增記憶體，這會導致 dev_dax_kmem_remove（） 錯誤地假設可以移除 （不存在的） 資源，並嘗試在 NULL 指標上進行清理。藉由完全略過這些範圍來修正此問題，請注意這些案例會被視為成功，因此當所有實際新增的範圍都成功移除時，仍會完成清除作業。（CVE-2026-74379）

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

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

  - md/raid1，raid10：修正拆分 md 複製 bios 的生物核算 使用 md_cloned_bio（） 來控制生物核算，而不是依賴 raid1 中的 r1bio_existed 或 raid10 中的 io_accounting 標誌。先前的邏輯無法可靠地反映 bio 是否是 md 克隆的 bio。當錯誤路徑上的 bio_submit_split_bioset（） 分割並重新提交失敗的 bio 時，這可能會導致對 md 複製的 bios 進行雙重核算，或遺漏對從 bio_submit_split_bioset（） 傳回的 bios 進行核算，方法是使用 md_cloned_bio（） 來偵測 md 複製的 bios 並相應地跳過核算。（CVE-2026-74373）

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

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

  - wifi： wcn36xx：修正過大的韌體 HAL 回應產生的堆積溢位 韌體回應分派器會將所有同步 HAL 回應複製到 4096 位元組的hal_buf中，而不驗證回應長度。超過 WCN36XX_HAL_BUF_SIZE 的回應會導致包含韌體控制內容的堆積緩衝區溢位。
    在回應長度上新增邊界檢查。（CVE-2026-74341）

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

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

  - 藍牙：6lowpan：避免未追蹤的啟用工作 lowpan_enable_set（） 會配置臨時工作項目並在 system_wq 上排程 do_enable_set（），然後返回 debugfs。debugfs 作用中作業此時已結束，但背景工作角色仍會執行模組文字並操作enable_6lowpan和listen_chan。
    bt_6lowpan_exit（） 會移除 debugfs 檔案，並立即關閉並放入listen_chan。它沒有佇列工作專案的指標，因此無法在拆除背景工作角色使用的狀態之前取消或排清它。有錯誤的案例涉及兩個路徑，每個直欄顯示該路徑內的順序：debugfs enable write module exit 1。lowpan_enable_set（） 會配置 1.bt_6lowpan_exit（） 移除set_enable debugfs 檔案 2 的工作。schedule_work（） 佇列 2.bt_6lowpan_exit（） 關閉 do_enable_set（） 並放置listen_chan 3。
    寫入作業會傳回 3。模組拆解可以繼續 4.do_enable_set（） 稍後會針對過時狀態執行 改為在 lowpan_enable_set（） 中同步執行啟用狀態轉換。簡單的 debugfs setter 可以休眠，而且此檔案已在相同的set_lock下同步處理 6LoWPAN 控制項寫入。一旦設定器傳回，debugfs 移除會涵蓋整個作業，而且結束就無法再與未追蹤的工作專案爭用。驗證重現了此核心報告： 錯誤：KASAN：do_enable_set+0x113/0x2e0 中的 slab-use-after-free 工作佇列：事件do_enable_set [bluetooth_6lowpan] 有錯誤的位址屬於 ffff888109cb8000 （CVE-2026-72337） 的物件

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

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

  - Bluetooth： L2CAP：修正沒有回應的命令的 tx ident leak 提交 6c3ea155e5ee （Bluetooth：
    L2CAP：修正不追蹤未完成的 TX ident） 變更的 ident 分配以使用 IDA，在收到相符的回應命令時釋放 l2cap_put_ident（） 中的 id。但是，為未定義回應的命令配置的識別碼永遠不會釋放。特別是L2CAP_LE_CREDITS在 LE CoC 通道的生命週期內重複傳送，因此對等串流資料到主機會在 254 個信用封包之後耗盡 1-255 識別範圍。從那時起，l2cap_get_ident（） 失敗：核心：藍牙：無法分配 ident：-28，並且每個後續L2CAP_LE_CREDITS封包都以 ID 0 發送，這是無效的（核心規範，第 3 卷，第 A 部分，第 4 節：信令識別碼 0x00 是無效的標識符，絕不能用於任何命令）。驗證身分的遠端堆疊會丟棄這些命令，永遠不會收到新的積分，並且通道會永久停止。使用預設通訊端緩衝區時，這會在大約 0.5 MB 的接收資料之後發生 （確切數量取決於通訊端接收緩衝區）： < ACL 資料 TX：處理 2048 旗標 0x00 dlen 12 LE L2CAP：LE 流量控制積分 （0x16） 識別值 0 len 4 來源 CID：64 認可：1 傳送L2CAP_LE_CREDITS後立即釋放識別值，因為沒有任何回應會釋放它。使用本機變數而非 chan->ident，讓EXT_FLOWCTL通道可能正在等候的 IDENT（例如擱置中的重新設定）不會被信用封包覆寫。同時將缺少的 L2CAP_LE_CONN_RSP 大小寫新增至 l2cap_put_ident（），以便在回應到達時釋放為傳出L2CAP_LE_CONN_REQ命令分配的標識。（CVE-2026-72333）

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

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

  - mtd： spi-nor： swp： 改善鎖定使用者體驗 在第一個區塊被鎖定 （或前幾個區塊） 的情況下，如果使用者想要完全解鎖裝置，則有兩種可能性： - 要麼要求解除鎖定整個裝置，這可行;- 或者它只要求解鎖當前鎖定的區塊，但失敗了。它失敗，因為條件can_be_top和can_be_bottom為真。事實上，在這種情況下，我們解鎖了所有內容，因此 TB 位並不重要。然而，在當前的實現中，use_top為真（因為這是最喜歡的選項），並且lock_len（實際上應該減少到 0）被設置為 nor->params->size - （ofs + len），這是一個正數。這是錯誤的。一個簡單的方法是簡單地添加一個額外的條件。在unlock（）路徑中，如果我們能從兩邊獲得相同的結果，那就意味著我們解鎖了所有東西，lock_len必須簡單地為0。會新增註解以釐清該邏輯。（CVE-2026-72155）

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

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

  - RDMA/rxe：將 WQE 複製到非 SRQ 接收路徑中的本機緩衝區 對於非 SRQ QP，回應程式會直接從對應至使用者空間的共用佇列緩衝區讀取 WQE 欄位。這允許惡意使用者在核心處理 WQE 時修改 num_sge 或 sge 項目等欄位，從而導致 rxe_resp_check_length（） 和 copy_data（） 中的越界讀取。引入 get_recv_wqe（），在處理之前驗證num_sge並將 WQE 複製到核心本機緩衝區，與 get_srq_wqe（） 中已用於 SRQ WQE 的方法相符。srq_wqe緩衝區會重複使用，因為每個 QP 的 SRQ 和非 SRQ 路徑是互斥的。
    (CVE-2026-74377)

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

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

  - 提示：拒絕對等繫結的反轉服務範圍 tipc_update_nametbl（） 會使用直接從連線取得的服務範圍下限和上限，插入對等節點通告的繫結，而不檢查下限 <= 上限。本端繫結路徑會驗證排序 （tipc_uaddr_valid（）），但名稱散發路徑不會。具有下限>上端的繫結插入服務範圍 rbtree 的遠端 （鍵碼位於下方），其中任何查詢或撤回都無法與之匹配 （service_range_foreach_match（） 需要 sr->lower <= end）。然後，發佈、其 service_range 節點和增強的 rbtree 項目會在命名空間的存留期內洩漏，而且每個對等體上限不會等同於本機建立的繫結上TIPC_MAX_PUBL。也拒絕網路路徑中的反轉範圍。否則，對等節點可能會傳送具有較低>較大的 PUBLICATION 項目，以洩漏不受限制的繫結表格記憶體。（CVE-2026-74281）

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

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

  - VDUSE：避免將資訊洩露給使用者空間 跳出不一定是頁面對齊的，因此目前的 VDUSE 可以透過將跳出頁面映射到使用者空間來洩漏核心資訊。配置退信頁面
    __GFP_ZERO以避免將資訊洩露給使用者空間。（CVE-2026-72305）

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

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

  - netfilter： ipset：不要在雜湊類型的無鎖定 RCU 讀取器中使用 test_bit（）Sashiko 指出，有一些無鎖定 RCU 讀取器使用 test_bit（），這是一種寬鬆的原子操作，不提供記憶體屏障保證。如果操作可能與 add/del/gc 並行運行，請改用 test_bit_acquire（），即不是下一個情況之一 - 受區域鎖定保護 - 在集合銷毀階段 - 在新的/臨時的集合建立階段 （CVE-2026-72436）

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

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

  - drm/panthor：取得柵欄鎖定時，一律使用 IRQ 安全變體 由於dma_fence物件可以與其他子系統共用，因此可以從這些驅動程式中的 hardirq 內容存取它們，而且我們必須在取得鎖定時也使用 IRQ 安全變體來考慮這一點。同時，切換到防護模型。（CVE-2026-72388）

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

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

  - dmaengine：sh：rz-dmac：一切設定完畢後移動中斷請求 一旦請求中斷，中斷處理常式可能會立即執行。由於 IRQ 處理常式可以存取只有在請求 IRQ 後才初始化的通道>ch_base，因此這可能會導致無效的記憶體存取。同樣，IRQ 執行緒可能會存取未初始化的資料 （ld_free、ld_queue 和 ld_active 清單），這也可能導致問題。只有在設定完所有內容之後，才要求中斷。若要讓錯誤路徑更簡單，請使用 dmam_alloc_coherent（） 而非 dma_alloc_coherent（）。（CVE-2026-72146）

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

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

  - ata： libata-core：為 PNY CS900 1TB SSD 新增 NOLPM 怪癖PNY CS900 1TB SSD（群聯 PS3111-S11，無 DRAM）在空閒期間進入設備啟動睡眠後從匯流排上掉下來。使用預設med_power_with_dipm原則時，連結會關閉 （SStatus 1 SControl 300） 且無法復原，從而強制檔案系統為唯讀狀態。強制max_performance可在長時間閒置時保持鏈路穩定。新增 NOLPM 怪癖，以便專門針對此磁碟機停用鏈路電源管理，而對於主機上的其他裝置則保持不變。（CVE-2026-72031）

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

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

  - md/raid1，raid10：修正讀取錯誤復原路徑中的鎖死 raid1d 和 raid10d 可能會在處理讀取錯誤時重新提交分割的 MD 複製 bio。在這種情況下，如果陣列在 md_handle_request（） 透過 percpu_ref_tryget_live（） 取得active_io引用之前暫停，則重新提交生物可能會導致鎖死。由於複製的 bio 已經保存了一個active_io引用，因此嘗試透過 percpu_ref_tryget_live（） 獲取另一個引用可能會導致陣列暫停時出現鎖死。透過對 md 複製的 bios 使用 percpu_ref_get（） 來修正此問題。（CVE-2026-74375）

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

ID	名稱	嚴重性
335736	Linux Distros 未修補弱點：CVE-2026-72077	high
335735	Linux Distros 未修補弱點：CVE-2026-68471	high
335734	Linux Distros 未修補弱點：CVE-2026-72376	medium
335733	Linux Distros 未修補弱點：CVE-2026-72252	high
335732	Linux Distros 未修補弱點：CVE-2026-68476	critical
335731	Linux Distros 未修補弱點：CVE-2026-72084	critical
335730	Linux Distros 未修補弱點：CVE-2026-74424	medium
335729	Linux Distros 未修補弱點：CVE-2026-72144	high
335728	Linux Distros 未修補弱點：CVE-2026-72454	high
335727	Linux Distros 未修補弱點：CVE-2026-72181	high
335726	Linux Distros 未修補弱點：CVE-2026-74391	high
335725	Linux Distros 未修補弱點：CVE-2026-72299	critical
335724	Linux Distros 未修補弱點：CVE-2026-72338	high
335723	Linux Distros 未修補弱點：CVE-2026-72116	high
335722	Linux Distros 未修補弱點：CVE-2026-72321	medium
335721	Linux Distros 未修補弱點：CVE-2026-72069	critical
335720	Linux Distros 未修補弱點：CVE-2026-72439	high
335719	Linux Distros 未修補弱點：CVE-2026-72325	medium
335718	Linux Distros 未修補弱點：CVE-2026-74296	high
335717	Linux Distros 未修補弱點：CVE-2026-72205	medium
335716	Linux Distros 未修補弱點：CVE-2026-72236	high
335715	Linux Distros 未修補弱點：CVE-2026-72148	high
335714	Linux Distros 未修補弱點：CVE-2026-74308	medium
335713	Linux Distros 未修補弱點：CVE-2026-72211	critical
335712	Linux Distros 未修補弱點：CVE-2026-72057	high
335711	Linux Distros 未修補弱點：CVE-2026-72099	high
335710	Linux Distros 未修補弱點：CVE-2026-72085	critical
335709	Linux Distros 未修補弱點：CVE-2026-72028	medium
335708	Linux Distros 未修補弱點：CVE-2026-72392	medium
335707	Linux Distros 未修補弱點：CVE-2026-72341	medium
335706	Linux Distros 未修補弱點：CVE-2026-72255	high
335705	Linux Distros 未修補弱點：CVE-2026-72500	high
335704	Linux Distros 未修補弱點：CVE-2026-72488	high
335703	Linux Distros 未修補弱點：CVE-2026-72179	medium
335702	Linux Distros 未修補弱點：CVE-2026-74250	medium
335701	Linux Distros 未修補弱點：CVE-2026-72404	high
335700	Linux Distros 未修補弱點：CVE-2026-74379	medium
335699	Linux Distros 未修補弱點：CVE-2026-74373	medium
335698	Linux Distros 未修補弱點：CVE-2026-74341	high
335697	Linux Distros 未修補弱點：CVE-2026-72337	medium
335696	Linux Distros 未修補弱點：CVE-2026-72333	high
335695	Linux Distros 未修補弱點：CVE-2026-72155	high
335694	Linux Distros 未修補弱點：CVE-2026-74377	high
335693	Linux Distros 未修補弱點：CVE-2026-74281	high
335692	Linux Distros 未修補弱點：CVE-2026-72305	medium
335691	Linux Distros 未修補弱點：CVE-2026-72436	critical
335690	Linux Distros 未修補弱點：CVE-2026-72388	high
335689	Linux Distros 未修補弱點：CVE-2026-72146	high
335688	Linux Distros 未修補弱點：CVE-2026-72031	high
335687	Linux Distros 未修補弱點：CVE-2026-74375	medium

偵測

Nessus 的 Misc. 系列

high

high

medium

high

critical

critical

medium

high

high

high

high

critical

high

high

medium

critical

high

medium

high

medium

high

high

medium

critical

high

high

critical

medium

medium

medium

high

high

high

medium

medium

high

medium

medium

high

medium

high

high

high

high

medium

critical

high

high

high

medium