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

  - ipv4：限制IPOPT_SSRR和IPOPT_LSRR選項 此修補程式將設定寬鬆來源和記錄路由 （LSRR） 以及嚴格來源和記錄路由 （SSRR） IP 選項限制為具有CAP_NET_RAW功能的使用者。
    這可防止無權限的應用程式強制封包透過攻擊者控制的節點路由，以洩露 TCP、ISN 和可能的其他通訊協定資訊。雖然 LSRR 和 SSRR 在許多網路環境中通常會被篩選，但它們仍可能受到支援並沿著某些網路路徑轉送。RFC 7126 （關於篩選包含 IPv4 選項的 IPv4 封包的建議） 建議將這些選項 4.3 放入 和 4.4中。（CVE-2026-53249）

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

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

  - netfilter： synproxy：新增互斥以保護鉤子參照計數 當使用者新增第一個 iptables 目標或 nftables 運算式時，作為 synproxy 基礎架構暫存器 netfilter 按需掛鉤，如果同時完成，它們可以相互爭用。引入互斥以序列化 refcount 控制項，阻止來自兩個前端的存取。雖然每個命名空間互斥可能更有效率，但目標/運算式 （如 SYNPROXY） 不需要它。（CVE-2026-53269）

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

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

  - RDMA/core：驗證傳入的 fops 用於 ib_get_ucaps（） Sashiko 指出，僅依賴 devt 並不安全，因為 char/block 別名，因此如果使用者找到具有相同dev_t的區塊設備，它可以偽裝成 ucap cdev fd。測試f_ops以僅接受真實的 cdv。（CVE-2026-53188）

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

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

  - 已解決 Linux 核心中的下列弱點：ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path. (CVE-2026-53174)

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

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

  - net/sched： act_api：使用 RCU 搭配延遲釋放動作生命週期時 當 NEWTFILTER 及 DELFILTER 同時執行時，可以建立具有相關聯動作的爭用。讓我們以 CPU0 執行 NEWTFILTER 和 CPU1 執行 DELFILTER 來說明： 0： mutex_lock（） <-- 持有 idr 鎖定 0： rcu_read_lock（） 0： p = idr_find（idr， index） <-- 動作 p 有效 （RCU 保護 IDR） 0： mutex_unlock（） <-- 釋放 idr 鎖定 1： refcount_dec_and_mutex_lock（） <-- refcnt 1->0，互斥保持 1： idr_remove（idr， index） <-- 從 IDR 1 中刪除的操作：mutex_unlock（） <-- 互斥已釋放，允許我們刪除操作 1：
    tcf_action_cleanup（p）;kfree（p） <-- 立即 Kfrees p，無延遲 0：
    refcount_inc_not_zero（&p->tcfa_refcnt） <-- 哎喲，UAF p 指向釋放的記憶體 此修補程式透過將結構rcu_head新增至延遲中使用的tc_action並在刪除路徑中引入 call_rcu（） 以延遲最終 kfree（） 來修正 NEWTFILTER 和 DELFILTER 之間的爭用情形。注意：這是提交 d7fb60b9cafb 的還原（net_sched：擺脫 tcfa_rcu），也是直接使用 kfree_rcu（） 的現代化/簡化。讓我們來說明新還原的程式碼路徑：0：rcu_read_lock（） 1：
    refcount_dec_and_mutex_lock（） <-- refcnt 1->0，互斥持有 1：idr_remove（idr，index） 1：mutex_unlock（） 1：
    call_rcu（&p->tcfa_rcu， tcf_action_rcu_free） <-- 寬限期 0 後延遲 kfree： p = idr_find（IDR， index） 0： refcount_inc_not_zero（&p->tcfa_refcnt） <-- 失敗，refcnt 已 0 1：rcu_read_unlock（） <-- 釋放，以便在寬限期後執行 CPU1 呼叫 idr_remove（） 後，無法再透過 IDR 存取物件。CPU0 的後續 idr_find（） 將傳回 NULL，即使它仍然持有過時的指標，立即的 kfree（） 現在也會延遲到 RCU 寬限期之後，因此不會發生 UAF。
    (CVE-2026-53264)

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

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

  - 已解決 Linux 核心中的下列弱點：Revert drm/xe: Skip exec queue schedule toggle if queue is idle during suspend This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6. The idle-skip optimization bypasses GuC suspend, so the GPU may not perform the context switch that flushes TLB entries for invalidated userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB invalidation and page faults during userptr invalidation tests.
    Restore unconditional schedule toggling on suspend so the context-switch TLB flush is always performed.
    This optimization will be reintroduced with a fix that does not skip suspend in LR/preempt-fence VM mode.
    (cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170) (CVE-2026-53201)

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

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

  - drm/amd/display：將 HDMI HDCP2 rx_id_list讀取限制為緩衝區大小 [原因和方式] 在透過 HDMI 進行 HDCP 2.x 中繼器驗證期間，驅動程式會讀取接收器的 RxStatus 暫存器，並擷取 10 位元訊息大小欄位 （最大值 1023）。此值會用作 ReceiverID 清單的讀取長度，而不會限制為目的地緩衝區的大小 rx_id_list[177]。惡意 HDMI 中繼器可能會通告大於緩衝區的訊息大小，從而在 I2C 讀取期間造成越界寫入。將 mod_hdcp_read_rx_id_list（） 中的讀取長度限制為rx_id_list緩衝區的大小，以符合 DP 分支中已使用的方法。（從提交 229212219e4247d9486f8ba41ef087358490be09 中挑選）（CVE-2026-53137）

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

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

  - gpio： rockchip：修正移除時的通用 IRQ 晶片洩漏 驅動程式在探測期間使用 irq_alloc_domain_generic_chips（） 配置網域通用晶片。不過，在驅動程式移除/拆卸時，當移除 IRQ 網域時，通用晶片不會自動釋放，因為網域旗標不包含IRQ_DOMAIN_FLAG_DESTROY_GC。這會導致網域通用晶片結構和相關聯的通用晶片都被洩露。此外，通用芯片仍保留在全域gc_list上，並且在移除 GPIO 組後，通用 IRQ 芯片暫停、恢復或關閉回調可能會訪問，從而可能導致釋放後使用和核心崩潰。在移除 rockchip_gpio_remove（） 中的 IRQ 網域之前，先明確呼叫 irq_domain_remove_generic_chips（），以修正資源洩漏。
    (CVE-2026-53226)

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

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

  - ipv6： sit：GSO 卸載後重新載入內部 IPv6 標頭 ipip6_tunnel_xmit（） 在函式項目處快取內部 IPv6 標頭指標，並在 iptunnel_handle_offloads（） 之後繼續使用它。對於 GSO skb，iptunnel_handle_offloads（） 會呼叫 skb_header_unclone（）。當 skb 標頭被複製時，skb_header_unclone（） 可以呼叫 pskb_expand_head（），這可能會移動 skb 頭。pskb_expand_head（） 合約要求在呼叫後重新載入 skb 標頭的指標。如果未採用後續的 skb_realloc_headroom （） 分支，SIT 會使用過時的 iph6 指標來讀取內部躍點限制和 DS 欄位。在舊頭的剩餘克隆被釋放後，這可以從釋放的 skb 頭中讀取。在卸載協助程式成功之後，以及從內部 IPv6 標頭進行後續讀取之前，重新載入 iph6。在 skb_realloc_headroom（） 之後保留現有的重新載入，因為該分支也可以取代 skb。（CVE-2026-53228）

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

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

  - wifi： mt76： mt7996：修正 mt7996_mac_dump_work（） 中的釋放後使用錯誤 當 mt7996 pci 晶片分離時，mt7996_crash_data會以 mt7996_coredump_unregister（） 形式釋放。不過，工作項目dump_work可能仍在執行或擱置中，當已釋放的crash_data在 mt7996_mac_dump_work（） 中再次取消參照時，會導致 UAF 錯誤。爭用情形可能發生如下： CPU 0 （移除路徑） |CPU 1 （工作佇列） mt7996_pci_remove（） |mt7996_sys_recovery_set（） mt7996_unregister_device（） |mt7996_reset（） mt7996_coredump_unregister（） |queue_work（） vfree（dev->coredump.crash_data） |mt7996_mac_dump_work（） |crash_data-> // UAF 透過確保在取消配置crash_data之前正確取消dump_work來修正此問題。在 mt7996_unregister_device（） 中新增 cancel_work_sync（），以與任何擱置或執行中的轉儲工作同步。（CVE-2026-53097）

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

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

  - netfilter：在假設 skb 與乙太網路裝置相關聯或僅檢查 'skb_mac_header（skb）' 處的 'ETH_HLEN' 位元組位於 'skb->head' 和 'sk>b-data' 之間之後，在使用 eth_hdr（） 'ip6t_eui64'、'xt_mac'、'bitmap：ip，mac'、'hash：ip，mac' 和 'hash：mac' ipset 類型，以及 'nf_log_syslog' 存取 'eth_hdr（skb）' 之前，需要乙太網 MAC 標頭。使這些路徑在存取「eth_hdr（skb）」之前，首先驗證 skb 是否與乙太網路裝置相關聯、是否已設定 MAC 標頭，以及它是否至少跨越一個完整的乙太網路標頭。（CVE-2026-53131）

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

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

  - drm/xe：修正 xe_exec_queue_create_ioctl（） 中的錯誤清除 xe_exec_queue_create_ioctl（） 中存在兩個錯誤處理問題： 1. 當 xe_hw_engine_group_add_exec_queue（） 失敗時，錯誤路徑會跳到跳過 xe_exec_queue_kill（） 的put_exec_queue。如果 VM 處於搶佔柵欄模式，則 xe_vm_add_compute_exec_queue（） 已將佇列新增至 VM 的計算執行佇列清單。跳過終止會將佇列留在該清單上，導致佇列釋放後出現懸空指標。2. 當 xe_hw_engine_group_add_exec_queue（） 成功後 xa_alloc（） 失敗時，錯誤路徑不會呼叫 xe_hw_engine_group_del_exec_queue（） 從硬體引擎群組清單中移除佇列。然後，佇列會在仍連結至 hw 引擎群組時釋放，造成釋放後使用。透過下列方式修正這兩個問題： - 變更 xe_hw_engine_group_add_exec_queue（） 失敗路徑以跳轉至 kill_exec_queue，以便 xe_exec_queue_kill（） 正確地從 VM 的計算清單中移除佇列。- 在kill_exec_queue 的 xa_alloc（） 失敗路徑之前新增del_hw_engine_group標籤，這會在繼續進行其餘清理之前，先從硬體引擎群組中移除佇列。（從提交 37c831f401746a45d510b312b0ed7a77b1e06ec8 中挑選）（CVE-2026-52976）

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

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

  - netfilter： conntrack_irc：修正可能的越界讀取 當我們比對命令字串後剖析失敗時，我們應該退出，而不是嘗試比對不同的命令。鑑於 TLS 的盛行，我懷疑它在 2026 年有任何相關性，這個協助程式應該被棄用。（CVE-2026-53268）

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

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

  - mailbox： mailbox-test：不要釋放重複使用的通道 如果 RX 通道具有不同的 MMIO，則可以將其別名設為 TX 通道。釋放通道時需要處理此特殊情況，否則會發生雙重釋放。（CVE-2026-53294）

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

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

  - USB： serial： io_ti：修正 build_i2c_fw_hdr（） 中的堆積溢位 build_i2c_fw_hdr（） 配置一個 （16*1024 - 512） + sizeof（struct ti_i2c_firmware_rec） 位元組的固定大小緩衝區，然後將 le16_to_cpu（img_header->Length） 位元組複製到其中，而不驗證 Length 是否適合韌體記錄標頭之後的可用空間。img_header->Length 是韌體檔案的__le16，最高可達 65535。check_fw_sanity（） 會驗證韌體大小總計，但不會專門驗證 img_header->Length。
    透過拒絕 img_header->Length 超過可用目的地空間的影像來修正。（CVE-2026-53195）

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

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

  - 已解決 Linux 核心中的下列弱點：iommu: Fix WARN_ON in
    __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment. (CVE-2026-52952)

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

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

  - netfilter： nft_fib：透過 OIFNAME 暫存器修正過時的堆疊洩漏 NFT_FIB_RESULT_OIFNAME目標暫存器以 len = IFNAMSIZ （四個 32 位元暫存器） 宣告，但在 lookup-fail 上，RTN_LOCAL 和 oif-mismatch 路徑 nft_fib{4,6}_eval（） 只會透過 *dest = 0 寫入一個暫存器。其餘三個暫存器保留為 nft_do_chain（） 結構nft_regs中堆疊上的任何內容，載入暫存器跨度的下游運算式可能會將未初始化的核心堆疊洩露給使用者空間。
    NFTA_FIB_F_PRESENT存在檢查具有相同的形狀：它僅對NFT_FIB_RESULT_OIF有意義，但當 eval 透過 nft_reg_store8（） 儲存單一位元組時，任何結果類型都接受它，使宣告的範圍的其餘部分過時。修正兩者： - 將 eval 中的裸 *dest = 0 替換為 nft_fib_store_result（），這會strscpy_pad （） OIFNAME 的整個 IFNAMSIZ （並且已在另一個提前返回路徑上使用），以及 - 將 NFTA_FIB_F_PRESENT 限制為NFT_FIB_RESULT_OIF，並將其目的地宣告為單一 u8，因此標記的範圍符合 eval 寫入的一個位元組。（CVE-2026-53134）

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

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

  - net： bcmgenet：修正洩漏的free_bds 回收 tx 佇列時，我們會快轉寫入指標，以丟棄任何正在傳輸的資料。這些丟棄的影格不會新增回可用 bd 集區。我們還需要告訴 netdev 我們正在刪除上述數據。（CVE-2026-53087）

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

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

  - ima_fs：如果不支援 TPM 演算法，則會為不支援的雜湊演算法正確建立 securityfs 檔案 ima_tpm_chip->allocated_banks[i].crypto_id 初始化為HASH_ALGO__LAST。然而，有些地方依賴演算法才有效，因為它是由 存取的 hash_algo_name[]。在hash_algo_name 6.12.40 中，我觀察到以下讀數越界：
    ================================================================== 錯誤： KASAN：create_securityfs_measurement_lists+0x396/0x440 中的全域越界 由任務交換器/0/1 在 addr ffffffff83e18138 讀取大小 8 CPU：4 UID：0 PID：1 通信：swapper/0 未受 6.12.40 #3 污染 呼叫追蹤： <TASK> dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ？ kasan_addr_to_slab+0x26/0x80 ？ create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ？ create_securityfs_measurement_lists+0x396/0x440create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 </TASK> 錯誤位址屬於變數：hash_algo_name+0xb8/0x420 錯誤位址周圍的記憶體狀態： ffffffff83e18000： 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 ffffffff83e18080： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83 e18100： 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180： f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200： 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 ================================================================== TPM 晶片似乎支援 sha3_256，但尚未tpm_algorithms：tpm tpm0：具有不支援的銀行演算法的 TPM 0x0027 這是 TPM_ALG_SHA3_256 == 0x0027來自受信任的平台模組 2.0 庫第 2 部分：結構，第 51 頁 [1]。另請參閱相關的 U-Boot 演算法更新 [2]。因此，透過建立檔案名稱來解決問題
    如果加密演算法未初始化，則_tpm_alg_<ID> 後綴。這是它在測試電腦上的外觀 （修補程式移植到 v6.12 版本）： # ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256 原則runtime_measurements_count違規 [1]：
    https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]： https://lists.denx.de/pipermail/u-boot/2024-July/558835.html(CVE-2026-53038）

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

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

  - drm/v3d：當間接 CSD 將工作群組歸零時，修正 vaddr 洩漏 v3d_rewrite_csd_job_wg_counts_from_indirect（） 會同時映射間接緩衝區和工作群組緩衝區，並預期在返回之前釋放它們。當從緩衝區讀取的任何工作群組計數為零時，函式會提前退出並跳過清理，從而洩漏兩個 BO 的 vaddr 對應。跳至清理路徑，而不是直接返回，因此一律會捨棄對應。（CVE-2026-53140）

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

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

  - net/sched： sch_dualpi2：清空 dualpi2_change（） 中的 C-queue 和 L-queue 修正 dualpi2_change（） 以在 dualpi2 qdisc 的組態變更後正確執行更新的 limit 和 memlimit 值。
    在此修補程式之前，dualpi2_change（） 在減少積壓或記憶體使用量時，總是嘗試透過根 qdisc（C 佇列）將封包出列，並且無條件地假設將傳回有效的 skb。當流量分類導致封包在 L 佇列中排隊，而 C 佇列為空時，這會導致在限制或記憶體限制強制執行期間發生空 skb 取消參照。如果 C 佇列路徑不為空，請先從 C 佇列路徑出列，即可修正此問題。一旦 C 佇列為空，封包就會直接從 L 佇列出列。系統會針對這兩個佇列檢查 qdisc_dequeue_internal（） 的傳回值。從 L 佇列出列時，會明確更新母項 qdisc qlen 及 backlog 計數器，以保持整體 qdisc 統計資料一致。（CVE-2026-52997）

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

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

  - 已解決 Linux 核心中的下列弱點：ptp: ocp: fix resource freeing order Commit a60fc3294a37 (ptp: rework ptp_clock_unregister() to disable events) added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight. (CVE-2026-53222)

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

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

  - netlabel：驗證未標記的位址及遮罩屬性長度 netlbl_unlabel_addrinfo_get（） 使用位址屬性長度來判斷屬性資料是否可以讀取為 IPv4 或 IPv6 位址，但未獨立驗證對應的遮罩屬性長度。因此，特製的通用網路連結要求可以提供具有較短遮罩屬性的有效 IPv4/IPv6 位址屬性，稍後會讀取為完整的結構in_addr或結構in6_addr。NLA_BINARY原則長度預設為最大長度，因此請針對未標記的 IPv4/IPv6 位址和遮罩屬性使用 NLA_POLICY_EXACT_LEN（）。
    這會在原則驗證期間拒絕短屬性，並透過原則自省公開確切的長度需求。（CVE-2026-53238）

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

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

  - ice：修正 ice_reset_all_vfs（） 中的 NULL 指標解除參照 ice_reset_all_vfs（） 忽略 ice_vf_rebuild_vsi（） 的傳回值。當 VSI 重建失敗時 （例如，在透過 nvmupdate64e 更新 NVM 韌體期間），ice_vsi_rebuild（） 會在其錯誤路徑上拆除 VSI，將 txq_map 和 rxq_map 保留為 NULL。後續無條件調用 ice_vf_post_vsi_rebuild（） 在存取 vsi->txq_map[0] 時會導致 ice_ena_vf_q_mappings（） 中的 NULL 指標解除參照。ice_reset_vf（） 中的單 VF 重設路徑已經透過檢查 ice_vf_reconfig_vsi（） 的傳回值並在失敗時跳過 ice_vf_post_vsi_rebuild（） 來正確處理此問題。將相同的模式應用於 ice_reset_all_vfs（）：檢查 ice_vf_rebuild_vsi（） 的傳回值，失敗時跳過 ice_vf_post_vsi_rebuild（） 和 ice_eswitch_attach_vf（）。
    VF 處於安全停用狀態 （ICE_VF_STATE_INIT未設定，VFGEN_RSTAT未設定為 VFACTIVE），且可透過 VF 的 PCI 重設 （sysfs 重設或驅動程式重新綁定） 觸發的 VFLR 來復原。請注意，此修補程式不會防止 VF VSI 重建在 NVM 更新期間失敗，根本原因是韌體在處理 EMP 重設時處於過渡狀態，這可能導致管理員佇列命令 （ice_add_vsi、ice_cfg_vsi_lan） 失敗。此修補程式只會防止後續的 NULL 指標解除參照，當重建失敗時，核心會損毀。crash> bt PID： 50795 任務：
    ff34c9ee708dc680 CPU：1 命令：kworker/u512：5 #0 [ff72159bcfe5bb50] machine_kexec於 ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec於 fffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec於 fffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end於 fffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops於 fffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault於 ffffffffab528595 #6 [ff72159bcfe5bd10] 在 ffffffffab600bb2 asm_exc_page_fault [異常 RIP：ice_ena_vf_q_mappings+0x79] RIP：ffffffffc0a85b29 RSP：ff72159bcfe5bdc8 RFLAGS：00010206 RAX：00000000000f0000 RBX：ff34c9efc9c000000000 RCX：00000000000000000 RDX：00000000000000000000 RSI：0000000000000010 RDI：ff34c9efc9c00000 RBP：ff34c9efc27d4828 R8：
    0000000000000093 R9： 0000000000000040 R10： ff34c9efc27d4828 R11： 0000000000000040 R12： 0000000000100000 R13： 0000000000000010 R14： R15： ORIG_RAX： ffffffffffffff CS： 0010 SS： 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild於 ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs於 ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task於 ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work於 fffffffffaa93dca4 #11 [ff72159bcfe5bec8] 在 ffffffffaa93e9de #12 處worker_thread [ff72159bcfe5bf18] 在 ffffffffaa946663 #13 處的 kthread [ff72159bcfe5bf50] ret_from_fork在 ffffffffaa8086b9 嘗試取消參照 RDX 中 ice_sriov.c：294 處的 NULL 指標時會發生錯誤，這會載入 vsi->txq_map （ice_vsi 中的位移0x4b8）。出錯的 VSI 是已分配的 slab 物件，但在失敗的 ice_vsi_rebuild（） 後未完全初始化：crash>struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0、rx_rings = 0x0、tx_rings = 0x0、q_vectors = 0x0、txq_map = 0x0、rxq_map = 0x0、alloc_txq = 0x10、num_txq = 0x10、alloc_rxq = 0x10、num_rxq = 0x10、nvmupdate64e 處理程序正在執行 NVM 韌體更新：
    crash> bt 0xff34c9edd1a30000 PID：49858 任務：ff34c9edd1a30000 CPU：1 命令：nvmupdate64e #0 [ff72159bcd617618] __schedule於 ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd於 ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry於 ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd於 ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm於 ffffffffc0a40254 [ice] #8 ---truncated--- （CVE-2026-53289）

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

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

  - 已解決 Linux 核心中的下列弱點：um: Fix potential race condition in TLB sync During the TLB sync, we need to traverse and modify the page table, so we should hold the page table lock. Since full SMP support for threads within the same process is still missing, let's disable the split page table lock for simplicity. (CVE-2026-53020)

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

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

  - 已解決 Linux 核心中的下列弱點：net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy.
    Let's therefore only run phy_sfp_probe when not using genphy. (CVE-2026-53231)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 (drm: Set old handle to NULL before prime swap in change_handle) tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 (drm/gem: fix race between change_handle and handle_delete) tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c (drm: Replace old pointer to new idr) tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now.
    Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too. (CVE-2026-53145)

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

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

  - 攻擊者可能會傳送具有無效 DATA 框架的 DoH3 GET 查詢，以延遲 DoH3 查詢的處理。（CVE-2026-40208）

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

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

  - xfrm： policy：修正 xfrm_policy_bysel_ctx（） 中不精確 bin 的釋放後使用 透過修剪垃圾桶來修正爭用，同時仍按住 xfrm_policy_lock bin，然後再刪除它。直接使用 __xfrm_policy_inexact_prune_bin（），因為鎖定已持有。包裝函式 xfrm_policy_inexact_prune_bin（） 會變成未使用狀態並移除。
    Race： CPU0 （XFRM_MSG_DELPOLICY） CPU1 （XFRM_MSG_NEWSPDINFO） ========================== ========================== xfrm_policy_bysel_ctx（）： spin_lock_bh（xfrm_policy_lock） bin = xfrm_policy_inexact_lookup（） __xfrm_policy_unlink（pol） spin_unlock_bh（xfrm_policy_lock） xfrm_policy_kill（ret） // 寬視窗，未保持鎖定 xfrm_hash_rebuild（）： spin_lock_bh（xfrm_policy_lock）
    __xfrm_policy_inexact_flush（）： kfree_rcu（bin） // bin 釋放 spin_unlock_bh（xfrm_policy_lock） xfrm_policy_inexact_prune_bin（bin） // UAF：bin 已釋放 （CVE-2026-53239）

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

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

  - 已解決 Linux 核心中的下列弱點：fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of *len 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at:
    ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 (CVE-2026-53029)

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

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

  - mailbox： mailbox-test： 探查錯誤時釋放通道 探測錯誤時，釋放先前取得的通道。
    這不僅可以防止洩漏，還可以防止 UAF 案例，因為用戶端結構仍會被移除，因為它是使用 devm 配置的。（CVE-2026-53296）

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

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

  - bpf：修正純量 regs 的 map_kptr_match_type 中的 NULL 解除參照 提交 ab6c637ad027 （bpf：修正本機 kptr 的 bpf_kptr_xchg（） 問題） 重構的 map_kptr_match_type（） 在檢查 base_type（） 之前在 btf_is_kernel（） 上分支。儲存在 kptr 插槽中的純量暫存器沒有 btf，因此 btf_is_kernel（reg->btf） 呼叫解除參照 NULL。在任何 reg->btf 存取之前，移動 base_type（） ！= PTR_TO_BTF_ID防護。（CVE-2026-53032）

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

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

  - clk： spacemit： ccu_mix：修正 ccu_mix_trigger_fc（） 中的反轉條件 修正跳過頻率變更觸發程序的反轉條件，在 cpufreq 擴展期間導致核心錯誤。（CVE-2026-53019）

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

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

  - 已解決 Linux 核心中的下列弱點：drm/xe/dma-buf: fix UAF with retry loop Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us.
    This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) (CVE-2026-52950)

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

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

  - IB/isert：拒絕短於 ISER_HEADERS_LEN 的登入 PDU 在 drivers/infiniband/ulp/isert/ib_isert.c 中， isert_login_recv_done() 會將登入要求負載長度計算為 wc->byte_len 減去 ISER_HEADERS_LEN 並且沒有下限，而 login_req_len 是帶正負號的整數。遠端 iSER 起始程式可以張貼攜帶少於 ISER_HEADERS_LEN (76) 位元組的登入 Send 工作要求，因此減法會反向溢位，同時 login_req_len 會變成 negative. isert_rx_login_req() 隨後會將該負值長度讀取回帶正負號的整數，攜帶 size = min(rx_buflen, MAX_KEY_VALUE_PAIRS)，同時由於 min() 帶正負號，因此會保留負值；隨後會傳遞數值作為 memcpy() 長度，同時符號擴展至多 GB size_t。複製到 8192-byte login->req_buf 的動作在執行上遠超出邊界並發生故障，導致目標節點損毀。登入階段發生在 iSCSI 驗證之前，因此不需要任何憑證即可到達此路徑。拒絕在減去前短於 ISER_HEADERS_LEN 的任何登入 PDU，鏡像現有內容會在失敗工作完成時提前傳回，因此 login_req_len 絕對不會變成負值。上限已經是安全的：已發布的登入緩衝區不能提供超過 ISER_RX_PAYLOAD_SIZE，因此差異保持在 MAX_KEY_VALUE_PAIRS 或在 MAX_KEY_VALUE_PAIRS 以下，同時現有的 min() 對其造成限制；只需要新增缺少的下限。
    (CVE-2026-53176)

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

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

  - ALSA： timer：關閉時強制關閉計時器實例 當snd_timer物件透過 snd_timer_free（） 釋放並且仍等待將snd_timer_instance物件分配給計時器物件時，它會嘗試取消所有實例的連結，並僅為每個 ti->timer 設定 NULL，然後立即釋放資源。然而，問題在於，當存在與連結到此計時器的主要執行個體相關聯的從屬計時器執行個體時：也就是說，儘管主執行個體未連結，但這些從屬執行個體仍然指向釋放的計時器物件，這可能會導致釋放後使用者。特別是當涉及新的使用者空間驅動計時器 （CONFIG_SND_UTIMER） 時，很容易觸發此錯誤，因為它可以透過簡單的檔案開啟/關閉來建立和刪除計時器物件，而其他應用程式可能會繼續存取該計時器。此修補程式試圖解決上述問題：現在不再只是取消鏈接，而是為每個擱置的計時器實例強制調用 snd_timer_close[_locked]（），以便所有分配的從屬計時器實例也正確分離。由於建立該實例的驅動程式稍後可能會呼叫 snd_timer_close（），因此也會在開頭新增SNDRV_TIMER_IFLG_DEAD檢查。（CVE-2026-53193）

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

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

  - 藍牙：管理：在類型檢查之前驗證廣告 TLV，tlv_data_is_valid（） 從 data[i] 讀取每個廣告資料欄位長度，然後檢查受管理 EIR 類型的 data[i + 1]，然後檢查目前欄位是否仍適合提供的緩衝區內。因此，長度位元組是緩衝區最後一個位元組的格式錯誤欄位可以使剖析器讀取廣告資料後一個位元組。當格式錯誤的 MGMT_OP_ADD_ADVERTISING 要求到達該路徑時，KASAN 會報告下列內容： 錯誤： KASAN：大小為 1 的 tlv_data_is_valid（） 讀取中的 vmalloc-out-of-bounds 呼叫追蹤：tlv_data_is_valid（） add_advertising（） hci_mgmt_cmd（） hci_sock_sendmsg（） 在任何類型八位元組檢查之前移動現有的元素長度檢查，以便在剖析器查看 data[i + 1] 之前，證明每個非空元素都包含其類型位元組。
    (CVE-2026-53255)

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

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

  - mm/memory-failure：修正 get_huge_page_for_hwpoison 中的 hugetlb_lock AA 鎖死 當與並行取消映射競爭時，同一 hugetlb 頁面上的兩個並發 madvise（MADV_HWPOISON） 呼叫可能會觸發遞迴微調鎖自我鎖死 （AA 鎖死） on hugetlb_lock： thread#0 thread#1 -------- -------- madvise（folio， MADV_HWPOISON） -> 成功毒害對開本 madvise（folio， MADV_HWPOISON） unmap（folio） try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq（&hugetlb_lock） <- 保留
    __get_huge_page_for_hwpoison hugetlb_update_hwpoison（） -> MF_HUGETLB_FOLIO_PRE_POISONED goto out：
    folio_put（） refcount： 1 -> 0 free_huge_folio（） spin_lock_irqsave（&hugetlb_lock） -> AA 鎖死！出局：
    path in __get_huge_page_for_hwpoison（） 呼叫 folio_put（） 以刪除 GUP 參照，而 HUGETLB.c 包裝函式 get_huge_page_for_hwpoison（） 仍持有 hugetlb_lock。如果並行取消對應已釋放頁面表格對應參照，則 folio_put（） 會將對開本參照計數降至零，觸發 free_huge_folio（） 嘗試重新取得非遞迴hugetlb_lock。透過將hugetlb_lock獲取從 hugetlb.c 包裝器移動到 get_huge_page_for_hwpoison（） 來解決此問題。將 spin_unlock_irq（） 放在 out： 標籤的 folio_put（） 之前，以便對開本一律在鎖外釋放。[akpm@linux-foundation.org：修正爭用，根據苗河重命名標籤]（CVE-2026-53207）

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

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

  - drm/amd/display：將 VBIOS HDMI 重定時器暫存器計數限制為陣列大小 [原因和方式] VBIOS 整合資訊表 （v1_11 和 v2_1） 包含 HdmiRegNum 和 Hdmi6GRegNum 欄位，當將重定時器 I2C 暫存器設定複製到固定大小陣列 （dp*_ext_hdmi_reg_settings[9] 和 dp*_ext_hdmi_6g_reg_settings[3]） 時，這些欄位用作迴圈邊界。這些 u8 欄位在使用前不會經過驗證，因此格式錯誤的 VBIOS 可以指定最多 255 的值，在驅動程式探查期間造成越界堆積寫入。在複製迴圈之前，在 get_integrated_info_v11（） 和 get_integrated_info_v2_1（） 中使用 min_t（） 將每個暫存器計數限制為目標陣列大小。（從提交 5a7f0ef90195940c54b0f5bb85b87da55f038c69 中挑選）（CVE-2026-53136）

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

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

  - net： mvpp2：在 XDP 或 skb 使用之前重新填充 RX 緩衝區 RX 錯誤路徑會將目前的描述元緩衝區傳回至硬體 BM 儲存區。這只有在驅動程式仍擁有緩衝區時才有效。
    mvpp2_rx_refill（） 在將目前緩衝區傳遞至 XDP 或附加至 skb 之後，可能會失敗。在這些情況下，mvpp2_run_xdp（） 可能已回收、重新導向頁面或將頁面排入佇列以等待XDP_TX，而 skb 釋放也會淘汰資料緩衝區。將這類緩衝區傳回給 BM 可讓硬體 DMA 進入 RX 通道不再擁有的記憶體。在將目前緩衝區交給 XDP 或 skb 之前，請先重新填入 BM 集區。如果配置在那裡失敗，請丟棄封包，並將仍擁有的目前緩衝區傳回 BM，以保留集區深度。一旦重新填充成功，稍後的本地丟棄會淘汰/釋放當前緩衝區，而不是將其返回給 BM。CVE-2026-53215

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

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

  - 攻擊者可透過 HTTP/3 查詢傳送特製的 DNS，觸發例外狀況，防止立即釋放某些緩衝區。緩衝區會在 QUIC 連線結束時釋放，但在某些設定中，可能會開啟足夠並行的 DoH3 資料流，以觸發記憶體不足狀況，進而造成拒絕服務。（CVE-2026-40211）

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

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

  - 藍牙：ISO：修正不釋放 iso_conn_big_sync hci_get_route（） 上的 hdev 參照，透過 hci_dev_hold（） 傳回參照計數的 hci_dev 指標。函式會正常結束，或發生錯誤，但從未釋放。（CVE-2026-53251）

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

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

  - netfilter： nft_ct：在 get eval 中拯救模板 ct 我在查看歷史 syzbot 報告 [1] 時注意到了這個問題。像下面的規則足以觸發錯誤： table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } 第一個表達式透過 nft_ct_set_zone_eval（） 附加 per-cpu 範本 ct （nf_ct_tmpl_alloc -> kzalloc， tuple 均為零，nf_ct_l3num（ct） == 0）。然後，下一個運算式在同一 skb 上呼叫 nft_ct_get_eval（），將範本視為真正的 ct 並命中 16 位元組的 memcpy 路徑。當 dreg 處於NFT_REG32_15時，這會溢出核心堆疊上的結構nft_regs;對於較小的渣滓值，它會默默地破壞相鄰的暫存器。拒絕 eval 項目和 nft_ct_get_fast_eval（） 中的範本 ct，鏡像檢查 nft_ct_set_eval（） 已經進行。此外，透過 priv->len 而不是 nf_ct_l3num（ct） 綁定 NFT_CT_SRC/NFT_CT_DST 中的位址副本：nf_ct_get_tuple（） 在 pkt_to_tuple（） 僅填充與通訊協定相關的前導位元組之前將元組歸零，因此元組>{src，dst}.u3.all 的尾隨位元組是明確定義的零。priv->len 會在規則載入時進行驗證，因此副本大小現在受目的地暫存器限制，而不是由 conntrack 上的不受信任欄位限制。[1]:
    https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c (CVE-2026-53267)

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

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

  - bpf：從task_vma迭代器傳回 VMA 快照 當協助程式取得相依於 mmap_lock 的鎖定時，在 BPF 程式主體中保留 per-VMA 鎖定會產生鎖定排序問題： vm_lock -> i_rwsem -> mmap_lock -> vm_lock 透過 memcpy（） 在 _next（） 中將 VMA 鎖定建立快照，然後在返回之前刪除鎖定。BPF 程式僅存取快照。驗證程式只信任 vm_mm 和 vm_file 指標 （請參閱 verifier.c 中的BTF_TYPE_SAFE_TRUSTED_OR_NULL）。vm_file在鎖定下使用 get_file（） 進行引用計數，並在下一次迭代或 _destroy（） 中通過 fput（） 釋放。vm_mm已經正確了，因為 lock_vma_under_rcu（） 驗證了 vma->vm_mm == mm。memcpy（） 會保留所有其他指標，因為驗證程式會將它們視為不受信任。（CVE-2026-53084）

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

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

  - 使用 SetMacAddrAction 時，可能會發生越界讀取，可能導致透過網路傳送未初始化的記憶體或損毀。（CVE-2026-40210）

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

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

  - locking/rtmutex：當服務員未排入佇列時，跳過 remove_waiter（） syzbot 透過 FUTEX_CMP_REQUEUE_PI 觸發了 remove_waiter（） 中的以下 splat： KASAN：範圍 [0x0000000000000a88-0x0000000000000a8f] 中的 null-ptr-deref class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c：1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0
    __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex（） 不會在偵測到鎖死時武裝服務員，導致 waiter->task nil，其中 3bfdc63936dd （rtmutex：在 remove_waiter（） 中使用 waiter：：task 而不是 current） 使此情況嚴重。此外，rt_mutex_start_proxy_lock（） 不應該在成功獲取 rtmutex 時調用 remove_waiter（）。1a1fb985f2e2 （futex：正確處理早期鎖死返回），將 remove_waiter（） 從 __rt_mutex_start_proxy_lock（） 中移出 （其中 'ret' 只有 0 或< 0） 到包裝函式中。收緊此檢查以考慮 try_to_take_rt_mutex（）。
    (CVE-2026-53163)

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

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

  - 無效區域可能會通過 ZONEMD 驗證，但不應該通過。只有在 ZoneToCache 設定了 ZONEMD 驗證時，這才相關。（CVE-2026-42390）

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

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

  - net： openvswitch：修正可能的 kfree_skb 的 ERR_PTR 在 Fixes 標籤中安裝修補程式之後，回覆 skb 的分配可以在鎖定ovs_mutex之前或之後進行。然而，錯誤清除仍然遵循經典的相反順序，假設在鎖定之前分配了回覆：它在解鎖後被釋放。如果在鎖定互斥之後發生回覆分配並且失敗，則回覆會留下一個ERR_PTR，並且執行會跳到對應的清理階段，該階段將嘗試釋放無效指標。
    在儲存錯誤值之後，將指標設定為 NULL，即可修正此問題。（CVE-2026-53227）

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

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

  - misc： fastrpc：修正工作佇列內容中fastrpc_user的釋放後使用 fastrpc_device_release（） 與處理 DSP 回應的工作佇列之間存在爭用。當使用者關閉檔案描述元時，fastrpc_device_release（） 會釋放fastrpc_user結構。同時，進行中的DSP叫用可以完成，fastrpc_rpmsg_callback（）會透過schedule_work（&ctx->put_work）排程內容清除。如果工作佇列在 fastrpc_device_release（） 釋放使用者結構時或之後執行 fastrpc_context_free（），則會解除參照釋放的fastrpc_user。根據比賽時上下文的狀態，可以點擊以下任何一個訪問： 1.
    fastrpc_buf_free（） 會呼叫 fastrpc_ipa_to_dma_addr（buf->fl->cctx， ...） 以從儲存的 IOVA 中剝離 SID 位元，然後再將實體位址傳遞給 dma_free_coherent（）。2. fastrpc_free_map（） 讀取 map->fl->cctx->vmperms[0].vmid，以重建 qcom_scm_assign_mem（） 呼叫所需的來源權限位遮罩，該呼叫將記憶體從 DSP VM 傳回 HLOS。3. fastrpc_free_map（） 取得 map->fl->lock 以安全地從 fl->maps 清單中移除映射節點。產生的釋放後使用表現為： pc ： fastrpc_buf_free+0x38/0x80 [fastrpc] lr ： fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 將基於 kref 的參照計數新增至 fastrpc_user。
    讓每個叫用內容在配置時對使用者進行參照，並在釋放內容時釋放它。在檔案關閉時釋放 fastrpc_device_release（） 中的初始參照。將釋放擱置內容、對應、mmap 和通道內容參照的使用者結構的拆解移至 kref 釋放回呼 fastrpc_user_free（） 中，以便僅在刪除最後一個參照時執行，無論這種情況是在裝置關閉時還是在最終進行中內容完成後發生。
    (CVE-2026-53161)

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

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

  - tcp：在 reqsk_queue_hash_req(). syzbot 中新增 preempt_{disable,enable}_nested() 報告 _inet_csk_reqsk_queue_drop() 中出現不尋常的 reqsk->rsk_refcnt underflow。__inet_csk_reqsk_queue_drop() 中擷取的 reqsk_put()
    只有在成功從 ehash 中移除 reqsk 時才會呼叫。此外，reqsk_timer_handler() 之後會呼叫另一個 reqsk_put()。這表示 reqsk 缺少 ehash 的參考和計時器本身。由於所有 syzbot 報告都啟用了 PREEMPT_RT，因此唯一可能的情況是 reqsk_queue_hash_req（） 在 mod_timer（） 之後和 refcount_set（） 之前被搶佔，然後在 1 秒後觸發的計時器由於其接聽程式的 close（） 而中止了 reqsk。讓我們用 preempt_disable_nested（） 和 preempt_enable_nested（） 包裝 mod_timer（） 和 refcount_set（）。請注意，inet_ehash_insert() 保有一般 spin_lock() (PREEMPT_RT 中的 mutex)， 因此必須在  preempt_disable_nested() 之外調用它，但是這點沒有問題。查詢路徑只會忽略 ehash 中的 0 個 sk_refcnt 項目，並嘗試建立另一個 reqsk，但是這樣會在 inet_ehash_insert(). [0]: refcount_t: 時失效，下溢;釋放後使用。警告：lib/refcount.c:28 位於 refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28, CPU#0:
    ktimers/0/16 模組連結位置：CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP 硬體名稱：Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28 程式碼：e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3a eb 37 e8 25 3d 23 fd 48 8d 3d de 7d d1 0a <67> 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f RSP:
    0000:ffffc90000157948 EFLAGS: 00010246 RAX: ffffffff84a1301b RBX: 0000000000000003 RCX: ffff88801ca98000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffffff8f72ae00 RBP: ffffffff99ae3b01 R08:
    ffff88801ca98000 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568 R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7b46710e9c CR3: 000000000dbb6000 CR4: 00000000003526f0 呼叫追蹤：<TASK> __refcount_sub_and_test include/linux/refcount.h:400 [inline] __refcount_dec_and_test include/linux/refcount.h:432 [inline] refcount_dec_and_test include/linux/refcount.h:450 [inline] reqsk_put include/net/request_sock.h:136 [inline] __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c:1007 reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c:1137 call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748 expire_timers kernel/time/timer.c:1799 [inline] __run_timers kernel/time/timer.c:2374 [inline] __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386 run_timer_base kernel/time/timer.c:2395 [inline] run_timer_softirq+0x67/0x170 kernel/time/timer.c:2403 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0x69/0x100 kernel/softirq.c:1151 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+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> (CVE-2026-53260)

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

ID	名稱	嚴重性
323464	Linux Distros 未修補弱點：CVE-2026-53249	medium
323463	Linux Distros 未修補弱點：CVE-2026-53269	medium
323462	Linux Distros 未修補弱點：CVE-2026-53188	high
323461	Linux Distros 未修補弱點：CVE-2026-53174	high
323460	Linux Distros 未修補弱點：CVE-2026-53264	high
323459	Linux Distros 未修補弱點：CVE-2026-53201	high
323458	Linux Distros 未修補弱點：CVE-2026-53137	high
323457	Linux Distros 未修補弱點：CVE-2026-53226	medium
323456	Linux Distros 未修補弱點：CVE-2026-53228	critical
323455	Linux Distros 未修補弱點：CVE-2026-53097	high
323454	Linux Distros 未修補弱點：CVE-2026-53131	critical
323453	Linux Distros 未修補弱點：CVE-2026-52976	high
323452	Linux Distros 未修補弱點：CVE-2026-53268	high
323451	Linux Distros 未修補弱點：CVE-2026-53294	high
323450	Linux Distros 未修補弱點：CVE-2026-53195	high
323449	Linux Distros 未修補弱點：CVE-2026-52952	high
323448	Linux Distros 未修補弱點：CVE-2026-53134	medium
323447	Linux Distros 未修補弱點：CVE-2026-53087	high
323446	Linux Distros 未修補弱點：CVE-2026-53038	medium
323445	Linux Distros 未修補弱點：CVE-2026-53140	medium
323444	Linux Distros 未修補弱點：CVE-2026-52997	medium
323443	Linux Distros 未修補弱點：CVE-2026-53222	medium
323442	Linux Distros 未修補弱點：CVE-2026-53238	medium
323441	Linux Distros 未修補弱點：CVE-2026-53289	medium
323440	Linux Distros 未修補弱點：CVE-2026-53020	high
323439	Linux Distros 未修補弱點：CVE-2026-53231	medium
323438	Linux Distros 未修補弱點：CVE-2026-53145	high
323437	Linux Distros 未修補弱點：CVE-2026-40208	low
323436	Linux Distros 未修補弱點：CVE-2026-53239	high
323435	Linux Distros 未修補弱點：CVE-2026-53029	medium
323434	Linux Distros 未修補弱點：CVE-2026-53296	high
323433	Linux Distros 未修補弱點：CVE-2026-53032	medium
323432	Linux Distros 未修補弱點：CVE-2026-53019	medium
323431	Linux Distros 未修補弱點：CVE-2026-52950	high
323430	Linux Distros 未修補弱點：CVE-2026-53176	medium
323429	Linux Distros 未修補弱點：CVE-2026-53193	high
323428	Linux Distros 未修補弱點：CVE-2026-53255	high
323427	Linux Distros 未修補弱點：CVE-2026-53207	medium
323426	Linux Distros 未修補弱點：CVE-2026-53136	high
323425	Linux Distros 未修補弱點：CVE-2026-53215	critical
323424	Linux Distros 未修補弱點：CVE-2026-40211	medium
323423	Linux Distros 未修補弱點：CVE-2026-53251	medium
323422	Linux Distros 未修補弱點：CVE-2026-53267	high
323421	Linux Distros 未修補弱點：CVE-2026-53084	medium
323420	Linux Distros 未修補弱點：CVE-2026-40210	medium
323419	Linux Distros 未修補弱點：CVE-2026-53163	medium
323418	Linux Distros 未修補弱點：CVE-2026-42390	medium
323417	Linux Distros 未修補弱點：CVE-2026-53227	medium
323416	Linux Distros 未修補弱點：CVE-2026-53161	high
323415	Linux Distros 未修補弱點：CVE-2026-53260	critical

偵測

Nessus 的 Misc. 系列

medium

medium

high

high

high

high

high

medium

critical

high

critical

high

high

high

high

high

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

low

high

medium

high

medium

medium

high

medium

high

high

medium

high

critical

medium

medium

high

medium

medium

medium

medium

medium

high

critical