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

  - mm/hugetlb：修正 allocate_file_region_entries（） 中的清單損毀 allocate_file_region_entries（） 使用新配置的 file_region 描述元補充 resv->region_cache。分配使用 GFP_KERNEL，因此 resv->lock 會被刪除：新項目會收集在堆疊本機清單頭上，allocated_regions，並在重新取得鎖定後拼接到 resv->region_cache 中。拼接使用了 list_splice（），它移動了條目，但不會重新初始化源頭，因此allocated_regions指向現在位於 resv->region_cache 上的條目。充值會在 while 迴圈中執行，在重新取得鎖定後重新檢查快取不足。對於共用映射，resv_map由 hugetlbfs inode 的每個映射程式共用，因此同一resv_map上的並行 region_chg（）/region_add（）/region_del（） 可以在解鎖視窗期間消耗快取項目並強制進行第二次迭代。該迭代在過時的頭上呼叫 list_add（） 並損毀清單;CONFIG_DEBUG_LIST __list_add_valid（） 檢查跳閘：list_add損毀。next->prev 應該是 prev （ffffc900011ff7f8），但原來是 ffff88814c281460。
    （next=ffff88814c545640）. lib/list_debug.c：31！ 的核心錯誤 lib/.c：31！ allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 如果不CONFIG_DEBUG_LIST錯誤的 list_add（） 會以無訊息的方式將核心堆疊位址連結到 resv->region_cache， 導致以後的釋放後使用。在密集的 KVM 主機上觀察到這是真正的主機錯誤，其中 QEMU 客體 RAM hugetlbfs 檔案被 QEMU 和單獨的 SPDK/DPDK 虛擬主機使用者目標映射MAP_SHARED，在一個共用resv_map上產生並行的 region_* 流量。使用 list_splice_init（），以便在每次拼接後將來源磁頭重新初始化為空，從而使重試迴圈安全。（CVE-2026-74518）

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

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

  - ublk：重設 ublk_ctrl_add_dev（） ublk_ctrl_add_dev（） memcpy（） 中核心擁有的 dev_info 欄位，將使用者空間ublksrv_ctrl_dev_info到 ub->dev_info，然後修正驅動程式擁有但遺漏的欄位
    ->state 和 ->ublksrv_pid。以 ->state = UBLK_S_DEV_LIVE 新增的裝置通過了 ublk_stop_dev_unlocked（） 用作磁碟代理的 -UBLK_S_DEV_DEAD>state ！= 測試，而附加了 （） 作為磁碟代理的測試，而
    ->ub_disk 仍然是 NULL，因此DEL_DEV緊接在 del_gendisk（） 中ADD_DEV哎呀之後。UBLK_S_DEV_QUIESCED加UBLK_F_USER_RECOVERY在 ublk_force_abort_dev（） 中提前一步死亡。中毒的 ->state 也會START_USER_RECOVERY，並將 char 裝置讀取/寫入路徑連接到從未啟動的裝置，並在 -EEXIST 處楔START_DEV。中毒的 ->ublksrv_pid 只會使GET_DEV_INFO將不相關的任務報告為 ublk 伺服器。在 memcpy（） 之後重設兩者，就像 ublk_detach_disk（） 一樣。用戶空間只會讀回這些內容，因此靜默地更正它們不會破壞任何問題。自從 ublk 合併以來，ADD_DEV 在未清理的情況下複製了 ->state，但當時它是無害的：gendisk 是在 ADD_DEV 期間分配的，並且 teardown 和 START_DEV -EEXIST 檢查都鍵關閉了 disk_live（） 而不是 ->state。一旦磁碟配置移至 START_DEV，且這些檢查切換至 ->state，oops 就會變得可連線。（CVE-2026-74472）

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

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

  - sctp：防止對等傳輸計數溢位 sctp_assoc_add_peer（） 會針對每個新的唯一對等遞增關聯的 16 位元transport_count。新增第 65,536 個傳輸會將計數包裝為零。SCTP sock_diag使用 transport_count 保留INET_DIAG_PEERS承載，然後為transport_addr_list中的每個項目複製一個sockaddr_storage。包裝之後，診斷轉儲會保留一個空的承載，並寫入 8 MiB 的對等位址經過 skb 尾部。當transport_count達到U16_MAX時，拒絕新的唯一對等。在現有對等查詢之後執行檢查，以便重複位址繼續在限制時傳回其現有傳輸。（CVE-2026-74469）

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

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

  - ALSA：usb-audio：設定 fill_max 時，修正 DMA 緩衝區越界寫入 當 USB 音訊端點透過 fill_max 描述元旗標要求完整封包傳輸時，data_ep_set_params（） 會將 ep->curpacksize 提升為 ep->maxpacksize。不過，maxsize 會保留原始取樣率衍生值。
    由於 u->buffer_size 被配置為 maxsize * 封包，因此產生的 DMA 緩衝區對於要求的傳輸長度來說太小了。當 USB 主機控制器串流至每個封包的 curpacksize 位元組時，它會透過 DMA 寫入緩衝區末端，損毀核心堆積記憶體。設定 maxsize 時，將 maxsize 更新為 curpacksize fill_max讓配置的 DMA 緩衝區大小符合實際的傳輸要求大小。[更改為僅在設定 ep->fill_max 時重新分配 maxsize -- tiwai ]（CVE-2026-74498）

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

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

  - can： peak_usb：驗證 uCAN 接收記錄長度 pcan_usb_fd_decode_buf（） 遍歷打包在一個 USB 接收緩衝區中的 uCAN 記錄。要求每筆記錄都包含其類型的固定標頭，並在將 CAN 承載位元組複製到 skb 之前先驗證它們。（CVE-2026-74455）

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

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

  - 藍牙：ISO：修正通訊端釋放後洩漏的 sk iso_sock_kill（） 測試！sock_flag（sk， SOCK_ZAPPED） ||sk->sk_socket ||sock_flag（sk， SOCK_DEAD） 表示提前返回，但這始終是正確的，因為 sock_orphan（sk） 設定SOCK_DEAD，因此通訊端釋放的 sk 參照總是洩露，iso_sock_destruct永遠不會被呼叫。
    當 __iso_sock_close（） 未設定SOCK_ZAPPED時，通訊端參照也會洩漏，因為 iso_conn_del（） 在 zapping 後不會呼叫 iso_sock_kill（）。透過將 SOCK_DEAD 替換為不用於其他內容的旗標BT_SK_KILLED並lock_sock以確保 iso_sock_kill（） 僅在通訊端釋放後放置 sk 一次來修復。發行和iso_conn_del可以同時執行。從 iso_conn_del（） 呼叫 iso_sock_kill（） 以在 zapping 後清理 sk。從 iso_sock_close（） 中移除對 iso_sock_kill（） 的呼叫，因為它通常在那裡沒有操作。
    (CVE-2026-74536)

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

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

  - drm/vmwgfx：避免 vkms init 失敗時的 destroy_workqueue（NULL） 透過 vmw_vkms_init（） 的兩條路徑可能會使 vmw->crc_workq 為 NULL，同時仍使驅動程式的其餘部分處於在模組卸載時呼叫 vmw_vkms_cleanup（） 的狀態： 1. vmw_host_get_guestinfo（GUESTINFO_VBLANK， ...） 失敗或傳回過大的緩衝區
    -- 沒有 VBLANK guestinfo 項目的主機上的常見情況 -- 在工作佇列配置之前提前傳回。2. alloc_ordered_workqueue（） 在記憶體壓力下傳回 NULL。vmw_vkms_cleanup（） 接著呼叫 destroy_workqueue（NULL），這會解除參照 wq->name 並發生錯誤。透過移除早期傳回來修正第一種情況：vmw->vkms_enabled 在 rpci-failure 路徑上已為 false，因此不會將任何工作排入佇列，並且無條件地配置工作佇列可使控制流程保持簡單。透過使用 NULL 檢查保護清理來修正第二種情況，因為 alloc_ordered_workqueue（） 在記憶體不足的情況下仍可能失敗。
    (CVE-2026-74442)

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

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

  - ALSA： 6fire：修正探查期間錯誤處理時的 UAF 雖然 6fire 驅動程式有一些修正來處理探查階段的早期錯誤處理，但它在釋放資源之前忘記了擱置中的 URB，這可能會導致 UAF。此修補程式透過執行幾乎相同的清理程序來解決此問題，就像錯誤路徑上的正常中斷連線階段一樣。（CVE-2026-74505）

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

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

  - hwmon：（nzxt-smart2） DMA 對齊輸出緩衝區 Sashiko 報告：當 send_output_report（） 呼叫 hid_hw_output_report（） 時，基礎 USB HID 核心會呼叫 usb_interrupt_msg（），直接針對 DMA 對應此緩衝區。當 DMA 對應排清或使快取行失效時，它會損毀 CPU 同時修改的相鄰變數 （互斥、update_interval）。這會因為非一致 CPU 架構 （例如 ARM 或 MIPS） 上的快取行共用而導致記憶體損毀。DMA API 偵錯工具 （CONFIG_DMA_API_DEBUG） 會針對此違規觸發執行階段警告。任何觸發 send_output_report（） 的作業 （例如設定風扇速度或更新間隔） 都會導致 USB DMA 對應。在具有非一致性快取的系統上，此結構錯誤會導致立即且確定性的記憶體損毀。將輸出緩衝區對齊ARCH_DMA_MINALIGN以解決問題。（CVE-2026-74551）

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

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

  - netfilter： xt_hashlimit：驗證雜湊表支援 XT_HASHLIMIT_RATE_MATCH XT_HASHLIMIT_RATE_MATCH 旗標模式會變更代表雜湊表中項目的dsthash_ent結構的語意。
    有一個聯合區域，它使用不同的佈局來表達費率匹配模式。更新 .checkentry 路徑以驗證參照相同雜湊表的兩個或多個不同規則所要求的 XT_HASHLIMIT_RATE_MATCH 模式旗標。否則，可能會以未初始化的方式存取聯集中的突發欄位。
    如果由小於 3 的修訂版設定，則拒絕使用 XT_HASHLIMIT_RATE_MATCH 模式旗標。
    (CVE-2026-74564)

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

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

  - ksmbd：修正 __close_file_table_ids（） 中的釋放後使用，當另一個工作階段保留透過 ksmbd_lookup_fd_inode（） 取得的臨時參照時，ksmbd_file 可以在邏輯關閉後保持活動狀態。
    ksmbd_close_fd（） 目前會將檔案標記為已關閉，並捨棄 IDR 擁有的參照，但會保留在結束工作階段的 IDR 中發佈指標，直到捨棄最終參照為止。如果外部持有者執行最終的 ksmbd_fd_put（），則 __put_fd_final（） 會將外部工作階段的檔案表提供給
    __ksmbd_close_fd（）。然後會釋放物件，而不會從其擁有者的 idr 中移除，而且擁有者工作階段稍後會在檔案表拆卸期間取消參照過時指標。當 ksmbd_close_fd（） 仍保留該表的鎖定時，從所有者的 idr 中刪除易失性 ID，並在刪除 idr 擁有的參照之前清除volatile_id。隨後的外部最終放置只會執行物理破壞，無法從錯誤的表格中移除物件。（CVE-2026-74522）

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

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

  - net： bridge：刪除連接埠群組後停止快速離開 br_multicast_leave_group（） 在其快速離開路徑中反覆運算 pp = &p->next 的 mp->ports。在 br_multicast_del_pg（） 移除 p 之後，繼續迴圈會將 pp 推進到已刪除的項目中。如果啟用了組播到單播，則網橋可以為具有不同來源 MAC 位址的相同連接埠和群組保留多個連接埠群組。停用多點傳播到單播後，br_port_group_equal（） 僅透過連接埠比對這些項目。然後，快速離開可以刪除一個項目並從其過時的下一個指標繼續，讓 mp->ports 指向已刪除的連接埠群組。快速離開只需要移除一個相符的連接埠群組。在 br_multicast_del_pg（） 之後中斷，以便迴圈在取消參照已移除的項目之前停止。（CVE-2026-74480）

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

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

  - binfmt_misc：移除項目時還原寫入存取權 使用 MISC_FMT_OPEN_FILE 旗標註冊項目會透過 open_exec（） 開啟解譯器，只要該項目存在，解譯器就會拒絕對該項目的寫入存取。移除該項目會透過 filp_close（） 關閉解譯器檔案，但永遠不會還原寫入存取權，因此 inode 的i_writecount永久為負。在項目消失後很長一段時間內，開啟解譯器進行寫入會持續失敗，並顯示 ETXTBSY，直到 inode 從 inode 快取中逐出為止。提交 90f601b497d7 （binfmt_misc：在關閉 open_exec（）） 開啟的檔案之前恢復寫入存取權） 修正了 bm_register_write（） 錯誤路徑中的相同不平衡，但自從引入該標誌以來，實際的刪除路徑一直在洩漏寫入拒絕。在關閉解譯器檔案之前，還原 put_binfmt_handler（） 中的寫入存取權。（CVE-2026-74487）

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

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

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

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

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

  - hwmon：（lm90） 僅在驅動程式準備就緒時報告警示 使用者空間可以在驅動程式註冊完成之前，也就是呼叫 devm_hwmon_device_register_with_info（） 之後立即讀取 sysfs 屬性。此時，data->hwmon_dev尚未初始化。這可能會觸發 NULL 指標訪問，因為 lm90_update_device（） 並將調用 lm90_update_alarms_locked（）。此呼叫會排程 report_work 和 lm90_report_alarms（），後者會將仍為 NULL 的資料>hwmon_dev傳遞至 hwmon_notify_event（） 並觸發 NULL 指標解除參照。透過僅排程報告來解決問題，並設定警示工作者資料>hwmon_dev。（CVE-2026-74552）

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

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

  - can： ems_usb：驗證 CPC 訊息長度 ems_usb_read_bulk_callback（） 遍歷封裝在一個 USB 接收緩衝區中的 CPC 訊息。檢查每個宣告的訊息是否符合 URB 承載。也需要類型特定的承載，以涵蓋 CAN、狀態、錯誤和溢位處理常式所使用的欄位。（CVE-2026-74460）

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

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

  - net：mpls：在 mpls_getroute（） 中初始化 rtm_tos mpls_getroute（） 透過填充從資料區域未歸零的 skb （alloc_skb（NLMSG_GOODSIZE， ...）） 分配的結構 rtmsg 來建立對 RTM_GETROUTE 請求的RTM_NEWROUTE回覆。它設定標頭的每個欄位，但rtm_tos除外：r = nlmsg_data（nlh）;
    r->rtm_family = AF_MPLS;r->rtm_dst_len = 20;r->rtm_src_len = 0;r->rtm_table = RT_TABLE_MAIN;
    r->rtm_type = RTN_UNICAST;r->rtm_scope = RT_SCOPE_UNIVERSE;r->rtm_protocol = rt->rt_protocol;
    r->rtm_flags = 0;struct rtmsg 沒有填充，因此一個未初始化的位元組rtm_tos（位移量 3）會直接複製到 recvmsg（） 上的使用者空間，從而洩漏一個位元組的未初始化堆積記憶體。這與 mpls_dump_route（） 形成鮮明對比，後者填充完全相同的標頭並設定 rtm_tos = 0。將 rtm_tos 初始化為 0，符合 mpls_dump_route（）。透過新增 MPLS 路由並為其標籤發出非RTM_F_FIB_MATCH RTM_GETROUTE，使用 KMSAN 重現： 錯誤：KMSAN：_copy_to_iter+0x36c/0x33f0 中的 kernel-infoleak
    _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit 建立於：__alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... 64 個位元組中的第 19 位元組未初始化 （位元組 19 = nlmsghdr（16） + rtmsg 位移 3 = rtm_tos） （CVE-2026-74577）

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

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

  - ALSA： seq：修正 initialize_timer（） 中的除以零 使用者空間驅動的 ALSA 計時器 （SND_UTIMER） 允許無權限的使用者透過SNDRV_TIMER_IOCTL_CREATE將支援snd_timer的硬體解析度設定為任意 64 位元值。snd_utimer_create（） 僅拒絕零。當這樣的計時器綁定到定序器佇列時，initialize_timer（） 將滴答週期計算為 tmr->ticks = 10000000000 / （r * freq）;其中 r 是用戶控制的分辨率，freq 是以 Hz 為單位的音序器更新率，箝位為 MIN_FREQUENCY。MAX_FREQUENCY （10..6250）。2^63 的分辨率使 64 位乘積 r * freq 對於任何偶數頻率（包括 DEFAULT_FREQUENCY （1000））包裝為零，因此除法會以除以零錯誤。
    除法在停用中斷的 tmr->lock 下執行，因此 oops 會保留微調鎖定並懸置 CPU。可由具有 /dev/snd/timer 和 /dev/snd/seq 存取權的無權限使用者存取。哎呀：
    除法錯誤：0000 [#1] SMP KASAN PTI CPU：7 UID：1000 PID：456 通訊：alsa_seq_utimer 未受污染 7.2.0-rc4+ RIP：0010：initialize_timer.constprop.0+0x20a/0x2d0 snd_seq_timer_start+0x15e/0x2b0 snd_seq_control_queue+0x56f/0xba0 snd_seq_write+0x3e0/0x730 使用 check_mul_overflow（） 拒絕溢位產品並回歸到單一刻度， 這也避免了將包裝但非零的除數（例如 2^63 * 1000 mod 2^64 == 0，或其他包裝為小值的分辨率）輸入到週期計算中。（CVE-2026-74504）

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

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

  - ALSA： usb-audio：修正 ump_to_endpoint（） 中的釋放後使用 create_midi2_ump（） 註冊卡片擁有的snd_ump_endpoint，並將指向其每個介面snd_usb_midi2_ump物件的反向指標儲存在 ump->private_data 中，但它永遠不會安裝 ump->private_free 勾點，也永遠不會清除該指標。如果 snd_usb_midi_v2_create（） 的後續步驟失敗，其錯誤路徑會呼叫 free_all_midi2_umps（），而 kfree（） 會讀取snd_usb_midi2_ump物件，而已註冊的端點會持續指向該物件。建立的 /dev/snd/umpC*D* 節點會保持公開狀態，因此任何 UMP 開啟的第一個作業 ump_to_endpoint（） 都會取消參照懸空的 ump->private_data，並從釋放的記憶體中讀取 rmidi->eps[dir]。因此，在註冊端點後導致建立失敗的惡意 USB MIDI 2.0 裝置可以在隨後開啟 UMP 節點時觸發 slab 釋放後使用讀取。在釋放物件之前清除端點的反向指標，並讓 ump_to_endpoint（） 容忍 NULL private_data，以便開啟/關閉/觸發回呼乾淨地失敗（其調用方已經處理了 NULL 端點），而不是取消引用過時的指標。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74501）

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

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

  - 藍牙：HIDP：驗證編號報告承載 當 hidp_get_raw_report（） 等候編號報告時，hidp_process_data（） 會將預期的報告編號與 skb->data[0] 進行比較。連線的 HIDP 對等只能使用 DATA 交易標頭回覆，在移除標頭之後，將 skb 留空。KMSAN 報告 hidp_session_run（） 中的未初始化值使用，其值源自 __alloc_skb（） 到 vhci_write（）。交易標頭檢查會移除空白框架報告，但此報告會保留，直到新增承載檢查為止。比較也可能耗用超出宣告的 L2CAP PDU 的對等控制位元組。數據 |FEATURE 回應後面接著額外的 0x01 位元組，使目前程式碼接受該位元組作為報告 ID 1，並以零位元組結果完成 HIDIOCGFEATURE。透過此變更，會以 -EIO 拒絕格式錯誤的回應，而後續有效回應仍會成功。在比較編號報告 ID 之前，需要一個承載位元組。未編號的報告會繼續接受空白承載。
    (CVE-2026-74507)

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

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

  - 藍牙：ISO：鎖定 sk 在 iso_sock_getname 存取 iso_pi（sk）->conn 需要 lock_sock，這裡不保留。透過新增鎖定/釋放來修復。（CVE-2026-74539）

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

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

  - binfmt_misc：不要讓 'F' 項目釘選自己的實例 以 'F' 註冊的項目會在註冊時開啟其解譯器，並保留該檔案，直到項目被釋放為止。任何沒有人手動刪除的條目只有在binfmt_misc超級區塊關閉後才會關閉。如果解譯器位於使該超級區塊保持活動狀態的安裝上，則兩者會相互固定：binfmt_misc sb -> inode -> entry -> interp_file
    -> vfsmount -> binfmt_misc sb TL;DR：檔案永遠不會關閉。一旦掛載命名空間消失，就沒有什麼可以取消註冊的。有兩種方法可以觸發此錯誤： - 將解譯器指向執行個體本身。其檔案是安裝程式擁有的一般檔案，bm_get_inode（） 和 simple_fill_super（） 都保留i_op empty_iops。所以 notify_change（） 回退到 simple_setattr（） 並且 chmod +x 可以工作。我們從來沒有設定過SB_I_NOEXEC，所以 open_exec（） 接受它。- 使用執行個體作為 overlayfs 較低層。覆蓋超級區塊會保留每一層的 clone_private_mount（），直到它被銷毀，並且該複製不在命名空間中。所以 umount_tree（） 永遠不會到達它。這是一個 DoS。洩漏的不僅僅是超級塊。它會釘選裝載的使用者命名空間，因此每次反覆運算都會永久消耗呼叫端的其中一個使用者命名空間費用。所以讓我們做理智的事情吧。SB_I_NOEXEC會使執行個體自己的檔案上的 open_exec（） 失敗，s_stack_depth使 overlayfs 在複製之前拒絕該層。這也涵蓋了 ecryptfs 和 fuse 直通變體。“F”的承諾沒有改變。stable 標籤故意比 Fixes 標籤窄。在沙箱掛載之前，這需要針對每個人共用的單一執行個體進行全域根目錄，而且無論如何，變更不適用於這些樹狀結構。請注意，SB_I_NODEV 是針對 userns 掛載隱含引發的，但在這裡也明確引發它。（CVE-2026-74484）

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

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

  - KVM：x86：在銷毀 vCPU 之前取消延遲的 I/O APIC EOI 處理 在 vCPU 銷毀之前，在虛擬機器銷毀前階段取消 （並排清） I/O APIC 延遲的 EOI 處理工作，因為如果該行被宣告，處理 EOI 廣播將插入另一個 IRQ，即會嘗試將 IRQ 傳遞至目標 vCPU。如果在 vCPU 銷毀後處理延遲的工作，則在銷毀 vCPU 後取消工作會導致 UAF。錯誤： KASAN：__kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c：1250 由任務 kworker/1:2/1218 在 addr ffff8880499abea0 讀取大小 8 CPU：1 UID：0 PID：1218 通訊：kworker/1:2 未受污染 7.1.0-rc7 #5 搶佔（延遲） 硬體名稱：QEMU Ubuntu 25.10 PC v2 （i440FX + PIIX， + 10.1 machine， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作佇列： 事件 kvm_ioapic_eoi_inject_work 呼叫追蹤： <TASK> __dump_stack lib/dump_stack.c：94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 print_report+0x139/0x4ad mm/kasan/report.c：482 kasan_report+0xe4/0x1d0 mm/kasan/report.c：595
    __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c：1250
    __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c：1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h：129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c：492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c：532 process_one_work+0xa59/0x19a0 kernel/workqueue.c：3314 process_scheduled_works kernel/workqueue.c：3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c：3478 kthread+0x370/0x450 kernel/kthread.c：436 ret_from_fork+0x72b/0xd30arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> 請注意，一旦 kvm_destroy_vm（） 啟動，VM 就無法連線，而且透過 kvm_ioapic_send_eoi（） 排程新工作只能透過 KVM_RUN 完成，即需要即時 vCPU。或者，KVM 可以簡單地在 VM 破壞的前階段破壞 I/O APIC，但這變得有點粗略，因為 KVM 期望如果 ioapic_in_kernel（） 為 true，則 I/O APIC 存在，而嵌套虛擬化尤其有在 vCPU 破壞期間接觸 VM 範圍狀態的壞習慣。例如，在前階段嘗試釋放 PIC 會導致 kvm_cpu_has_extint（） 中的 NULL 指標解除參照，並且不難想像 I/O APIC 也有類似的缺陷。（CVE-2026-74517）

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

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

  - mm/huge_memory：在釋放分割後對開本之前解除鎖定i_mmap_rwsem __folio_split（） 會在分割後不斷取消參照對應：shmem_uncharge（mapping->host） 和 remap_page（） 當對開本仍處於凍結/鎖定狀態時，並在分割後對開本解除鎖定並釋放之後，在最後進行 i_mmap_unlock_read（mapping）。沒有任何內容包含 inode 引用。分割依賴於 @folio （超出 EOF 的放置迴圈永遠不會移除，因為它從 folio_next （對開本） 開始 -- 保持鎖定狀態並在頁面快取中以阻止驅逐。但解鎖迴圈會在 i_mmap_unlock_read（） 執行之前解鎖@folio。
    如果調用方的@lock_at是 EOF 以外的尾部，因為在分割 shmem THP 的毒尾部時會傳遞 memory_failure（），該尾部在截斷期間超過 i_size，它也會從頁面快取中消失;因此，一旦 @folio 解鎖，沒有鎖定，快取內作品集會固定 inode，並且並發的最終 iput（） 可以在 i_mmap_unlock_read（） 接觸之前驅逐它並釋放 RCU i_mmap_rwsem： 錯誤：KASAN：slab-use-after-free in
    __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h：537 [內嵌] __folio_split+0x732/0x1640 mm/huge_memory.c：4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c：1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c：2470 由任務 4601 釋放：
    shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c：5177 evict+0x57f/0xac0 fs/inode.c：870 在 @folio 仍固定 inode 時執行每個映射解除參照：在 remap_page（） 之後立即刪除i_mmap_rwsem，在解鎖和釋放分割後作品集的迴圈之前，並清除@mapping，以便退出路徑不會再次解鎖它。shmem_uncharge（） 和 remap_page（） 在該點之前已經運行，因此在此之後，解鎖迴圈的任何內容都不會觸及 inode 或映射。這現在是分割所依賴的規則，同時在頁面快取更新之前保持@folio凍結：一旦分割後的對開本開始解鎖，就沒有 inode 或映射取消參照。（CVE-2026-74482）

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

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

  - forcedeth：修正 nv_remove nv_remove（） 中 txrx_stats 的 UAF，以釋放 unregister_netdev（） 之前的 per-CPU txrx_stats。在取消註冊完成之前，ndo_get_stats64、NAPI/xmit 資料路徑和 nv_close（）/drain 仍可能存取txrx_stats，進而導致釋放後使用。僅在 unregister_netdev（） 之後釋放統計資料。（CVE-2026-74548）

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

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

  - xsk：回收 ZC 批次路徑中無效的 Tx 描述元零副本 Tx 批次剖析器在遇到無效的描述元時停止。如果在一或多個接續描述元之後發生這種情況，則 Tx 消費者可以前進，過去既未提交給驅動程式，也未透過完成通道傳回使用者空間的片段。當封包超過xdp_zc_max_segs時，也會出現類似的問題。耗用到限制的描述元會在不完成的情況下釋放，其餘的繼續描述元隨後可以解譯為另一個封包的開頭。以封包單位剖析 Tx 批次，並將屬於完整有效封包的描述元與清空無效或過大的封包時消耗的描述元區分開來。將前者傳回給驅動程式，並將後者附加到 CQ 位址區域，以便使用者空間可以回收其 UMEM 框架。將獨立式無效描述元視為僅限單一描述元回收封包。前進 Tx-ring 消費者會釋放環槽，但本身不會將引用的 UMEM 框架的所有權返回給使用者空間。一旦開始清空，請繼續，直到封包的封包結尾描述元被消耗為止。當尚未提供 EOP 時，保留通訊端上的清空狀態，以便在稍後的呼叫期間繼續清空。將不完整但在其他方面有效的封包保留在 Tx 通道上。使用多緩衝區 Tx 的共用 UMEM 集區也需要封包框架剖析。一次遍歷一個封包的 Tx 通訊端，保留現有的每個通訊端公平性方案，而不是使用舊的單一描述元後援。保留不使用多重緩衝區 Tx 的共用集區的後援。由於每個通訊端都會維護清空狀態，而且單一和共用路徑都可以繼續中斷的清空，因此將通訊端清單從單一變更為共用不需要特殊的繫結時間轉換。CQ 專案是位置的，驅動程式只能完成 xsk_tx_peek_release_desc_batch（） 所傳回的部分 Tx 工作。因此，當早期驅動程式可見描述元仍未完成時，就無法立即發佈僅限回收項目。追蹤回收項目之前的驅動程式可見 CQ 項目數目。讓 xsk_tx_completed（） 發佈部分硬體 Tx 完成，並僅在每個較早的 Tx 描述元完成後發佈回收項目。當前面沒有驅動程式可見的工作時，立即完成僅限回收批次，並防止在回收項目保持擱置狀態時附加另一個 Tx 批次。此外，也會依集區暫存描述元陣列的大小來限制批次處理，因為屬於共用 UMEM 之通訊端的 Tx 通道可能具有不同的大小。這可確保 ZC 批次路徑所耗用的每個無效 Tx 描述元都會作為有效封包的一部分提交給驅動程式，或傳回使用者空間，而不會違反 CQ 完成順序。
    (CVE-2026-74558)

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

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

  - drm/vmwgfx：拒絕沒有 DX 內容的DX_BIND_QUERY vmw_cmd_dx_bind_query（） 會無條件地解除參照 sw_context->dx_ctx_node->ctx。使用者空間可以透過在命令串流中提交帶有 dx_context_handle == SVGA3D_INVALID_ID 和 SVGA_3D_CMD_DX_BIND_QUERY 操作碼的 execbuf，從任何渲染節點 fd 觸發 NULL 指標解除參照：dx_ctx_node 保持為 NULL，核心在分配時失敗。然後透過 vmw_context_get_dx_query_mob（） 在 vmw_resources_reserve（） 中重新讀取相同的 NULL。所有同級 DX 處理常式都會使用 VMW_GET_CTX_NODE（） 在遺漏的dx_ctx_node上失敗關閉。在這裡使用相同的模式，在發佈任何重新配置狀態之前預先傳回 -EINVAL。（CVE-2026-74445）

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

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

  - keys：修正 keyring_get_key_chunk（） 中的越界讀取 對於描述層級區塊 keyring_get_key_chunk（） 會將讀取指標按內嵌前置詞的層級 * sizeof（long） 推進，但只會對前置詞進行邊界檢查，因此會讀取足夠長的金鑰描述，超過其 kmemdup（desc， desc_len + 1） 配置。計算完整的位元組位移，並在讀取之前針對它對描述進行邊界檢查。只有當兩個鍵通過哈希 x、type 和 domain_tag 塊發生衝突時，遍歷才會到達描述級區塊，因此這是從無權限的 add_key（2） 到達的，該鍵具有一對特製的相同類型鍵，其索引哈希發生衝突;KASAN 報告 slab-out-of-bounds 讀取。（CVE-2026-74567）

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

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

  - rds： tcp：在 rds_tcp_laddr_check（） 中跨 ipv6_chk_addr（） 保持 RCU 鎖定 rds_tcp_laddr_check（） 使用 dev_get_by_index_rcu（） 查詢作用域 IPv6 介面，刪除 RCU 讀取端鎖定，然後才將裸結構 net_device * 傳遞至 ipv6_chk_addr（）。dev_get_by_index_rcu（） 僅使裝置在同一 RCU 讀取端部分內保持活動狀態。在rcu_read_unlock（）之後，並發RTM_DELLINK可以釋放net_device;然後，ipv6_chk_addr（） 會解除參照 __ipv6_chk_addr_and_flags（） 中的過時指標 （例如
    l3mdev_master_dev_rcu（dev）），讀取釋放的記憶體。在整個 ipv6_chk_addr（） 呼叫中保持 RCU 讀取端鎖定，而不是在查詢後立即刪除它，因此裝置在使用時無法釋放。錯誤：KASAN：__ipv6_chk_addr_and_flags 中的 slab-use-after-free （...net/ipv6/addrconf.c：1998） 透過任務 exploit/153 在 addr ffff8880106ec000 讀取大小 8 呼叫追蹤：...kasan_report （mm/kasan/report.c：595） __ipv6_chk_addr_and_flags （...net/ipv6/addrconf.c：1998） ipv6_chk_addr （net/ipv6/addrconf.c：2031 net/ipv6/addrconf.c：1972） rds_tcp_laddr_check （net/rds/tcp.c：370） rds_bind （net/rds/bind.c：248） __sys_bind （net/socket.c：1920） __x64_sys_bind （net/socket.c：1956） do_syscall_64 （arch/x86/entry/syscall_64.c：63） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） （CVE-2026-74563）

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

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

  - net/sched： cls_u32：驗證 offshift 以防止越界移位 u32_change（） 將使用者提供的 tc_u32_sel.offshift （未簽名的字元，0-255） 複製到核心 knode 物件中，而不進行邊界驗證。當封包稍後在設定TC_U32_VAROFFSET的情況下命中 u32_classify（） 時，它會評估「ntohs（offmask &; *data） >> offshift」，其中左運算元是提升為 32 位元 int 的 16 位元值。任何偏移 >= 32 都是 6.5.7p3 的 C11 未定義行為，可由無權限的使用者透過使用者/網路命名空間觸發。
    UBSAN：net/sched/cls_u32.c：236：43 中的移位越界 移位指數 32 對於 32 位元類型 int 來說太大 在 u32_change（） 中建立篩選器期間拒絕偏移 >= 16） 來修正此問題。（CVE-2026-74544）

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

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

  - ALSA： timer：關閉完成後清除SNDRV_TIMER_IFLG_DEAD snd_timer_close_locked（） 會以 SNDRV_TIMER_IFLG_DEAD 標示執行個體，並在已設定旗標時提前傳回，但旗標永遠不會再次清除。完成的關閉以 remove_slave_links（） 結束，這會使 timeri->timer 為 NULL，因此透過 timer == NULL 路徑，第二次關閉已經無害;提前返回只能透過中間再次開啟的執行個體來存取。對於這樣的實例，關閉不會取消任何連結，因此 snd_timer_instance_free（） 會釋放一個仍處於計時器>open_list_head的物件，如果它是使用從屬金鑰開啟的，則仍然處於snd_timer_master_list，仍然擁有任何採用的從屬，並且仍然保留其計時器和模組引用。snd_seq_timer_open（） 會以完全相同的方式重新開啟執行個體：在內部已執行 snd_timer_close_locked（） 的失敗後，它會重試在同一物件上開啟後援。有權存取 /dev/snd/timer 和 /dev/snd/seq 的無權限使用者可以強制失敗，因為當擱置的從屬裝置符合新主機 （slave_class， slave_id） 金鑰並且目標計時器已達到 max_instances 時，snd_timer_check_master（） 會傳回 -EBUSY，而 dev_class = SNDRV_TIMER_CLASS_SLAVE 的SNDRV_TIMER_IOCTL_SELECT會保留呼叫端提供的dev_sclass， 因此，可以偽造排序器佇列的金鑰。
    釋放的實例隨後會被該計時器上的任何進一步 snd_timer_open（）、snd_timer_check_slave（） 和 /proc/asound/timers 解除參照，這會在過時的 ti->owner 指標上出錯。該標誌只需要在關閉進行時可見，這是其他用戶所需要的。在 remove_slave_links（） 中清除它，在設定它的相同計時器>鎖定下，一旦實例從每個清單中消失。
    (CVE-2026-74503)

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

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

  - Bluetooth： hci_sync：在 hci_past_sync（） 回呼中按住 conn 避免將釋放的指標提供給 kmalloc 可能已重複使用的 hci_conn_valid（） 指標。保留 refcount 以避免這種情況。（CVE-2026-74528）

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

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

  - ksmbd：拒絕重複的 SMB2 協商要求 未經驗證的用戶端可以在SESSION_SETUP之前在一個連線上傳送多個成功的 SMB2 協商要求。當連線處於KSMBD_SESS_NEED_SETUP狀態時，smb2_handle_negotiate（） 會接受另一個 SMB3.1.1 協商，並以新的配置覆寫 conn->preauth_info。釋放連線時，只會釋放最終配置，因此每增加一個成功要求，就會洩漏一個物件。選取方言後重複的 SMB2 協商是通訊協定違規。在此情況下，MS-SMB2 區段 3.3.5.4 會要求伺服器中斷連線而不回覆。除了禁止回應之外，還設定拒絕要求時結束的連線。拒絕 SMB2 協商，除非連線是新的，或正在等待 SMB1 多重通訊協定協商之後的 SMB2 協商。序列化 conn->srv_mutex 下的 SMB1 和 SMB2 交涉路徑，因為它們會更新全連線方言和交涉狀態。將鎖定合約移至選取狀態和方言的 ksmbd_smb_negotiate_common（），並新增 ksmbd_conn_new（） 以取得一致的狀態存取。（CVE-2026-74494）

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

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

  - can： peak_usb：新增 USB 通道索引的邊界檢查 通道控制索引ctrl_idx衍生自直接來自裝置 USB 承載的 rx->len。遮罩0x0f允許值 0-15，但 usb_if->dev[] 的陣列大小僅為 2。值 2-15 會導致堆積越界讀取，最終在 IRQ 內容中造成核心錯誤。在 pcan_usb_pro_handle_canmsg（） 和 pcan_usb_pro_handle_error（） 中的陣列存取之前新增邊界檢查ctrl_idx。（CVE-2026-74457）

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

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

  - 藍牙：ISO：修正 kfree 與 kref_get_unless_zero hci_conn：：iso_data 的爭用，無需鎖定或 RCU 即可存取和修改。這會導致爭用 [任務 hdev->workqueue] [任務 2] iso_recv iso_conn_put（conn） conn = LOAD hcon->iso_data iso_conn_free（conn） iso_conn_hold_unless_zero（conn） hcon->iso_data = NULL kfree（conn） kref_get_unless_zero（&conn->ref） /* UAF */ 以及 iso_conn_add（） 與
    iso_conn_free（）。透過新增微調鎖 hci_conn：:p roto_lock 並使用它來保護 hci_conn：：iso_data 來修正。
    (CVE-2026-74533)

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

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

  - afs：修正傳送訊息時的 UAF 在 afs_make_call（） 中，存在非同步呼叫接收和銷毀的爭用。如果分派的呼叫未設定呼叫>write_iter （用來指定 FS 的資料內容。StoreData），則第一個 rxrpc_kernel_send_data（） 不會在 msghdr 中設定MSG_MORE。
    一旦 rxrpc_send_data（） 將最後一個請求封包排入佇列，回應可能隨時傳入並導致呼叫完成並放置。不過，afs_make_call（） 會再次查看呼叫以查看它
    ->write_iter應該被處理 - 只有在調用中有自己的引用時才允許這樣做。
    雖然同步呼叫是這種情況，但對於 FS 等非同步呼叫則不然。FetchData。如果正在傳送非同步呼叫，但呼叫以某種方式失敗（例如，它從伺服器中止），則 afs_make_call（） 中也存在潛在的 UAF。問題在於，如果 rxrpc 傳送失敗，afs_make_call（） 會嘗試中止呼叫，但來自 rxrpc 的非同步通知可能導致afs_call被拆除。generic/650 會隨機使 CPU 離線來玩遊戲，並且可以插入顯著的延遲，以便在 afs_make_call（） 檢查呼叫>write_iter之前取消分配呼叫
    - 隨後出現了 UAF（被 KASAN 捕獲）。錯誤：KASAN：afs_make_call+0x1c90/0x2210 中的 slab-use-after-free [kafs] 任務 fsstress/1409 在 addr ffff888035e050e8 讀取大小 8 透過讓 afs_make_op_call（） 為 op->call 提供自己的參照來修正此問題，而不是將調用者的參照傳輸給它，然後在 afs_make_call（） 傳回時刪除參照。這也意味著 afs_make_call（） func 現在永遠不會在調用中丟失其引用。（CVE-2026-74506）

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

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

  - GPIO：pch：將 raw_spinlock_t 用於暫存器鎖定 pch_irq_type（） 註冊為 irq_chip .irq_set_type 回呼，並使用 spin_lock_irqsave（） 進行晶片>微調鎖定。此回呼可從
    __setup_irq（） -> __irq_set_trigger（） -> chip->irq_set_type（），而調用方持有 desc->lock，一個raw_spinlock_t，停用 hardirqs。該上下文不可休眠，但在PREEMPT_RT常規spinlock_t是 rtmutex 支持的休眠鎖，因此在那裡獲取它是無效的。這已在具有 lockdep 的PREEMPT_RT核心 （PROVE_RAW_LOCK_NESTING 和 DEBUG_ATOMIC_SLEEP） 上確認。接地的 PoC 反映了 pch_irq_type（） 的鎖定，並驅動它通過真正的 genirq 載波 irq_set_irq_type（） ->
    __irq_set_trigger（） -> chip->irq_set_type（），即 __setup_irq（） 用於請求的 IRQ 的相同 __irq_set_trigger（） 邊緣。使用原始 spin_lock_irqsave（） 邊緣時，lockdep 報告了無效的等待上下文，緊接著是： 錯誤：從 kernel/locking/spinlock_rt.c：48 的無效上下文呼叫休眠函數 in_atomic（）：1，irqs_disabled（）：1，non_block：0，PID：95，名稱：insmod hardirqs 上次停用時間：（3784）：_raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 將鏡像鎖切換到 raw_spinlock_t 使兩個濺射都消失了。將暫存器鎖定轉換為 raw_spinlock_t。
    相同的鎖也會序列化 GPIO 方向/值回呼和暫停/恢復暫存器儲存/還原，但所有這些關鍵部分僅執行 MMIO 暫存器存取 （ioread32（）/iowrite32（）） 和 irq_set_handler_locked（）;它們都不包含可休眠的操作。因此，讓此暫存器鎖定保持非休眠狀態適用於 irqchip 回呼，而且不會變更 GPIO 端鎖定合約。這與最近針對其他 GPIO 控制器解決的問題和修正類別相同，例如提交 286533cb14a3 （gpio：sch：在 irq 啟動路徑中使用 raw_spinlock_t） 和提交 90f0109019e6 （gpio：eic-sprd：在 irq 啟動路徑中使用 raw_spinlock_t）。（CVE-2026-74468）

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

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

  - of/address：修正 of_pci_range_parser_one（） 中的 NULL 匯流排取消參照 匯流排比對重做使得 of_match_bus（） 對於具有範圍/dma 範圍但沒有本機 #address 儲存格的節點傳回 NULL。parser_init（） 儲存了該 NULL 匯流排，範圍迭代器稍後取消參照了它。在 parser_init（） 中拒絕此類節點，為忽略 init 傳回的調用者留下一個明確的空迭代器，並使 of_dma_get_max_cpu_address（） 接受 init 失敗，以便被拒絕的節點無法限制 DMA 限制。
    (CVE-2026-74491)

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

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

  - i2c：imx：清除從屬指標前取消 hrtimer 在 i2c_imx_unreg_slave（） 中，停用中斷後將從屬指標設定為 NULL。不過，在清除指標之前，擱置中的中斷可能已經啟動 hrtimer （i2c_imx_slave_timeout）。如果 hrtimer 在 i2c_imx->slave 設定為 NULL 之後觸發，則計時器回呼 i2c_imx_slave_finish_op（） 將呼叫具有 NULL 從屬指標的 i2c_imx_slave_event（），這會導致釋放後使用 / NULL 指標解除參照。透過取消 hrtimer 並在停用中斷後等待其完成，再清除從屬指標來修正。（CVE-2026-74461）

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

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

  - scsi： libiscsi：修正 SCSI 感應緩衝區中的過時資料洩漏 iscsi_scsi_cmd_rsp（） 會從目標提供的資料區段複製 SCSI 回應的感應資料。該段帶有一個 2 位元組的感知長度，後面跟著感知位元組，因此它必須包含 2 + senselen 位元組，但邊界檢查只需要 datalen >= senselen：senselen = get_unaligned_be16（data）;if （datalen < senselen） goto invalid_datalen;
    memcpy（sc->sense_buffer， data + 2， min_t（uint16_t， senselen， SCSI_SENSE_BUFFERSIZE））;如果目標傳回 datalen 等於 senselen 的 SCSI 回應 （使用 senselen <= SCSI_SENSE_BUFFERSIZE），則會使來自 data + 2 的 memcpy（） 讀取最多兩個位元組。這些位元組是過時的 conn->data 內容，並最終進入命令的感知緩衝區，該緩衝區會傳回給使用者空間。在檢查中考慮 2 位元組感應長度前置詞。（CVE-2026-74557）

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

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

  - iommu/iommufd：在叫用網域錯誤處理常式之前，修正 IOPF 群組擁有權 UAF iopf_group_alloc（） 將每個最後一頁 IOPF 群組連結至一般 IOPF 擱置清單。iommufd_fault_iopf_handler（） 也會將 IOMMUFD 傳遞清單中接受的群組排入佇列，而不會將它從一般擱置清單中移除。
    當分離或 HWPT 取代將裝置的 IOPF 參考計數降為零時，IOMMU 驅動程式可能會呼叫 iopf_queue_remove_device（） 。該函式會透過一般擱置清單回應並釋放群組，而不會從 IOMMUFD 的遞送清單或回應 xarray 中移除相同的群組。然後，稍後的讀取、回應或清除可以存取釋放的群組並造成 UAF。在 IOMMUFD 將接受的群組排入佇列以等待使用者空間回應之前，將接受的群組從通用擱置清單中除名，以修正此問題。無論擱置清單成員資格為何，都使 iopf_group_response（） 傳送回應，因此 IOMMUFD 仍可完成出佇列的群組。
    (CVE-2026-74520)

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

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

  - netfilter： nf_conntrack_sip：在 sip_help_tcp（） 中將 NAT 重寫增量擴大到 s32 sip_help_tcp（） 將每則 NAT 重寫 SIP 訊息的大小變更儲存在 s16 diff 中，並將其累積到 s16 tdiff 中，但當封包保持在 65535 enlarge_skb（） 限制以下時，單一訊息可能會增長超過 S16_MAX：
    nf_nat_sip（） 會重寫每個相符的 URI，而長連絡人清單會將訊息擴充數十 KB。然後 diff 包裝，datalen = datalen + diff - msglen 會產生一個巨大的無符號 datalen，因此下一個迭代的 ct_sip_get_header（） 讀取過線性化的 skb 尾部。將 diff、tdiff 和 seq_adjust 鉤子加寬到 s32。兩者都受到 65535 位元組封包限制的限制，並且 seqadj 核心已經是 s32（nf_ct_seqadj_set（） 採用 s32），因此先前接受的輸入不會被拒絕。錯誤：KASAN：ct_sip_get_header中的釋放後使用 （net/netfilter/nf_conntrack_sip.c：464） 透過任務 ksoftirqd/1/25 讀取 addr ffff888010800000 大小 1 ct_sip_get_header （net/netfilter/nf_conntrack_sip.c：464） sip_help_tcp （net/netfilter/nf_conntrack_sip.c：1694） nf_confirm （net/netfilter/nf_conntrack_proto.c：183） nf_hook_slow （net/netfilter/core.c：619） ip6_output （net/ipv6/ip6_output.c：246） ip6_forward （net/ipv6/ip6_output.c：690） ipv6_rcv （net/ipv6/ip6_input.c：351） __netif_receive_skb_one_core （net/core/dev.c：6212） process_backlog （net/core/dev.c：6676） __napi_poll （net/core/dev.c：7735） net_rx_action （net/core/dev.c：7955） handle_softirqs （kernel/softirq.c：622） run_ksoftirqd （kernel/softirq.c：1076） ...（CVE-2026-74569）

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

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

  - nvmet-tcp：檢查 nvmet_tcp_set_queue_sock 的傳回值 nvmet_tcp_tls_handshake_done（） 中目前會忽略 nvmet_tcp_set_queue_sock（） 的傳回值。如果失敗（例如，由於通訊端未處於TCP_ESTABLISHED狀態），通訊端回呼將無法正確設置，從而導致佇列和通訊端洩漏。透過擷取傳回值並在失敗時呼叫 nvmet_tcp_schedule_release_queue（） 來修正此問題，以確保正確清除。（CVE-2026-74385）

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

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

  - dm-ioctl：修正 sizeof（tt->version） list_version_get_info 為 12 位元組，但程式碼將 16 位元組寫入輸出緩衝區 - info->vers->version[0]、info->vers->version[1]、info->vers->version[2] 和 info->vers->next。這可能會導致緩衝區溢位。將 sizeof（tt->version） 替換為 sizeof（struct dm_target_versions），以修正此緩衝區溢位。（CVE-2026-72106）

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

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

  - sctp：修正 INIT 處理中的 err_chunk 記憶體洩漏 當 sctp_verify_init（） 遇到無法識別的參數時，它會分配一個err_chunk來報告它們。不過，此區塊會在數個程式碼路徑中洩漏：
    1. 在 sctp_sf_do_5_1B_init（） 中，如果 sctp_verify_init（） 填入err_chunk後 security_sctp_assoc_request（） 失敗，則函數立即返回而不釋放它。2、在sctp_sf_do_unexpected_init（）中，security_sctp_assoc_request（）故障路徑上也發生了同樣的洩漏。3.
    在 sctp_sf_do_unexpected_init（） 中，在將無法識別的參數複製到 INIT-ACK 後的成功路徑上，函數返回而不釋放err_chunk，這與正確釋放它的 sctp_sf_do_5_1B_init（） 不同。在返回錯誤路徑和 sctp_sf_do_unexpected_init（） 中的成功路徑之前，新增 sctp_chunk_free（err_chunk） 呼叫來修正所有三個洩漏。（CVE-2026-72413）

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

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

  - jbd2：修正 jbd2_journal_initialize_fast_commit（） 中的整數反向溢位 jbd2_journal_initialize_fast_commit（） 透過檢查 （journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS） 來驗證日誌容量。j_last和num_fc_blks都是無符號的，因此當num_fc_blks超過j_last時，減法會繞過邊界檢查，換行為較大的值。產生的反向溢位會損毀j_last、j_fc_first和j_free，進而導致日誌中止。透過在減法之前檢查num_fc_blks與j_last進行修正，傳回
    -EFSCORRUPTED。（CVE-2026-72225）

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

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

  - bridge： stp：修正刪除網橋時潛在的釋放後使用 當網橋管理關閉時，不應布防三個 STP 計時器。當網橋在行政上關閉時，它們會同步停用，並且各個呼叫站點在布防它們之前檢查「IFF_UP」。br_topology_change_detection（） 中缺少此檢查，並且可以設計出這樣一種情況：當橋接器在管理上關閉時，拓撲更改計時器已布防，從而導致刪除橋接器時釋放後使用 [1]。透過新增遺漏檢查來修正，並為刪除橋接器時同步關閉三個計時器。[1] ODEBUG：釋放活動 （活動狀態 0） 物件：
    ffff88811662b9b0 物件類型：timer_list提示：br_topology_change_timer_expired （net/bridge/br_stp_timer.c：120） 警告：lib/debugobjects.c：629，debug_print_object+0x1bc/0x450， CPU#9：
    ip/359 （CVE-2026-72389）

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

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

  - RDMA/hns：修正cmd_mbox失敗後的日誌溢流 hns_roce_cmd_mbox（） 是驅動程式和硬體之間的命令介面。當硬體異常時，hns_roce_cmd_mbox（）故障後無限的錯誤列印會導致日誌泛洪，甚至系統崩潰。在 hns_roce_cmd_mbox（） 及其包裝函式 hns_roce_create_hw_ctx/hns_roce_destroy_hw_ctx） 失敗後，將 ibdev_err（） 和 ibdev_warn（） 替換為錯誤處理路徑中的速率限制版本。（CVE-2026-74389）

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

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

  - net/sched： cls_flow：不要公開摺疊的核心指標 對於封包標頭中遺漏的欄位，流程分類器會回復至 addr_fold（）。在地圖模式下，使用者空間控制遮罩、異或、rshift、加數和除數，並可以透過類別統計來觀察產生的分類ID。這允許使用者/網路命名空間中的 tc 分類器恢復 skb->sk、skb_dst（） 或 skb_nfct（） 的 32 位折疊值。與指標雜湊的標準核心實踐保持一致，並將 XOR 折疊替換為金鑰 siphash（加密安全）（CVE-2026-74290）

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

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

  - pmdomain： imx： 修正 i.MX8MP VC8000E開機順序 根據勘誤表[1]： ERR050531VPU_NOC 在 VC8000E/VPUMIX 開機/關機循環期間，斷電交握可能會懸。說明：VC8000E重設取消宣告邊緣和 AXI 時鐘可能有計時問題。因應措施：將 BLK_CLK_EN_CSR 的 bit2 （vc8000e_clk_en） 設定為 0，以關閉 AXI 時鐘和傳送到 VC8000E 的 VC8000E 時鐘，以及在通電期間傳送到 VPU_NOC m_v_2 介面的 AXI 時鐘VC8000E關閉 （VC8000E HW 取消宣告重設） 在「struct imx8m_blk_ctrl_domain_data」中新增布林變數 is_errata_err050531，以表示是否需要因應措施。如果 is_errata_err050531 為 true，請先在開啟 gpc 電源之前清除 clk，然後在開啟 gpc 電源後啟用 clk。[1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A （CVE-2026-72007）

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

ID	名稱	嚴重性
335793	Linux Distros 未修補弱點：CVE-2026-74518	high
335792	Linux Distros 未修補弱點：CVE-2026-74472	high
335791	Linux Distros 未修補弱點：CVE-2026-74469	high
335790	Linux Distros 未修補弱點：CVE-2026-74498	high
335789	Linux Distros 未修補弱點：CVE-2026-74455	high
335788	Linux Distros 未修補弱點：CVE-2026-74536	medium
335787	Linux Distros 未修補弱點：CVE-2026-74442	medium
335786	Linux Distros 未修補弱點：CVE-2026-74505	medium
335785	Linux Distros 未修補弱點：CVE-2026-74551	high
335784	Linux Distros 未修補弱點：CVE-2026-74564	high
335783	Linux Distros 未修補弱點：CVE-2026-74522	high
335782	Linux Distros 未修補弱點：CVE-2026-74480	critical
335781	Linux Distros 未修補弱點：CVE-2026-74487	high
335780	Linux Distros 未修補弱點：CVE-2026-74531	high
335779	Linux Distros 未修補弱點：CVE-2026-74552	medium
335778	Linux Distros 未修補弱點：CVE-2026-74460	medium
335777	Linux Distros 未修補弱點：CVE-2026-74577	high
335776	Linux Distros 未修補弱點：CVE-2026-74504	medium
335774	Linux Distros 未修補弱點：CVE-2026-74501	high
335773	Linux Distros 未修補弱點：CVE-2026-74507	high
335772	Linux Distros 未修補弱點：CVE-2026-74539	high
335771	Linux Distros 未修補弱點：CVE-2026-74484	medium
335770	Linux Distros 未修補弱點：CVE-2026-74517	critical
335769	Linux Distros 未修補弱點：CVE-2026-74482	high
335768	Linux Distros 未修補弱點：CVE-2026-74548	high
335767	Linux Distros 未修補弱點：CVE-2026-74558	medium
335766	Linux Distros 未修補弱點：CVE-2026-74445	medium
335765	Linux Distros 未修補弱點：CVE-2026-74567	high
335764	Linux Distros 未修補弱點：CVE-2026-74563	high
335763	Linux Distros 未修補弱點：CVE-2026-74544	high
335762	Linux Distros 未修補弱點：CVE-2026-74503	high
335761	Linux Distros 未修補弱點：CVE-2026-74528	high
335760	Linux Distros 未修補弱點：CVE-2026-74494	medium
335759	Linux Distros 未修補弱點：CVE-2026-74457	high
335758	Linux Distros 未修補弱點：CVE-2026-74533	high
335757	Linux Distros 未修補弱點：CVE-2026-74506	high
335756	Linux Distros 未修補弱點：CVE-2026-74468	medium
335755	Linux Distros 未修補弱點：CVE-2026-74491	medium
335754	Linux Distros 未修補弱點：CVE-2026-74461	high
335753	Linux Distros 未修補弱點：CVE-2026-74557	high
335752	Linux Distros 未修補弱點：CVE-2026-74520	high
335751	Linux Distros 未修補弱點：CVE-2026-74569	critical
335744	Linux Distros 未修補弱點：CVE-2026-74385	high
335743	Linux Distros 未修補弱點：CVE-2026-72106	high
335742	Linux Distros 未修補弱點：CVE-2026-72413	medium
335741	Linux Distros 未修補弱點：CVE-2026-72225	high
335740	Linux Distros 未修補弱點：CVE-2026-72389	high
335739	Linux Distros 未修補弱點：CVE-2026-74389	medium
335738	Linux Distros 未修補弱點：CVE-2026-74290	high
335737	Linux Distros 未修補弱點：CVE-2026-72007	medium

偵測

Nessus 的 Misc. 系列

high

high

high

high

high

medium

medium

medium

high

high

high

critical

high

high

medium

medium

high

medium

high

high

high

medium

critical

high

high

medium

medium

high

high

high

high

high

medium

high

high

high

medium

medium

high

high

high

critical

high

high

medium

high

high

medium

high

medium