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

  - scsi： libiscsi_tcp：連結至連線緩衝區的 SCSI 回應資料區段 iscsi_tcp_hdr_dissect（） 會將數個 PDU 類型的資料區段接收到固定大小的 conn->data 緩衝區，該緩衝區配置為 ISCSI_DEF_MAX_RECV_SEG_LEN （8192） 位元組。對於 LOGIN_RSP、TEXT_RSP、REJECT 和 ASYNC_EVENT 操作碼，剖析路徑已拒絕 DataSegmentLength 超過該緩衝區的 PDU。SCSI 命令回應 （ISCSI_OP_SCSI_CMD_RSP） 路徑也會透過 iscsi_tcp_data_recv_prep（） 將其資料區段 （感應/回應資料） 複製到 conn->data 中，但不會進行相同的檢查。in.datalen 上唯一綁定的上游是 conn->max_recv_dlength，這是發起方通告的 MaxRecvDataSegmentLength，通常在遠高於 8192 時協商（open-iscsi 預設為 262144）。因此，傳回 DataSegmentLength 介於 8193 和 max_recv_dlength 之間的 SCSI 回應的目標會溢位 8192 位元組的 conn->data 緩衝區。套用相同的界定之後，ISCSI_OP_SCSI_CMD_RSP的處理方式會完全像這些回應一樣：繫結資料區段，在存在時將其接收到 conn->data 中，否則在沒有資料的情況下完成 PDU。
    將操作碼合併到該案例組中，而不是複製檢查。（CVE-2026-74556）

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

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

  - net： udp_tunnel：修正 udp_tunnel_nic_unregister（） 中的記憶體洩漏 syzbot 在 UDP 通道 NIC 卸載程式碼中報告記憶體洩漏 [1]。當裝置註冊失敗時 （例如在 register_netdevice（） 中），netdev core 會透過傳送單一NETDEV_UNREGISTER通知來展開。如果工作在NETDEV_REGISTER期間排入佇列 （設定了 utn->work_pending），則 udp_tunnel_nic_unregister（） 會提前傳回：if （utn->work_pending） return;
    因為失敗的註冊不會輸入 netdev_wait_allrefs_any（），所以不會發生後續的NETDEV_UNREGISTER重新廣播。因此，udp_tunnel_nic_alloc（） 中配置的結構udp_tunnel_nic會永久洩漏。透過移除提前歸還來解決此問題。相反地，在釋放@utn之前，請先使用 cancel_delayed_work_sync（） 同步取消任何擱置中的工作。為了能夠在按住 RTNL 的同時調用 cancel_delayed_work_sync（），請將 udp_tunnel_nic_device_sync_work（） 切換為 rtnl_trylock（）。如果爭用 RTNL，請以 1 個延遲 （透過 queue_delayed_work（）） 將工作重新排入佇列，以防止在等候 RTNL 鎖定時發生高 CPU 爭用。不再需要 utn->work_pending 簿記，且會移除，因為工作佇列核心已追蹤工作的擱置/執行狀態。[1] 錯誤：記憶體洩漏未參照的物件0xffff888127d5f840（大小 96）：comm syz-executor，PID 5806，jiffies 4294942188回溯 （crc 99fdb6c8）：__kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c：756 [內嵌] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c：833 [內嵌] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c：931 notifier_call_chain+0x59/0x160 kernel/notifier.c：85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c：2250register_netdevice+0xc10/0xeb0 net/core/dev.c：11478 （CVE-2026-74543）

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

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

  - i2c： imx：當硬體斷電時標示 I2C 配接卡 在某些 i.MX 平台上，某些 I2C 用戶端驅動程式會保留定期工作佇列，以繼續觸發 I2C 傳輸。在系統暫停/還原期間，兩者之間存在一個時間範圍： - suspend_noirq和系統進入暫停 - 系統開始還原並resume_noirq 在此視窗中，I2C 控制器資源 （例如 clock 和 pinctrl） 可能已經停用或尚未還原。如果工作佇列在此期間觸發 I2C 傳輸，驅動程式會在硬體資源無法使用時嘗試存取 I2C 暫存器，這可能會導致系統停擺。在 noirq 暫停期間將 I2C 配接卡標示為已暫停，並封鎖新的傳輸，直到恢復為止，確保只有在硬體資源可用時才發出 I2C 傳輸。（CVE-2026-74462）

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

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

  - 藍牙：ISO：修正 iso_conn iso_conn_del（） 和 iso_chan_del（） 的參照計數，導致雙重放置iso_conn：[任務 hdev->workqueue] [任務 2] iso_conn_del iso_chan_del iso_conn_hold_unless_zero iso_conn_lock iso_conn_lock conn->sk = NULL iso_conn_unlock sk = iso_sock_hold（conn） <--------- if （！sk） iso_conn_put iso_conn_put iso_conn_put /* UAF */ ！sk 的額外放置目前需要 iso_conn_del（），因為失敗的 iso_chan_add（） 可能會使iso_conn與任何 sk 無關聯。透過在非 NULL 時讓 iso_pi（sk）->conn 自己的參照計數來修正，因此iso_conn_del不需要放置它。調整 iso_conn_add（） 參照計數，以便在 conn 未與 sk 關聯時放置它。CVE-2026-74534

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

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

  - Bluetooth： hci_sync：在 hci_connect_pa_sync（） 回呼中保留 conn 如果在 hci_sync 任務執行時釋放 conn，則理論上存在 UAF。保留 refcount 以避免這種情況。（CVE-2026-74529）

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

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

  - hwmon： （adt7470） 修正更新執行緒中的忙碌迴圈和 I2C 溢流 當使用者空間透過 sysfs 將 'auto_update_interval' 配置為 0 時，背景 kthread 會執行 schedule_timeout_interruptible（0），並立即傳回。如果 'num_temp_sensors' 同時或先前設定為 0，則 adt7470_read_temperatures（） 內的 msleep_interruptible（） 延遲也會變成 0。這種組合迫使後台線程進入一個緊密、不受限制的忙碌循環，佔用 CPU 並用連續的交易流淹沒 I2C 總線。透過將 auto_update_interval_store（） 中的clamp_val下限從 0 提高到 500 毫秒來修正此弱點。這可確保感測器更新之間有合理的最小睡眠時間，保護系統免受有意或意外的 I2C 匯流排拒絕服務的影響。
    (CVE-2026-74547)

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

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

  - audit：修正 audit_del_rule（） 中潛在的釋放後使用，「audit_del_rule（）」會透過「audit_remove_mark_rule（）」破壞「e->rule.exe」，然後取消規則與 RCU 可見的篩選清單的連結並等待寬限期。'audit_filter（）' 和 'audit_filter_rules（）' 中的並行讀取器仍會取消參照 'e->rule.exe'，而 fsnotify 標記可以在獨立的存留期路徑上釋放。這會在規則刪除期間建立釋放後使用時段。透過取消規則與 RCU 可見清單的連結，並在呼叫「audit_remove_mark_rule（）」（和其他規則移除協助程式）之前呼叫「synchronize_rcu（）」來修正此問題。這可確保所有現有的 RCU 讀取器在摧毀任何基礎資源之前都已結束關鍵區段。（CVE-2026-74512）

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

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

  - net： sxgbe：RX 配置失敗時釋放 TX 環 當 RX 描述元環配置失敗時，init_dma_desc_rings（） 只會釋放部分配置的 RX 環並傳回。先前在相同函式中配置的 TX 通道已洩漏。重新排列錯誤標籤，以在 RX 失敗時清理 TX 環。（CVE-2026-74525）

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

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

  - vxlan：在 route_shortcircuit（） 中使用 pskb_network_may_pull（） route_shortcircuit（） 目前呼叫 pskb_may_pull（skb， sizeof（struct iphdr）） （或 ipv6hdr），它檢查從 skb->data 開始的位元組是否可用。然而，在 vxlan_xmit（） 中，skb->data 指向 MAC 標頭，因此 skb_network_offset（skb） ETH_HLEN（14 位元組）。使用 pskb_may_pull（skb， 20） 只會檢查 skb->data 中的 20 位元組 （即 14 位元組 MAC 標頭 + 6 位元組的 IP 標頭），而 IP 標頭的其餘部分可能會未提取到非線性片段中。後續的 ip_hdr（skb）->daddr 解除參照可以讀取超出提取的線性緩衝區長度。使用 pskb_network_may_pull（） 來修正此問題，（） 會將 skb_network_offset （skb） 新增至長度檢查，以確保線性緩衝區中存在完整的網路標頭。（CVE-2026-74473）

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

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

  - Perl 之前的 1.652 DBI 版本允許透過 preparse 計算的輸出緩衝區大小時的整數環繞，在 32 位元 perl 上進行堆積越界寫入。 preparse 使用 'newSV（strlen（statement） * 7 + 16）' 保留其輸出緩衝區，為最長的 ':p 99999' 擴展預算每個輸入位元組 7 個輸出位元組。乘積是在 STRLEN 中計算的，在 32 位元 perl 構建上為 32 位寬，因此 613,566,757 位元組的語句乘以 4,294,967,299，將模 2^32 包裝為 3，並保留 19 位元組。然後，剖析器會透過原始指標複製陳述式，而不進行容量檢查，並在配置結束時寫入整個 585 MB 輸入。99,999 個預留位置限制不會限制此路徑，一般非預留位置內容會達到此路徑。任何傳遞該長度的不受信任陳述式以在 32 位元 perl 上進行準備的呼叫端都會獲得攻擊者控制位元組的堆積越界寫入。使用 64 位元 STRLEN 的組建不受影響，因為包裝需要大約 2.3 EB 的陳述式。
    (CVE-2026-73193)

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

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

  - KVM：s390：pci：修正固定/未固定頁面的記憶體帳戶 account_mem（） 和 unaccount_mem（） 函式會呼叫 get_uid（），這會在每次叫用時增加結構user_struct的參照計數。
    但我們不會透過呼叫 free_uid（） 來遞減計數。它還根據當前 >mm 對頁面進行核算/取消核算。但 unaccount_mem（） 可能會從與最初釘選頁面的程序上下文不同的程序上下文調用。讓我們透過在計算釘選頁面時儲存釘選過程user_struct和mm_struct來解決此問題，然後在頁面取消釘選時釋放這些資源。[borntraeger@linux.ibm.com：修正空格]（CVE-2026-74514）

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

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

  - xsk：修正 xsk_drop_skb（） 中 AF_XDP 多緩衝區 Tx 的緩衝區洩漏 此修補程式的靈感來自 sashiko 的 check[1]。它表示發生溢位時，要發佈的cq位址無效。其實更嚴重的是，在這種特殊情況下，發布cq地址的整個過程是不對的：
    只要從TXQ讀取描述元，它就應該真正發佈地址並在CQ中推進cached_prod。以下是完整分析。xsk_drop_skb（） 在三個地方被調用，它們都丟棄了部分構建的多緩衝區 skb： 1） xsk_build_skb（） -EOVERFLOW 錯誤路徑：封包超過MAX_SKB_FRAGS 2） __xsk_generic_xmit（） 迴圈後清理：TX 環中的無效描述符阻止部分封包完成 3） xsk_release（）：當 xs->skb 保存不完整的封包時，通訊端關閉 在這三種情況下， 已處理片段的 TX 描述元已從 TX 通道 （xskq_cons_release） 耗用，並且已保留 CQ 插槽。不過，xsk_drop_skb（） 會呼叫 xsk_consume_skb（），這會透過 xsk_cq_cancel_locked（） 取消 CQ 保留。由於緩衝區位址永遠不會出現在完成佇列中，因此使用者空間將永久失去對這些緩衝區的追蹤。讓 consume_skb（） 觸發現有的 xsk_destruct_skb 析構函式來修正此問題，該解構函式已透過 xsk_cq_submit_addr_locked（） 將緩衝區位址提交至 CQ。請注意，將描述元取消回 TX 通道 （透過 xskq_cons_cancel_n） 不是適當的選項，因為總是超過 MAX_SKB_FRAGS 的過大封包將無限期重試，這顯然是 TX 路徑中的鎖死錯誤。此外，將 xsk_build_skb（） 中的 desc->addr 分配移至溢位檢查上方，以便在潛在的 -EOVERFLOW 跳轉到 free_err 之前記錄當前描述元的位址，這與 xsk_build_skb_zerocopy（） 中的 zerocopy 路徑一致。[1]： https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/(CVE-2026-74560）

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

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

  - 鍵：使金鑰環鍵塊位元組順序與 keyring_diff_objects（） 一致keyring_get_key_chunk（） 首先將描述位元組載入到索引區塊低位址中，而 keyring_diff_objects（） 對與低端的第一個不同位元進行編號，並將絕對位元組索引折疊到層級中，而不刪除層級已經攜帶的內嵌前綴偏移。兩者在位元組順序和位元位置上存在分歧，因此可以告訴陣列，兩個鍵首先在行者使用的區塊上沒有差異的位元，讓精心製作的描述衝突到一個節點中。按照 keyring_diff_objects（） 假設的順序載入區塊，並在將位元組索引折疊到層級時刪除內嵌前綴長度。這只會變更用來將金鑰放在金鑰環內的記憶體內排序;新增、搜尋和讀取非衝突金鑰不受影響。（CVE-2026-74566）

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

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

  - KVM： SVM：如果 Avia 在 L2 處於作用中狀態時被禁止，則更新 x2APIC MSR 攔截 停用 AVIC 時，一律更新 L1 的 x2APIC MSR 攔截，即使 L2 處於作用中狀態且 KVM 使用單獨的 MSR 點陣圖來執行 L2。如果在執行 L2 之前已完全啟用 AVIC，然後在 L2 處於活動狀態時被禁止 （對於 VM 範圍的禁止），則 KVM 將在停用 AVIC 的情況下執行 L1，但停用 x2APIC MSR 攔截，即
    將允許 L1 讀取主機的大部分 APIC 狀態、傳送任意中斷、更改任務優先順序，並最終對主機進行簡單的 DoS。例如，在 HYPERV_REENLIGHTENMENT_VECTOR、0xee 的 L1 中傳送自我 IPI，並在主機核心中以 CONFIG_HYPERV=n 作為安全 PoC，會產生： 上的 CPU#425虛假中斷 （向量0xee） 。Acked 並入侵 KVM 以濫用 kvm_set_posted_intr_wakeup_handler（） 註冊處理常式並在 POSTED_INTR_WAKEUP_VECTOR 上發出 WARN 會產生：------------[ 切到這裡 ]------------ 警告：
    arch/x86/kvm/svm/svm.c：5594 在 pi_wakeup_handler+0x9/0x10 [kvm_amd]， CPU#156： nested_x2apic_t/316940 CPU：
    156 UID： 0 PID： 316940 通訊： nested_x2apic_t 污染： G S U 污染： [S]=CPU_OUT_OF_SPEC， [U]=使用者 硬體名稱： Google Astoria-Turin/astoria， BIOS 0.20260209.0-0 02/09/2026 RIP：
    0010：pi_wakeup_handler+0x9/0x10 [kvm_amd] 呼叫追蹤： <IRQ> sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 </IRQ> <TASK> asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP：0010：vcpu_run+0x1430/0x1e40 [KVM] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [KVM] kvm_vcpu_ioctl+0x580/0x6b0 [KVM] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP： 0033：0x46ff4b </TASK> ---[ 結束追蹤 00000000000000000 ]--- （CVE-2026-74516）

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

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

  - uprobes：修正 hprobe_expire（） 中的 NULL 指標解除參照） 分叉具有擱置 uretprobe 的任務可能會因 clone（） 路徑中的 NULL 指標解除參照而使核心陷入困境： 錯誤：核心 NULL 指標解除參照，位址：0000000000000018 哎呀：0002 [#1] SMP NOPTI RIP：0010：hprobe_expire CR2：0000000000000018 呼叫追蹤：uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe 這是在Meta叢集上的真實主機上發現的。我的印像是正在發生的事情：CPU 1 CPU 2（追蹤任務）----- -------------------命中 uprobe，prepare_uretprobe（）：hprobe LEASED，refcount >= 1 uprobe_unregister（） put_uprobe（）：refcount -> 0 fork（）
    -> dup_utask（） hprobe_expire（hprobe， true） try_get_uprobe（） -> NULL get_uprobe（NULL） <-- 哎呀 只有在 uprobe 為非 NULL 時才獲取額外的參照;NULL 表示它已消失，而且是要傳回的正確值。（CVE-2026-74477）

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

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

  - drm/amdkfd：修正 pqm_create_queue（） 中的 QID 位元洩漏 當啟用 MES 並且 amdgpu_amdkfd_alloc_kernel_mem（） 在處理程序的第一次佇列建立期間失敗時，pqm_create_queue（） 會透過「return retval」提前返回，而無需經過 err_create_queue 清理標籤。這表示永遠不會呼叫 clear_bit （*qid， pqm->queue_slot_bitmap），保留的 QID 位元會永久設定在 queue_slot_bitmap。隨著時間的推移，這會洩漏 QID 插槽，可能會耗盡所有可用的佇列插槽。透過將 'return retval' 替換為 'goto err_allocate_pqn' 來解決此問題，以便一律在錯誤路徑上呼叫 clear_bit（），而不會接觸未初始化的 pqn 指標。AILIKFD-813 （從提交 a107f74c38edbb80d6ab64dcaeeb292c14e9779f 中挑選） （CVE-2026-74448）

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

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

  - mm/slab：使用新的 kmalloc 類型防止自由路徑中的無限遞迴 提交 280ea9c3154b （mm/slab：
    避免從自己的 slab 配置slabobj_ext陣列） 避免從相同大小的 kmalloc 快取遞迴分配 obj_exts，方法是在陣列大小等於要配置的物件大小時提高 obj_exts 陣列的配置大小。然而，正如 Danielle Costantino 和 Shakeel Butt 所報告的那樣，即使是來自不同大小的 kmalloc 緩存的 slab 也可以通過相互分配 obj_exts 陣列來形成一個循環 [1]：發生了什麼：KMALLOC_NORMAL slab 的 obj_exts 陣列（由分配分析/memcg 會計使用）本身是從KMALLOC_NORMAL緩存中獲取的 kmalloc（），因此 slab 保存另一個 slab 的obj_exts陣列關係可以形成循環。使用 sizeof（struct slabobj_ext） == 16 和主機的幾何圖形： - kmalloc-512 有 64 個物件/slab ->陣列為 64*16 == 1024 位元組，由 kmalloc-1k 提供;- kmalloc-1k 有 32 個物件/slab ->陣列為 32*16 == 512 位元組，由 kmalloc-512 提供。因此，kmalloc-512 板和 kmalloc-1k 板可以容納彼此的obj_exts陣列。丟棄一個會釋放另一個的陣列，後者會清空並丟棄該 slab，從而釋放第一個陣列，依此類推：__free_slab（） -> free_slab_obj_exts（） -> kfree（） -> discard_slab（） -> __free_slab（） 沿著循環遞迴，直到堆疊耗盡。透過記憶體配置分析，這允許在自由路徑中進行無限遞迴，並導致 Meta 叢集中的生產主機上發生堆疊溢位 [1]： 錯誤：任務堆疊保護頁面被命中 哎呀：堆疊保護頁面 RIP：0010：kfree+0x8/0x5d0 呼叫追蹤：__free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ...（~125x __free_slab <-> kfree） ... <kernel driver freeing a resource> do_syscall_64 建議 [1] 透過始終從大小大於物件大小的 kmalloc 快取 （或大型 kmalloc） 提供 obj_exts 陣列分配來解決此問題。然而，正如 Vlastimil Babka [2] 所指出的，這可能會浪費過多的內存，因為大型 kmalloc 大小（例如 kmalloc-8k）的 slab 通常需要比物件大小小得多的obj_exts陣列。因此，與其增加尺寸，不如讓我們採取不同的方法;配置obj_exts陣列時，不允許在 kmalloc 類型之間形成循環。目前，所有obj_exts陣列都是從一般 kmalloc 快取提供。如果從永遠不能有obj_exts陣列的特殊 kmalloc 類型提供一般 kmalloc 快取的obj_exts陣列，則無法建立循環。若要達成此目的，請建立名為 KMALLOC_NO_OBJ_EXT 的新 kmalloc 類型。當 1） 記憶體配置分析未永久停用，或 2） 優先順序高於 KMALLOC_CGROUP 的 kmalloc 類型以 KMALLOC_NORMAL 別名時，會使用 SLAB_NO_OBJ_EXT 旗標建立KMALLOC_NO_OBJ_EXT快取。現在必須延遲 KMALLOC_NO_OBJ_EXT 快取的 Sheaf 啟動程序，因為當該大小的 KMALLOC_NO_OBJ_EXT 快取尚未準備就緒時obj_exts，穀倉的配置可能會觸發一般 kmalloc 快取的陣列配置。為簡單起見，請稍後為所有 kmalloc 快取執行滑輪的啟動連結。引入新的 slab alloc 旗標 SLAB_ALLOC_NO_OBJ_EXT，以防止配置obj_exts陣列，並讓 kmalloc_slab（） 在指定時覆寫類型以KMALLOC_NO_OBJ_EXT。請注意，kmalloc_type（） 保持不變，因為 kmalloc_flags（） 繞過 kmalloc 快速路徑。不要將SLAB_ALLOC_NO_RECURSE傳遞給 alloc_slab_obj_exts（） 中的 kmalloc_flags（），而應僅在從一般 kmalloc 快取配置物件時才使用 SLAB_ALLOC_NO_OBJ_EXT。雖然這可以防止obj_exts的無限遞迴分配，但它允許KMALLOC_NO_OBJ_EXT快取具有滑輪。由於束分配指定了防止分配束和obj_exts陣列的SLAB_ALLOC_NO_RECURSE，因此遞迴深度是有界限的。obj_exts 非 ---truncated--- （CVE-2026-74576） 的陣列

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

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

  - KVM：s390：pci：如果已啟用，則拒絕配接器中斷轉送 MPCIFC 指令不允許在未先取消註冊的情況下註冊配接器中斷。因此，如果 zPCI 裝置已啟用中斷轉送，請拒絕任何啟用中斷轉送的要求。這也會修正覆寫，進而針對相同裝置多次呼叫 ioctl 時洩漏資源。（CVE-2026-74515）

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

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

  - Bluetooth： mgmt：修正配對命令取消中的 UAF 配對完成和驗證失敗回呼會透過遍歷 hdev->mgmt_pending 來查詢擱置中的 MGMT_OP_PAIR_DEVICE 命令。查閱傳回的命令仍連結在共用擱置清單上，但不會保留mgmt_pending_lock以供稍後取消參照和移除。並行MGMT_OP_CANCEL_PAIR_DEVICE要求可以在回呼使用之前移除並釋放相同的擱置命令。當 cancel_pair_device（） 從 pending_find（） 獲取命令並且回呼在取消路徑取消參照之前將其刪除時，反向爭用也是可能的。這可能會導致釋放後使用和第二個 list_del（）。在按住擱置命令的同時，將擱置中的命令從 hdev->mgmt_pending 中移除，使配對查詢協助程式轉移擱置命令的所有權mgmt_pending_lock。回呼和取消路徑接著完成命令並直接釋放它，因此爭用路徑無法再次找到或釋放相同的命令。在 cancel_pair_device（） 中進行臨時hci_conn參照，因為命令完成會刪除儲存在擱置命令中的參照。
    (CVE-2026-74510)

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

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

  - 藍牙：ISO：在 iso_connect_ind 中鎖定 sk 存取 iso_pi（sk）->conn 需要 lock_sock，這在 iso_connect_ind 的 ev3 部分中沒有採用。如果通訊端在鎖定前已從 LISTEN/CONNECT 狀態轉換離，它也可能是 NULL。透過新增鎖定/釋放來修復。視需要在鎖定取得後重新檢查 hcon 是否有效。（CVE-2026-74538）

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

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

  - drm/amdkfd：修正 EOP 環形緩衝區大小對齊方式中的uint32_t溢位，eop_ring_buffer_size在結構中queue_properties是 u32。在 kfd_queue_acquire_buffers（） 中，預期的 EOP 緩衝區大小會計算為 ALIGN（eop_ring_buffer_size， PAGE_SIZE）;ALIGN 使用 typeof（x），因此加法以 32 位完成。使用者提供的大小 0xFFFFF001 換行為 0，導致 kfd_queue_buffer_get（） 跳過其精確大小檢查 （限制大小 ！= 0） 並接受在位址對應的任何 BO。在 GFX8/GFX9 上，MQD cp_hqd_eop_control 然後針對由 4KB BO 支援的 8KB EOP 環進行編程，因此 CP EOP 寫入可能會越過緩衝區並使 GPU 出現故障。將運算元轉換為 u64，以便以 64 位元計算對齊方式;然後，kfd_queue_buffer_get（） 中的大小檢查會拒絕過大的請求。（從提交 ae443117b742c357bfef3a7bddabf76fcf86e9ef 中挑選）（CVE-2026-74447）

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

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

  - drm/vc4：以 BPOS 提供溢位插槽大小，而不是整個 bin BO 大小 vc4_overflow_mem_work（） 將 BPOA 指向 16MB biner BO 內的 512KB 插槽，但會將整個 BO 的大小寫入 BPOS。因此，在每個 biner 記憶體不足事件中，PTB 有權跨所有其他插槽寫入磚清單 （其中可能保留進行中作業的磚狀態、磚配置和溢位記憶體），並且對於除第一個插槽之外的任何插槽，經過 biner BO 的結尾進入不相關的 CMA 記憶體。由於 CMA 頁面會回收到頁面快取和使用者配置中，因此這是 GPU DMA 的任意記憶體損毀。在實踐中，它表現為 GPU 因控制清單指標損毀、使用者空間堆積損毀、GPU 在第一次懸置後永久保持楔形狀態，以及每當作業溢出初始 biner 插槽時偶爾會發生整個系統崩潰。該錯誤可以追溯到從專用溢位 BO（其中寫入完整 BO 大小是正確的）到開槽 biner BO 的轉換。（CVE-2026-74454）

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

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

  - fou：修正 fou_create（） 中的釋放後使用 fou_create（） 在將新的 FOU 連接埠新增至 per-netns 清單之前，會透過 sk_user_data 發布結構 fou。如果 fou_add_to_port_list（） 失敗，錯誤路徑會在仍可透過 sk_user_data 存取時釋放 fou。然後，並行接收可以在 fou_from_sock（） 中取消參照釋放的物件。此排序問題先前已在連結的討論中指出。要求本機埠 0 時，可連線失敗。每一個通訊端都繫結至不同的暫時性埠，但 fou_cfg_cmp（） 會比較所要求的埠 0，並在項目已存在時報告 -EALREADY 。在釋放 fou 之前釋放通道通訊端，以便先清除sk_user_data，並使用 kfree_rcu（） 延遲回收以保護並行 RCU 讀取器。這符合 fou_release（） 中的存留期處理。
    (CVE-2026-74496)

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

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

  - can： kvaser_usb_leaf： kvaser_usb_leaf_wait_cmd（）：驗證收到的命令範圍 等候和大量接收路徑會從 USB 緩衝區遍歷可變長度命令。短於 CMD_HEADER_LEN 的非零命令仍然可以分派，而且等候路徑會使用裝置提供的長度，將相符的命令複製到固定呼叫端擁有的結構kvaser_cmd。拒絕不包含固定標頭或超出目前 USB 緩衝區專案的非零命令。在等待路徑中，也要拒絕超過目的地的相符命令，再複製它。（CVE-2026-74458）

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

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

  - hwmon：（adt7470） 修正風扇快速讀取中的除以零 TOCTOU 損毀 如果風扇資料在 FAN_DATA_VALID（） 檢查和 FAN_PERIOD_TO_RPM（） 轉換之間變成 0，則會因為快取風扇值並行更新的爭用而導致除以零損毀。透過讀取風扇資料一次來修正 TOCTOU 問題。（CVE-2026-74546）

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

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

  - binfmt_misc：掛載失敗時不要洩漏使用者命名空間 bm_get_tree（） 會引用使用者命名空間，並將其作為 sget 金鑰交給 get_tree_keyed（）。sget_fc（） 將該引用移動到 sb->s_fs_info 中並清除 fc->s_fs_info，因此從那時起超級塊就擁有它，而 bm_free（） 不再看到它。超級區塊將其放入 ->put_super（） 中。但 generic_shutdown_super（） 只會呼叫
    ->put_super（） 來自 if （sb->s_root） 分支內部，因此當 bm_fill_super（） 失敗時，沒有任何內容會釋放它： - kzalloc_obj（） 失敗將s_root留為 NULL，並跳過整個分支。- 檔案迴圈中的 simple_fill_super（） 失敗會保留 s_root，但 s_op 仍然指向 simple_super_operations，而  沒有
    ->put_super（）。bm_fill_super（） 只會在 simple_fill_super（） 傳回成功後安裝s_ops，並且提前安裝也無濟於事，因為 simple_fill_super（） 會覆寫s_op。無論哪種方式，vfs_get_super（） 都會調用 deactivate_locked_super（），並且引用將永遠消失。binfmt_misc掛載可在使用者命名空間中使用，並且 inode 和 dentry 快取都是SLAB_ACCOUNT的，因此記憶體緊張的 cgroup 下的無權限呼叫者可能會根據需要失敗 simple_fill_super（），並且每次嘗試洩漏一個使用者命名空間。改為刪除 ->kill_sb（） 中的參照，該參照會無條件運行，就像 nfsd 和 rpc_pipefs 釋放其鍵控s_fs_info一樣。這也會阻止 ->put_super（） 在超級區塊仍處於@fs_supers狀態時清除s_fs_info。generic_shutdown_super（） 故意將其留在那裡，以便 sget_fc（） 不斷找到它，直到 kill_sb（） 運行，但 NULL s_fs_info會使 test_keyed_super（） 錯過它，因此同一使用者命名空間的並發掛載會跳過 grab_super（） 等待，並為仍在拆除的命名空間建立第二個超級區塊。（CVE-2026-74483）

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

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

  - pinctrl： devicetree：不要在錯誤路徑上釋放未初始化的dev_name dt_remember_or_free_map（） 對每個對應項目的重複dev_name。如果 kstrdup_const（） 失敗，dt_free_map（） 會釋放所有num_maps項目中的dev_name，包括尚未初始化的項目。一些 pinctrl 驅動程式 （包括 pinctrl-imx） 會使用 kmalloc（） 配置映射，並留下dev_name讓核心初始化。因此，未觸及的項目包含傳遞給 kfree_const（） 的未初始化資料。在 qemu 的 mcimx6ul-evk （pinctrl-imx） 上重現，並在綁定 pinctrl 消耗裝置時進行 failslab 插入，在 KASAN 下： 錯誤： KASAN：
    dt_free_map+0x34/0xa4 中的雙重釋放 透過任務 init/1 k釋放 addr c425a900 從 dt_free_map+0x34/0xa4 dt_free_map 從 dt_remember_or_free_map+0x184/ 從 pinctrl_dt_to_map+0x33c/0x198 dt_remember_or_free_map 0x4c8 pinctrl_dt_to_map 從 create_pinctrl+0x9c/0x5c0 將所有dev_name欄位初始化為 NULL 在複製裝置名稱之前， 在部分失敗後安全地進行完整對應清除。（CVE-2026-74519）

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

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

  - dmaengine： idxd：修正 idxd_cdev_open（） 中的 fdev 設定失敗清除 當 wq->wq_lock 仍保留時，failed_dev_add 和 failed_dev_name 路徑會刪除檔案裝置參照。如果 put_device（fdev） 刪除最後一個參照，idxd_file_dev_release（） 會同步執行並嘗試再次採用 wq->wq_lock，從而陷入死鎖。
    這些路徑也會落入後來的 ctx 清理標籤中，即使 idxd_file_dev_release（） 擁有該清理並釋放 ctx。這可以使 idxd_xa_pasid_remove（ctx） 和 kfree（ctx） 在釋放的上下文上運行。在檔案裝置設定失敗之前移動 idxd_wq_get（），因為釋放回呼一律會呼叫 idxd_wq_put（）。然後在 put_device（fdev） 之前解鎖 wq->wq_lock，並直接從檔案裝置設定失敗路徑返回，將 ctx 清理留給釋放回呼。（CVE-2026-74574）

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

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

  - drm/vc4： 在每一個 BIN 工作之前，將磚狀態資料陣列歸零 biner BO 是分割成 512KB 插槽的單一 16MB 緩衝區，這些插槽會在提交時分發給工作，並在工作完成時回收，而不會被清除。每個插槽在開始時都會保留工作的磚狀態資料陣列 （TSDA），後面接著磚配置集區。雖然圖塊分配池僅由渲染線程通過在當前工作期間生成的 biner 分支遍歷，但 TSDA 是 PTB 自己的每個圖塊簿記，並由硬件本身使用。儘管核心在圖塊分箱模式配置中設定了自動初始化圖塊狀態數據陣列標誌，但 PTB 顯然仍然作用於插槽的前一個用戶留下的過時圖塊狀態：圖納最終會創建具有無效原始流和分支的無效命令流，這可能導致 GPU 懸置，如 [1][2] 中觀察到的那樣。設定工作的分箱插槽時，將 TSDA 歸零。這會在提交路徑中清除每個圖塊 48 個位元組 （1080p 幀為 ~24KB），並保證 PTB 永遠不會看到另一個工作的圖塊狀態。今天僅檢查圖塊計數是否為零，因此它來自的 8 位字段可以描述幾乎比它必須所在的插槽大六倍的圖塊狀態陣列。在分發插槽之前將其綁定，因為這樣的大小決定了為圖塊分配池剩餘的插槽量。（CVE-2026-74453）

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

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

  - drm/amd/pm：修正 pptable 釋放後使用amdgpu_dpm_get_pp_table（） 在刪除 adev->pm.mutex 後傳回指向驅動程式擁有電源表的指標。然後，sysfs 路徑會從該指標複製。並行pp_table寫入可以在複製期間取代和釋放分配，從而導致釋放後使用。變更 DPM 介面，以在保留互斥時複製到呼叫端提供的儲存體。保留屬性探索的僅大小查詢，而不公開驅動程式擁有的指標。（從提交 f6eed7acfd30099ef7baeb6ba45bb59daad80631 中挑選）（CVE-2026-74450）

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

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

  - hwmon：（nct6775-core） 修正溫度暫存器的數量，與 不同NCT6116，NCT6106NCT6116只有三個溫度暫存器，並且只有三個溫度源和溫度源配置暫存器。暫存器位址符合 的 NCT6106 位址，且可重複使用。程式碼使用單獨的數組來列出 的 NCT6116溫度源暫存器，但使用暫存器數組的 NCT6106 大小來設定暫存器的數量。NCT6106暫存器陣列提供六個位址，而溫度源暫存器陣列NCT6116僅提供三個位址。這會導致 KASAN 報告。錯誤：KASAN：nct6775_probe+0x936/0x46f0 中的全域越界 [NCT6775] 任務 modprobe/954 在 addr ffffffffc19561a6 讀取大小 2 ... 呼叫追蹤：dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ？__kasan_kmalloc.constprop.0+0xc9/0xd0 ？
    __kmalloc_node_track_caller+0x194/0x5b0 ？nct6775_probe+0x936/0x46f0 [nct6775] ？nct6775_probe+0x936/0x46f0 [NCT6775] ... 透過將溫度和溫度配置暫存器的數量硬編碼為 3 NCT6116來解決此問題。刪除不必要的 NCT6116_REG_TEMP_SOURCE 陣列並重複使用NCT6106_REG_TEMP_SOURCE。（CVE-2026-74553）

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

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

  - Bluetooth： hci_sync：在 hci_connect_big_sync（） 回呼中保留 conn 如果在 hci_sync 任務執行時釋放 conn，則理論上存在 UAF。保留 refcount 以避免這種情況。處理 NULL hcon，傳回 0 + 不執行任何操作以符合先前的行為。（CVE-2026-74530）

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

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

  - btrfs：跳過全域區塊保留，以考慮救援掛載 [錯誤] 在損毀區塊群組樹狀結構根目錄後掛載會 rescue=ibadroots 觸發 NULL 指標解除參照： 錯誤：核心 NULL 指標解除參照，位址：0000000000000100 RIP：0010：btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] 呼叫追蹤：fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] 損毀的 raid 等量樹狀結構根會發生相同的當機， 透過 btrfs_read_block_groups（） 而不是 fill_dummy_bgs（）。[原因]使用 rescue=ibadroots，btrfs_read_roots（） 允許在無法讀取任一根根時繼續掛載，將對應的根指標保留為空，而其磁碟上功能位保持設定。 然後，btrfs_update_global_block_rsv（） 僅根據功能位取消參照遺失的根。[修復]救援掛載是完全唯讀的，無法啟動交易，因此永遠不會消耗全域儲備。在 btrfs_is_full_ro（） 下，將儲備標記為已滿，並在執行會計之前返回。由於我們需要檢查 fs 是否完全掛載 RO，因此將 fs_is_full_ro（） 匯出為 btrfs_is_full_ro（），並將其移至 fs.h。[ 將 fs_is_full_ro（） 匯出提交壓縮到這個提交中。（CVE-2026-74571）

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

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

  - veth：在執行 XDP 之前轉換 frag_list skb，frag_list skb 可以在設定 data_len但nr_frags零的情況下到達 veth。veth_convert_skb_to_xdp_buff（） 只會轉換共用、鎖定、有片段[]或沒有足夠餘量的 skb。稍後會使用 skb_is_nonlinear（） 來決定是否設定 XDP_FLAGS_HAS_FRAGS 和 xdp_frags_size。這會將frag_list資料公開給 XDP，就好像它儲存在 frags[] 中一樣，但 frags[] 是空的。然後，AF_XDP複製模式可以信任虛假的 XDP 片段中繼資料，遍歷一個空的片段項目，並從 __xsk_rcv（） 在 memcpy（） 中損毀。在將非線性 skb 公開給 XDP 之前，先透過 skb_pp_cow_data（） 路由它們，並且僅在產生的 skb 具有 frags[] 時才通告 XDP 片段。skb_copy_bits（） 已經處理frag_list輸入，而 skb_pp_cow_data（） 使用 skb_add_rx_frag（） 建立 frags[] 輸出，這是 XDP 多緩衝區預期的表示法。（CVE-2026-74476）

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

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

  - ksmbd：使用 memcmp（） 比較 ClientGUID ClientGUID 是固定大小的二進位值，可以包含內嵌的 NUL 位元組。strncmp（） 會在第一個 NUL 位元組停止比較，因此不同的 ClientGUID 值可能會錯誤地視為相等。在 SMB3 多通道工作階段綁定和FSCTL_VALIDATE_NEGOTIATE_INFO中使用 memcmp（） 來比較所有SMB2_CLIENT_GUID_SIZE位元組。（CVE-2026-74521）

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

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

  - netfilter： nf_tables：使每個表nft_object rhltable nft_object rhltable 是全域的，這允許存取被其他現有 netn 從查詢路徑中分解的物件。鑑於 nft_obj_destroy（） 會立即釋放物件，這可能會導致這些正在釋放的物件的釋放後使用。使每個表的現有 rhltable 來解決此問題，以處理 nft_rcv_nl_event（） 路徑。更新 nft_obj_lookup（） 以將表視為 non-const，否則，編譯器在將objname_ht傳遞給 rhltable_lookup（） 時會抱怨。（CVE-2026-74565）

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

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

  - btrfs：zoned：修正中繼資料回寫和交易提交之間的鎖死 在分區檔案系統中寫出中繼資料範圍緩衝區時，btree_writepages（） 會在整個回寫迴圈中保留 fs_info->zoned_meta_io_lock，包括對 btrfs_check_meta_write_pointer（） -> check_bg_is_active（） 的呼叫。對於樹狀記錄區塊群組，check_bg_is_active（） 可能無法啟動區域，並回歸 btrfs_zone_finish_one_bg（） 以釋放作用中區域。該路徑等待執行中的事務提交，同時仍保留zoned_meta_io_lock，但提交者需要相同的鎖才能寫出樹狀結構範圍，因此兩個任務死鎖： 任務 A （kworker，中繼資料回寫） 任務 B （fsstress，交易提交） ------------------------------------ ------------------------------------- wb_workfn（） btrfs_commit_transaction（T） btree_writepages（） btrfs_write_and_wait_transaction（） btrfs_zoned_meta_io_lock（） btrfs_write_marked_extents（）btrfs_check_meta_write_pointer（） btree_writepages（） check_bg_is_active（） [treelog_bg] btrfs_zoned_meta_io_lock（） btrfs_zone_finish_one_bg（） < zoned_meta_io_lock 上的區塊，任務 A> do_zone_finish（） btrfs_inc_block_group_ro（） btrfs_wait_for_commit（） 所持有的 btrfs_zone_finish（） <等待提交交易 T 的區塊， 由任務 B 完成> 正是出於這個原因，check_bg_is_active（） 中的同級分支已經在 do_zone_finish（） 周圍刪除了zoned_meta_io_lock。在 tree-log 分支中執行相同的操作：釋放 btrfs_zone_finish_one_bg（） 周圍的鎖定，然後重新取得它。該鎖僅保護此分支不接觸的 fs_info->active_{meta，system}_bg，並且 ctx->zoned_bg 在解鎖過程中保留對區塊組的引用，因此在刪除鎖定時不會丟失任何內容。此懸置偶爾會在分區的 btrfs 檔案系統上以 fstests generic/475 重現。（CVE-2026-74572）

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

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

  - octeontx2-af：阻止 VF 破壞共用 CGX LMAC 的特殊 CGX PKIND 狀態 PF 和 VF NIX LF，重複使用相同的硬體 PKIND 程式設計。啟用 HiGig2 或 EDSA 剖析時，VF NIX LF 配置不得透過 PF 設定重設 LMAC RX PKIND 或預設 TX 剖析組態。新增 cgx_get_pkind（） 和 rvu_cgx_is_pkind_config_permitted（），以便在 LMAC 使用 NPC_RX_HIGIG_PKIND 或 NPC_RX_EDSA_PKIND 時，VF 跳過 cgx_set_pkind（）、rvu_npc_set_pkind（） 和NIX_AF_LFX_TX_PARSE_CFG更新。
    (CVE-2026-74527)

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

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

  - 藍牙：HIDP：拒絕沒有交易標頭的框架 hidp_recv_ctrl_frame（） 和 hidp_recv_intr_frame（） 讀取 skb->data[0]，然後再檢查 L2CAP SDU 是否包含交易標頭。
    連線的 HIDP 對等體可以傳送空白的基本模式 SDU，並讓兩個路徑都使用 skb 尾部的未初始化位元組。KMSAN 會在 hidp_session_run（） 中報告使用情況，其中未初始化的值源自於
    __alloc_skb（） 到 vhci_write（）。控制路徑會產生兩個報告，岔斷路徑會產生一個報告。位元組也可以由格式錯誤的下層封包控制。如果 HCI ACL 封包包含具有宣告的零長度承載的 L2CAP PDU，後面接著額外的 0x15 位元組，則 l2cap_recv_acldata（） 會在分派前將 skb->len 減少到宣告的 PDU 長度。儘管如此，目前的 HIDP 路徑仍會消耗額外的位元組，因為 HIDP_TRANS_HID_CONTROL |HIDP_CTRL_VIRTUAL_CABLE_UNPLUG並終止 HIDP 工作階段。透過此變更，會捨棄相同的封包，且後續的功能報告要求會成功。使用 skb_pull_data（） 提取交易標頭，並丟棄不包含它的框架。（CVE-2026-74508）

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

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

  - drm/panthor：拒絕具有過大資料的韌體區段 在 panthor_fw_load_section_entry（） 中，計算要複製的資料大小，而不根據分配的section_size進行驗證：section->data.size = hdr.data.end - hdr.data.start;如果特製的韌體設定的 data.size 大於配置的記憶體，可能會導致 panthor_fw_init_section_mem（） memcpy（section->mem->kmap， section->data.buf， section->data.size）;此外，如果 section->data.size 超過 BO 大小，此 memset 是否會下溢大小計算，從而導致核心記憶體的大規模越界歸零？memset（section->mem->kmap + section->data.size， 0， panthor_kernel_bo_size（section->mem） - section->data.size）;拒絕初始資料大於區段大小的區段項目。
    (CVE-2026-74452)

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

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

  - binfmt_misc：拒絕旗標字元作為欄位分隔符號 註冊字串以使用者選擇的分隔符號開頭，該分隔各個欄位。因此，即使在截斷的字串上，欄位剖析器也會終止 create_entry（） 使用相同的分隔符填充緩衝區：memset（buf + count， del， 8）;
    大多數欄位都會使用 strchr（）/scanarg（） 掃描分隔符，並愉快地停在填充上。flags 欄位不同：check_special_flags（） 不掃描分隔符，而是使用旗標字元 'P'、'O'、'C' 和 'F'，並在第一個不是這些字元組處停止，依靠尾端分隔符結束掃描。如果分隔符號本身是旗標字元，則填補不再充當終止字元。掃描會吞下所有八個填補位元組，並持續讀取配置結尾，直到到達不是旗標字元的位元組為止。例如，註冊 PaPEPPxPPiP 並以「P」作為分隔符號 （名稱 a、類型副檔名、magic x、解譯器 i、空旗標） 會讓旗標掃描在緩衝區末端執行。註冊最終被拒絕，因為剖析器不會完全停止在 buf + count 處，而是僅在越界讀取已經發生之後停止。如果配置配置不吉利，掃描可能會進入未映射的頁面;在 KASAN 下，它被報告為越界讀取的板。binfmt_misc掛載可供使用者名稱空間中的無權限使用者使用，因此無需權限即可進行讀取。拒絕作為前面其中一個旗標字元的分隔符號。無論如何，只有在越界讀取之後，這類註冊一律會遭到拒絕，因此沒有有效的註冊字串會變更含義。（CVE-2026-74485）

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

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

  - drm/amd/display：修正零視口上 calculate_mcache_setting 中的除以零 如果平面以零區域視口到達calculate_mcache_setting，則calculate_mcache_setting提前退出，時為 num_mcaches == 0 和 mvmpg_width/高度 == 0。這會導致除以零的恐慌，也可能導致num_mcaches上的下溢。透過將 calculate_mcache_setting 變更為 bool 並在每次 calculate_mcache_row_bytes 呼叫後新增防護來解決此問題。如果 num_mcaches 或 mvmpg_width/height 為零，則傳回 false。呼叫端會將失敗傳播為拒絕模式，以防止錯誤。（從提交 29c0f7c655f47bcbd575ff75e58480df6ec3c9da 中挑選）（CVE-2026-74449）

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

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

  - iommu/arm-smmu-v3-iommufd：假設裝置只有一個資料流，則 vDEVICE 只需要一個資料流 ID arm_vsmmu_vsid_to_sid（） 會將客體的 vSID 對應至從 master->streams[0] 取得的單一實體資料流 ID。具有數個資料流的裝置只會對應第一個資料流，因此客體 vSID 無效無法連線到其他資料流的 ATC 和 IOTLB 項目;具有 None 的裝置會使 master->stream 成為ZERO_SIZE_PTR，越界讀取。新增 arm_vsmmu_vdevice_init（） 操作，以在 master->num_streams 不是 -EOPNOTSUPP 時拒絕 vDEVICE，而不是以無訊息方式對應它。（CVE-2026-74573）

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

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

  - net：當對等配置失敗時，不要傳送 ICMP/NDISC 重新導向 當 inet_getpeer_v4（） 或 inet_getpeer_v6（） 在記憶體壓力或樹狀結構大小上限下無法配置對等項目時，重新導向處理常式先前會回復為傳送不受速率限制的 ICMP/NDISC 重新導向訊息。在 IPv4 中，當 peer == NULL 時，ip_rt_send_redirect（） 直接呼叫 icmp_send（）。在 IPv6 中，ip6_forward（） 和 ndisc_send_redirect（） 將 NULL 對等體傳遞給 inet_peer_xrlim_allow（），當對等體 == NULL 時，該對等體傳回 true。由於 ICMP/NDISC 重新導向不是預設全域速率限制遮罩 （sysctl_icmp_ratemask） 的一部分，因此當對等 == NULL 時傳送重新導向會建立未速率限制的 ICMP 封包風暴。
    當 peer 為 NULL 時，透過在 ip_rt_send_redirect（）、ip6_forward（） 和 ndisc_send_redirect（） 中失敗關閉來解決此問題。（CVE-2026-74550）

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

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

  - 跟蹤：檢查 trace_module_add_events（） 中 __register_event（） 的傳回值 trace_module_add_events（） 會忽略 __register_event（） 的傳回值，並針對每個事件無條件呼叫 __add_event_to_tracers（）。如果 __register_event（） 失敗 （例如，如果 event_init（） 失敗），則不會將trace_event_call新增至清單ftrace_events，但 __add_event_to_tracers（） 仍會建立指向它的trace_event_file。如果模組載入隨後失敗，且模組記憶體被釋放，則追蹤狀態會在trace_event_file中保留過時的trace_event_call指標，導致稍後執行 tracefs 或追蹤子系統作業時釋放後使用。透過檢查 __register_event（） 的傳回值並僅在事件註冊成功時呼叫 __add_event_to_tracers（） 來修正此問題。（CVE-2026-74471）

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

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

  - Bluetooth： btintel：剖析診斷 TLV btintel_diagnostics（） 存取 tlv->val[0] 之前，先驗證診斷 VSE 是否足夠長以包含該欄位，因此可能會導致讀取超出接收框架的資料。透過驗證存取前的長度來修正。（CVE-2026-74532）

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

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

  - drm/panthor：驗證韌體介面結構大小 iface_fw_to_cpu_addr（） 僅檢查韌體提供的 MCU 虛擬位址是否指向共用區段內。傳回的指標稍後會用作完整的韌體介面結構，因此接受共用區段結尾附近的位址仍可能導致越界存取。將預期的物件大小傳遞給 iface_fw_to_cpu_addr（），並拒絕不完全符合共用區段的範圍。（CVE-2026-74451）

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

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

  - scsi：libsas：修正 HA 還原鎖死和hisi_sas磁碟喚醒爭用 提交 fbefe22811c3 （scsi：libsas：不要總是清空 HA 還原的事件工作佇列） 引入了 sas_resume_ha_no_sync（） 以避免鎖死：在 HA 事件工作佇列上執行的 PHYE_RESUME_TIMEOUT 處理常式呼叫 sas_deform_port（） -> sas_destruct_devices（），這會移除 SCSI 裝置並等待主機變成執行階段活動。但是，在 sas_resume_ha（） -> sas_drain_work（） 傳回之前，主機無法繼續，並且該處理常式上的排水被封鎖。但是，跳過清空會重新引入爭用：hisi_sas在所有 PHY UP 工作和 libsas 發現工作完成之前從恢復返回。然後，控制器可能會在磁碟仍在喚醒時自動暫停。磁碟會向暫停的控制器發出 IO，IO 失敗，而且磁碟會停用。將PHYE_RESUME_TIMEOUT通知移至 sas_drain_work（） 之後，從源頭修正鎖死。屆時，主機還原即將完成，因此透過device_link移除裝置不再在還原上阻塞，而且循環會中斷。鎖死消失後，還原 hisi_sas 中的 sas_resume_ha（） （耗盡變體） 並移除 sas_resume_ha_no_sync（）。重新排序對其他 libsas 消費者來說是安全的 （isci、pm8001、aic94xx、mvsas）。在暫停期間，sas_suspend_devices（） 會呼叫每個裝置的 sas_notify_lldd_dev_gone（），這會將 dev->lldd_dev 設為 NULL。當 scsi_unblock_requests 在還原中重新啟用 I/O 時，LLDD 會在到達硬體之前立即拒絕任何對逾時 phy 磁碟的 I/O：isci 傳回 SAS_DEVICE_UNKNOWN （對應至 DID_BAD_TARGET），而 pm8001 傳回 SAS_PHY_DOWN （對應至 DID_NO_CONNECT）。
    兩者都直接透過 scsi_done（） 完成，無需輸入 SCSI EH。這在新舊排序中都是相同的，因為lldd_dev_gone會在暫停期間執行，在繼續之前。重新排序只會影響PHYE_RESUME_TIMEOUT處理常式執行的時間 （由 sas_drain_work（） 同步與繼續傳回後非同步），而不影響 I/O 是否可以連線到裝置。aic94xx 及 mvsas 不會登錄任何 PM 操作，且永遠不會到達此程式碼路徑。（CVE-2026-74555）

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

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

  - net：openvswitch：修正 CT 期間流程金鑰更新失敗時的 skb 洩漏 ovs_ct_execute（） 一律會在失敗時竊取或釋放 skb，而 ovs_flow_key_update（） 則不會。因此，如果它失敗並且我們立即返回，skb 最終就會洩露。透過中斷並讓循環底部的常見錯誤處理程式碼正確釋放 skb 來解決這個問題。這是不太可能的情況，因為它需要透過在先前可剖析的 skb 上套用一組動作來讓封包變得無法剖析，但仍然應該修正。由 Sashiko 報導。（CVE-2026-74464）

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

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

  - igbvf：修正 TX DMA 錯誤清除中的洩漏 如果在對應 TX 緩衝區時遇到錯誤，驅動程式應該取消對應已針對該 skb 對應的任何緩衝區。因為計數會在每個片段對應之前遞增，所以當達到dma_error時，它一律會符合所需的正確取消對應數目。
    在 dma_error 中 while 迴圈之前遞減計數會導致差一錯誤。如果任何對應在對應失敗之前成功，則只會有一個 DMA 對應 （頭部） 會洩漏。此錯誤是由 2010 年針對 dma_error 中的無限迴圈修正而引入的。所有其他受影響的驅動程序都已修復。（CVE-2026-74495）

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

ID	名稱	嚴重性
335843	Linux Distros 未修補弱點：CVE-2026-74556	critical
335842	Linux Distros 未修補弱點：CVE-2026-74543	medium
335841	Linux Distros 未修補弱點：CVE-2026-74462	medium
335840	Linux Distros 未修補弱點：CVE-2026-74534	high
335839	Linux Distros 未修補弱點：CVE-2026-74529	high
335838	Linux Distros 未修補弱點：CVE-2026-74547	medium
335837	Linux Distros 未修補弱點：CVE-2026-74512	high
335836	Linux Distros 未修補弱點：CVE-2026-74525	medium
335835	Linux Distros 未修補弱點：CVE-2026-74473	critical
335834	Linux Distros 未修補弱點：CVE-2026-73193	critical
335833	Linux Distros 未修補弱點：CVE-2026-74514	medium
335832	Linux Distros 未修補弱點：CVE-2026-74560	medium
335831	Linux Distros 未修補弱點：CVE-2026-74566	medium
335830	Linux Distros 未修補弱點：CVE-2026-74516	high
335829	Linux Distros 未修補弱點：CVE-2026-74477	medium
335828	Linux Distros 未修補弱點：CVE-2026-74448	medium
335827	Linux Distros 未修補弱點：CVE-2026-74576	high
335826	Linux Distros 未修補弱點：CVE-2026-74515	high
335825	Linux Distros 未修補弱點：CVE-2026-74510	high
335824	Linux Distros 未修補弱點：CVE-2026-74538	high
335823	Linux Distros 未修補弱點：CVE-2026-74447	high
335822	Linux Distros 未修補弱點：CVE-2026-74454	high
335821	Linux Distros 未修補弱點：CVE-2026-74496	high
335820	Linux Distros 未修補弱點：CVE-2026-74458	high
335819	Linux Distros 未修補弱點：CVE-2026-74546	medium
335818	Linux Distros 未修補弱點：CVE-2026-74483	medium
335817	Linux Distros 未修補弱點：CVE-2026-74519	high
335816	Linux Distros 未修補弱點：CVE-2026-74574	high
335815	Linux Distros 未修補弱點：CVE-2026-74453	high
335814	Linux Distros 未修補弱點：CVE-2026-74450	high
335813	Linux Distros 未修補弱點：CVE-2026-74553	high
335812	Linux Distros 未修補弱點：CVE-2026-74530	high
335811	Linux Distros 未修補弱點：CVE-2026-74571	medium
335810	Linux Distros 未修補弱點：CVE-2026-74476	critical
335809	Linux Distros 未修補弱點：CVE-2026-74521	critical
335808	Linux Distros 未修補弱點：CVE-2026-74565	high
335807	Linux Distros 未修補弱點：CVE-2026-74572	high
335806	Linux Distros 未修補弱點：CVE-2026-74527	high
335805	Linux Distros 未修補弱點：CVE-2026-74508	high
335804	Linux Distros 未修補弱點：CVE-2026-74452	high
335803	Linux Distros 未修補弱點：CVE-2026-74485	high
335802	Linux Distros 未修補弱點：CVE-2026-74449	high
335801	Linux Distros 未修補弱點：CVE-2026-74573	critical
335800	Linux Distros 未修補弱點：CVE-2026-74550	high
335799	Linux Distros 未修補弱點：CVE-2026-74471	high
335798	Linux Distros 未修補弱點：CVE-2026-74532	high
335797	Linux Distros 未修補弱點：CVE-2026-74451	high
335796	Linux Distros 未修補弱點：CVE-2026-74555	medium
335795	Linux Distros 未修補弱點：CVE-2026-74464	high
335794	Linux Distros 未修補弱點：CVE-2026-74495	critical

偵測

Nessus 的 Misc. 系列

critical

medium

medium

high

high

medium

high

medium

critical

critical

medium

medium

medium

high

medium

medium

high

high

high

high

high

high

high

high

medium

medium

high

high

high

high

high

high

medium

critical

critical

high

high

high

high

high

high

high

critical

high

high

high

high

medium

high

critical