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

  - NLTK 3.9.4 through 在 3.10.2 CrubadanCorpusReader 中包含一個路徑遊走弱點。
    _load_lang_ngrams 會將語料庫根與 crubadan_code （從語料庫table.txt對應檔案讀取的 column-0 值） 聯結，並使用內建 open（） 而不是 pathsec 驗證的開啟器開啟結果，因此當該值為絕對值時，os.path.join 會捨棄該根，並且讀取會逸出語料庫目錄，而沒有設定 ENFORCE 時套用 nltk.pathsec 的包含檢查。控制語料庫套件的攻擊者可以透過lang_freq洩露語料庫根目錄之外的檔案內容，僅限於以 -3grams.txt 結尾的路徑，其內容剖析為權杖計數行。（CVE-2026-71514）

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

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

  - sctp：修正快取 ASCONF 區塊的釋放後使用addip_last_asconf快取未完成的傳出 ASCONF 區塊。一般 ASCONF-ACK 完成路徑會釋放區塊並清除指標。但是，sctp_asconf_queue_teardown（） 會釋放快取的區塊而不清除addip_last_asconf。在對等重新啟動處理期間，sctp_sf_do_dupcook_a（） 會SCTP_CMD_PURGE_ASCONF_QUEUE佇列，這會在關聯保持作用中並使指標懸置時叫用 sctp_asconf_queue_teardown（）。然後，經過驗證的延遲 ASCONF-ACK 可以到達 sctp_sf_do_asconf_ack（），後者會存取過時的區塊並將其傳遞給 sctp_process_asconf_ack（），從而導致釋放後使用和第二次釋放。清除指標會公開 T4 到期的爭用。對等重新啟動處理會讓計時器在清除前停止佇列，但SCTP_CMD_TIMER_STOP使用 timer_delete（），它不會等待已在另一個 CPU 上執行的回呼。這類回呼可以在清除和取消參照 NULL 之後到達 sctp_sf_t4_timer_expire（）。釋放快取區塊後清除 addip_last_asconf，如果沒有未完成的 ASCONF，則使 sctp_sf_t4_timer_expire（） 消耗過時的 T4 到期日。（CVE-2026-74587）

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

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

  - 之前 3.9.4 的 NLTK 版本在 JSONTaggedDecoder.decode_obj（） 中包含一個不受限制的遞迴弱點，攻擊者可藉由提供深度巢狀 JSON 結構來造成拒絕服務。攻擊者可以製作超過遞迴限制的 JSON 承載，以觸發未處理的 RecursionError，從而使 Python 處理程序損毀。（CVE-2026-66393）

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

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

  - net/dibs：正確釋放dmb_clientid_arr dibs 裝置中斷處理常式可以在 dibs_dev_del（） 之後處於活動狀態，並且仍可存取dmb_clientid_arr。（UAF）如果 dibs_lo_dev_probe（） 呼叫 dibs_dev_add（） 失敗，dmb_clientid_arr將被釋放兩次（雙重釋放）。最後一次參照消失後，dibs_dev_release（） 中的釋放dmb_clientid_arr。請注意，目前可以在 dibs_dev_add（） 而不是 dibs_dev_alloc（） 中配置，因為在 dibs_dev_add（） 之前無法註冊任何 dmb。（CVE-2026-74629）

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

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

  - net： bridge： mrp：修正線路上未初始化的位元組 br_mrp_alloc_test_skb（） 從 dev_alloc_skb（） 在 skb 上建立 MRP 測試幀，這不會清除線性資料區域。在 MRA 環角色分支上，子選項 TLV 標頭附加 sub_tlv = skb_put（skb， sizeof（*sub_tlv））;sub_tlv->類型 = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR;因此永遠不會寫入 sub_tlv->長，並且兩個尾隨對齊位元組附加了一個裸的 skb_put（），該字節也不會清除它們。相鄰的 oui 和 sub_opt 區域明確歸零，因此每個發出的 MRA MRP_Test幀中都會留下三個未初始化的位元組。將子選項 TLV 標頭和對齊填充放在單一 skb_put_zero（） 中，這會清除兩者。AUTO_MGR子 TLV 不攜帶負載，因此歸零長度欄位已經是它應有的值。（CVE-2026-74659）

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

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

  - 提示：在 tipc_node_link_down（） 中節點鎖定下讀取 le->link tipc_node_link_down（） 在採用 n->lock 之前快取連結指標：struct tipc_link *l = le->link;/* 已解鎖 */ if （！l） return;
    tipc_node_write_lock（n）;if （！tipc_link_is_establishing（l）） { /* 解除參照 l */ ...tipc_link_reset（l）;/* 寫入 l */ if （delete） { kfree（l）; le->link = NULL;delete=true 呼叫端會在 n->lock 下釋放該物件，因此鎖定不會保護快取的指標免受它的影響：- CPU A， delete=false：
    TIPC_LINK_DOWN_EVT 上的 tipc_rcv（） 或透過 tipc_node_timeout（） 的連結監督計時器，讀取 L 已解鎖，然後在 n->lock 下取消參照;- CPU B， delete=true： netlink TIPC_NL_BEARER_DISABLE -> bearer_disable（） -> tipc_node_delete_links（） -> tipc_node_link_down（n， bearer_id， true） -> kfree（l）。連結是使用純 kfree（） 而不是 kfree_rcu（） 釋放的，並且對於 UDP 承載 disable_media（） 僅排程非同步 cleanup_bearer（） 工作，因此其 synchronize_net（） 在連結消失後運行。因此，讀取 l 的正在進行中的 CPU A 會在 B 釋放記憶體後取消參照釋放的記憶體：tipc_link_is_establishing（） 中的釋放後使用讀取，以及透過建立分支上的 tipc_link_reset（） 進行釋放後使用寫入。
    在 7.2.0-rc5-00284-gaf39eb111ce6 上擷取了以下追蹤： 錯誤：KASAN：tipc_link_is_establishing 中的 slab-use-after-free （net/tipc/link.c：285） 由任務 swapper/2/0 tipc_link_is_establishing 在 addr ffff88802e2aa068 讀取大小 4 （net/tipc/link.c：285） tipc_node_link_down （net/tipc/node.c：1076） tipc_node_timeout （net/tipc/node.c：843） 由任務 9549 分配： tipc_link_create （net/tipc/link.c：490） tipc_node_check_dest （net/tipc/node.c：1279） tipc_disc_rcv （net/tipc/discover.c：252） tipc_udp_recv （net/tipc/udp_media.c：389） 由任務 9549 釋放： tipc_node_link_down （net/tipc/node.c：1084） tipc_node_delete_links （net/tipc/node.c：1320） bearer_disable （net/tipc/bearer.c：414）
    __tipc_nl_bearer_disable （net/tipc/bearer.c：992） 移動 tipc_node_write_lock（） 內讀取的 le->link，以便針對刪除路徑中的 kfree（） 進行序列化。現在的 racing 拆卸要麼尚未執行，我們看到有效的連結，要麼已經執行，但我們看到 NULL。（CVE-2026-74609）

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

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

  - NLTK 之前 3.10.3 在 AllowlistUnpickler 中包含一個遠端程式碼執行弱點，該弱點僅驗證 pickle 模組字串，而不驗證全域名稱，允許攻擊者透過屬性遊走到允許列入清單名稱空間之外的可呼叫項目來解析點狀名稱。攻擊者可以製作不受信任的轉換剖析器模型，這些模型會在 TransitionParser.parse 透過allowlisted_pickle_load載入模型時執行任意命令。（CVE-2026-71513）

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

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

  - fscrypt：在允許設定加密原則之前，使用掛載 idmap 進行所有者簽入 fscrypt_ioctl_set_policy（） fscrypt_ioctl_set_policy（） 呼叫 inode_owner_or_capable（） 和 &nop_mnt_idmap，而不是發出 ioctl 的掛載的 idmap。fscrypt 由支援 idmapped 掛載的檔案系統使用（例如 ext4、f2fs），因此在這樣的掛載中，這會將調用方的 fsuid 與未映射的磁碟上所有者而不是映射的所有者進行比較：實際所有者可能會被錯誤地拒絕使用 -EACCES，並且錯誤地允許不相關的調用者。請改用 file_mnt_idmap（filp）。（CVE-2026-74595）

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

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

  - dibs：在 dibs_dev_alloc（） 中初始化 dibs->lock dibs->lock 是由 dibs_dev_add（） 初始化的，但 dibs 裝置在呼叫之前已經可以中斷：ism_probe（） 在呼叫 dibs_dev_add（） 之前執行 ism_dev_init（），因此執行 request_irq（）。此時任何用戶端都無法註冊 dmb，因此不會發生 dmb 中斷，但 GID 事件中斷可以，並且 ism_handle_irq（） 在檢查其他任何內容之前，在進入時無條件地採用 dibs->lock。請改為初始化 dibs_dev_alloc（） 中的鎖定，以便在驅動程式可以將裝置發佈至其中斷處理常式時立即有效。
    (CVE-2026-74617)

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

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

  - bonding： alb：在 bond_alb_monitor bond_alb_monitor（） 中重新檢查 RTNL 下的 primary_is_promisc，讀取 RCU 下的 primary_is_promisc，然後刪除 RCU 並透過 rtnl_trylock（） 獲取 RTNL，然後撤銷它在活動從屬上設定的混雜。在該窗口中，活動從屬可以在 RTNL 下更改 （RTM_DELLINK
    -> __bond_release_one（） -> bond_alb_handle_active_change（）），這已經刪除了混雜並清除了primary_is_promisc。監視器仍會處理過時的決策：如果在沒有容錯移轉的情況下移除從屬，則curr_active_slave現在為 NULL，且 deref 出錯;如果故障轉移，過時的 dev_set_promiscuity（-1） 會反向溢位新從屬的混雜計數器，並將其釘選在IFF_PROMISC中。哎呀：
    一般保護錯誤，可能是非規範地址...... KASAN：範圍內的 null-ptr-deref [0x0000000000000000-0x0000000000000007] 工作佇列：b42 bond_alb_monitor RIP：0010：bond_alb_monitor （drivers/net/bonding/bond_alb.c：1600） process_one_work （kernel/workqueue.c：3322） worker_thread （kernel/workqueue.c：3486） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） 核心錯誤 - 未同步： 重大異常 在進行 RTNL 後重新檢查 primary_is_promisc （和 curr_active_slave），以便監視器僅復原增量，它仍然擁有。其他綁定監控器已經在提交階段重新讀取 RTNL 下的狀態 （bond_miimon_commit/bond_ab_arp_commit）;bond_alb_monitor（） 是唯一對 Trylock 前決定採取行動的人。（CVE-2026-74726）

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

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

  - perf/core：修正同級分離後的群組領導者釋放後使用問題 perf_group_detach（） 以不同的方式處理領導者和同級分離。當群組領導者分離時，所有同級都會升級為單一事件，且其group_leader指標會重設為自己。分離同級時，它會從領導者的sibling_list中移除，但其group_leader指標仍會指向舊的領導者。當同級被關閉並立即釋放時，這是無害的，就像在DETACH_DEAD路徑中一樣。當同級分離但保持活動狀態時，例如在 CPU 熱插拔與 DETACH_GROUP 期間，這是不安全的。在此情況下，同級會從內容中移除，而其檔案描述元仍可使其保持作用中。典型的失敗序列為： - 群組包含領導者 L 和同級 S。 - CPU 熱插拔會以 DETACH_GROUP 分離 S，將其從 L->sibling_list 中移除，但留下 S->group_leader == L。 - L 稍後會關閉並釋放。- S 上的PERF_IOC_FLAG_GROUP ioctl 會跟隨 S->group_leader 並取消參照釋放的領導者。這是透過同時執行 perf 事件模糊測試程式、CPU 熱插拔和壓力工作負載來重現的： 無法處理虛擬位址 006b6b6b6b6b6cdb 上的核心分頁要求 CPU：2 PID：12489 通訊：perf_fuzzer 6.18.7 搶佔 pc：perf_ioctl+0x34c/0xc68 x20：ffffff89a3fa2c70 x8：6b6b6b6b6b6b6b6b 代碼：943c4a0e 340047a0 f9404a94 f9411e88 （f940b908） 呼叫追蹤：perf_ioctl+0x34c/0xc68 （P） __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 錯誤發生在 perf_ioctl（） 中，其中 perf_event_for_each（） 跟在過時的group_leader指標後面，然後 perf_event_for_each_child（） 取消參照釋放的領導者的上下文。透過將分離的同級提升為單一子來修正釋放後使用。同時修正 __event_disable（） cgroup 帳戶處理和事件狀態變更。（CVE-2026-74637）

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

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

  - mm/page_table_check：跳過以 PageAnon（） 為基礎的特殊零對應 page_table_check_set（） 和 page_table_check_clear（） 帳戶對應。共用零頁 PTE 和巨大的零 PMD 是特殊映射，但page_table_check仍然可以將它們視為檔案備份頁面。無權限的處理程序可以填入足夠的零對應，以溢位file_map_count並命中現有的 BUG_ON（）。PTE 路徑可以使用共用零頁面來執行此操作，而 PMD 路徑可以使用大型零映射執行相同的操作。略過使用者頁面表格帳戶路徑中的特殊零對應。保持 PTE 端 pte_special（） 檢查，並從映射的對開本而不是 pmd_special（） 中識別巨大的零 PMD。這涵蓋了 pmd_special（） 是無操作的架構，而無需將huge_zero_pfn檢查新增至通用計數器協助程式。（CVE-2026-74600）

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

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

  - hwmon：（pmbus） 修正通知邏輯中的類型混淆 Sashiko 報告：在 pmbus_notify（） 中迴圈開始時，程式碼無條件地將每個屬性轉換為結構sensor_device_attribute：
    drivers/hwmon/pmbus/pmbus_core.c：pmbus_notify（） { for （i = 0; i < data->num_attributes; i++） { struct device_attribute *da = to_dev_attr（data->group.attrs[i]）; struct sensor_device_attribute *attr = to_sensor_dev_attr（da）; int index = attr->index; ... }不過，data->group.attrs 可以包含其他類型，例如結構pmbus_samples_reg或結構pmbus_sensor，它們只會內嵌基底結構device_attribute。如果 da 是結構pmbus_samples_reg，則 dev_attr 是最後一個成員。將其轉換為結構sensor_device_attribute並讀取索引欄位似乎會存取超出配置結尾的記憶體，這可能會觸發 slab-out-of-bounds 讀取。此外，如果 da 是結構pmbus_sensor，則轉換它會導致索引欄位與 page、phase 和 reg 欄位重疊。這是否會在 little-endian 系統上產生垃圾遮罩，在警示期間虛假符合目標 reg、頁面和旗標？在 struct pmbus_sensor 和 struct pmbus_label 中使用 struct sensor_device_attr 來修正問題。
    由於這些屬性永遠不會觸發通知，因此請將它們的 attr->index 值設為 -1。使用此值可與布林屬性區分開來，布林屬性會觸發通知，並使用索引欄位對遮罩、頁面和暫存器值進行編碼。（CVE-2026-74711）

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

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

  - thunderbolt：在索引 sw->ports 之前綁定 DROM 雙連結連接埠號 tb_drom_parse_entry_port（） 會在索引 sw->ports[] 之前針對 sw->config.max_port_number 驗證裝置提供的 header->index，但同級欄位 entry->dual_link_port_nr （也是從 DROM 讀取的 6 位元值） 會為相同的陣列編製索引，但沒有此類檢查。惡意或格式錯誤的 Thunderbolt 裝置可設定超出配置的 sw->ports[] （max_port_number + 1 個項目） 的dual_link_port_nr，產生越界tb_port指標，該指標會儲存並在稍後解除參照。拒絕dual_link_port_nr超過 max_port_number 的連接埠項目，該界限已套用至 header->index。（CVE-2026-74585）

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

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

  - sched_ext：先在 scx_cgroup_lock（） 中採用 cgroup_lock（） scx_cgroup_lock（） 寫入鎖定scx_cgroup_ops_rwsem，然後採用 cgroup_lock（），這可以透過 kernfs 鎖死： scx 啟用/停用 cgroup rmdir cpu.weight 寫入 ------------------ ------------ ---------------- cgroup_lock（） percpu_down_write（rwsem） cgroup_lock（） kernfs_get_active（） percpu_down_read（rwsem） kernfs_drain（） 啟用路徑會等待 rmdir 釋放cgroup_mutex。rmdir 停用 CPU 控制器的檔案，會在 kernfs_drain（） 中等待寫入的活動參照。scx_group_set_weight（） 中的寫入會等待擱置寫入器後面的 rwsem。先取 cgroup_lock（）。set_* 路徑在讀取端內不採用 cgroup 鎖定，因此擱置的寫入鎖定只會等待一律執行至完成的讀取區段，並且不會保留從 rwsem 返回 cgroup_mutex 的相依性。（CVE-2026-74593）

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

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

  - vhost-scsi：驗證 T10 PI 散佈清單計數 交涉 PI 時 T10 ，vhost-scsi 會在對應要求散佈清單之前，從資料迭代器分割保護位元組。格式錯誤的要求可能會要求涵蓋或超過完整承載長度的保護位元組。前者不留下任何資料位元組進行映射，而後者在推進迭代器之前exp_data_len下溢。這兩種情況都可以讓零資料 SGL 計數達到 sg_alloc_table_chained（），這會觸發 BUG_ON（！nents）。在減去prot_bytes並推進迭代器之前，拒絕覆蓋或超過承載的保護長度。在呼叫配置器之前，也從保護 SGL 計算傳播負錯誤，以符合資料 SGL 路徑。
    (CVE-2026-74703)

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

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

  - ima：修正 xattr_verify（） 中的越界讀取 xattr_verify（） 中的摘要長度檢查混合了 int 和 size_t：if （xattr_len - sizeof（xattr_value->type） - hash_start >= iint->ima_hash->length） sizeof（） 產生size_t，因此通常的算術轉換會在減法執行之前將整個左側提升為無符號 64 位元。對於被截斷的 xattr 來說，這是下溢而不是負數：一個 1 位元組IMA_XATTR_DIGEST_NG xattr （xattr_len == 1， hash_start == 1） 將 1 - 1 - 1 變成 SIZE_MAX，這很簡單 >= ima_hash-> 長度。然後檢查通過，以下 memcmp（） 讀取從分配給它的緩衝區 vfs_getxattr_alloc（） 末尾開始的 iint->ima_hash->length 位元組。
    沒有任何上游會先將xattr_len限制回安全範圍：ima_get_hash_algo（） 僅特殊情況xattr_len < 2 來選擇預設演算法，而 evm_verifyxattr（） 在未載入 HMAC 金鑰時傳回 INTEGRITY_UNKNOWN 而不是失敗，因此截斷的 security.ima 值會按原樣達到長度檢查。
    重寫比較，讓每個運算元都保持帶正負號的 int，而且不會隱含轉換為 size_t。
    (CVE-2026-74671)

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

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

  - vhost_iotlb：add_range vhost_iotlb_add_range_ctx（） 中的綁定映射分配僅在表具有非零限制、恰好達到該限制並已設定VHOST_IOTLB_FLAG_RETIRE時才會淘汰舊項目。未淘汰的資料表在達到其設定的限制後，仍可繼續配置項目。現有的虛擬主機裝置會使用 vhost.c 的max_iotlb_entries配置其 IOTLB，其預設值為 2048，並可透過模組參數進行調整。在配置點使用呼叫端提供的限制，而不是在通用 IOTLB 協助程式中新增個別的預設值，並拒絕虛擬主機路徑中可報告錯誤的非正值。當可以從使用者空間或客體控制的要求填入項目時，其他虛擬主機 IOTLB 使用者不應建立零限制表格。新增 mlx5 vDPA、VDUSE 和 vhost-vDPA 的呼叫端max_iotlb_entries參數。拒絕非正數 VDUSE 和 vhost-vDPA 值，並要求安裝完整範圍對應的 vdpa_sim 和 mlx5 vDPA 路徑至少有兩個項目，因為這些對應會分割成兩個 IOTLB 項目。
    在插入前半部分之前，檢查 IOTLB 是否可以保留兩個分割項目，以處理通用協助程式中的全範圍對應。這可避免在留下一半對應後傳回錯誤。當表格已滿時，請保留即將淘汰表格的現有淘汰行為，並針對未淘汰表格傳回 -ENOSPC。重複使用已淘汰的對應節點，而不是釋放它並配置替換節點，因此 IOTLB 更新串流無法在資料表達到其限制後繼續強制GFP_ATOMIC配置。
    如果零限制 IOTLB 仍到達通用協助程式，請將其視為設定錯誤，並傳回
    -埃因瓦爾。我自己發現了這個錯誤，儘管該補丁是在 AI 幫助下編寫的。（CVE-2026-74713）

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

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

  - net： tap：在剖析 tap_get_user_xdp（） 中的 virtio net 標頭之前設定 skb->dev） 提交 4f61f133f354 （net： tap：當 skb->dev 為 null 時，dev_parse_header_protocol 中的 NULL 指標解除參照） 透過在呼叫 tun_vnet_hdr_to_skb（） 之前指派 skb->dev 來修正 tap_get_user（） 中的損毀。這是必需的，因為 virtio_net_hdr_to_skb（） 可能會叫用 dev_parse_header_protocol（），這會取消參照 skb->dev。如果沒有指派，可能會發生 NULL 指標解除參照。然而，tap_get_user_xdp（） 在指派 skb->dev 之前仍會剖析 virtio-net 標頭。當虛擬主機 TX 路徑通過包含 GSO virtio-net 標頭的 XDP 緩衝區，但通訊協定故意設定為零時，tun_vnet_hdr_to_skb（） 可以到達 dev_parse_header_protocol（），而 skb->dev 仍為 NULL，從而導致當機。透過在調用 tun_vnet_hdr_to_skb（） 之前查找 tap 設備並分配 skb->dev 來解決此問題，以匹配 tap_get_user（） 中已經使用的順序。保留跨 dev_queue_xmit（） 的現有 RCU 讀取端關鍵區段。
    (CVE-2026-74684)

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

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

  - net/sched： act_ct：修正標頭檢查拒絕封包時的sk_buff洩露 tcf_ct_handle_fragments（） 在將任何內容交給碎片整理引擎之前執行其標頭健全性檢查：if （family == NFPROTO_IPV4） err = tcf_ct_ipv4_is_fragment（skb， &frag）;否則 err = tcf_ct_ipv6_is_fragment（skb， &frag）;
    if （err || ！frag） return err;tcf_ct_ipv4_is_fragment（） 傳回 -EINVAL 或 -ENOMEM;
    當 ipv6_find_hdr（） 失敗時，tcf_ct_ipv6_is_fragment（） 會新增 -EPROTO。它們都不會釋放 skb 或將 skb 排入佇列，因此在該路徑上，呼叫端仍然擁有它。然而，tcf_ct_act（） 會將每個非零返回匯集到所有權轉移出口：err = tcf_ct_handle_fragments（net， skb， family， p->zone， &defrag）;if （err） goto out_frag;...out_frag：if （err ！= -EINPROGRESS） tcf_action_inc_drop_qstats（&c->common）;返回TC_ACT_CONSUMED;TC_ACT_CONSUMED表示動作已取得 skb 的所有權，因此沒有呼叫端釋放它 - sch_handle_ingress（）、sch_handle_egress（） 和 tcf_qevent_handle（） 都會刻意略過該判定的釋放。因此，skb 是孤立的：每個格式錯誤的封包都會洩漏一個sk_buff加上其資料緩衝區，不受限制。請注意，丟棄計數器已針對這些錯誤遞增，因此統計資料會宣告從未發生的丟棄。三種不同的所有權狀態達到out_frag：今天 - skb 可能被碎片整理引擎 （-EINPROGRESS） 排入佇列，已經被 nf_ct_handle_fragments（） 釋放，或者仍然歸我們所有。告訴調用者是哪一個，並在最後一種情況下自行釋放封包，這會恢復修復之前的TC_ACT_SHOT行為：提交。在 v7.2-rc6 上重現，具有 54 位元組的框架，帶有 40 位元組的 IPv6 標頭，nexthdr = 0（逐跳），之後沒有任何內容，在具有操作 ct 的 clsact 輸入鏈上。kmemleak 報告一個洩露的 232 位元組skbuff_head_cache對象及其每個數據包的 704 位元組數據緩衝區;使用此修補程式時，它沒有報告任何內容。(CVE-2026-74621)

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

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

  - hashcat 在剖析還原檔案時無法限制命令列選項，允許攻擊者注入輸出重新導向選項，例如 --outfile--potfile-path和 。攻擊者可以使用惡意選項製作還原檔案，將攻擊者控制的內容附加到任意檔案中，從而在針對殼層啟動檔案時啟用程式碼執行。（CVE-2026-68766）

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

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

  - netfilter： nf_conntrack：將無效記錄推遲到解鎖之後，當 ct->lock 仍保留時，TCP 和 SCTP conntrack 路徑可能會發出無效封包記錄。當無效的日誌記錄路由到nfnetlink_log並啟用 conntrack 匯出時，日誌路徑可以重新輸入 conntrack netlink glue 並再次轉儲相同的 conntrack。通訊協定屬性傾印可能會採用 ct->lock，因此在持有該鎖定時記錄可能會鎖死。
    在保留 ct->lock 時僅儲存最小記錄內容，並在解除鎖定後發出記錄，以延遲 TCP 無效記錄。也使 TCP 逾時降低無效路徑傳回是否需要日誌，然後在解鎖後發出該日誌。對保留 ct->lock 時可存取的 SCTP 無效狀態轉換記錄執行相同的動作。將 lockdep 判斷提示新增至 nf_ct_l4proto_log_invalid（），以便將來在持有 ct->lock 時記錄無效 conntracks 的呼叫者也會在 TCP 和 SCTP 之外被捕獲。（CVE-2026-74624）

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

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

  - net： openvswitch：重新分配不相符 ID 的更新回覆 ovs_flow_cmd_new（） 會在選擇性回覆 skb 需要ovs_mutex之前，在知道將更新哪個現有流程之前，預先配置選擇性回覆 skb。這通常沒問題，因為 skb 的大小是根據請求流識別碼調整的。該識別碼也會成為插入流程的識別碼。不過，針對更新，具有 UFID 的要求可能會遺漏 UFID 查詢，然後回復至流程金鑰查詢。該查詢可以合法地找到現有的金鑰識別流程。
    UFID 是選用的，流程金鑰是主要識別碼。對於回應回覆，ovs_flow_cmd_fill_info（） 會寫入相符流程的識別碼，而不是用於預先配置的要求識別碼。因此，簡短的請求 UFID 可能會為金鑰識別碼留下太小的空間。然後，填充可能會以 -EMSGSIZE 失敗，並命中更新路徑中的BUG_ON（錯誤 < 0）。解決更新目標之後，如果相符的流程需要比允許的要求識別碼更大的回覆，請重新配置回覆 skb。在取代動作之前執行此操作，以便在罕見的額外配置失敗時，請求仍然可以完全失敗。（CVE-2026-74664）

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

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

  - bnxt_en：在所有晶片上停用 TPA 的 EOP 以防止資料損毀 AGG 環上的 EOP （框架結尾填補） 可能會導致一個區段結尾的零填補與下一個區段的資料重疊。如果啟用寬鬆排序 （RO），零填充可能會覆寫下一個區段中的有效資料並損毀資料。較舊的晶片 （P5 和更舊版本） 不會在啟用 EOP 時自動停用 RO。在某些 ARM 系統上，啟用 RO 的 57508 （P5） 晶片上報告資料損毀。啟用 TPA 時，一律停用 AGG 通道上所有晶片上的 EOP 以修正資料損毀。（CVE-2026-74697）

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

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

  - net/smc：修正 smc_llc_event_handler（） 中 CONFIRM_LINK 和 ADD_LINK_CONT 的 qentry 覆寫 smc_llc_event_handler（） 中的 SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT 分支將傳入的 qentry 儲存到本機 LLC 流程中，而無需先檢查 qentry 是否已經處於擱置狀態。如果惡意或有錯誤的對等體在流程處於活動狀態且已設定 flow->qentry 時傳送第二個 CONFIRM_LINK 或 ADD_LINK_CONT 要求，則 smc_llc_flow_qentry_set（） 會覆寫指標而不釋放先前的配置，從而為每則虛假訊息洩漏一個 kmalloc-96 物件。同級SMC_LLC_DELETE_LINK分支已經具有正確的 ！flow->qentry 防護。將相同的保護套用至 CONFIRM_LINK/ADD_LINK_CONT 分支，以便在 qentry 已被佔用時，重複訊息會中斷，並由 out： 標籤的 kfree（qentry） 釋放，而不是無訊息地洩漏現有配置。回應方向 （smc_llc_rx_response（）） 不受影響：它已經在對等站點使用 flow->qentry 進行保護，並正確丟棄重複的回應。（CVE-2026-74719）

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

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

  - eventfs：修正 eventfs_remove_rec（） 中的釋放後使用 eventfs_remove_rec（） 遞迴移除目前迴圈位置的子項。遞迴呼叫傳回後，list_for_each_entry（） 會從已移除的子項讀取 list.next 來前進。如果 free_ei（） 刪除最終參照，則 release_ei（） 會重複使用 list/rcu 聯集將 SRCU 回呼排入佇列。在閱讀之前，孩子可能會被釋放。eventfs_mutex序列化清單更新，但不會讓已移除的子系保持作用中狀態，或防止 SRCU 回呼執行。使用 list_for_each_entry_safe（） 儲存下一個同級，然後再遞迴移除目前的子系。
    (CVE-2026-74606)

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

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

  - bpf， sockmap：修正傳送判定sk_redir釋放後使用 sk_psock_msg_verdict（） 採用 psock->sk_redir 的通訊端參照。tcp_bpf_send_verdict（） 在持有來源通訊端鎖定時複製該指標，但在刪除 tcp_bpf_sendmsg_redir（） 周圍的鎖定之前不會引用本機副本。當 apply_bytes 保持快取的判定處於活動狀態時，相同來源通訊端上的另一個 sendmsg（） 可以消耗剩餘的位元組並釋放快取的參照，而第一個執行緒仍然只保留原始本機指標： CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes 保持非零 release_sock（sk） lock_sock（sk） apply_bytes達到零 psock->sk_redir = NULL release_sock（sk） tcp_bpf_sendmsg_redir（sk_redir） sock_put（sk_redir） tcp_bpf_sendmsg_redir（sk_redir） 最後一個 sock_put（） 可以在 CPU 0 取消參照之前釋放sk_redir。KASAN 報告： 錯誤：KASAN：tcp_bpf_sendmsg_redir+0xf39/0x1020 中的 slab-use-after-free 由任務 poc/87 在 addr ffff888108537090 讀取大小 8 呼叫追蹤：tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 由任務 85 分配：
    sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 由任務 0 釋放：
    __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 上次可能相關的工作建立：__sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 當來源通訊端鎖定仍保護 psock->sk_redir 時，取得一個臨時通訊端參照，並在 tcp_bpf_sendmsg_redir（） 傳回後將其刪除。這會讓每個未鎖定的使用與快取判定擁有權無關。（CVE-2026-74589）

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

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

  - serial： qcom-geni：修正 TX DMA 緩衝區排清 在進行中的 TX DMA 期間傳輸排清 qcom-geni UART 時，UART 會卡住，無限重複損毀的 TX DMA 訊框。DMA 模式uart_ops不提供flush_buffer回調，因此在序列核心重設傳輸 kfifo、下溢其長度並無限期地重新提交頁面大小傳輸後，進行中的傳輸可能會完成。新增一個可停止傳輸並清除tx_remaining和tx_queued。停止路徑也已中斷：當序列引擎仍可讀取緩衝區時，它會取消對應緩衝區，而且永遠不會重設 TX DMA 狀態機器。先取消主排序器命令，然後重設狀態機器並等待它後再取消映射。刪除早期返回，以便在主命令處於非作用中狀態時也清除擱置中的映射。該錯誤可以從使用者空間觸發，並立即進行大量寫入，然後是 TCOFLUSH。下一個 tcdrain 將永遠懸而未決。此錯誤已重現，並使用 /dev/ttyHS1 在 Arduino Uno Q （QRB2210） 上驗證了此修正。（CVE-2026-74655）

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

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

  - btrfs：修正 btrfs_do_encoded_write（） 中的記憶體洩漏 的 6.12.94 本機模糊測試發現下列記憶體洩漏： 未參照的物件0xffff888018050a80 （大小 64）： comm syz.0.17， pid 10297， jiffies 4294953601 十六進位轉儲 （前 32 個位元組）： 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 ................10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................回溯 （CRC A8A6FC29）： kmemleak_alloc_recursive include/linux/kmemleak.h：42 [inline] slab_post_alloc_hook mm/slub.c：4152 [inline] slab_alloc_node mm/slub.c：4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c：4358 kmalloc_noprof include/linux/slab.h：878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h：207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c：4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c：4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c：9746 btrfs_encoded_write fs/btrfs/file.c：1482 [內嵌] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c：1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c：4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c：-1 vfs_ioctl fs/ioctl.c：51 [內嵌] __do_sys_ioctl fs/ioctl.c：906 [內嵌] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c：892 do_syscall_x64 arch/x86/entry/common.c：47 [內嵌] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f 未參照的物件0xffff888018050a00（大小 64）：comm syz.0.17、pid 10297、jiffies 4294953601十六進位轉儲（前 32 個位元組）：00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................回溯 （crc cb5c9580）：kmemleak_alloc_recursive include/linux/kmemleak.h：42 [內聯] slab_post_alloc_hook mm/slub.c：4152 [內聯] slab_alloc_node mm/slub.c：4197 [內聯]
    __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c：4358 kmalloc_noprof include/linux/slab.h：878 [內聯] kzalloc_noprof include/linux/slab.h：1014 [內聯] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c：114 extent_changeset_prealloc fs/btrfs/extent_io.h：217 [內聯] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c：1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c：1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c：4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup。 c：4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c：9746 btrfs_encoded_write fs/btrfs/file.c：1482 [內嵌] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c：1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c：4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c：-1 vfs_ioctl fs/ioctl.c：51 [內嵌] __do_sys_ioctl fs/ioctl.c：906 [內嵌] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c：892 do_syscall_x64arch/x86/entry/common.c：47 [內嵌] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f 在從 btrfs_do_encoded_write（） 返回之前釋放範圍變更集來修正此問題。（CVE-2026-74722）

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

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

  - 之前的 3.10.2 NLTK 版本在 FramenetCorpusReader 中包含符號連結型沙箱繞過，可讓攻擊者讀取語料庫根目錄之外的任意 XML 檔案。攻擊者可以在語料庫子目錄中放置名稱不含路徑分隔符號的符號連結，這些符號連結會通過路徑驗證防護，並在透過 frame_by_name（）、_lu_file（） 或 doc（） 方法存取時解析為預期語料庫根目錄之外的檔案。（CVE-2026-62384）

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

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

  - net： devmem：防止 net-iov / 頁面混合 我們應該在單個 skb 中擁有 net_iov 或頁面支持的片段，否則它會在堆棧中爆炸。不允許在 zerocopy_fill_skb_from_devmem（） 中混合。
    (CVE-2026-74627)

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

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

  - vsock/virtio：讀取背景工作鎖定下的 virtqueues 提交 bd50c5dc182b （vsock/virtio：新增對裝置暫停/繼續的支援） 使 * _run 旗標在 restore 安裝替換 virtqueue 時從 false 轉換為 true。RX、TX 和事件工作者在鎖定和檢查對應的旗標之前會讀取其 virtqueue，因此延遲凍結和還原的工作者可以觀察替換佇列的執行狀態，同時保留指向已刪除佇列的指標。檢查執行旗標後，讀取其互斥下的每個 virtqueue，將指標和狀態保持在同一佇列產生中。（CVE-2026-74614）

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

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

  - vt：穩定 kbd_keycode 中的 tty 參照，其中 tty_port_tty_get kbd_keycode（） 讀取 vc->port.tty 而不取得 tty 參照，與 con_shutdown（） 爭用，後者在不同的鎖定下清除 port.tty。使用 tty_port_tty_get（）/tty_kref_put（） 在需要 tty 指標的持續時間內保留適當的參照。
    (CVE-2026-74675)

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

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

  - USB： atm： cxacru：在 cxacru_cm（） 中出錯時正確終止 rcv_urb 如果 cxacru_cm（） 在提交或等待snd_urb時遇到錯誤，它會中止並傳回錯誤，而不會終止已提交的rcv_urb。這會讓rcv_urb保持作用中狀態。當初始化期間發生這種情況時（例如，在 cxacru_atm_start（） 中），驅動程式可能會忽略錯誤並繼續調用 cxacru_poll_status（），這會再次調用 cxacru_cm（）。嘗試提交仍在活動的rcv_urb會觸發 usb_submit_urb（） 中的警告： cxacru 1-1：1.0：傳送 CM 0x84 失敗 （-104） ATM dev 0：cxacru_atm_start：
    CHIP_ADSL_LINE_START 返回 -104 ------------[ cut here ]------------ URB ffff88812658d200 在活動時提交 警告：drivers/usb/core/urb.c：379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c：379 ... 呼叫追蹤： <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c：631 cxacru_cm_get_array drivers/usb/atm/cxacru.c：722 [內聯] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c：828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c：814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c：927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c：1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c：1370 ... 若要修正此問題，請確保在 cxacru_cm（） 提前中止時正確終止 rcv_urb。我們可以在錯誤路徑中的rcv_urb上安全地呼叫 usb_kill_urb（），因為即使 URB 未處於活動狀態（例如，如果它一開始就未能提交，或者如果它已經完成），調用也是安全的。（CVE-2026-74680）

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

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

  - ALSA： usb-audio：在新增格式類型 II 傳輸分隔符號之前，修正類型 II 傳入 URB 上的 OOB 寫入 data_ep_set_params（） 大小：u->packets = urb_packs;u->buffer_size = maxsize * u->packets;if （fmt->fmt_type == UAC_FORMAT_TYPE_II） u->packets++;/* 用於傳輸分隔符號 */ u->urb = usb_alloc_urb（u->packets， GFP_KERNEL）;buffer_size是根據預先遞增的封包計數計算，而且永遠不會重新計算，因此對於類型 II 端點，緩衝區比 URB 所建置的封包計數少一個封包。然後，prepare_inbound_urb（） 會為每個封包佈置一個 ISO 框架，並且從不查閱buffer_size：
    關閉 = 0;for （i = 0; i < urb_ctx->packets; i++） { urb->iso_frame_desc[i].offset = offs;
    urb->iso_frame_desc[i].length = ep->curpacksize;offs += ep->curpacksize;} urb->transfer_buffer_length = offs;urb->number_of_packets = urb_ctx->packets;因此，最後一個描述元會將一個封包指向傳輸緩衝區的末端，其中主機控制器會在每次傳入傳輸時寫入裝置資料。
    prepare_silent_urb（） 和 prepare_playback_urb（） 透過 ctx->buffer_size 綁定其填充迴圈，因此只有擷取受到影響。fmt_type來自裝置的音訊串流描述元，因此一旦使用者空間在串流上設定hw_params，任何宣傳 Type II 擷取格式的裝置都會命中此格式。7.2.0-rc5 （arm64） 上的 KASAN，搭配 dummy_hcd/raw 小工具裝置，每次傳入傳輸一份報告： 錯誤：KASAN：dummy_timer 中的 slab-out-of-bounds 由任務 cons02/166 在 addr ffff0000186171c0 寫入大小為 64 __asan_memcpy dummy_timer hrtimer_run_softirq 由任務 166 分配：usb_alloc_coherent snd_usb_endpoint_set_params 錯誤位址位於已分配 64 位元組區域右側 0 位元組處 [ffff000018617180， ffff0000186171c0） 在考慮分隔符號封包並buffer_size綁定填充迴圈後計算buffer_size，就像 prepare_silent_urb（） 在出站端所做的那樣。這會將每個類型 II URB 配置增加一個最大大小封包。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74682）

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

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

  - bpf：保留換向算術的指標狀態 在 adjust_ptr_min_max_vals（） 中處理純量 += 指標時，目標暫存器會從來源指標繼承指標狀態。
    僅複製選取的欄位很脆弱，因為指標來源會由數個bpf_reg_state欄位追蹤。使用呼叫端的暫存位移暫存器來保留純量運算元，同時將目的地取代為完整的指標狀態。這會保留PTR_TO_STACK暫存器的框架編號，並保持父項身分欄位的一致性。（CVE-2026-74720）

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

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

  - sctp：如果要移除控制區塊傳輸，則清除它 sctp_make_heartbeat_ack（） 會在 chunk->transport 中快取目的地傳輸，而不進行參照。啟用 src_out_of_asoc_ok 時，HEARTBEAT ACK 可能會在control_chunk_list上保持佇列狀態，而不是立即傳輸。如果在區塊仍排入佇列時移除對等傳輸，則 sctp_assoc_rm_peer（） 會捨棄傳輸並排程以釋放 RCU，但只會清除 out_chunk_list 中快取的傳輸指標。因此，佇列控制區塊會保留懸空傳輸指標。一旦ASCONF_ACK清除隱藏並傳輸佇列的控制區塊，SCTP 就會取消參照過時的傳輸指標，從而導致釋放後使用。在移除傳輸時，也清除 control_chunk_list 中佇列控制區塊的區塊 chunk->transport，以修正此問題。（CVE-2026-74688）

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

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

  - 之前的 3.10.0 NLTK 版本在 FileSystemPathPointer.open（） 中包含邏輯錯誤，其中沙箱驗證檢查會將正規化路徑與自身進行比較，使安全性檢查永久惰性。
    攻擊者可將 file:// URL 傳遞至 nltk.data.load（），以讀取處理程序使用者可存取的任意檔案，包括憑證和設定檔。（CVE-2026-65915）

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

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

  - 之前的 3.10.0 NLTK 版本在 FramenetCorpusReader 和 NKJPCorpusReader 中包含一個路徑遊走弱點，攻擊者可藉由提供不安全的選擇器或中毒的索引狀態來剖析語料庫根目錄之外的 XML 檔案。攻擊者可以利用具有特製參數的 frame_by_name、doc、lu 和標頭方法來讀取應用程式可存取的任意 XML 檔案。（CVE-2026-62385）

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

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

  - ring-buffer：使用 current_context 進行安全的 per-CPU 緩衝區交換 ring_buffer_swap_cpu（） 函式目前會檢查每個 CPU 認可計數器，以判斷在執行交換之前，是否正在主動寫入緩衝區。不過，存在一個可以略過此檢查的爭用視窗：
    ring_buffer_lock_reserve cpu_buffer = 緩衝區>緩衝區[cpu];cpu_buffer_a rb_reserve_next_event rb_start_commit // inc 提交 if （unlikely（READ_ONCE（cpu_buffer->buffer） ！= buffer）） {...}
    __rb_reserve_next rb_move_tail rb_end_commit（cpu_buffer）;dec committing => 0 /* 中斷命中，交換成功！*/ local_inc（&cpu_buffer->committing）;ring_buffer_unlock_commit cpu_buffer = 緩衝區>緩衝區[cpu];cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON（cpu_buffer， ！local_read（&cpu_buffer->committing）） // 觸發警告 在單一寫入作業期間 （rb_move_tail內） 提交計數器可能會暫時降至 0，從而建立一個窗口，即使寫入仍在進行中，交換也可以成功。這會導致緩衝區狀態不一致，並觸發 rb_commit（） 中的RB_WARN_ON。將提交計數器檢查替換為current_context檢查，這些檢查在 ring_buffer_lock_reserve（） 的入口處設定，並在整個寫入操作中保持有效，從而在交換期間提供緩衝區忙碌狀態的可靠指標。(CVE-2026-74601)

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

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

  - vxlan：不要在已關閉的裝置上布防老化計時器 vxlan_changelink（） 每當請求的老化間隔與配置的老化間隔不同時，就會布防 vxlan->age_timer：if （conf.age_interval ！= vxlan->cfg.age_interval） mod_timer（&vxlan->age_timer， jiffies）;沒有 netif_running（） 測試，因此即使在從未啟動的裝置上，計時器也會布防。驅動程式中唯一的同步取消是 vxlan_stop（） 中的 timer_delete_sync（），這是 .ndo_stop。在 __dev_close_many（） 執行之前，netif_close_many（） 會在不IFF_UP的情況下捨棄裝置，因此會跳過此類裝置的取消。vxlan_setup（） 設定 dev->needs_free_netdev = true，並且 age_timer 是 struct vxlan_dev 的成員，因此 free_netdev（） 會在計時器仍在 timer_base 上排隊時釋放計時器所在的分配。expire_timers（） 在載入 timer->function 之前取消連結項目，因此計時器核心會透過釋放物件的清單指標寫入： 錯誤：
    KASAN：__run_timers+0x208/0x654 中的 slab-use-after-free 透過任務 true/192 在 addr ffff00001adace68 寫入大小 8 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c 由任務 189 分配：alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 由任務 191 釋放：
    netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 所涉及的 rtnl 作業是 netns 範圍，因此無特權的使用者可以在新的使用者和網路命名空間中執行這些作業。在關閉的裝置上布防計時器從未產生任何效果：vxlan_cleanup（） 在 ！netif_running（） 上提前返回，而 vxlan_open（） 會在裝置啟動後為任何非零間隔布防計時器。新增遺漏的測試。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74615）

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

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

  - 之前的 3.9.4 NLTK 版本在 CorpusReader.open（） 中包含一個符號連結逸出弱點，允許本機攻擊者讀取語料庫根目錄之外的任意檔案。存在此弱點的原因是路徑驗證是詞彙，不會考慮符號連結解析，因此攻擊者能夠將符號連結放在語料庫根目錄內，以存取預期邊界之外的檔案。（CVE-2026-70626）

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

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

  - inet： frags：在布防計時器之前發布佇列 inet_frag_create（） 在將佇列插入 FQDIR rhashtable 之前，先布防片段佇列計時器。如果命名空間片段逾時為零或負數，則計時器可以在佇列發佈之前執行。然後，計時器回呼會將佇列標記為完成，嘗試移除尚未在雜湊表中的節點，並捨棄預期的雜湊參照。建立隨後可以發佈已完成的佇列，而不還原該參照，在呼叫端捨棄剩餘參照之後，留下過時的雜湊節點。先發佈佇列，並在保持佇列鎖定的同時布防計時器。這使得計時器到期等待佇列在雜湊表中可見，因此 inet_frag_kill（） 可以移除節點並平衡雜湊參照。（CVE-2026-74662）

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

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

  - vt：新增 KDSKBMETA ioctl 的權限檢查 KDSKBMETA 修改鍵盤中繼模式，但缺少 vt_k_ioctl（） 中所有其他鍵盤設定器 ioctl 強制執行的 ！perm 檢查，允許處理程序在未經授權的情況下在非控制主控台上變更中繼模式。（CVE-2026-74676）

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

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

  - NFS：在FREE_STATEID通話期間固定「結構nfs_server」Dan Aloni 報告說，如果 FREE_STATEID 操作因某種原因延遲，他能夠遇到釋放後使用錯誤。透過在FREE_STATEID期間增加「struct nfs_server」物件的參照計數來解決此問題，這樣當操作仍在進行時，它就不會從我們下面清除。（CVE-2026-74730）

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

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

  - sched/psi：psi_cgroup_free（） 中的關閉rtpoll_timer psi_schedule_rtpoll_work（） 從排程器熱路徑無鎖定調用，並且可以爭用 psi_trigger_destroy（） 關閉 rtpoll_trigger_lock 下的最後一個 rtpoll 觸發器：psi_schedule_rtpoll_work（） psi_trigger_destroy（） rcu_read_lock（）;任務 = rcu_dereference（rtpoll_task）;rcu_assign_pointer（rtpoll_task，空）;timer_delete（&rtpoll_timer）;
    mod_timer（&rtpoll_timer， ...）;rcu_read_unlock（）;synchronize_rcu（）;kthread_stop（task_to_destroy）;然後可以在重新布防的計時器仍處於擱置狀態的情況下釋放群組，並且 poll_timer_fn（） 在釋放的記憶體上運行。
    461DABA06BDC（PSI：消除 PSI 觸發調度機制中的kthread_worker）在 synchronize_rcu（） 之後同步刪除了計時器，這阻止了這種情況，但觸發器創建卻發生了爭用：刪除可能會取消新觸發器集在寬限期內布防的計時器，並且由於創建還重新初始化了當時的計時器，因此會損壞它。8f91efd870ea （psi：修正 psi_trigger_create/destroy 之間的爭用） 將初始化移至 group_init（） 中，並將刪除移至鎖定區段，以上方視窗換取建立爭用。在破壞路徑中放置的兩個位置都無效。
    不過，在團隊還活著時觸發的待定計時器是無害的。poll_timer_fn（） 只會喚醒 rtpoll 等候佇列，不會自行重新布防。改為將計時器繫結至群組的存留期，並在 psi_cgroup_free（） 中將其關閉。到那時，沒有什麼可以武裝它了。timer_shutdown_sync（），因為計時器永遠不會再布防。(CVE-2026-74594)

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

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

  - mac802154：修正信標工作程式中的 netdev 釋放後使用 mac802154_beacon_worker（） 讀取 RCU 下的 local->beacon_req 並從請求衍生子介面，但隨後刪除 RCU 讀取鎖定並繼續使用 sdata 和內嵌wpan_dev。 mac802154_stop_beacons_locked（） 僅取消擱置的信標工作、清除 local->beacon_req 並釋放請求。因此，已執行中的信標工作程式可以在介面拆卸後繼續，並取消參照已釋放的 netdev 專用區域。掃描工作程式在離開 RCU 之前已經釘選了 netdev。將相同的存留期規則套用至信標工作程式：當要求仍受 RCU 保護時，取得 netdev 參照，並在取得參照後繼續的所有路徑上釋放它。（CVE-2026-74661）

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

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

  - mm/filemap：__filemap_add_folio（） 在重試前還原索引 在 __filemap_add_folio（） 的衝突分割迴圈中，重複套用 xas_set_order（）：每個應用程式都會修改 xas.xa_index，並根據該階段嘗試的split_order向下捨入：如果一切按預期進行，它最終（或立即）會在 xas_try_split（） 上收斂到所需的folio_order， 現在xas.xa_index與 index 相同：然後 xas_store（） 將新的作品集放入那裡的 xarray 中。但是，如果需要一個新節點，而GFP_NOWAIT分配沒有獲得一個節點，則會刪除鎖定，使用 xas_nomem（） 進行配置，並重試序列。如果 （該部分） 在重新取得鎖定時 xarray 保持不變，則沒問題。但是，如果衝突同時由另一個線程解決（甚至可能做同樣的事情，在同一索引中插入對開本）怎麼辦？現在將我們的作品集以中間捨入索引放入 xarray 中沒有危險嗎？接下來是 ！folio_contains（） 錯誤，當 CONFIG_DEBUG_VM=y 正在檢查時。使用 xas_set_order（） 修正此問題，以還原迴圈底部的原始xas.xa_index，因此重試會在重新取得鎖定後進行完整的重新評估，並且無法使用錯誤的索引來存取 xas_store（）。生產受到罕見的 SIGILL 和 SIGSEGV 的困擾，可執行文本發現離它所屬位置的頁面很遠，啟用偵錯時 ！folio_contains（） 錯誤發生：自從此修補程式進入以來就沒有出現症狀。（CVE-2026-74591）

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

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

  - samples/damon/mtier：零配額目標值出錯 修補程式系列 mm/damon：避免從 damos_quota_score（） 除以零。DAMON_SAMPLE_MTIER和DAMON_LRU_SORT允許使用者在 damos_quota_score（） 中觸發除以零。透過新增參數驗證檢查來避免這種情況。此修補程式（共 2 個）：
    如果target_value為零，damos_quota_score（） 可以觸發除以零。DAMON_SAMPLE_MTIER允許使用者透過 node0_mem_{used，free}_bp 參數設定target_value。不過，它不保護零值情況。因此，用戶可以觸發除以零。當使用者嘗試以零 node0_mem_{used，free}_bp 參數值啟動 DAMON 時，傳回錯誤來修正此問題。DAMON_SAMPLE_MTIER只是一個範例模組，但後果卻相當糟糕。此外，零node0_mem_free_bp參數對某些用戶來說可能看起來像是一個合理的設置。因此，這個問題可能真的發生在現實世界中。重現此問題的一種可靠方法如下所示： # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y >啟用 # dmesg -w [...][18792.235916] 哎呀：除法錯誤：0000 [#1] SMP NOPTI [...][18792.242787] RIP：0010：damos_quota_score+0x6f/0x480 [...]這個問題是由 Sashiko 發現的 [1]。（CVE-2026-74643）

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

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

  - ALSA： FCP：修正 fcp_meter_ctl_get（） 中的 OOB 寫入 fcp_ioctl_set_meter_map（） 如果 （map.map_size < 1 || map.map_size > 255 || map.meter_slots < 1 || map.meter_slots > 255） return -EINVAL;並將其作為控制項的通道計數傳遞給 fcp_add_new_ctl（），並儲存為 elem->channels。每個控制項讀取都會寫入結構snd_ctl_elem_value，其整數陣列宣告為長值[128]，因此限制為 128，而不是 255。
    fcp_meter_ctl_get（） 將每個通道一個 64 位元字儲存到該陣列中，沒有自己的邊界： for （i = 0; i < elem->channels; i++） { int idx = private->meter_level_map[i]; int value = idx < 0 ？ 0 ：
    le32_to_cpu（resp[idx]）;ucontrol->value.integer.value[i] = 值;} snd_ctl_elem_read_user（） 為 kmalloc-2048 中的 1224 位元組 LP64 的 memdup_user（_control， sizeof（*control）） 提供該物件。
    offsetof（struct snd_ctl_elem_value， value） 為 72，因此元素 i 寫入位元組 72 + 8 * i，而元素 144 已經超過了分配。在map_size 255 處，最後一個儲存區在位元組 2112 結束，即物件過去的 888 位元組，進入相鄰的 slab 物件的 64 位元組。儲存的單字來自裝置，並 meter_level_map[] 選取哪個單字落在哪個插槽中，因此範圍和內容都會受到控制。核心沒有抓住這一點。snd_ctl_check_elem_info（） 只能從 __snd_ctl_elem_info（） 到達，snd_ctl_elem_read（） 在 CONFIG_SND_CTL_DEBUG 下呼叫;如果沒有該選項，snd_ctl_skip_validation（） 就是編譯時 true。__snd_ctl_add_replace（） 驗證 kcontrol->count，並且從不檢查 elem->channels。
    安裝過大的對應需要CAP_SYS_RAWIO，但控制項的有效期超過建立它的 hwdep 描述元，因此越界存放區是由任何能夠讀取 /dev/snd/controlC0 上控制項的處理程序發出。7.2.0-rc5 （arm64） 上的 KASAN，由無權限的控制項觸發讀取： 錯誤：KASAN：
    任務 fcp_trigger/185 在 addr ffff000017af04c8 處寫入大小為 8 的 fcp_meter_ctl_get 中的 slab-out-of-bounds
    __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl 由作業 185 分配： memdup_user snd_ctl_ioctl 有錯誤的位址位於已配置的 1224 位元組區域右側 0 位元組 [ffff000017af0000， ffff000017af04c8） 以 ABI 限制而不是 255 綁定映射大小，並在接收器處綁定存儲迴圈，使其無法通過 elem->channels 所保留的值陣列。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-74640）

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

ID	名稱	嚴重性
339014	Linux Distros 未修補弱點：CVE-2026-71514	low
339013	Linux Distros 未修補弱點：CVE-2026-74587	critical
339012	Linux Distros 未修補弱點：CVE-2026-66393	high
339011	Linux Distros 未修補弱點：CVE-2026-74629	high
339010	Linux Distros 未修補弱點：CVE-2026-74659	medium
339009	Linux Distros 未修補弱點：CVE-2026-74609	high
339008	Linux Distros 未修補弱點：CVE-2026-71513	high
339007	Linux Distros 未修補弱點：CVE-2026-74595	high
339006	Linux Distros 未修補弱點：CVE-2026-74617	critical
339005	Linux Distros 未修補弱點：CVE-2026-74726	high
339004	Linux Distros 未修補弱點：CVE-2026-74637	high
339003	Linux Distros 未修補弱點：CVE-2026-74600	medium
339001	Linux Distros 未修補弱點：CVE-2026-74711	high
339000	Linux Distros 未修補弱點：CVE-2026-74585	high
338999	Linux Distros 未修補弱點：CVE-2026-74593	high
338998	Linux Distros 未修補弱點：CVE-2026-74703	high
338997	Linux Distros 未修補弱點：CVE-2026-74671	high
338996	Linux Distros 未修補弱點：CVE-2026-74713	high
338995	Linux Distros 未修補弱點：CVE-2026-74684	high
338994	Linux Distros 未修補弱點：CVE-2026-74621	high
338993	Linux Distros 未修補弱點：CVE-2026-68766	high
338992	Linux Distros 未修補弱點：CVE-2026-74624	high
338991	Linux Distros 未修補弱點：CVE-2026-74664	high
338990	Linux Distros 未修補弱點：CVE-2026-74697	high
338989	Linux Distros 未修補弱點：CVE-2026-74719	high
338988	Linux Distros 未修補弱點：CVE-2026-74606	high
338987	Linux Distros 未修補弱點：CVE-2026-74589	high
338986	Linux Distros 未修補弱點：CVE-2026-74655	high
338985	Linux Distros 未修補弱點：CVE-2026-74722	medium
338984	Linux Distros 未修補弱點：CVE-2026-62384	high
338983	Linux Distros 未修補弱點：CVE-2026-74627	high
338982	Linux Distros 未修補弱點：CVE-2026-74614	high
338981	Linux Distros 未修補弱點：CVE-2026-74675	high
338980	Linux Distros 未修補弱點：CVE-2026-74680	medium
338979	Linux Distros 未修補弱點：CVE-2026-74682	high
338978	Linux Distros 未修補弱點：CVE-2026-74720	high
338977	Linux Distros 未修補弱點：CVE-2026-74688	critical
338976	Linux Distros 未修補弱點：CVE-2026-65915	high
338975	Linux Distros 未修補弱點：CVE-2026-62385	high
338974	Linux Distros 未修補弱點：CVE-2026-74601	high
338973	Linux Distros 未修補弱點：CVE-2026-74615	high
338972	Linux Distros 未修補弱點：CVE-2026-70626	high
338971	Linux Distros 未修補弱點：CVE-2026-74662	critical
338970	Linux Distros 未修補弱點：CVE-2026-74676	high
338969	Linux Distros 未修補弱點：CVE-2026-74730	critical
338968	Linux Distros 未修補弱點：CVE-2026-74594	high
338967	Linux Distros 未修補弱點：CVE-2026-74661	high
338966	Linux Distros 未修補弱點：CVE-2026-74591	critical
338965	Linux Distros 未修補弱點：CVE-2026-74643	medium
338964	Linux Distros 未修補弱點：CVE-2026-74640	high

偵測

Nessus 的 Misc. 系列

low

critical

high

high

medium

high

high

high

critical

high

high

medium

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

medium

high

high

high

high

medium

high

high

critical

high

high

high

high

high

critical

high

critical

high

high

critical

medium

high