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

  - clk：qcom：gdsc：拆除 gdsc_unregister（） 中的每個網域 genpds gdsc_unregister（） 會移除 OF 提供者項目並拆除父/子網域佈線，但絕不會在 gdsc_init（） 註冊的個別 generic_pm_domain 結構上呼叫 pm_genpd_remove（）：void gdsc_unregister（struct gdsc_desc
    *desc） { 結構裝置 *dev = desc->dev; size_t num = desc->num; gdsc_pm_subdomain_remove（desc， num）;
    of_genpd_del_provider（dev->of_node）;} 這在全球gpd_list上留下了懸而未決的條目。在提供者解除綁定/重新綁定週期（早期啟動期間的延遲探查重播、擁有 GDSC 的 clk 驅動程式的實際模組卸載或 OF 重疊拆卸）之後，下一個 gdsc_init（） 最終會嘗試重新註冊仍在清單中的名稱，並且 pm_genpd_init（） 傳回 -EEXIST。當我們在這裡時，翻轉順序，以便首先刪除面向消費者的 OF 提供者項目 - 否則，與拆卸相關的新 of_genpd_get_from_provider（） 呼叫可能會附加到正在刪除的網域。
    在子網域連結被拆除後，迭代 scs[] 陣列和 pm_genpd_remove（） 每個已註冊的網域。監管機構保持 devm 管理 （gdsc_register（） 中的 devm_regulator_get_optional（） ），因此當底層裝置未綁定時，發布會自動發生;只是需要明確撤銷 genPD 帳戶。（CVE-2026-93145）

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

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

  - scsi： ufs： core： 避免 TX EQTR 內容中可能的記憶體回收鎖死 當 devfreq gear scaling 已靜止 UFS 標籤集時，TX EQTR 可能會執行。在這種情況下，函數 ufshcd_tx_eqtr（）、__ufshcd_tx_eqtr（） 和 ufs_qcom_get_rx_fom（） 使用 GFP_KERNEL 配置記憶體。如果觸發直接回收，回收/回寫可能取決於 UFS 裝置的 I/O。因為佇列處於靜止狀態，所以這可能會導致鎖死。
    在 ufshcd_tx_eqtr（） 中使用 memalloc_noio_save/restore（） 來涵蓋 TX EQTR 呼叫樹中的所有分配，包括： - ufshcd_tx_eqtr（） 中的 params->eqtr_record - __ufshcd_tx_eqtr（） 中的 eqtr_data - ufs_qcom_get_rx_fom（） 中的參數 這比使用 GFP_NOIO 標記個別呼叫網站更可取，因為它會自動涵蓋呼叫樹狀結構中任何位置新增的任何未來分配，而不需要每個呼叫者都知道此限制。[mkp：按照 Bart 的建議修復標籤]（CVE-2026-93057）

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

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

  - net： stmmac：還原 RX DMA 位移中的NET_IP_ALIGN 由於 RX 路徑已轉換為零複製，因此頁面集區頁面會直接作為 skb 頭移交給堆疊，而 DMA 引擎寫入的位移量會決定封包標頭的對齊方式。在轉換之前，負載被複製到從 napi_alloc_skb（） 獲得的 skb 中，該 skb 保留 NET_SKB_PAD + NET_IP_ALIGN。轉換將餘量移至 stmmac_rx_offset（），但並未延續NET_IP_ALIGN，因此在 NET_IP_ALIGN 為 2 的架構上，IP 標頭現在會未對齊：64 （NET_SKB_PAD） + 14 （乙太網路） + 20 （IP） = 98 XDP 分支相同：256 （XDP_PACKET_HEADROOM） + 14 （乙太網路） + 20 （IP） = 290 這是 ARM32 致命的， 因為即使設定了 CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS，LDM 和 LDRD 也會陷入未對齊的位址上。
    任何收到的回應要求都會使電腦崩潰，例如： 未處理的錯誤：0x81873062 處的對齊異常 （0x001） 內部錯誤：：1 [#1] SMP ARM 硬體名稱：Altera SOCFPGA Arria10 PC 位於 icmp_echo+0x38/0xa8 LR 位於 icmp_rcv+0x22c/0x370 呼叫追蹤icmp_echo：從 icmp_rcv+0x22c/0x370 icmp_rcv 從 ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu 從 ip_local_deliver+0xc8/0x1a0 ip_local_deliver 從 ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish 從 ip_list_rcv_finish+ 0x110/0x118 ip_list_rcv_finish 從 ip_list_rcv+0xc8/0xdc ip_list_rcv
    __netif_receive_skb_list_core+0x170/0x1c0 ...napi_complete_done來自 stmmac_napi_poll_rx+0xcb0/0x1030 代碼：e24dd068 e59020a0 e28dc010 e0822001 （e8920003） 核心錯誤 - 未同步： 中斷中發生重大異常 錯誤指令是 icmp_echo（） 中 *icmp_hdr（skb） 的 ldm。透過將NET_IP_ALIGN新增回 RX 位移來修正，這會還原堆疊用來取得的對齊方式。請注意，提交 a955318fe67e （stmmac：對齊 RX 緩衝區） 在 2021 年進行了類似的變更，並被提交 12d125b4574b （stmmac： 還原 stmmac：對齊 RX 緩衝區） 還原，因為它會導致封包損毀。該修補程式將偏移量從 0 提高，而無需調整緩衝區大小帳戶，因此 DMA 引擎可以說寫入超過 RX 緩衝區的結尾，儘管這從來都不是根本原因。提交 df542f669307 （net：stmmac：切換至非 XDP RX 路徑中的零拷貝），因為從 stmmac_rx_offset（） 衍生頁面集區分配，因此會考慮額外的位元組。（CVE-2026-90059）

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

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

  - btrfs： qgroup：修正 qgroup_free_reserved_data（） 中錯誤的長度計算 在該函數中，我們將起始位置向下舍入，結束位置四捨五入。但在@len的計算過程中，我們使用round_up（start + len， sectorsize），這是四捨五入的結束位置，而不是四捨五入的長度。
    這會導致更大的長度，後來我們仍然使用 start + len，這是完全不正確的。透過宣告本機@aligned_start和@aligned_len來修正它，然後改用它們。
    (CVE-2026-90259)

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

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

  - media：ipu6：init 後不要釋放輔助裝置 pdata ipu6_bus_initialize_device（） 將 isys/psys pdata 指標儲存在結構ipu6_bus_device中並初始化輔助裝置。在那之後，錯誤還原必須刪除輔助裝置參照，並讓 ipu6_bus_release（） 釋放匯流排裝置和 adev->pdata。當 MMU 初始化失敗時，isys 和 psys init 路徑已呼叫 put_device（），而 ipu6_bus_add_device（） 會在 auxiliary_device_add（） 失敗時呼叫 auxiliary_device_uninit（）。因此，這兩個路徑都會執行匯流排釋放回呼。呼叫端中額外的 kfree （pdata） 可以第二次釋放相同的物件。在初始化輔助裝置之後移除手動 pdata 釋放。此問題由靜態分析檢查程式發現，並經手動來源檢閱確認。（CVE-2026-93070）

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

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

  - bpf：檢查所有不可部分完成 RMW 路徑的指標類型 不可部分完成 RMW 驗證只有在目前目的地為PTR_TO_ARENA時才會記錄指令指標類型。因此，第二條路徑可以使用普通指標到達相同的指令，而無需將其與已儲存的競技場類型進行比較。驗證後修正會使用儲存的類型重寫指令，以針對每個路徑BPF_PROBE_ATOMIC。
    記錄所有不可部分完成 RMW 路徑的實際目的地類型，以便現有的不相符檢查拒絕一條指令的不相容使用。（CVE-2026-90177）

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

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

  - btrfs：zoned：不要在重新定位合併的暫時性 -EAGAIN 上強制唯讀 在分區 FS 上，每當過度認可的中繼資料加上 zone_unusable 位元組超過中繼資料區塊群組中的可用大小時，btrfs_delayed_refs_rsv_refill（） 就會傳回 -EAGAIN，以避免在一個交易中過度認可中繼資料和早期 ENOSPC。如果在執行回收時發生此情況，則交易將中止。將 -EAGAIN 視為區塊群組回收時的軟式、可重試條件。
    (CVE-2026-90266)

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

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

  - m68k： nfcon：不要在 nfcon_device（） 中呼叫 console_is_registered（），因為 7c2af0f634f1 （tty： tty_io：使用 console_list_lock 進行清單同步） show_cons_active（） 呼叫 console_list_lock 下的 .device（） 方法，但 console_is_registered（） 也嘗試取得 console_list_lock，造成鎖死。這裡應該沒有必要檢查 console_is_registered（），因為當控制台未註冊時，不應在第一個位置呼叫該函數。（CVE-2026-90158）

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

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

  - HID：在清理失敗的探測之前同步輸入 hid_device_io_start（） 允許報告與探測同時執行。如果探查隨後失敗，__hid_device_probe（） 會釋放驅動程式資源並清除 hdev->driver，而不先排除這些報告回呼。例如，當失敗路徑釋放相關聯的 hidraw 物件時，報告可能會輸入 hidraw_report_event（），當報告採用物件的清單鎖定時，會導致釋放後使用。在執行失敗的探查清除之前停止輸入。這會重新取得driver_input_lock，並等候任何已在進行中的報告回呼。（CVE-2026-90329）

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

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

  - ASoC： dapm： 修正第二個列舉通道上的差一檢查 當 item[0] 到達 e->items 時，snd_soc_dapm_put_enum_double（） 會拒絕它，但會讓 item[1] 等於它。兩者都繼續 snd_soc_enum_item_to_val（），它索引 e->值，沒有自己的邊界，因此具有值表的枚舉會讀取一個元素。索引與 MUX 合併一起出現，這放寬了同一塊中的項目 [1] 檢查。它刪除的值 MUX 處理常式在那裡使用 >=，而 soc-ops.c 中的 snd_soc_put_enum_double（） 仍然如此。只有 adav80x 會將值表格與兩個班次配對，其第二個通道看起來是偶然的，但控制項確實會報告兩個值。寫三個進去讀出adav80x_mux_values的結尾。核心僅在預設關閉的 CONFIG_SND_CTL_INPUT_VALIDATION 下捕獲它。CVE-2026-90068

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

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

  - null_blk：在 init 錯誤路徑上釋放全域tag_set如果啟用shared_tags，null_setup_tagset（） 會透過 null_init_global_tag_set（） 配置全域tag_set。如果稍後裝置建立失敗，err_dev會銷毀預設裝置並呼叫 unregister_blkdev（），但絕不會釋放全域tag_set。由於模組 init 失敗，因此永遠不會叫用 null_exit（），因此全域tag_set的標籤和映射會永久洩露。釋放 err_dev 中的全域tag_set，與 null_exit（） 相符，如果 （tag_set.ops） blk_mq_free_tag_set（&tag_set）。（CVE-2026-90188）

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

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

  - firewire： core：修正 build_tree（） 錯誤路徑中的記憶體洩漏 在 build_tree（） 的錯誤路徑中，當函數傳回時，節點實例可以保留在本機鍊錶中。每當在自我 ID 序列中偵測到無效值時，每一個已配置的節點實例要么是鏈結清單中的項目，要么是其父節點的 ports 陣列中的項目。因此，透過從鏈錶的頭部遍歷鍊錶，可以安全地釋放分配的節點實例。使用 for_each_fw_node（） 釋放剩餘的節點執行個體，再返回給呼叫端。（CVE-2026-90213）

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

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

  - net：將缺少的 ref_tracker_dir_exit（） 新增到 alloc_netdev_mqs（） Sashiko 報告說，當 alloc_netdev_mqs（） 中的 alloc_percpu（） 或 dev_addr_init（） 失敗時，嘗試讀取 /sys/kernel/debug/ref_tracker/* 會導致無使用ref_tracker_dir_exit（） 崩潰，因為提交 4d92b95ff2f9 （net：新增 net device refcount tracker infrastructure） 將 （） 新增至僅 free_netdev（） 路徑。（CVE-2026-90135）

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

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

  - ipack： ipoctal：修正 remove 清理中的 UAF、null-ptr-deref 和 use-after-free 當 tty 工作階段仍處於活動狀態時移除裝置時，會出現三個問題： 1. struct ipoctal 的 UAF：remove 回呼透過 kfree（） 釋放 ipoctal，而 tty 操作仍可存取它。透過引入基於 kref 的存留期管理來修正 當 tty 被開啟時，kref 會進入 install（），當 tty 最終被破壞時，會在 cleanup（） 中釋放;remove（） 使用 kref_put（） 而不是 kfree（）。2. ipoctal_write_tty（） 中的 NULL 解除參照：__ipoctal_remove（） 透過 tty_port_free_xmit_buf（） 釋放xmit_buf，而使用者空間進程可能仍保留 tty fd 並呼叫 write（）。透過檢查 ipoctal_write_tty（） 中的空xmit_buf來修正。3. ipoctal_cleanup（） 中的 UAF：ipack_put_carrier（ipoctal->dev） 在 ipack_device_del（） 釋放 ipack_device 後解除參照 ipoctal->dev。透過在 probe（） 期間快取 ipoctal->carrier_owner 並直接在 cleanup（） 中呼叫快取指標上的 module_put（） 來修正，避免對 ipoctal->dev 進行任何存取。還在 struct ipoctal 中引入一個已移除的旗標，該旗標設定在 __ipoctal_remove（） 的開頭，並在每個存取硬體資源的 tty 操作中簽入 （port_activate、write_tty、set_termios、掛起、關機）。這樣可以防止在 remove（） 傳回後取消映射 devm_ioremap（） 區域時出現頁面錯誤。（CVE-2026-93050）

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

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

  - riscv， bpf：修正 bpf_jit_free 中的記憶體洩漏 當子程式呼叫 bpf_int_jit_compile（） 時，它會在第一次傳遞期間提前返回 （！prog->is_func || extra_pass 為 false），在後續的額外傳遞中保持 ctx->offset 處於活動狀態。如果後續子程式的 JIT 編譯失敗，BPF 核心會中止並呼叫 bpf_jit_free（） 來清理第一個子程式。但是，bpf_jit_free（） 無法釋放 jit_data->ctx.offset，這會導致 JIT 上下文偏移陣列的記憶體洩漏。透過在 bpf_jit_free（） 中新增缺少的 kfree（jit_data->ctx.offset） 來修正此問題。（CVE-2026-92519）

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

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

  - ksmbd：修正 ksmbd_alloc_user（） 中的 slab-out-of-bounds 讀取 ksmbd_alloc_user（） 會以 user->passkey_sz = resp->hash_sz 從掛載的 IPC 登入回應中複製 resp->hash_sz 位元組;user->passkey = kmalloc（resp->hash_sz， KSMBD_DEFAULT_GFP）;if （user->passkey） memcpy（user->passkey， resp->hash， resp->hash_sz）;resp->hash_sz 是回應提供的__u16，但 resp->hash[] 只有 KSMBD_REQ_MAX_HASH_SZ 位元組。格式錯誤或惡意的登入回應可能會設定hash_sz遠遠超過此值 （最高 65535），因此 memcpy（） 會讀取超過回應物件的結尾。ipc_validate_msg（） 不綁定hash_sz，因此在配置和複製之前，請拒絕任何hash_sz超過堆疊上 hash[] 緩衝區的回應。[ 2030.238706] 錯誤：KASAN：ksmbd_alloc_user+0x278/0x680 中的 slab-out-of-bounds [ 2030.240549] 由任務 kworker/4:1/18611 在 addr ffff888121bb6680 讀取大小 65535 [ 2030.242296] [ 2030.242710] CPU：4 UID：
    0 PID： 18611 Comm： kworker/4:1 未受污染 7.1.0-next-20260623-virtme #96 PREEMPT（lazy） [ 2030.242732] 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [2030.242743] 工作佇列：ksmbd-io handle_ksmbd_work [ 2030.242763] 呼叫追蹤：[ 2030.242769]2030.242776<TASK> [] dump_stack_lvl+0xa2/0xd0 [ 2030.242794] print_address_description+0x77/0x200 [ 2030.242815] ？ ksmbd_alloc_user+0x278/0x680 [ 2030.242831] print_report+0x58/0x70 [ 2030.242848] kasan_report+0x117/0x150 [ 2030.242869] ?ksmbd_alloc_user+0x278/0x680 [ 2030.242888] kasan_check_range+0x3c7/0x3f0 [ 2030.242908] ？ ksmbd_alloc_user+0x278/0x680 [ 2030.242925] __asan_memcpy+0x29/0x70 [ 2030.242942] ksmbd_alloc_user+0x278/0x680 [ 2030.242960] ksmbd_login_user+0xc3/0x120 [ 2030.242978] ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017] ？ __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035] ？ ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054] ？ __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090] ？
    __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126] ？ copy_from_kernel_nofault+0x199/0x300 [ 2030.243156] ？ __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173] ？ get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208] handle_ksmbd_work+0x954/0x1280 [ 2030.243230] ？
    __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249] ？ process_scheduled_works+0xa07/0x1490 [ 2030.243270] ？ process_scheduled_works+0xa07/0x1490 [ 2030.243291] process_scheduled_works+0xa70/0x1490 [ 2030.243320] ？
    __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340] ？ do_raw_spin_lock+0x130/0x300 [ 2030.243358] ？ lock_is_held_type+0x7b/0x110 [ 2030.243388] worker_thread+0x932/0xe20 [ 2030.243415] kthread+0x38a/0x470 [2030.243431] ？ __pfx_worker_thread+0x10/0x10 [ 2030.243451] ？ __pfx_kthread+0x10/0x10 [ 2030.243467] ret_from_fork+0x484/0x910 [ 2030.243485] ？ __pfx_ret_from_fork+0x10/0x10 [ 2030.243501] ？
    __switch_to+0xc77/0x12c0 [ 2030.243523] ？ __pfx_kthread+0x10/0x10 [ 2030.243540] ret_from_fork_asm+0x1a/0x30 [ 2030.243564] </TASK> [ 2030.2435702030.290164] [ ] 依任務 19279 分配：
    [ 2030.290911] kasan_save_track+0x3e/0x80 [ 2030.292179] __kasan_kmalloc+0x72/0x90 [ 2030.293217]
    __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467] handle_generic_event+0x59b/0x750 [ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553] genl_rcv_msg+0x606/0x7b0 [ 2030.297129] netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500] genl_rcv+0x2d/0x40 [ 2030.299273] netlink_unicast+0x7ba/0x930 [2030.300019] netlink_sendmsg+0x8c3/0xb00 [ 2030.301073] __sock_sendmsg+0xec/0x140 [ 2030.301579]
    __sys_sendto+0x357/0x470 [ 2030.302255] __x64_sys_sendto+0xe3/0x100 [ 2030.303425] do_syscall_64+0x135/0x460 [ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [2030.305819] 有錯誤的位址屬於 ffff888121bb6640 [ 2030.305819] 的物件，該物件屬於大小為 192 的快取 kmalloc-192 [ 2030.309595] 有錯誤的位址 ---truncated--- （CVE-2026-90174）

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

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

  - UDF 符號連結 pathComponent 標頭 OOB 讀取 udf_symlink_filler（） 可以輸入具有部分 pathComponent 標頭的 udf_pc_to_char（）。在存取完整 pathComponent 標頭之前，請先驗證其是否仍有足夠的輸入。拒絕格式錯誤的符號連結資料，否則會使 udf_pc_to_char（） 執行越界讀取。（CVE-2026-93055）

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

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

  - RDMA/erdma：處理 EQ 事件時保留 CQ 參照 EQ 處理常式會從 dev->cq_xa 中查詢 CQ，並在 xarray 鎖定之外叫用 CQ 完成或錯誤回呼。erdma_destroy_cq（） 可以從 xarray 中刪除 CQ 並釋放其佇列緩衝區和門鈴記錄，而先前排程的 EQ 處理常式仍在使用 CQ。新增 CQ 參照計數，並使用 refcount_inc_not_zero（） 在 xarray 鎖定下進行參照。
    在刪除 destroy-path 參照之前，請先從 xarray 中移除 CQ，然後等待進行中的 EQ 使用者，再釋放 CQ 資源。（CVE-2026-90309）

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

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

  - 韌體：arm_scmi：清理通道時避免 IDR 更新 scmi_cleanup_channels（） 會使用 idr_for_each（） 遍歷 TX/RX 通道 IDR，以釋放傳輸資源並破壞專用傳輸裝置，然後再呼叫 idr_destroy（） 。destroy 回呼會從正在遍歷的相同 IDR 中移除每個專案。此清理路徑不需要這，而且它是不安全的，因為 idr_for_each（） 在回呼執行時尚未推進其基數樹迭代器。從回呼中移除目前項目可能會使迭代器狀態失效。回呼也無法受到 rcu_read_lock（） 的保護，因為 scmi_device_destroy（） 可能會休眠。將 IDR 拆解留給下一個 idr_destroy（） 調用，並將回呼限制為裝置銷毀。（CVE-2026-93086）

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

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

  - RDMA/srp：修正將 wc->byte_len 傳遞給 srp_process_rsp（） 的截斷 SRP_CRED_REQ srp_recv_done（） 上的堆積資訊洩露。它不會傳遞任何內容給 srp_process_cred_req（） 和 srp_process_aer_req（），它們會從接收緩衝區讀取固定大小的欄位，而不檢查是否已接收這些欄位。緩衝區大小為 max_ti_iu_len，來自登入回應，未經驗證。如果目標通告 8，然後傳送 8 位元組的SRP_CRED_REQ，會讓啟動器從緩衝區末端之外讀取 req->tag。req->標籤會複製到SRP_CRED_RSP中並傳回，以便這些位元組到達目標。
    SRP_AER_REQ 的行為方式相同，也會讀取 req->lun。每個回應的洩漏為 8 位元組。max_ti_iu_len也會決定緩衝區來自哪個 slab 快取。使用 8 時，緩衝區是 kmalloc-8 物件，讀取完全位於其外部： 錯誤： KASAN：srp_recv_done+0x172b/0x1aa0 中的 slab-out-of-bounds 由任務 kworker/u8：3/50 在 addr ffff888104714da8 讀取大小 8，該任務屬於大小 8 的快取 kmalloc-8 錯誤位址位於已分配的 8 位元組區域右側 0 位元組 [ffff888104714da0， ffff888104714da8） 如果沒有 KASAN，傳回的位元組是 slab 中下一個的位元組。一次執行傳回 .strtab。
    srp_process_rsp（） 中的 rsp->data[3] 也有同樣的問題：在讀取之前只檢查resp_data_len。
    捨棄比正在剖析的結構短的要求，並在讀取tsk_mgmt之前檢查byte_len。（CVE-2026-90307）

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

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

  - RDMA/rxe：在呼叫 rxe_odp_init_pages（） 之前，修正 ODP init 錯誤處理路徑 rxe_odp_mr_init_user（） 儲存區 &umem_odp->umem 中的 >umem 中的 UAF。如果 rxe_odp_init_pages（） 失敗，rxe_odp_mr_init_user（） 會釋放umem_odp並傳回錯誤。然後，rxe_reg_user_mr（） 透過 rxe_cleanup（）、rxe_mr_cleanup（）、ib_umem_release（mr->umem） 來消除錯誤。ib_umem_release（） 的開頭有一個 IS_ERR_OR_NULL（umem） 檢查。但由於 mr->umem 在 rxe_odp_mr_init_user（） 的錯誤處理路徑中未重設為 NULL，因此檢查通過並讀取 umem->is_dmabuf 等已釋放的欄位，從而導致 UAF。釋放失敗的 ODP umem 後清除 mr->umem 來修正 UAF，這樣 MR 清除路徑就不會再次釋放它。（CVE-2026-90423）

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

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

  - misc： sgi-gru：移除中斷內容頁面表格遍歷 GRU TLB 遺漏處理常式會遍歷處理程序的頁面表格，而不保留頁面表格鎖定或對應頁面的參照。它也會在使用者頁面表格上使用核心頁面表格存取子，並僅支援 x86-64 上的 PMD 層級大型對應。拆下直接助行器。將中斷錯誤直接傳送至使用者輪詢模式，以便現有的呼叫作業系統後援在處理程序內容中重試它們。移除無法再遞增的 mmap-lock 失敗統計資料。
    (CVE-2026-90383)

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

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

  - ARM： 9481/2：中斷點：CFI 僅在需求時中斷點 這會從 ARM 中移除 stub hw_breakpoint_cfi_handler（），使其不會竊取中斷點類型 0x03 （ARM_ENTRY_CFI_BREAKPOINT），除非核心中主動使用 CFI。當不使用 CFI 進行檢測時，或者當在使用者空間中發出中斷點時，我們會從 hw_breakpoint_pending（） 未處理的錯誤傳回 1，以便使用者空間可以使用此中斷點。使用 LKDTM 和此命令列進行測試：echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT 仍可如預期運作。（CVE-2026-90306）

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

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

  - SMB： 伺服器：修正 ksmbd_ipc_login_request_ext（） 傳回緩衝區的洩漏 在 ksmbd_alloc_user（） 呼叫後無條件釋放它。kmemleak splat：未參照的物件0xffff888103b83540（大小 192）：comm pool-0、pid 16970、jiffies 4377290937十六進位轉儲（前 32 個位元組）：00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................回溯 （CRC 408CCC66）：__kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310
    ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-90175）

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

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

  - pinctrl：聯發科：將 devm_gpiochip_add_data（） 用於 GPIO 晶片 gpio_chip 配置了裝置管理的記憶體，但註冊了非託管的 gpiochip_add_data（）。當驅動程式內建時，這是無害的，但一旦它們可以建置為模組並解除綁定/rmmod，devm 就會在 gpio_chip 仍註冊時釋放記憶體，從而導致釋放後使用。向 devm_gpiochip_add_data（） 註冊，使其共用相同的裝置管理生命週期，這也可讓手動 gpiochip_remove（） 錯誤路徑消失。（CVE-2026-92482）

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

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

  - drm/rockchip： dw_dp：釋放核心資源 DisplayPort AUX 通道等核心資源會在 dw_dp_bind（） 期間初始化和註冊，但永遠不會取消註冊，這可能會導致記憶體洩漏和/或釋放後使用： [ 224.661371] 錯誤： KASAN：device_is_dependent+0xe0/0x2b0 中的 slab-use-after-free [224.662015] 由任務 modprobe/658 在 addr ffff00011aee8550 讀取大小 8 [ 224.662612] [ 224.662752] CPU：
    7 UID：0 PID：658 通訊：modprobe 未受污染 7.0.0-rc2-next-20260305 #14 搶佔 [ 224.662759] 硬體名稱：Radxa ROCK 5B （DT） [ 224.662762] 呼叫追蹤：[ 224.662764] show_stack+0x20/0x38 （C） [ 224.662772] dump_stack_lvl+0x6c/0x98 [ 224.662777] print_report+0x160/0x4b8 [ 224.662783] kasan_report+0xb4/0xe0 [224.662790] __asan_report_load8_noabort+0x20/0x30 [ 224.662796] device_is_dependent+0xe0/0x2b0 [224.662802] device_is_dependent+0x108/0x2b0 [ 224.662808] device_link_add+0x1f8/0x10b0 [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] [ 224.662864] component_bind_all+0x3a8/0x720 [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 [224.662904] component_master_add_with_match+0x1f4/0x230 [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] [ 224.662939] platform_probe+0xe8/0x168 [224.662945] really_probe+0x340/0x828 [ 224.662950] __driver_probe_device+0x2e0/0x350 [ 224.662954] driver_probe_device+0x80/0x140 [ 224.662959] __driver_attach+0x398/0x460 [ 224.662964] bus_for_each_dev+0xe0/0x198 [ 224.662968] driver_attach+0x50/0x68 [ 224.662972] bus_add_driver+0x2a0/0x4c0 [ 224.662977] driver_register+0x294/0x360 [ 224.662982] __platform_driver_register+0x7c/0x98 [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] 由於先前提交在 DW DP 核心程式庫中匯出了 dw_dp_unbind（） 函式來處理必要的清理工作， 在元件的 unbind（） 回呼及其 bind（） 錯誤路徑中使用它。（CVE-2026-93194）

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

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

  - btrfs： defrag：修正重組和 delalloc 空間保留之間的鎖死 使用 autodefrag 和 flushoncommit 執行 fsstress 時，除了範圍範圍鎖定之外，還會保留 defrag 在保留已變更和鎖定的對開本時保留 delalloc 空間而遇到鎖死。堆疊追蹤如下：
    [958.624] task：kworker/u50：3 state：D stack：0 pid：20365 tgid：20365 ppid：2 task_flags：0x4208060 flags：0x00080000 [958.626] 工作佇列：events_unbound btrfs_async_reclaim_metadata_space [btrfs] [958.627] 呼叫追蹤：[958.628] [958.628] <TASK> __schedule+0x4be/0x10f0 [958.629] ？ preempt_count_add+0x69/0xa0 [958.630] schedule+0x26/0xd0 [958.631] wait_current_trans+0x102/0x160 [btrfs] [958.632] ？
    __pfx_autoremove_wake_function+0x10/0x10 [958.633] start_transaction+0x374/0x900 [btrfs] [958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs] [958.635] flush_space+0xca/0x5e0 [btrfs] [958.636] ？
    _raw_spin_unlock+0x15/0x30 [958.637] ？ btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs] [958.639] ？
    _raw_spin_unlock+0x15/0x30 [958.640] ？ calc_available_free_space.isra.0+0x6f/0x110 [btrfs] [958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs] [958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs] [958.644] process_one_work+0x19d/0x3a0 [958.644] worker_thread+0x1c4/0x330 [958.645] ？
    __pfx_worker_thread+0x10/0x10 [958.646] kthread+0xfc/0x130 [958.647] ？ __pfx_kthread+0x10/0x10 [958.648] ret_from_fork+0x1f7/0x2c0 [958.648] ？ __pfx_kthread+0x10/0x10 [958.649] ret_from_fork_asm+0x1a/0x30 [958.650] </TASK>958.651[] task：kworker/u49：7 state：D stack：0 pid：52990 tgid：52990 ppid：2 task_flags：0x4208060 flags：0x00080000 [958.653] 工作佇列：回寫wb_workfn （flush-btrfs-334） [958.655] 呼叫追蹤：[958.655] [958.656] <TASK> __schedule+0x4be/0x10f0 [958.657] ？ __blk_flush_plug+0xe9/0x140 [958.658] schedule+0x26/0xd0 [958.658] io_schedule+0x42/0x70 [958.659] folio_wait_bit_common+0x12b/0x330 [958.660] ？ folio_wait_bit_common+0x100/0x330 [958.662] ？ __pfx_wake_page_function+0x10/0x10 [958.663] extent_write_cache_pages+0x599/0x830 [btrfs] [958.664] ？ acpi_fwnode_get_reference_args+0x1fa/0x270 [958.665] btrfs_writepages+0x77/0x130 [btrfs] [958.666] ？ __pfx_end_bbio_data_write+0x10/0x10 [btrfs] [958.667] do_writepages+0xc6/0x160 [958.668] __writeback_single_inode+0x42/0x310 [958.669] writeback_sb_inodes+0x231/0x570 [958.670] wb_writeback+0x8a/0x340 [958.671] wb_workfn+0xbf/0x450 [958.672] ？ finish_task_switch.isra.0+0xc1/0x350 [958.673] process_one_work+0x19d/0x3a0 [958.673] worker_thread+0x1c4/0x330 [958.674] ？ __pfx_worker_thread+0x10/0x10 [958.675] kthread+0xfc/0x130 [958.676] ？ __pfx_kthread+0x10/0x10 [958.676] ret_from_fork+0x1f7/0x2c0 [958.677] ？ __pfx_kthread+0x10/0x10 [958.678] ret_from_fork_asm+0x1a/0x30 [958.679] </TASK> [958.679] task：btrfs-cleaner state：D stack：0 pid：296750 tgid：296750 ppid：2 task_flags：0x208040 flags：0x00080000 [958.681] 呼叫追蹤：[958.682] [958.682] <TASK> __schedule+0x4be/0x10f0 [958.683] schedule+0x26/0xd0 [958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs] [958.685] ？ __pfx_autoremove_wake_function+0x10/0x10 [958.686] reserve_bytes+0x283/0x4c0 [btrfs] [958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs] [958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs] [958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs] [958.691] btrfs_defrag_file+0x903/0x1110 [btrfs] [958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs] [958.694] cleaner_kthread+0x97/0x1c0 [btrfs] [958.694] ？ __pfx_cleaner_kthread+0x10/0x10 [btrfs] [958.696] kthread+0xfc/0x130 [958.696] ？ __pfx_kthread+0x10/0x10 [958.697] ret_ ---truncated--- （CVE-2026-90265）

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

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

  - RDMA/cma：修正 syzbot 報告在非同步位址解析期間透過 addr_handler（） 觸發的 res_to_rt（） 中的 WARN_ON（！res->dev） res_to_rt中的警告： 警告：res_to_rt+0x1c4/0x230 CPU#1處的 drivers/infiniband/core/restrack.c：138：kworker/u8：4/59 連結的模組： CPU：1 UID：0 PID：59 Comm：
    kworker/u8：4 未受污染 syzkaller #0 PREEMPT（完整） 硬體名稱：Google Compute Engine、BIOS Google 2026 年 7 月 24 日 工作佇列：ib_addr process_one_req RIP：0010：res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c：138 RSP：0018：ffffc9000201f850 EFLAGS：00010293 RAX：ffffffff88d00ce5 RBX：ffff88807f0fd4f8 RCX：ffff88801e6e0000 RDX：0000000000000000000 RSI：ffffffff8fd996f0 RDI：
    0000000000000003 RBP： 00000000000000000 ： ffff88801e6e0000 R09： 000000000000000a R10： 0000000000000009 R11： 0000000000000000 R12： dffffc00000000000 R13： 1ffff1100fe1fa9f R14： 000000000000000000 ： 00000000000000000 R15：R08
    0000000000000003 FS：00000000000000000（0000） GS：ffff888125012000（0000） knlGS：000000000000000000 CS：0010 DS：
    0000 ES：0000 CR0：0000000080050033 CR2：00001d559c3d2000 CR3：0000000077c4c000 CR4：00000000003526f0 呼叫追蹤： <TASK> rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c：236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c：3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c：624 process_one_work kernel/workqueue.c：3375 [內嵌] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c：3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c：3539kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> 在 addr_handler（） 中，呼叫 cma_acquire_dev_by_src_ip（） 來填入 id_priv->cma_dev，並將相關聯的ib_device繫結至 id_priv->id.device。如果 cma_acquire_dev_by_src_ip（） 傳回錯誤 （非零狀態） ，則該 ID 與任何 RDMA 裝置保持不相關聯。以前，即使 cma_acquire_dev_by_src_ip（） 失敗，也會無條件叫用 rdma_restrack_add（&id_priv->res），傳遞具有 NULL 開發指標的資源，並在 res_to_rt（） 中觸發WARN_ON判斷提示。僅在取得裝置成功時新增要重新追蹤的資源，即可修正此問題。（CVE-2026-90218）

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

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

  - nvme-pci：探查失敗時釋放描述元集區 一旦配置管理標籤集，每個 NUMA 節點描述元的 DMA 集區就會從 nvme_init_hctx_common（） 延遲建立，但它們只會透過 nvme_release_descriptor_pools（） 在 nvme_remove（） 中銷毀。配置管理標籤集之後的任何探查失敗都會透過out_disable標籤和 nvme_pci_free_ctrl（） 展開，兩者都不會釋放集區，從而洩漏dma_pool物件。釋放out_disable錯誤路徑中的描述元集區。它不得新增至 nvme_pci_free_ctrl（），因為這會在正常拆卸路徑上對 nvme_remove（） 進行雙重釋放。（CVE-2026-90233）

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

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

  - RDMA/erdma：修正移除時的 CEQ tasklet 釋放後使用 每個 CEQ 中斷處理常式僅排程 eqc->tasklet。tasklet 呼叫 erdma_ceq_completion_handler（），它透過 get_next_valid_eqe（） 讀取 DMA 相干的 EQ 環，並透過 notify_eq（） 更新 eq->dbrec。erdma_ceqs_uninit（） 釋放每個 CEQ IRQ，然後銷毀其 EQ。 free_irq（） 會阻止另一個硬 IRQ 並等待正在進行的處理常式，但它不會清空處理常式已排程的 tasklet。因此，在 erdma_eq_destroy（） 釋放 eq->qbuf 或 eq->dbrec 之後，tasklet 可以存取它們。清除 ceq_cb->ready 不會與在 erdma_ceq_completion_handler（） 開始時已通過檢查的 tasklet 同步。在 free_irq（） 之後，當沒有處理常式可以再次排程它時，以及 erdma_ceq_uninit_one（） 釋放 EQ 緩衝區之前，終止 tasklet。（CVE-2026-92514）

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

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

  - RDMA/bnxt_re：在 DBR/切換頁面 mmap bnxt_re_mmap（） 上清除VM_MAYWRITE拒絕 DBR_PAGE 和 TOGGLE_PAGE mmap 旗標的VM_WRITE，但唯讀映射仍可保留VM_MAYWRITE。稍後會使用 mprotect（PROT_WRITE） 進行升級。這可以繞過僅在 mmap 時執行的寫入檢查。在共用 DBR/toggle-page 分支的 vm_insert_page（） 之前清除 VM_MAYWRITE，以符合現有原則，即這些頁面不需要使用者空間寫入。（CVE-2026-92495）

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

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

  - 信箱：riscv-sbi-mpxy：驗證 RPMI 通知長度 SBI 傳回值控制從共用記憶體複製到 RPMI 通知緩衝區的位元組數。在該副本之前，不會針對協商的共用記憶體大小進行驗證。事件遍歷器也會使用反向迴圈條件，並可以檢查簡短的事件記錄。在複製通知之前先驗證完整的通知長度，僅在完整的事件標頭保留時反覆運算，並在宣告的事件承載超出複製的通知資料時停止。（CVE-2026-90191）

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

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

  - ALSA： core：修正 snd_card_do_free（） 中的釋放後使用當 devres 管理的音效卡未綁定，而使用者空間應用程式仍保留開啟的檔案描述元時，在 snd_card_do_free（） 中偵測到釋放後使用。對於託管卡，記憶體是使用 devres_alloc（） 配置的，其釋放函數設定為 __snd_card_release（），它會呼叫 snd_card_free（）。當裝置解除綁定時，解除綁定執行緒會呼叫 snd_card_free（），這會刪除對卡片裝置的參照。如果使用者執行緒仍有開啟的檔案描述元，則參照計數不會達到零，且解除綁定執行緒會在 wait_for_completion（&released） 上封鎖。當使用者執行緒關閉檔案描述元時，它會刪除最終參照，並叫用裝置釋放回呼 release_card_device（），呼叫 snd_card_do_free（） 。
    snd_card_do_free（） 執行清理並呼叫 complete（card->release_completion）。這會喚醒從 snd_card_free（） 和 __snd_card_release（） 傳回的解除綁定執行緒。然後，devres 核心會立即釋放包含 snd_card 結構的記憶體區塊。同時，使用者執行緒繼續在 snd_card_do_free（） 中執行，並評估「if （！card->managed）」。它從剛由解除綁定執行緒釋放的snd_card結構中讀取「託管」布林值，從而觸發 KASAN 釋放後使用。在呼叫 complete（） 之前，透過在本機變數中快取 card->managed 的值來修正此問題。如此可確保在喚醒解除繫結執行緒之後，不會取消參照卡片指標，並可能釋放卡片。
    錯誤： KASAN：snd_card_do_free sound/core/init.c：604 中的釋放後使用 [內聯] 錯誤： KASAN：release_card_device+0x1ab/0x1b0 sound/core/init.c：153 中的釋放後使用 由任務 syz-executor130/5857 在 addr ffff8881912ec909 讀取大小 1 呼叫追蹤： <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c：120 print_address_description+0x55/0x1e0 mm/kasan/report.c：378 print_report+0x58/0x70 mm/kasan/report.c：482 kasan_report+0x117/0x150 mm/kasan/report.c：595 snd_card_do_free sound/core/init.c：604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c：153 device_release+0xc4/0x1f0 drivers/base/core.c：-1 kobject_cleanup lib/kobject.c：689 [inline] kobject_release lib/kobject.c：720 [inline] kref_put include/linux/kref.h：65 [inline] kobject_put+0x222/0x550 lib/kobject.c：737 snd_card_file_remove+0x331/0x390 sound/core/init.c：1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c：2986 __fput+0x418/0xa50 fs/file_table.c：512 fput_close_sync+0x11f/0x240 fs/file_table.c：617 __do_sys_close fs/open.c：1511 [內嵌] __se_sys_close fs/open.c：1496 [內嵌]
    __x64_sys_close+0x7e/0x110 fs/open.c：1496 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> （CVE-2026-90198）

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

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

  - iommu/vt-d：修正 RID 網域取代時的iopf_refcount洩露 intel_iommu_attach_device（） 會為新網域啟用 IOPF，但絕不會為舊網域停用 IOPF。在函式開頭呼叫的 device_block_translation（） 會拆除轉換，但不會觸及任何 IOPF 狀態;正是出於這個原因，blocking_domain_attach_dev（） 必須在叫用它之前明確調用它 iopf_for_domain_remove（）。
    identity_domain_attach_dev（） 也有同樣的問題。其註解聲稱不需要 PRI 處理，因為裝置已處於封鎖狀態，但封鎖狀態和 IOPF 參考計數彼此獨立。因此，將具有iopf_handler的網域替換為 RID 層級的另一個網域，會在資訊>iopf_refcount中洩漏參照。計數永遠不會降回零，因此永遠不會調用 iopf_queue_remove_device（），並且 iommu_disable_pci_pri（） 會在釋放裝置時觸發其 WARN_ON（info->iopf_refcount）。PASID 路徑已透過 iopf_for_domain_replace（） 正確處理此問題;轉換兩個 RID 路徑以執行相同的動作。使用取代協助程式而不是裸移除會在停用之前保留啟用，因此參照計數不會暫時達到零，並將裝置從 IOPF 佇列中收回。（CVE-2026-90242）

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

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

  - wifi： ath12k：修正 ath12k_wmi_process_csa_switch_count_event（） 中的過度讀取 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT沒有原則項目，因此剖析基礎架構不會強制執行事件結構的最小長度。此外，num_vdevs欄位直接取自韌體，並用作綁定在 vdev_ids 陣列上的迴圈，而不檢查它是否適合 TLV 有效負載。任一狀況都可能導致越界讀取。新增 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT 的 TLV 原則項目，以便剖析基礎架構強制執行固定大小事件結構的最小長度。新增協助程式 ath12k_wmi_tlv_data_len（），以從其資料指標之前的標頭復原已剖析 TLV 的承載長度。在 ath12k_wmi_process_csa_switch_count_event（） 中使用它來在循環之前綁定num_vdevs。僅測試編譯檔案。(CVE-2026-90408)

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

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

  - cpufreq： amd-pstate-ut： 當 amd-pstate 驅動程式未啟用時，跳過測試 在 intel 平台上amd_pstate_ut modprobe 時，可能會發生當機問題。amd_pstate_ut：1 amd_pstate_ut_acpi_cpc_valid成功！amd_pstate_ut：2 amd_pstate_ut_check_enabled成功！錯誤：核心 NULL 指標解除參照，位址：
    0000000000000080 #PF：核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 PGD 0 P4D 0 哎呀：0000 [#1] SMP NOPTI CPU：0 PID：20300 通訊：modprobe Kdump：已載入 污染：G O 6.6.0-0010.rc1.ctl4.x86_64 #1 硬體名稱：烽火 R2200 通信 V5/Xeon 主板，BIOS 3.1a 2020 年 2 月 24 日 RIP：
    0010：amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] 呼叫追蹤： <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ？ __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ？ kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 新增狀態偵測至 AMD pstate 驅動程式以防止amd_pstate_ut 驅動程式，無需在非 AMD 平台上進行測試。（ML：調整標題）（CVE-2026-92493）

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

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

  - cxl/mbox：將信箱輸出分配限制為承載大小CXL_MEM_SEND_COMMAND將使用者的 in.size 限制為信箱承載大小，但保留 out.size 不受限制，然後 cxl_mbox_cmd_ctor（） 呼叫 kvzalloc（out.size）。一個大的 out.size 驅動了巨大的分配，高於INT_MAX它會警告和污染，並且當 panic_on_warn=1 時，它會感到恐慌。傳輸 __cxl_pci_mbox_send_cmd（） 已經將回應副本限制為 min（out.size， payload_size， device len），因此輸出緩衝區永遠不會寫入超過 payload_size。將分配也限制為payload_size，以匹配 RAW 路徑。（CVE-2026-93186）

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

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

  - ext4：清除在回寫期間跳過的對開本上過時的 XARRAY 標籤 在 data=journal 模式下，當超級區塊在重新開機期間以唯讀方式重新掛載時，回寫執行緒可能會命中 ext4_journal_check_start（） 中的 WARN_ON_ONCE（sb_rdonly（sb））： 工作佇列：回寫wb_workfn （flush-253：0） RIP：
    0010：ext4_journal_check_start+0x8b/0xd0呼叫追蹤：__ext4_journal_start_sb+0x3c/0x1e0 mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0 do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0
    __writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 然後是警告： EXT4-fs 警告 （device vda1）： ext4_evict_inode：195： inode #6263： comm （sd-umount）： 資料將遺失 這個問題並非每次都重現，而是經常重現。重現步驟是建立一個具有 8 個 CPU、16G 記憶體和設定 data=journal的 VM：sudo tune2fs -o journal_data /dev/vda1 執行 fio：rm -f fiotest fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8
    --filename=fiotest --filesize=30G --group_reporting 重新開機 VM，然後檢查主控台輸出：
    virsh console testvm 但沒有髒 inode，folio_clear_dirty_for_io 清除PG_dirty但留下標籤PAGECACHE_TAG_DIRTY，並PAGECACHE_TAG_TOWRITE設定，這些標籤僅由 __folio_start_writeback 清除。在 data=journal 模式下，jbd2 會將日誌記錄的資料檢查點到其最終位置，並清除自己的已變更旗標，而不會觸及對開本PG_dirty或 xarray 已變更旗標。提交 f4a2b42e7891 （ext4：回寫後修正過時的 xarray 標籤） 會修正仍設定 PG_dirty 但沒有已變更頁面的情況。另一種情況是PG_dirty已清除，但PAGECACHE_TAG_DIRTY和PAGECACHE_TAG_TOWRITE仍處於設定狀態。在此情況下，回寫執行緒會檢查乾淨的對開本，並在mpage_prepare_extent_to_map中略過它：if （！folio_test_dirty（Folio） || ...folio_unlcok（對開頁）;繼續並且永遠不會到達提交 f4a2b42e7891 清除過時 xarray 標籤的ext4_bio_write_folio。重新掛載檔案系統後列印除錯日誌 唯讀：writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 所有作品集實際上都是乾淨的：對開本 idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... 我們需要通過在跳過路徑中循環回寫來清除此類乾淨作品集的 xarray 過時標籤，就像 f4a2b42e7891 在 ext4_bio_write_folio 中所做的那樣。（CVE-2026-92502）

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

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

  - net： kcm：在執行 BPF 剖析器 kcm_parse_func_strparser（） 呼叫 bpf_prog_run_pin_on_cpu（） 時保持 RCU 讀取鎖定，這會防止 CPU 移轉，但不會建立 RCU 讀取端關鍵區段。因此，BPF 映射操作在從 KCM strparser 程式呼叫時可以觸發 WARN_ON_ONCE（！bpf_rcu_lock_held（））。執行程式時保持 RCU 讀取鎖定。（CVE-2026-90143）

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

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

  - drm/panthor： 修正已驅逐 BO 部分取消對應的 NPD 問題 此認可修正了由於已驅逐 BO 的部分取消對應，在分割 GPU 對應時會發生的 NULL 指標解除參照問題。當 GPU 對應分割時，有一個邏輯可以處理大頁面的部分取消對應。針對已驅逐 BO 的 VMA 未完全略過此邏輯，這會導致「bo->backing.pages」指標的 NPD 可能性，當驅逐時釋放 BO 的頁面時，指標會設定為 NULL。
    當對被驅逐的 BO 進行部分取消映射時，出現了以下垃圾場。無法處理虛擬位址上的核心分頁要求 0000000000002000 記憶體中止資訊：ESR = 0x0000000096000004 EC = 0x25：
    DABT（當前 EL），IL = 32 位 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x04：0 級轉換錯誤 資料中止資訊：ISV = 0，ISS = 0x00000004，ISS2 = 0x00000000 CM = 0，WnR = 0，TnD = 0，TagAccess = 0 GCS = 0，Overlay = 0，DirtyBit = 0，Xs = 0 使用者頁：4k 頁，48 位元 VA， pgdp=00000008842e8000 [0000000000002000] pgd=0000000000000000，p4d=0000000000000000 內部錯誤：哎呀： 0000000096000004 [#1] SMP <snip> pstate： 20000005 （nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--） pc：
    iova_mapped_as_huge_page+0x20/0x68 [panthor] lr ： panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor] sp ：
    ffff800086193920 x29： ffff800086193920 x28： ffff800086193a18 x27： ffff800086193b80 x26： 0000000000400000 x25： 0000000000810000 x24： 0000000000400000 x23： ffff000808af1800 x22： 0000000000a00000 x21：
    ffff800086193a00 x20： ffff000806fd3f00 x19： 0000000000410000 x18： 00000000ffffffff x17： 00000000000000000 x16： 000000000000000000 x15： ffff800083ce2d83 x14： 00000000000000000 x13： 3120646574636976 x12：
    6520303030303138 x11： 2d30303030313420 x10： ffff8000836e6c80 x9 ： ffff80007bfc889c x8 ： 3ffffffffffffff x7 ： ffff8000836e6c80 x6 ： 000000000000000 x5 ： ffff000097ef19088 x4 ： 00000000000000000 x3 ：
    0000000000000000 x2 ： 0000000000010000 x1 ： 0000000000000400 x0 ： 000000000000000000 呼叫追蹤：
    iova_mapped_as_huge_page+0x20/0x68 [panthor] （P） op_remap_cb.isra.0+0x70/0xb0
    __drm_gpuvm_sm_unmap+0xf8/0x1c0 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa0/0x168 [panthor] panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor] panthor_ioctl_vm_bind+0xbc/0x170 [panthor] drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xb4/0x118 invoke_syscall+0x5c/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x38/0x128 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 代碼：8b030021 cb020021 f940b800 d34cfc21 （f8617801） ---[ end trace 00000000000000000000 ]--- v2： 修正縮排 （CVE-2026-93180）

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

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

  - media：stm32：dcmi：修正 probe（） 中的一些錯誤處理錯誤 這裡有幾個問題： 1） 我們分配後：chan = dma_request_chan（&pdev->dev， tx）;然後錯誤路徑需要清理後再返回。
    第一個錯誤路徑會直接傳回。2） 錯誤路徑檢查 dcmi->mdma_chan，但要到稍後才分配，因此會導致記憶體洩漏。請改用測試mdma_chan。3） 在指派 dcmi->dma_chan 之前，錯誤處理會呼叫 dma_release_channel（dcmi->dma_chan），這會導致 NULL 指標解除參照。請改用 chan 變數。我還在調用 dma_release_channel（） 之後移動了對 dma_release_channel（） 的調用，以便它更好地鏡像分配代碼。（CVE-2026-90405）

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

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

  - octeontx2-vf：修正探測/移除中的工作佇列和 netdev 爭用 在 register_netdev（） 之前初始化 VF 工作佇列ndo_set_rx_mode這樣就不會將 NULL 工作佇列上的工作排入佇列。在銷毀工作佇列之前取消註冊 netdev，並新增適當的探查錯誤清除。（CVE-2026-90084）

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

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

  - iommu/dma：還原圍繞msi_page_list的鎖定 與群組的預設網域不同，群組的預設網域一律是新配置且私有的 （iommu_group_alloc_default_domain（）），而 VFIO 類型 1 的舊版容器會在群組的iommu_ops和快取一致性強制執行相符時，將其合併到現有網域中。iommu_dma_get_msi_page（） 僅斷言持有調用方自己的群組互斥 （iommu_group_mutex_assert（））。在發佈 IOMMU_RESV_SW_MSI 的 IOMMU 上，例如 ARM SMMU，具有兩個透過舊版容器指派的這類裝置的 VM 可以讓其客體驅動程式平行探測和配置 MSI;每個主機端VFIO_DEVICE_SET_IRQS都位於不同的裝置 FD 和群組互斥上，但兩個裝置的網域是相同的合併網域，因此兩者都可以同時進入 iommu_dma_get_msi_page（） 並損毀msi_page_list。提交 288683c92b1a （iommu：將 iommu_dma_prepare_msi（） 設為通用作業） 刪除了先前的msi_prepare_lock，理由是每個iommu_domain對群組都是唯一的，這適用於預設網域，但不適用於此 VFIO 類型 1 情況。恢復靜態鎖，因為它只是保護一個角落案例，可能永遠不會被爭奪。iommufd 透過讓自己的呼叫端 （iommufd_sw_map_msi（）） 在到達共用清單之前進行 CTX 範圍的sw_msi_lock來避免對等問題。VFIO 類型 1 無法鏡像這一點，因為它會分派到 VFIO 管轄範圍之外的 iommu_dma_sw_msi（）。（CVE-2026-90244）

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

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

  - platform/chrome： cros_ec_typec：拒絕越界 PD 上限計數 cros_typec_register_partner_pdos（） 會將合作夥伴 PDO 從 EC TYPEC_STATUS 回應複製到固定的 caps_desc.pdo[PDO_MAX_OBJECTS] 陣列中。memcpy（caps_desc.pdo， resp->source_cap_pdos， sizeof（u32） * resp->source_cap_count）;...
    memcpy（caps_desc.pdo， resp->sink_cap_pdos， sizeof（u32） * resp->sink_cap_count）;PDO_MAX_OBJECTS是 7 歲。
    source_cap_count 和 sink_cap_count 是來自 EC 的 u8 欄位。唯一的檢查是它們並非都是零。如果其中任何一個大於 7，則 memcpy 會寫入堆疊上陣列的末尾。計數 255 會使其溢位約 1 KB。EC 來源陣列只有七個項目寬度。更大的計數也從他們身邊讀過。ChromeOS EC 韌體目前限制了這些計數，因此合規的設定不會達到此目標。核心仍應驗證這些值，而不是信任它們。驗證 memcpy 旁邊的 cros_typec_register_partner_pdos（） 中的計數。如果任一計數高於 PDO_MAX_OBJECTS，則跳過 PDO 註冊。cros_typec_handle_status（） 的其餘部分仍會執行，因此會處理和清除事件。
    (CVE-2026-93190)

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

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

  - wifi： mt76： mt7915：在探測 IRQ 失敗時釋放 hif2 參照 mt7915_pci_init_hif2（） 取得的 hif2 參照只會在關閉 dev->hif2 的錯誤路徑上釋放，直到 IRQ 設定之後才會指派。如果 pci_alloc_irq_vectors（） 或主要 devm_request_irq（） 失敗，則參照會洩漏。透過 mt7915_put_hif2（） 將其明確放在這些路徑上。（CVE-2026-90352）

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

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

  - remoteproc：防止損毀處理與 rproc_del（） 爭用 rproc_crash_handler_work（） 和 rproc_del（） 之間沒有同步處理，因此，在排程損毀處理常式工作甚至執行時，驅動程式可能會被移除，從而導致釋放後使用問題。為避免這種情況，在移除繼續之前，需要取消排程的工作並同步處理。為了確保這不會與報告爭用，進而排程新工作，會引進刪除旗標。這類似於為確保 start 不會與 rproc_del（） 爭用而引入的 RPROC_DELETE 狀態，但無法使用現有機制，因為它可以在原子上下文中調用 rproc_report_crash（） - 並且狀態受到互斥的保護。如果取消工作，則 pm_stay_awake（） 會保持不平衡，需要展開。在實際的 rproc_shutdown（） 呼叫之前封鎖和取消當機處理常式工作確實具有明確的副作用，即關閉進程導致的當機不會進入當機處理路徑，因此不會產生 devcoredumps 等。由於這些程式碼路徑之間存在相互排除，因此功能沒有具體減少，但需要進一步的工作來處理這種情況。
    (CVE-2026-90431)

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

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

  - drm/amd/display：修正平面重設函式 amdgpu_dm_plane_drm_plane_reset（） 中的懸空指標，可在配置新狀態之前釋放舊狀態。如果 kzalloc（） 失敗，則函式會傳回而不更新狀態指標，留下一個懸空指標指向已釋放的記憶體。先配置新狀態來修正此問題。
    配置失敗時，舊狀態保持不變，函式會安全地傳回。由 Linux 驗證中心 （linuxtesting.org） 使用 SVACE 找到。[調整圍繞當前 amd-staging-drm-next 的移動]（CVE-2026-93176）

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

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

  - ocfs2： o2hb：靜止協商處理常式及逾時工作 活動訊號區域會立即將結構o2hb_region發佈為 NEGO_TIMEOUT 的私有資料，並在 make_item（） 建立 configfs 區域後立即NEGO_APPROVE o2net 處理常式。核准處理常式可以呼叫 o2hb_arm_timeout（），因此對等可以在 dev_store（） 完成建置活動訊號執行階段之前，或在拆卸開始關閉該執行階段之後，接觸區域逾時工作。最終的 configfs put 也必須讓 reg 保持活動狀態，直到最後一個進行中的 o2net 回呼刪除其處理常式參照。o2net_unregister_handler_list（） 會封鎖未來的處理常式查詢，但不會等待已通過 o2net_handler_get（） 的sc_rx_work。該清空也需要涵蓋本機接聽程式拆解，其中 o2net 排序的工作佇列可能已經在 destroy_workqueue（） 內。
    在兩個方向上修正存留期規則。在透過 o2net 處理常式表格發佈 reg 之前，初始化區域延遲的工作，讓新區域或停止區域無法使用 hr_stopping 進行武裝，並靜止失敗啟動和拆卸路徑上的延遲工作，即使沒有活動訊號執行緒可以呼叫 o2hb_disarm_timeout（） 也是如此。然後在拆除處理常式可見區域狀態之前取消註冊處理常式，並使清空等待作用中或正在破壞的 o2net 有序工作佇列，然後再釋放 reg。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序： 區域生命週期：延遲協商回呼：1. make_item（） 註冊 1.o2net_process_message（） 在 reg. dev_store（） 的活動訊號處理常式建立 2 之前取得區域處理常式。回呼會在查詢可執行的活動訊號內容之後執行。鎖定被刪除並取消參照規則 2。啟動失敗或 rmdir 3。approve 或逾時路徑會嘗試停止活動訊號執行緒、佇列 reg 的延遲工作，或釋放靜默現有工作，並在處理常式捨棄最終 configfs ref 取消註冊後爭用回呼本文。3.
    region_release（） 必須排空 4.回呼或延遲的工作可以處理常式可見的 o2net rx 工作比 reg 有效，除非在釋放 reg 之前的生命週期程式碼。會讓區域保持不可布防，並耗盡作用中或銷毀的 o2net 工作佇列。驗證重現了此核心報告：KASAN slab-use-after-free in
    __run_timers+0x22c/0x5b0 大小 8 的寫入 呼叫追蹤：dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630
    __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 按任務堆疊分配：
    kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600 （CVE-2026-90301）

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

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

  - btrfs：始終等待有序範圍以避免 OE 爭用 [BUG] Syzbot 報告了一個錯誤，指出同一範圍可能存在衝突的 OE： BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：
    重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件 alrea[ 179.162726][ T6897] BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件已存在） ------------[ 切到此處 ]------------ fs/btrfs/ordered-data 的核心錯誤。c：264！硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0呼叫追蹤： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 0000000000000000000 ]--- [CAUSE] 自從提交 ff66fe666233 （btrfs：修正附加直接寫入的錯誤緩衝 IO 後援） 以來，如果直接 IO 短時間結束，我們會將 isize 還原回原來的 isize，以便在緩衝後援期間可以遵守附加寫入。通常，我們在緩衝回寫期間依賴 lock_and_cleanup_extent_if_need（） 函式來等候任何現有的有序範圍。但只有在start_pos位於 isize 內時，才會發生有序範圍等待。由於我們已在失敗的直接 IO 期間還原 isize，因此我們不會等候任何有序範圍。這表示我們可以進行直接 IO OE 仍在樹狀結構中、完成但尚未移除的爭用，然後我們插入緩衝寫入的 OE，導致上述損毀。[修復]讓 OE 等待無條件，以處理還原的 isize 情況。由於 lock_and_cleanup_extent_if_need（） 現在要麼鎖定範圍，要麼傳回 -EAGAIN，因此也要移除處理無範圍鎖定案例的分支，並重新命名它以移除 _if_need 字尾。以下微基準測試顯示了 btrfs_buffered_write（） 的運行時間差異，執行“xfs_io -f -c pwrite 0 1m”工作負載，所有值都是以納秒為單位的平均運行時間。函式執行階段 |之前 |之後
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整體運行時間仍然很小（仍然不到 3 微秒），我想說額外的成本仍然是可以接受的。解決此問題的替代方法是在 iomap_end（） 期間等待有序範圍，其中 isize 還原已完成。但該解決方案將破壞 nowait 要求，就像 nowait 直接 IO 短時間結束一樣，我們必須無條件地等待 OE，否則下一個附加緩衝 IO 仍然會遇到相同的問題。所以這裡我們必須將等待成本移至緩衝寫入，但至少程式碼稍微精簡一些。（CVE-2026-90264）

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

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

  - vdpa/mlx5：修正錯誤路徑中反覆運算add_direct_chain錯誤清單 在 add_direct_chain（） 中，新配置的直接 MR 項目會新增至本機清單「tmp」，只有在成功時才會拼接到 mr->head 中。在錯誤路徑上，清理迴圈錯誤地反覆運算 mr->head 而不是 tmp。透過反覆運算err_alloc清理路徑中的「tmp」來修正。（CVE-2026-90128）

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

ID	名稱	嚴重性
347879	Linux Distros 未修補弱點：CVE-2026-93145	high
347878	Linux Distros 未修補弱點：CVE-2026-93057	medium
347877	Linux Distros 未修補弱點：CVE-2026-90059	high
347876	Linux Distros 未修補弱點：CVE-2026-90259	medium
347875	Linux Distros 未修補弱點：CVE-2026-93070	high
347874	Linux Distros 未修補弱點：CVE-2026-90177	high
347873	Linux Distros 未修補弱點：CVE-2026-90266	medium
347872	Linux Distros 未修補弱點：CVE-2026-90158	medium
347871	Linux Distros 未修補弱點：CVE-2026-90329	high
347870	Linux Distros 未修補弱點：CVE-2026-90068	medium
347869	Linux Distros 未修補弱點：CVE-2026-90188	medium
347868	Linux Distros 未修補弱點：CVE-2026-90213	medium
347867	Linux Distros 未修補弱點：CVE-2026-90135	medium
347866	Linux Distros 未修補弱點：CVE-2026-93050	high
347865	Linux Distros 未修補弱點：CVE-2026-92519	medium
347864	Linux Distros 未修補弱點：CVE-2026-90174	high
347863	Linux Distros 未修補弱點：CVE-2026-93055	high
347862	Linux Distros 未修補弱點：CVE-2026-90309	high
347861	Linux Distros 未修補弱點：CVE-2026-93086	medium
347860	Linux Distros 未修補弱點：CVE-2026-90307	high
347859	Linux Distros 未修補弱點：CVE-2026-90423	high
347858	Linux Distros 未修補弱點：CVE-2026-90383	high
347857	Linux Distros 未修補弱點：CVE-2026-90306	medium
347856	Linux Distros 未修補弱點：CVE-2026-90175	medium
347855	Linux Distros 未修補弱點：CVE-2026-92482	medium
347854	Linux Distros 未修補弱點：CVE-2026-93194	high
347853	Linux Distros 未修補弱點：CVE-2026-90265	medium
347852	Linux Distros 未修補弱點：CVE-2026-90218	medium
347851	Linux Distros 未修補弱點：CVE-2026-90233	medium
347850	Linux Distros 未修補弱點：CVE-2026-92514	high
347849	Linux Distros 未修補弱點：CVE-2026-92495	high
347848	Linux Distros 未修補弱點：CVE-2026-90191	high
347847	Linux Distros 未修補弱點：CVE-2026-90198	high
347846	Linux Distros 未修補弱點：CVE-2026-90242	medium
347845	Linux Distros 未修補弱點：CVE-2026-90408	high
347844	Linux Distros 未修補弱點：CVE-2026-92493	medium
347843	Linux Distros 未修補弱點：CVE-2026-93186	medium
347842	Linux Distros 未修補弱點：CVE-2026-92502	medium
347841	Linux Distros 未修補弱點：CVE-2026-90143	high
347840	Linux Distros 未修補弱點：CVE-2026-93180	medium
347839	Linux Distros 未修補弱點：CVE-2026-90405	medium
347838	Linux Distros 未修補弱點：CVE-2026-90084	medium
347837	Linux Distros 未修補弱點：CVE-2026-90244	high
347836	Linux Distros 未修補弱點：CVE-2026-93190	high
347835	Linux Distros 未修補弱點：CVE-2026-90352	medium
347834	Linux Distros 未修補弱點：CVE-2026-90431	medium
347833	Linux Distros 未修補弱點：CVE-2026-93176	high
347832	Linux Distros 未修補弱點：CVE-2026-90301	high
347831	Linux Distros 未修補弱點：CVE-2026-90264	medium
347830	Linux Distros 未修補弱點：CVE-2026-90128	medium

偵測

Nessus 的 Misc. 系列

high

medium

high

medium

high

high

medium

medium

high

medium

medium

medium

medium

high

medium

high

high

high

medium

high

high

high

medium

medium

medium

high

medium

medium

medium

high

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

high

medium

medium