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

  - bpf：目前，不允許刪除 NMI 中的本機儲存體，透過 NMI 中的 kfree_rcu（）、call_rcu（） 或 call_rcu_tasks_trace（） 延遲釋放 selem 或本機儲存體時，本機儲存體可能會鎖死。由於在 NMI 中刪除 selem 不太可能是使用案例，因此從 NMI 中的 bpf_xxx_storage_delete（） 協助程式呼叫時傳回錯誤來部分緩解它。請注意，仍有可能透過重入程式造成鎖死。完整的緩解措施需要在 irqs_disabled（） 為 true 時傳回錯誤，但這對於 bpf_xxx_storage_delete（） 來說太嚴厲了。長期解決方案需要_nolock版本的call_rcu。另一個可能的解決方案是將釋放延遲到 irq_work [0]，但它會增加 selem 的大小，這是不理想的。只有在協助程式和系統調用使用的 bpf_selem_unlink（） 中才需要檢查。bpf_selem_unlink_nofail（） 很好，因為它是在映射和所有者拆卸期間調用的，永遠不會在 NMI 中運行或重入。[0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/(CVE-2026-53106）

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

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

  - f2fs：修正因錯誤使用 nat_entry 旗標而導致的資料遺失 在檢查點作業同時對新建立的檔案執行 fsync 時 （在寫入任何檢查點之前） 時，可能會發生資料遺失。
    場景如下： 建立 &; 寫入 &; fsync '檔案 A' 寫入檢查點 - f2fs_do_sync_file // 內嵌 inode - f2fs_write_inode // inode 對開本已變更 - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // 沒有變更節點 - f2fs_need_inode_block_update // 傳回 false SPO 並遺失「檔案 A」 f2fs_flush_nat_entries（） 會設定 IS_CHECKPOINTED 和 HAS_LAST_FSYNC 旗標nat_entry，但這並不表示檢查點實際上已成功完成。但是，f2fs_need_inode_block_update（） 會檢查這些標誌，並錯誤地假設檢查點已完成。根本原因是只有在檢查點寫入完全完成後，才能保證IS_CHECKPOINTED和HAS_LAST_FSYNC的語意。此修補程式會修改 f2fs_need_inode_block_update（） 以在讀取 nat_entry 旗標之前取得 sbi->node_write 鎖定，確保一旦觀察到設定了 IS_CHECKPOINTED 和 HAS_LAST_FSYNC，檢查點作業就已經完成。（CVE-2026-53017）

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

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

  - bpf， sockmap：修正當 lock_sock_fast（） 採用快速路徑且 iter 程序嘗試更新 sockmap 時，af_unix iter 鎖死 bpf_iter_unix_seq_show（） 可能會鎖死的問題。最終會在 sock_map_update_elem（） 的 bh_lock_sock（） 處旋轉： 警告：偵測到可能的遞迴鎖定 test_progs/1393 正在嘗試取得鎖定：ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}， at： sock_map_update_elem+0xdb/0x1f0但任務已持有鎖定： ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}，位於：
    __lock_sock_fast+0x37/0xe0其他資訊，可協助我們偵錯此問題： 可能的不安全鎖定案例：
    CPU0 ----鎖定（slock-AF_UNIX）;lock（slock-AF_UNIX）;鎖死 *** 可能是因為缺少鎖定巢狀標記法 test_progs/1393 持有的 4 個鎖定： #0： ffff88814b59c790 （&p->lock）{+.+.}-{4:4}，位於：
    bpf_seq_read+0x59/0x10d0 #1：ffff88811ec25fd8 （sk_lock-AF_UNIX）{+.+.}-{0:0}， at： bpf_seq_read+0x42c/0x10d0 #2： ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}， at： __lock_sock_fast+0x37/0xe0 #3： ffffffff85a6a7c0 （rcu_read_lock）{....}-{1:3}， at： bpf_iter_run_prog+0x51d/0xb00 呼叫追蹤：dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0
    _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-53035）

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

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

  - 配額：修正 dquot_scan_active（） 與配額停用的爭用 dquot_scan_active（） 可以與 quota_release_workfn（） 中的配額停用爭用，例如：CPU0 （quota_release_workfn） CPU1 （dquot_scan_active） ============================== ============================== spin_lock（&dq_list_lock）;list_replace_init（&releasing_dquots， &rls_head）;/* dquot X on rls_head，dq_count == 0，DQ_ACTIVE_B仍設定 */ spin_unlock（&dq_list_lock）;synchronize_srcu（&dquot_srcu）;spin_lock（&dq_list_lock）;
    list_for_each_entry（dquot， &inuse_list， dq_inuse） { /* 尋找 dquot X */ dquot_active（X） -> true atomic_inc（&X->dq_count）; } spin_unlock（&dq_list_lock）;spin_lock（&dq_list_lock）;dquot = list_first_entry（&rls_head）;WARN_ON_ONCE（atomic_read（&dquot->dq_count））;問題不僅僅是表面問題，因為在記憶體壓力下，dquot_scan_active（） 的呼叫者最終可能會處理釋放的 dquot。
    透過確保在我們取得對 dquot 的引用時從發布清單中刪除來解決問題。
    (CVE-2026-53050)

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

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

  - wifi：rtlwifi：pci：修正可能由未完成的irq_prepare_bcn_tasklet引起的釋放後使用 irq_prepare_bcn_tasklet 在 rtl_pci_init（） 中初始化RTL_IMR_BCNINT並在硬體觸發中斷時進行排程。但它永遠不會在 rtl_pci_deinit（） 中被終止。當 rtlwifi 卡探查失敗或正在分離時，ieee80211_hw會解除配置。但是，irq_prepare_bcn_tasklet可能仍在執行或擱置中，ieee80211_hw導致在
    _rtl_pci_prepare_bcn_tasklet（）。與irq_tasklet類似，在rtl_pci_deinit（）中新增tasklet_kill（），以確保在ieee80211_hw釋放之前正確終止irq_prepare_bcn_tasklet。該問題是透過靜態分析發現的。（CVE-2026-53112）

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

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

  - netfilter： nf_tables：在提交階段透過 splice_list_rcu（） 加入鉤子清單 使用 splice_list_rcu（） 將清單中的新鉤子發佈到基鏈/流程表中，以確保在並行規則集更新進行時透過 rcu 進行網路連結轉儲清單遊走是安全的。（CVE-2026-52988）

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

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

  - bpf：修正 pcpu_init_value 中的 OOB 將元素從BPF_MAP_TYPE_CGROUP_STORAGE映射複製到具有相同value_size且未四捨五入為 8 位元組的另一個 pcpu 映射時，會發生越界讀取。此問題發生在以下情況： 1. 建立value_size未對齊 8 位元組 （例如 4 位元組） 的CGROUP_STORAGE對應 2.使用相同的value_size（例如 4 位元組）建立 pcpu 映射 3.Update 元素 in 2 with data in 1 pcpu_init_value 假設所有來源都四捨五入為 8 位元組，並呼叫 copy_map_value_long 來製作資料副本，但是，這個假設並不成立，因為在某些情況下來源可能不會四捨五入到 8 位元組，例如，CGROUP_STORAGE、 skb->data。驗證程式會精確驗證來源宣告的大小，而不是核心四捨五入為 8 位元組的大小，當來源只有 4 個位元組，而複本大小 （4） 四捨五入為 8 時，就會發生 OOB。（CVE-2026-53076）

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

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

  - nexthop：修正參照 IPv4 nexthop 的 IPv6 路由，syzbot 報告錯誤 [1] [2]。當 IPv6 下一躍點替換為 IPv4 下一躍點時，不會更新包含此下一躍點的所有群組的has_v4旗標。這是因為只有在將AF_INET替換為AF_INET6時才呼叫nh_group_v4_update，但遺漏了相反的方向（AF_INET6到AF_INET）。這允許過時的 has_v4=false 繞過fib6_check_nexthop，導致 IPv6 路由附加至實際上僅包含AF_INET成員的群組。後續路由查詢接著會呼叫 nexthop_fib6_nh（），該  會傳回 AF_INET 成員的 NULL，導致 NULL 指標解除參照。每當家庭發生變化時，請致電nh_group_v4_update來修復，而不僅僅是AF_INET AF_INET6。
    Reproducer： # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # 替換為 AF_INET （no -6），has_v4保持 false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001：db8：：/64 nhid 100 # panic ping -6 2001：db8：：1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3 （CVE-2026-53012）

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

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

  - dm 快取原則 smq：修正快取區塊失效時遺失的鎖定 在直通模式下，原則invalidate_mapping作業會同時從多個工作節點呼叫，因此應該受到鎖定的保護。否則，我們最終可能會在分配的區塊計數器上出現資料爭用，甚至在執行並發寫入時內部資料結構出現釋放後使用問題。請注意，smq_invalidate_mapping（） 中現有的 FIXME 不會影響直通模式，因為那裡不存在遷移任務，但如果支援透過暫停/恢復而不需要重新載入目標的快速裝置縮小，則需要注意。
    重現步驟： 1. 建立由 1024 個快取項目組成的快取裝置 dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig
    --table 0 262144線性 /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 建立快取 --table 0 262144快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2.填入快取，並記錄快取區塊的數量 fio
    --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, /); print a[1]}'） 3.將快取重新載入直通模式 dmsetup 暫停快取 dmsetup 重新載入快取 --table 0 262144 快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 直通 smq 0 dmsetup 恢復快取 4.寫入直通快取。藉由設定多個 I/O 大小等於快取區塊大小的工作，則不同工作者會同時使快取區塊失效。fio --filename=/dev/mapper/cache --name=test
    --rw=randwrite --bs=64k \ --direct=1 =2 --numjobs--randrepeat=0 --size=64m 5.檢查降級是否符合快取的區塊計數。這些數字應該相符，但可能會因為資料爭用而有所不同。nr_demoted=$(dmsetup status cache | awk '{print $12}') echo $nr_cached， $nr_demoted （CVE-2026-53062）

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

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

  - bpf：先拒絕 bpf_prog_test_run_skb bpf_prog_test_run_skb（） 呼叫 eth_type_trans（） 中的短 IPv4/IPv6 輸入，然後使用 skb->protocol 初始化 sk 系列和位址欄位以進行測試執行。對於 IPv4 和 IPv6 封包，即使提供的測試輸入僅包含乙太網路標頭，它也可以存取 ip_hdr（skb） 或 ipv6_hdr（skb）。如果乙太網路框架攜帶 IPv4/IPv6 EtherType，但 L3 標頭太短，請儘早拒絕輸入。將 IPv4/IPv6 標頭長度檢查折入現有的通訊協定交換器，並在存取網路標頭之前傳回 -EINVAL。（CVE-2026-53074）

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

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

  - KVM：s390：pci：透過手動將索引乘以 sizeof（struct zpci_gaite），修正由於雙重縮放指標算術 kvm_s390_pci_aif_enable（）、kvm_s390_pci_aif_disable（） 和 aen_host_forward（） 而導致的 GAIT 表格索引。由於 aift->gait 已經是一個結構zpci_gaite指標，因此這會加倍縮放偏移量，存取元素 aisb*16 而不是 aisb。當 aisb >= 32 （ZPCI_NR_DEVICES=512） 時，這會導致越界存取 透過移除錯誤的乘法大小來修正。（CVE-2026-52968）

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

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

  - net/rds：將 RDS/IB 的使用限制在初始網路命名空間 防止在初始命名空間以外的網路命名空間中使用 RDS/IB。現有的 RDS/IB 程式碼將無法在非初始網路命名空間中正常運作。（CVE-2026-53077）

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

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

  - Rclone 是一種命令行程式，可在不同的雲端儲存空間供應商之間同步檔案和目錄。From 1.46.0 until 1.74.3， rclone rcd --rc-serve 接受對以下格式為 /[remote：path]/object 的路徑的未經驗證的 GET 和 HEAD 要求。遠端值可透過 URL 進行剖析，並傳遞至一般後端初始化。內嵌遠端設定可以設定後端選項，用於在初始化期間執行本機命令。因此，單一未經驗證的 GET 或 HEAD 要求可以以 rclone 處理程序使用者身分執行命令。此弱點已在 1.74.3 中修正。(CVE-2026-49980)

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

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

  - dm 快取：在直通模式下透過並行寫入修正 null-deref 在直通模式下，當 dm-cache 開始使快取項目失效，並且 bio 監獄牢房鎖定因並行寫入相同的快取區塊而失敗時，mg->cell 仍為 NULL。invalidate_complete（） 中的錯誤路徑嘗試無條件地解鎖和釋放儲存格，導致 NULL 指標解除參照： KASAN：範圍 [0x0000000000000000-0x0000000000000007] 內的 null-ptr-deref] CPU：0 UID：0 PID：134 Comm：fio 未受污染 6.19.0-rc7 #3 搶佔 RIP：0010：dm_cell_unlock_v2+0x3f/0x210 <snip> 呼叫追蹤：invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0
    __submit_bio+0x419/0x870 <snip> 重現步驟： 1. 建立快取裝置 dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig
    --table 0 262144線性 /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 建立快取 --table 0 262144快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2.將第一個資料區塊升級到快取中 fio --filename=/dev/mapper/cache
    --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3.將快取重新載入直通模式 dmsetup 暫停快取 dmsetup 重新載入快取 --table 0 262144 快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 直通 smq 0 dmsetup 恢復快取 4.同時寫入第一個快取區塊 fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0
    --direct=1 --numjobs=2 --size 64k 透過在嘗試解鎖之前檢查 mg->cell 是否有效來修復它。
    (CVE-2026-53064)

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

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

  - fs/ntfs3：修正 attr_data_get_block_locked（） 中 vcn0 缺少的執行負載 當壓縮或疏鬆屬性的叢集以框架對齊時，vcn 會使用 cmask 向下捨入至框架開始，這可能會導致 vcn ！= vcn0。在此情況下，vcn 和 vcn0 可能位於不同的屬性區段中。程式碼已透過在配置前載入 vcn 的執行來處理 vcn 位於不同區段的情況。
    但是，當 vcn0 位於與 vcn 不同的區段中時，它無法載入 vcn0 的執行。這會導致 run_lookup_entry（） 傳回 vcn0 的SPARSE_LCN，因為它的區段從未載入到記憶體中的執行清單中，從而觸發 WARN_ON（1）。在現有 vcn 區段檢查之後新增 vcn0 的遺漏檢查，以修正此問題。如果 vcn0 超出目前區段範圍 [svcn， evcn1]，請在執行執行查閱之前，尋找並載入包含 vcn0 的屬性區段。下列案例會觸發錯誤：
    attr_data_get_block_locked（） vcn = vcn0 &; cmask <- vcn ！= vcn0，在針對 VCN 區段執行框架對齊載入之後 <- 未載入 vcn0 區段！attr_allocate_clusters（） <- 分配成功 run_lookup_entry（vcn0） <- vcn0 not in run -> SPARSE_LCN WARN_ON（1） <- 此處觸發錯誤！（CVE-2026-53027）

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

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

  - fs/adfs：驗證 adfs_validate_bblk（） 中的 nzones：在啟動區塊驗證期間，在使用磁碟記錄之前，拒絕區域計數為零的 ADFS 磁碟記錄。當 nzones 為 0 時，adfs_read_map（） 將其傳遞給傳回 ZERO_SIZE_PTR 的 kmalloc_array（0， ...），然後 adfs_map_layout（） 寫入 dm[-1]，在分配的緩衝區之前造成越界寫入。adfs_validate_dr0（） 已經拒絕舊格式影像的 nzones ！= 1。針對新格式影像的 adfs_validate_bblk（） 新增對等檢查，以便在探測時拒絕具有 nzones == 0 的特製影像。由 syzkaller 發現。（CVE-2026-52992）

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

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

  - net：usb：rtl8150：修正 rtl8150_start_xmit（） 中的釋放後使用 在呼叫 usb_submit_urb（） 後存取 skb->len 用於 tx 統計資料時，syzbot 報告 rtl8150_start_xmit（） 中的 KASAN slab-use-after-free 讀取： 錯誤：KASAN：rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c：712 在 addr ffff88810eb7a930 處讀取大小 4 由任務 kworker/0:4/5226 URB 完成處理常式 write_bulk_callback（） 透過 dev_kfree_skb_irq（dev->tx_ 釋放 skbskb）。在提交者返回 usb_submit_urb（） 之前，URB 可能會在 softirq 上下文中的另一個 CPU 上完成，因此當提交者讀取 skb->len 時，skb 已經排入 per-CPU completion_queue並被 net_tx_action（） 釋放： CPU A （xmit） CPU B （USB completion softirq） ------------ ------------------------------ dev->tx_skb = skb;usb_submit_urb（） --+ |-------> write_bulk_callback（） |dev_kfree_skb_irq（dev->tx_skb） |net_tx_action（） |napi_skb_cache_put（） <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len 之前提交 URB，並在更新 tx_bytes 計數器時使用快取的值。保留預先存在的 tx_bytes 語意：計數器會追蹤原始影格長度 （skb->len），而不是傳遞給裝置的 ETH_ZLEN/USB 對齊填充計數值。變更該變更將是使用者可見的會計變更，而且超出此 UAF 修正的範圍。（CVE-2026-52982）

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

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

  - fs/fcntl：修正 fasync 訊號中的 SOFTIRQ-unsafe 鎖定順序 當處理程序群組收到訊號時，send_sigio（） 和 send_sigurg（） 中可能會發生 SOFTIRQ-safe 至 SOFTIRQ-unsafe 鎖定順序鎖死。為處理程序群組 （PIDTYPE_PGID） 設定 FASYNC 時，這兩個函式都會使用 read_lock（&tasklist_lock） 來周遊任務清單。但是，它們經常從 softirq 上下文調用： - send_sigio（） 透過 input_inject_event -> kill_fasync - send_sigurg（） 透過 tcp_check_urg -> sk_send_sigurg （NET_RX_SOFTIRQ） 鎖死是由 rwlock 寫入器公平機制引起的： 1. CPU 0 （進程上下文） 在 do_wait（） 中保存 read_lock（&tasklist_lock）。2. CPU 1（進程上下文）嘗試在 fork（） 或 exit（） 中write_lock（&tasklist_lock）並旋轉，這會阻止所有新的讀取器。3. CPU 0 被 softirq 中斷（例如 TCP URG 封包接收）。4. softirq 調用 send_sigurg（） 並嘗試獲取 read_lock（&tasklist_lock），但由於 CPU 1 正在等待而鎖死。由於 PID 雜湊和 do_each_pid_task（） 周遊已經受到 RCU 保護，因此安全周遊不再嚴格要求 tasklist_lock 上的read_lock。透過將 tasklist_lock 替換為 rcu_read_lock（），將進程群組訊號路徑與單一 PID 路徑對齊來解決此問題。這也可減輕透過 TCP URG 封包的潛在遠端拒絕服務媒介。Lockdep splat：===================================================== 警告：
    SOFTIRQ-safe -> 檢測到 SOFTIRQ-不安全的鎖定順序 [...]鏈存在於： &dev->event_lock --> &f_owner->lock --> tasklist_lock 可能中斷不安全鎖定場景： CPU0 CPU1 ---- ---- lock（tasklist_lock）;local_irq_disable（）;lock（&dev->event_lock）;lock（&f_owner->lock）; <Interrupt> lock（&dev->event_lock）;鎖死 *** （CVE-2026-52946)

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

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

  - drm/msm/dpu：修正電源和頻率之間的不相符 在 DPU 運行時間暫停期間，調用 dev_pm_opp_set_rate（dev， 0） 會將 MMCX 軌降到MIN_SVS，而核心時鐘頻率會維持其原始 （最高） 速率。當運行時間恢復重新啟用時鐘時，這可能會導致軌電壓和時鐘速率之間不匹配。例如，在 DPU 繫結路徑中，序列可以是： cpu0：
    dev_sync_state -> rpmhpd_sync_state cpu1：dpu_kms_hw_init時間軸 0
    ------------------------------------------------> t rpmhpd_sync_state後，電壓性能不再保證保持在最高水平。在dpu_kms_hw_init期間，調用 dev_pm_opp_set_rate（dev， 0） 會降低電壓，導致 MMCX 電源軌降至 MIN_SVS，而核心時脈仍處於最大頻率。重新啟用電源時，只會啟用時脈，導致 MMCX 軌處於MIN_SVS，但核心時脈處於最高速率的情況。在這種狀態下，導軌無法維持時脈速率，可能導致不穩定或系統崩潰。從 dpu_runtime_suspend 移除對 dev_pm_opp_set_rate（dev， 0） 的呼叫，以確保在 DPU 恢復時還原正確的投票。拼湊 https://patchwork.freedesktop.org/patch/710077/ ：（CVE-2026-53056）

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

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

  - i2c： dev：防止 I2C_TIMEOUT ioctl 中的整數溢位 使用 Syzkaller 進行模糊測試時，觀察到持續的「schedule_timeout：逾時值錯誤」警告，並伴隨著 SMBus 控制器狀態機器損毀。I2C_TIMEOUT ioctl 接受使用者提供的逾時 （以 10 毫秒為倍數）。使用者引數會針對 INT_MAX 進行檢查，但隨後會乘以 10，然後再傳遞給 msecs_to_jiffies（）。惡意使用者可傳遞通過「arg > INT_MAX」檢查但在乘以 10 時溢位的大型值 （例如 429496729）。這會導致一個截斷的 32 位元無正負號值，繞過 'msecs_to_jiffies（）' 中的內部 '（int）m < 0' 檢查。然後，截斷的值會指派給「client->adapter->timeout」（帶正負號的 32 位元 int），該值會重新解譯為負數。當傳遞給 wait_for_completion_timeout（） 時，此負值會進行符號擴展為 64 位元無符號 long，從而觸發「schedule_timeout」警告並導致過早返回。這會使 SMBus 狀態機器處於無法恢復的狀態，構成本地拒絕服務 （DoS）。透過將使用者引數限制為「INT_MAX / 10」來解決此問題。[WSA：也移動評論]（CVE-2026-52948）

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

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

  - net： qrtr：修正 qrtr_port_remove 中的參照計數飽和度和潛在的 UAF 在 qrtr_port_remove（） 中，在連接埠從 qrtr_ports XArray 中移除之前，以及在 RCU 寬限期過去之前，通訊端參照計數會透過 __sock_put（） 遞減。這打破了基本的 RCU 更新範式。它會公開一個爭用視窗，其中並行 RCU 讀取器 （例如 qrtr_reset_ports（） 或 qrtr_port_lookup（）） 可以從 XArray 取得通訊端的指標，並嘗試在參照計數已降至零的通訊端上呼叫 sock_hold（） 。在 syzkaller 模糊測試期間，遇到了這個確切的爭用條件，導致了以下參照計數飽和警告和潛在的釋放後使用：refcount_t：飽和;記憶體洩漏。警告： lib/refcount.c：22 的 CPU：3 PID：1273 refcount_warn_saturate+0xae/0x1d0 連結的模組：qrtr（+） bochs drm_shmem_helper ... 呼叫追蹤： <TASK> qrtr_reset_ports net/qrtr/af_qrtr.c：768 [內嵌] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c：805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c：901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c：3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c：715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c：169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c：1283 ...</TASK> 透過將參照計數遞減推遲到 xa_erase（） 和 synchronize_rcu（） 完成之後來解決此問題。（注意：此修補程式的 v1 錯誤地將 __sock_put（） 替換為 sock_put（）。正如 Simon Horman 所指出的，qrtr_port_remove（） 的呼叫者仍然持有對通訊端的引用，因此在這裡釋放通訊端記憶體會導致呼叫者中出現後續的 UAF。因此，保留 __sock_put（），但只是為了結束 RCU 競賽而重新定位。（CVE-2026-52947）

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

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

  - erofs：將 LCN 統一為 u64 用於 32 位元平台 正如 sashiko 報告的 [1]，「lcn」被輸入為「無符號長」（有時或「無符號 int」），這在 32 位平台上只有 32 位元寬，這導致「（lcn << lclusterbits）」在 4 GiB 時被截斷。為了鞏固邏輯，只需在程式碼庫周圍一致地使用「u64」。[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com(CVE-2026-53015）

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

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

  - bpf， sockmap：修正 proto update unix_stream_connect（） 中的 null-ptr-deref af_unix sk_state （'WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED）'） _before_ 它指派對等節點 （'unix_peer（sk） = newsk'）。
    sk_state == TCP_ESTABLISHED使 sock_map_sk_state_allowed（） 相信通訊端已正確設置，其中包括具有定義的對等體。IOW，當可以在仍具有 unix_peer（sk） == NULL 的通訊端上呼叫 unix_stream_bpf_update_proto（） 時，有一個視窗。CPU0 bpf CPU1 連接 -------- ------------ WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED） sock_map_sk_state_allowed（sk） ...sk_pair = unix_peer（sk） sock_hold（sk_pair） sock_hold（newsk） smp_mb__after_atomic（） unix_peer（sk） = newsk 錯誤：核心 NULL 指標解除參照，位址：0000000000000080 RIP：0010：unix_stream_bpf_update_proto+0xa0/0x1b0 呼叫追蹤：
    sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240
    __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 最初的想法是在 sk_state 更新之前移動對等分配[1]，但這涉及額外的記憶體屏障，並且更改熱路徑被拒絕。然後考慮在 unix_stream_bpf_update_proto（） 中的原型更新期間進行 NULL 檢查[2]，但後續討論[3] 集中在根本原因上，即 sockmap 更新採用錯誤的鎖定。或者，更具體地說，缺少 unix_state_lock（）[4]。最後得出的結論是，教導 sockmap 關於af_unix鎖定會不必要地複雜[5]。撇開複雜性不談，由於允許BPF_PROG_TYPE_SCHED_CLS和BPF_PROG_TYPE_SCHED_ACT更新 sockmaps，因此 sock_map_update_elem（） 採用 unix 鎖，因為它目前在 unix_state_lock（） 中實現：spin_lock（&unix_sk（s）->lock），將會有問題。
    unix_state_lock（） 在進程上下文中獲取，然後是 softirq-context TC BPF 程式嘗試採用相同的微調鎖 -- deadlock[6]。這樣我們就回到了同儕檢查的想法[2]。[1]:
    https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]:
    https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]:
    https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]:
    https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]:
    https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]:
    https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ af_unix/stream connect（） 可能爭用 sockmap 更新的場景摘要： 1. connect（） 與 bpf（BPF_MAP_UPDATE_ELEM），即
    sock_map_update_elem_sys（） 實作的 NULL 檢查就足夠了。一旦分配，在釋放通訊端 fd 之前，不會釋放通訊端對等體。這不是問題，因為 sock_map_update_elem_sys（） 會碰到 fd refcnf。2. connect（） 與 BPF 程式進行更新 根據 verifier.c：may_update_sockmap（） 更新限制為 BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS （僅限 bpf_sock_map_update（）BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP 另外一個需要考慮的競爭： CPU0 bpf CPU1 連接 -------- ------------ WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED） sock_map_sk_state_allowed（sk） sock_hold（newsk） smp_mb__after_atomic（） ---truncated--- （CVE-2026-53034）

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

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

  - ceph：修正 __ceph_build_xattrs_blob（） 中由於 blob 大小過時而造成的BUG_ON generic/642 測試案例可以重現核心損毀： [40243.605254] ------------[ 切到這裡 ]------------ [40243.605956] fs/ceph/xattr.c：918！ 的核心錯誤！[40243.607142] 哎呀：無效的操作碼：0000 [#1] SMP PTI [40243.608067] CPU：7 UID：
    0 PID：498762 Comm：kworker/7:1 未受污染 7.0.0-rc7+ #3 PREEMPT（full） [40243.609700] 硬體名稱：QEMU Ubuntu 25.10 PC v2 （i440FX + PIIX， + 10.1 machine， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] 工作佇列：ceph-msgr ceph_con_workfn [40243.612715] RIP：
    0010：__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] 代碼：0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc 0b <0f> 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP： 0018：ffffcc80c4d4b688 EFLAGS：00010287 [40243.617773] RAX：0000000000010026 RBX：0000000000000001 RCX：00000000000000000000 [40243.618928] RDX：
    ffff8a773798dee0 RSI：00000000000000000 RDI：000000000000000000 [40243.620158] RBP：ffffcc80c4d4b6a0 R08：
    00000000000000000000 ： 00000000000000000000000 [40243.621573] R10： 000000000000000000 R11： 0000000000000000000 R12R09：
    ffff8a75f3b58000 [40243.622907] R13： ffff8a75f3b58000 R14： 0000000000000080 R15： 0000000000000bffd [40243.624054] FS： 0000000000000000000（0000） GS：ffff8a787d1b4000（0000） knlGS：000000000000000000 [40243.625331] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [40243.626269] CR2：000072f390b623c0 CR3：
    000000011c02a003 CR4： 0000000000372ef0 [40243.627408] 呼叫追蹤： [40243.627839] [40243.628188] <TASK>
    __prep_cap+0x3fd/0x4a0 [40243.628789] ？ do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ？ __lock_acquire+0x4a2/0x2650 [40243.630773] ？ find_held_lock+0x31/0x90 [40243.631347] ？ handle_cap_grant+0x79f/0x1060 [40243.632068] ？ lock_release+0xd9/0x300 [40243.632696] ？ __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ？ lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ？ ceph_con_process_message+0x65/0x190[40243.636828] ？ lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ？ kfree+0x311/0x4f0 [40243.638749] ？ kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ？ sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ？ lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ？ process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ？
    __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ？ __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ？ __pfx_kthread+0x10/0x10 [40243.647316] ？
    __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] [40243.648902] </TASK> 連結的模組： overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000000 ]--- 提交 d93231a6bc8a （Ceph：防止用戶端超出 MDS 最大 xattr 大小） 將required_blob_size計算移至 __build_xattrs（） 呼叫之前，從而引入爭用。 __build_xattrs（） 在執行期間釋放並重新取得i_ceph_lock。在該視窗中，handle_cap_grant（） 可能會使用更新的 MDS 提供的 blob 更新 i_xattrs.blob，並增加 i_xattrs.version。當__bui ---truncated--- （CVE-2026-52961）

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

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

  - KVM：拒絕 kvm_reset_dirty_gfn（） 中的包裝偏移 kvm_reset_dirty_gfn（） 使用 if （！memslot ||（offset + __fls（mask）） >= memslot->npages） 傳回;但偏移量為 u64，且未勾選加法。u64 包裝可以無訊息地繞過檢查。支援這些項目的髒環MAP_SHARED在 vcpu fd 的KVM_DIRTY_LOG_PAGE_OFFSET，因此 VMM 可以在核心推送它們和KVM_RESET_DIRTY_RINGS取用它們之間重寫任何項目的插槽和位移欄位。重設時，kvm_dirty_ring_reset（） 透過 READ_ONCE（） 重新讀取值，並將它們直接回饋到此檢查中;
    只有旗標交握被視為移交，插槽/偏移負載會受信任。製作兩個條目 entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 會使 kvm_dirty_ring_reset（） 中的合併迴圈計算 delta = （s64）（0 - 0xffffffffffffffc1） = 63，它落在 [0， BITS_PER_LONG） 中，因此它透過設定位元 63 將 entry[i+1] 折疊到現有遮罩中。然後，尾端 kvm_reset_dirty_gfn（） 呼叫會看到偏移量 = 0xffffffffffffffc1，__fls（遮罩） = 63;u64 中的總和為 0，且邊界檢查通過。該偏移會原封不動地傳播到 kvm_arch_mmu_enable_log_dirty_pt_masked（） 中。在舊版 MMU 路徑上 -- kvm_memslots_have_rmaps（） == true，即影子分頁、任何已配置影子根的 VM 或寫入追蹤插槽 -- 它會到達 gfn_to_rmap（），該路徑會以接近U64_MAX的 gfn 編製 slot->arch.rmap[0][] 索引。這是 kvm_rmap_head 的越界載入，然後是載入指標指向的任何內容的條件清除PT_WRITABLE_MASK。可從任何持有 /dev/kvm 的處理程序存取此路徑。首先自行檢查範圍偏移，因此加法無法換行。
    memslot->npages 的範圍遠低於 U64_MAX，因此一旦位移 < npages 成立，位移量 + __fls（遮罩） （使用
    __fls（遮罩） < BITS_PER_LONG） 保持在範圍內。（CVE-2026-52969）

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

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

  - af_unix：刪除 SOCKMAP 的所有 SCM 屬性。SOCKMAP 可以隱藏 AF_UNIX GC 的飛行中 fd。當 SOCKMAP 中的通訊端收到帶有 inflight fd 的 skb 時，sk_psock_verdict_data_ready（） 會查詢映射的通訊端並將 skb 排入佇列到其 psock->ingress_skb。由於舊版和新版 GC 都無法檢查 psock 佇列，因此隱藏的 skb 會洩漏進行中的通訊端。請注意，這無法透過 kmemleak 偵測到，因為進行中的通訊端連結至全域清單。此外，SOCKMAP 重新導向打破了基於 Tarjan 的 GC 認為 unix_edge.successor 始終處於活動狀態的假設，一旦 skb 被重新導向，這種情況就不再成立，導致下面的釋放後使用。[0] 此外，SOCKMAP 無法正確呼叫 scm_stat_del（），因此 unix_show_fdinfo（） 可能會報告不正確的 fd 計數。sk_msg_recvmsg（） 首先不支援任何 SCM 屬性。讓我們在將 skb 傳遞到 SOCKMAP 層之前刪除所有 SCM 屬性。[0]：錯誤：KASAN：unix_del_edges 中的 slab-use-after-free （net/unix/garbage.c：118 net/unix/garbage.c：181 net/unix/garbage.c：251） 由任務 kworker/56:1/496 在 addr ffff888125362670 讀取大小 8 CPU：56 UID：0 PID：496 Comm：kworker/56:1 未受污染 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT（lazy） 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 工作佇列： 事件sk_psock_backlog呼叫追蹤： <TASK> dump_stack_lvl （lib/dump_stack.c：122） print_report （mm/kasan/report.c：379） kasan_report （mm/kasan/report.c：597） unix_del_edges （net/unix/garbage.c：118 net/unix/garbage.c：181 net/unix/garbage.c：251） unix_destroy_fpl （net/unix/garbage.c：317） unix_destruct_scm （./include/net/scm.h：80 ./include/net/scm.h：86 net/unix/af_unix.c：1976） sk_psock_backlog （./include/linux/skbuff.h：?)process_scheduled_works （kernel/workqueue.c：？） worker_thread （kernel/workqueue.c：？） kthread （kernel/kthread.c：438） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：258） </TASK> 由任務 955 分配： kasan_save_track （mm/kasan/common.c：58 mm/kasan/common.c：78） __kasan_slab_alloc （mm/kasan/common.c：369） kmem_cache_alloc_noprof （mm/slub.c：4539） sk_prot_alloc （net/core/sock.c：2240） sk_alloc （net/core/sock.c：2301） unix_create1 （net/unix/af_unix.c：1099） unix_create （net/unix/af_unix.c：1169）
    __sock_create （net/socket.c：1606） __sys_socketpair （net/socket.c：1811） __x64_sys_socketpair （net/socket.c：1863 net/socket.c：1860 net/socket.c：1860） do_syscall_64 （arch/x86/entry/syscall_64.c：？） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：130） 由任務 496 釋放： kasan_save_track （mm/kasan/common.c：58 mm/kasan/common.c：78） kasan_save_free_info （mm/kasan/generic.c：587）
    __kasan_slab_free （mm/kasan/common.c：287） kmem_cache_free （mm/slub.c：6165） __sk_destruct （net/core/sock.c：2282 net/core/sock.c：2384） sk_psock_destroy （./include/net/sock.h：？） process_scheduled_works （kernel/workqueue.c：？） worker_thread （kernel/workqueue.c：？） kthread （kernel/kthread.c：438） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：258） （CVE-2026-53005）

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

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

  - platform/x86：dell-wmi-sysman：繫結列舉字串彙總 populate_enum_data（） 會將韌體提供的值修飾符和可能值字串彙總到固定的 512 位元組結構成員中。目前的程式碼會綁定每個個別的來源字串，但然後使用原始 strcat（） 附加每個字串和分隔符號，而不檢查剩餘空格。將彙總迴圈切換至有界限的附加協助程式，並拒絕其組合字串不適合目的地緩衝區的列舉套件。[ij：新增包含]（CVE-2026-53022）

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

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

  - dm 快取：修正直通模式切換中的髒對應檢查 如提交 9b1cc9f251af （dm 快取：在非作用中和作用中的 DM 表之間共用快取中繼資料物件） 中所述，dm-cache 假設在暫停後重新載入表，而 LVM 的表預載會打破此假設。直通模式的已變更對應檢查是圍繞此假設設計，並在資料表建立期間執行，導致在中繼資料更新進行時預先載入檢查失敗。這可能會將變更對應載入直通模式，進而導致資料遺失。重現步驟： 1. 建立零migration_threshold的回寫快取以產生已變更的映射 dmsetup 建立 cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup 建立 corig --table 0 262144線性 /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 建立快取
    --table 0 262144快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 回寫 SMQ \ 2 migration_threshold 0 2.在直通模式下預先載入表格 dmsetup 重新載入快取 --table 0 262144 快取 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 直通 smq 0 3.
    寫入第一個快取區塊以使其變髒 fio --filename=/dev/mapper/cache --name=populate
    --rw=write --bs=4k \ --direct=1 --size=64k 4.恢復非作用中表格。現在可以將髒區塊載入到直通模式。dmsetup 繼續快取 透過將檢查移至預先繼續階段以支援表格預先載入來修正。同時移除未使用的函式dm_cache_metadata_all_clean。（CVE-2026-53061）

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

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

  - PPP：要求在目標 netns 中針對未連接的 ioctl 進行CAP_NET_ADMIN /dev/ppp Open 目前已針對 file->f_cred->user_ns 授權，而未連接的系統管理 ioctl 在 current->nsproxy->net_ns 上運作。
    因此，本機非特權使用者可以使用CLONE_NEWUSER建立新的使用者命名空間，只在該新使用者命名空間中取得CAP_NET_ADMIN，而且仍會針對繼承的網路命名空間發出 PPPIOCNEWUNIT、PPPIOCATTACH 或 PPPIOCATTCHAN。在處理未連接的 PPP 系統管理 ioctl 之前，要求在擁有目標網路命名空間的使用者命名空間中進行CAP_NET_ADMIN。這會在其實際擁有特權的網路命名空間中保留正常的 pppd 作業，同時拒絕 userns-only inherited-netns 情況。（CVE-2026-53075）

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

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

  - scsi：target：core：修正 UNMAP 邊界檢查中的整數溢位 sbc_execute_unmap（） 檢查 LBA + 範圍不超過裝置容量，但不防止 LBA + 範圍在 64 位元溢位上繞行。
    新增與相同檔案中已用於WRITE_SAME的模式相符的溢位檢查。（CVE-2026-53021）

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

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

  - 已解決 Linux 核心中的下列弱點：block: fix zones_cond memory leak on zone revalidation error paths When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it. (CVE-2026-53127)

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

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

  - netfilter： nft_ct：修正 obj eval 中缺少的 expect put nft_ct_expect_obj_eval（） 會配置期望並可能呼叫 nf_ct_expect_related（），但絕不會刪除其本機參照。在返回餘額分配之前添加 nf_ct_expect_put（exp）。（CVE-2026-52970）

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

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

  - HID： usbhid：修正 hid_post_reset（） 中的鎖死 您可以建置包含 HID 元件和儲存裝置或 UAS 元件的 USB 裝置。元件只能一起重設。這表示 hid_pre_reset（） 和 hid_post_reset（） 位於區塊 IO 錯誤處理中。因此，其中使用的記憶體配置都無法執行封鎖 IO，因為 IO 可以在重設裝置和呼叫介面驅動程式時，在保留的互斥上鎖死。對其中的所有分配使用GFP_NOIO。（CVE-2026-53037）

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

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

  - libceph：修正 osdmap_decode（） 中潛在的越界存取 從 osdmap_decode（） 中傳入的 osdmap 解碼 osd_state 和 osd_weight 時，會針對每個 osd 解碼兩者，即映射>max_osd時間。ceph_decode_need（） 檢查僅考慮一次 sizeof（*map->osd_weight）。如果傳入訊息損毀，以致 max_osd 值超過 osdmap 訊息的實際內容，則可能會導致越界記憶體存取。此修補程式透過變更 ceph_decode_need（） 檢查中的對應部分以考慮 map->max_osd*sizeof（*map->osd_weight） 來修正此問題。（CVE-2026-52958）

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

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

  - neigh：讓 neigh_xmit 取得 skb 所有權neigh_xmit一律釋放 skb，除非找不到鄰居表。但即使是第一個新增的 neigh_xmit 使用者 （mpls） 也依賴 neigh_xmit 來釋放 skb （或將其排入佇列等待 tx）。sashiko 報告：如果使用未初始化的鄰居NEIGH_ND_TABLE表呼叫 neigh_xmit（），則會傳回 -EAFNOSUPPORT 並繞過其內部out_kfree_skb錯誤路徑。因為這裡忽略了 neigh_xmit（） 的傳回值，這會不會洩漏 SKB？假設完全擁有權，並移除未 xmit 或釋放 skb 的最後一個程式碼路徑。（CVE-2026-52981）

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

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

  - bpf：修正 sock_ops 中相同暫存器 dst/src OOB 讀取和指標洩漏 當 BPF sock_ops程式存取具有 dst_reg == src_reg 的 ctx 欄位時，SOCK_OPS_GET_SK（） 和 SOCK_OPS_GET_FIELD（） 巨集無法將 ！fullsock / ！locked_tcp_sock 路徑中的目標暫存器歸零。這兩個巨集都借用一個臨時暫存器來檢查 is_fullsock / is_locked_tcp_sock當 dst_reg == src_reg時，dst_reg 持有 ctx 指標。
    當檢查為 false 時 （例如，TCP_NEW_SYN_RECV帶有 request_sock 的狀態），dst_reg應該歸零，但不是，留下過時的 ctx 指標： - SOCK_OPS_GET_SK：dst_reg保留 ctx 指標，以PTR_TO_SOCKET_OR_NULL方式通過 NULL 檢查，並且可以用作虛假的通訊端指標， 導致 bpf_skc_to_tcp6_sock（） 等協助程式中的堆疊越界存取。- SOCK_OPS_GET_FIELD：dst_reg保留驗證者認為是SCALAR_VALUE的 ctx 指標，洩漏核心指標。透過以下方式修正這兩個巨集： - 將 fullsock 路徑中的 JMP_A（1） 變更為 JMP_A（2） 以跳過新增的指令。- 在 ！fullsock 路徑中的暫存器還原之後新增 BPF_MOV64_IMM（si->dst_reg， 0），放置在還原之後，因為 dst_reg == src_reg 表示我們需要完整src_reg才能讀取 ctx->temp。CVE-2026-53078

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

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

  - greybus： raw：如果在中斷連接後呼叫 write，則修正釋放後使用 如果使用者在呼叫中斷連接後寫入 chardev，核心會因以下追蹤而出現錯誤 （CONFIG_INIT_ON_FREE_DEFAULT_ON=y）： 錯誤：核心 NULL 指標解除參照，位址：0000000000000218 ...
    通話追蹤： <TASK> gb_operation_create_common+0x61/0x180 gb_operation_create_flags+0x28/0xa0 gb_operation_sync_timeout+0x6f/0x100 raw_write+0x7b/0xc7 [gb_raw] vfs_write+0xcf/0x420 ？ task_mm_cid_work+0x136/0x220 ksys_write+0x63/0xe0 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f 斷開通話gb_connection_destroy， 這最終會釋放連接物件。在寫入檔案作業中呼叫 gb_operation_sync時，它會取得釋放的連線作為參數，核心會發生錯誤。無法將gb_connection_destroy移出中斷連線功能，因為 Greybus 子系統預期在中斷連線傳回時，屬於軟體組的所有連線都會遭到破壞。若要防止此錯誤，請使用 rw 鎖定來同步寫入和中斷連線之間的存取。這可確保寫入函式不會嘗試使用中斷連線的連線。
    (CVE-2026-53024)

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

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

  - bonding： 3ad：為 port->aggregator 實施適當的 RCU 規則 syzbot 在 bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler [1] 中發現資料爭用，這暗示缺乏正確的 RCU 實作。將__rcu限定詞新增至 port->aggregator，並新增適當的 RCU API。[1] 錯誤：KCSAN：bond_3ad_get_active_agg_info 中的資料爭用 / CPU 0 上的任務 36 寫入 0xffff88813cf5c4b0 8 位元組的bond_3ad_state_machine_handler：ad_port_selection_logic drivers/net/bonding/bond_3ad.c：1659 [內聯] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c：2569 process_one_work kernel/workqueue.c：3302 [內聯] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c：3385 worker_thread+0x58a/0x780 kernel/workqueue.c：3466 kthread+0x22a/0x280 kernel/kthread.c：436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 由 CPU 1 上的任務 22063 讀取到 8 位元組的0xffff88813cf5c4b0：
    __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c：2858 [內嵌] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c：2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c：853 rtnl_link_info_fill net/core/rtnetlink.c：906 [內嵌] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c：927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c：2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c：4453rtmsg_ifinfo_event net/core/rtnetlink.c：4486 [內嵌] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c：4495
    __dev_notify_flags+0x76/0x390 net/core/dev.c：9790 netif_change_flags+0xac/0xd0 net/core/dev.c：9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c：3180 rtnl_group_changelink net/core/rtnetlink.c：3813 [內嵌]
    __rtnl_newlink net/core/rtnetlink.c：3981 [內嵌] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c：4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c：6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c：2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c：7022 netlink_unicast_kernel net/netlink/af_netlink.c：1318 [內嵌] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c：1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c：1894 sock_sendmsg_nosec net/socket.c：787 [內嵌]
    __sock_sendmsg net/socket.c：802 [內嵌] ____sys_sendmsg+0x563/0x5b0 net/socket.c：2698
    ___sys_sendmsg+0x195/0x1e0 net/socket.c：2752 __sys_sendmsg net/socket.c：2784 [內嵌] __do_sys_sendmsg net/socket.c：2789 [內嵌] __se_sys_sendmsg net/socket.c：2787 [內嵌] __x64_sys_sendmsg+0xd4/0x160 net/socket.c：2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h：47 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 值已變更：0x0000000000000000
    -> 0xffff88813cf5c400 由 kernel concurrency sanitizer 報告於： CPU： 1 UID： 0 PID： 22063 comm：
    syz.0.31122 受污染：G W syzkaller #0 PREEMPT（完整） 受污染：[W]=WARN 硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 04/18/2026 （CVE-2026-52975）

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

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

  - ALSA：usb-audio：繫結的 MIDI 端點描述元掃描 snd_usbmidi_get_ms_info（） 會在使用 baAssocJackID[] 之前驗證內部 MIDIStreaming 端點描述元大小，但描述元遍歷器仍然可以傳回類別特定的端點描述元，其 bLength 超過端點額外掃描中的剩餘位元組。這會留下稍後的彈性陣列讀取受 bLength 限制，但不受 endpoint-extra 掃描中剩餘位元組的限制。當 bLength 為零或延伸超過剩餘的端點額外掃描時，停止行走。CVE-2026-52963

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

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

  - bpf， arm64：修正 arm64 BPF JIT 中使用check_imm帶正負號範圍檢查 check_imm （bits， imm） 中的差一錯誤，以驗證分支位移 （以 arm64 指令單元） 在傳遞給編碼器之前，是否適合 B、B.cond 或 CBZ/CBNZ 編碼的帶正負號 N 位直接欄位。巨集目前測試 （imm > 0 & imm >> 位） ||（imm < 0 & ~imm >>位元），它允許 [-2^N， 2^N） 中的值，實際上是帶正負號的 （N+1） 位元範圍。帶正負號的 N 位元欄位僅保留 [-2^（N-1）， 2^（N-1）），因此檢查允許每邊多一個位元的範圍。特別是，對於 check_imm19（），[2^18， 2^19） 中的值會滑過檢查，但不適合 B.cond 的 19 位帶正負號 imm19 欄位。然後，aarch64_insn_encode_immediate（） 將原始值遮罩到 19 位元欄位中，設定位元 18（符號位元）並將前向分支翻轉為向後分支。check_imm26（） 和 B/BL 編碼存在相同類別的問題。移位依 （位元 - 1） 而不是位，以便強制執行實際帶正負號的 N 位範圍。（CVE-2026-53036）

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

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

  - netdevsim：零初始化虛擬結構 iphdr sk_buff Syzbot 報告源自 nsim_dev_trap_skb_build 的 KMSAN uninit 值，並且分配也在同一函式中執行。透過呼叫 skb_put_zero 而不是 skb_put 來解決此問題，以保證整個 IP 標頭的零初始化。
    (CVE-2026-52985)

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

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

  - vdpa：使用通用driver_override基礎結構 透過 __driver_attach（） 探測驅動程式時，會在沒有保留裝置鎖定的情況下呼叫匯流排的 match（） 回呼，因此在沒有鎖定的情況下存取driver_override欄位，這可能會導致 UAF。使用驅動程式核心driver_override基礎結構來修正此問題，並在內部進行適當的鎖定。請注意，在未保留裝置鎖定的情況下，從 __driver_attach（） 呼叫 match（） 是故意的。[1] （CVE-2026-53118）

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

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

  - bpf：修正子程序中的 ld_{abs，ind} 故障路徑分析 ld_{abs，ind} 指令的用法在不久前透過提交 09b28d76eac4 擴展到子程序中 （bpf：新增異常傳回檢查。只有當子程式有 BTF 註解且具有純量傳回類型時，才允許在子程式中使用這些。bpf_gen_ld_abs（） 中的程式碼產生器具有傳統 cBPF 時間的異常退出路徑 （r0=0 + 退出）。雖然強制執行針對純量傳回類型，但如果透過 ld_{abs，ind} 載入封包資料失敗，驗證程式也必須模擬異常退出的路徑。目前情況並非如此。藉由讓驗證程式模擬成功和失敗路徑來修正它，並以與尾部呼叫類似的方式擴充它。成功路徑 （r0=未知，繼續下一個 insn） 會推送到堆疊上以供稍後驗證，而 r0=0 並返回給呼叫端是在貫穿端完成。（CVE-2026-53090）

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

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

  - 藍牙：使用 HCI_PROTO_DEFER 修正 hci_conn_request_evt（） 中的鎖定 當通訊協定設定 HCI_PROTO_DEFER 時，hci_conn_request_evt（） 會在沒有 hdev->lock 的情況下呼叫 hci_connect_cfm（conn）。通常 hci_connect_cfm（） 假設它已持有，如果同時刪除 conn -> UAF。只有 SCO 和 ISO 設定HCI_PROTO_DEFER且僅用於延遲安裝偵聽，並且不會為 ISO 產生HCI_EV_CONN_REQUEST。在非延遲偵聽通訊端程式碼路徑中，會呼叫 hci_connect_cfm（conn） 並保留 hdev->lock。按住鎖即可修復。
    (CVE-2026-53072)

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

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

  - ocfs2/dlm：驗證 dlm_match_regions（） 修補程式系列中的qr_numregions ocfs2/dlm：修正 dlm_match_regions（） 中的兩個錯誤。在 dlm_match_regions（） 中，DLM_QUERY_REGION網路訊息中的 qr_numregions 欄位用於在沒有充分驗證的情況下在 qr_regions 緩衝區上驅動迴圈。本系列修正了兩個問題： - 修補程式 1 新增了邊界檢查，以拒絕qr_numregions超過 O2NM_MAX_REGIONS 的訊息。
    o2net 層僅驗證訊息位元組長度;它不會限制欄位值，因此特製的訊息可以將qr_numregions設定為最多 255，並觸發超過 1024 位元組qr_regions緩衝區的越界讀取。- 修補程式 2 修正了本機與遠端比較迴圈中的差一錯誤，該迴圈使用 '<=' 而不是 '<'，即使qr_numregions在範圍內，也會讀取一個超出有效範圍的項目。此修補程式（共 2 個）：
    DLM_QUERY_REGION網路訊息中的 qr_numregions 欄位會直接用作 dlm_match_regions（） 中的迴圈邊界，而不檢查O2NM_MAX_REGIONS。由於qr_regions的大小最多為 O2NM_MAX_REGIONS （32） 個項目，因此具有 qr_numregions > 32 的特製訊息會導致越界讀取通過qr_regions緩衝區。在進入迴圈之前，為qr_numregions新增邊界檢查。（CVE-2026-53043）

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

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

  - net/sched： netem：修正佇列限制檢查以包含重新排序的封包 netem_enqueue（） 中的佇列限制檢查使用 q->t_len，它僅計算內部 tfifo 中的封包。不計算由重新排序路徑 （__qdisc_enqueue_head） 放置在 sch->q 中的封包，因此在重新排序時，總佇列佔用率可能會超過 sch->limit。在限制檢查中包括 sch->q.qlen。（CVE-2026-52984）

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

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

  - netfilter： xtables：將多個比對項限制為 inet 系列 這是部分還原： 提交 ab4f21e6fb1c （netfilter： xtables：在更多延伸模組中使用 NFPROTO_UNSPEC） 以僅允許 IPv4 和 IPv6。- xt_mac - xt_owner - xt_physdev 使用者空間中的 ebtables 不會使用這些延伸模組。此外，xt_realm僅適用於 ipv4，因為 dst->tclassid 是 ipv4 特定的。（CVE-2026-53001）

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

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

  - VSOCK/virtio：修正MSG_ZEROCOPY固定頁面帳戶處理 virtio_transport_init_zcopy_skb（） 使用 iter->count 作為 msg_zerocopy_realloc（） 的大小參數，而 iter-count 又會將其傳遞給 mm_account_pinned_pages（） 進行RLIMIT_MEMLOCK帳戶處理。但是，此函數是在 virtio_transport_fill_skb（） 已經通過 __zerocopy_sg_from_iter（） 消耗迭代器之後調用的，因此在最後一個 skb 上，iter->count 將為 0，跳過RLIMIT_MEMLOCK強制執行。將 pkt_len （正在傳送的總位元組數） 作為明確參數傳遞給 virtio_transport_init_zcopy_skb（），而不是讀取已消耗的 iter->count。這會符合 TCP 和 UDP，兩者都呼叫具有原始訊息大小的 msg_zerocopy_realloc（）。（CVE-2026-52994）

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

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

  - iommu/amd： 修正 clone_alias（） 以使用原始裝置的 devid 目前 clone_alias（） 假設第一個引數 （pdev） 一律是原始裝置指標。此函式由 pci_for_each_dma_alias（） 調用，（） 根據拓撲決定在第一個引數中傳送原始或別名裝置詳細資訊。這表示用來查詢和複製 DTE 的來源 devid 可能不正確，導致錯誤或過時的 DTE 項目傳播至別名裝置。透過將原始 pdev 作為不透明資料引數傳遞給直接 clone_alias（） 呼叫和 pci_for_each_dma_alias（） 來解決此問題。在 clone_alias（） 中，從資料擷取原始裝置並從中計算 devid。（CVE-2026-53053）

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

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

  - 藍牙：hci_ldisc：錯誤時清除HCI_UART_PROTO_INIT當 hci_register_dev（） 在 hci_uart_register_dev（） 中失敗時，在呼叫 hu->proto->close（hu） 並將 hu->hdev 設定為 NULL 之前，不會清除HCI_UART_PROTO_INIT。這意味著在資源釋放後，傳入的 UART 資料將到達 hci_uart_tty_receive（） 中特定於協定的 recv 處理常式。在呼叫 hu->proto->close（） 並將 hu->hdev 設定為 NULL 之前，請先清除具有寫入鎖定的HCI_UART_PROTO_INIT。寫入鎖定可確保所有作用中的讀取器都已完成，且在釋放資源之前，沒有新的讀取器可以進入通訊協定 recv 路徑。這允許特定於通訊協定的 recv 函式移除HCI_UART_REGISTERED保護，而不會在 hci_register_dev（） 失敗時冒 NULL 指標解除參照的風險。（CVE-2026-53073）

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

ID	名稱	嚴重性
322646	Linux Distros 未修補弱點：CVE-2026-53106	medium
322645	Linux Distros 未修補弱點：CVE-2026-53017	medium
322644	Linux Distros 未修補弱點：CVE-2026-53035	medium
322643	Linux Distros 未修補弱點：CVE-2026-53050	high
322642	Linux Distros 未修補弱點：CVE-2026-53112	high
322641	Linux Distros 未修補弱點：CVE-2026-52988	high
322640	Linux Distros 未修補弱點：CVE-2026-53076	high
322639	Linux Distros 未修補弱點：CVE-2026-53012	medium
322638	Linux Distros 未修補弱點：CVE-2026-53062	high
322637	Linux Distros 未修補弱點：CVE-2026-53074	medium
322636	Linux Distros 未修補弱點：CVE-2026-52968	high
322635	Linux Distros 未修補弱點：CVE-2026-53077	high
322634	Linux Distros 未修補弱點：CVE-2026-49980	critical
322633	Linux Distros 未修補弱點：CVE-2026-53064	medium
322632	Linux Distros 未修補弱點：CVE-2026-53027	medium
322631	Linux Distros 未修補弱點：CVE-2026-52992	high
322630	Linux Distros 未修補弱點：CVE-2026-52982	critical
322629	Linux Distros 未修補弱點：CVE-2026-52946	high
322628	Linux Distros 未修補弱點：CVE-2026-53056	medium
322627	Linux Distros 未修補弱點：CVE-2026-52948	medium
322626	Linux Distros 未修補弱點：CVE-2026-52947	high
322625	Linux Distros 未修補弱點：CVE-2026-53015	medium
322624	Linux Distros 未修補弱點：CVE-2026-53034	medium
322623	Linux Distros 未修補弱點：CVE-2026-52961	medium
322622	Linux Distros 未修補弱點：CVE-2026-52969	high
322621	Linux Distros 未修補弱點：CVE-2026-53005	high
322620	Linux Distros 未修補弱點：CVE-2026-53022	medium
322619	Linux Distros 未修補弱點：CVE-2026-53061	medium
322618	Linux Distros 未修補弱點：CVE-2026-53075	high
322617	Linux Distros 未修補弱點：CVE-2026-53021	medium
322616	Linux Distros 未修補弱點：CVE-2026-53127	medium
322615	Linux Distros 未修補弱點：CVE-2026-52970	medium
322614	Linux Distros 未修補弱點：CVE-2026-53037	medium
322613	Linux Distros 未修補弱點：CVE-2026-52958	critical
322612	Linux Distros 未修補弱點：CVE-2026-52981	high
322611	Linux Distros 未修補弱點：CVE-2026-53078	high
322610	Linux Distros 未修補弱點：CVE-2026-53024	high
322609	Linux Distros 未修補弱點：CVE-2026-52975	high
322608	Linux Distros 未修補弱點：CVE-2026-52963	medium
322607	Linux Distros 未修補弱點：CVE-2026-53036	high
322606	Linux Distros 未修補弱點：CVE-2026-52985	medium
322605	Linux Distros 未修補弱點：CVE-2026-53118	high
322604	Linux Distros 未修補弱點：CVE-2026-53090	medium
322603	Linux Distros 未修補弱點：CVE-2026-53072	high
322602	Linux Distros 未修補弱點：CVE-2026-53043	critical
322601	Linux Distros 未修補弱點：CVE-2026-52984	medium
322600	Linux Distros 未修補弱點：CVE-2026-53001	medium
322599	Linux Distros 未修補弱點：CVE-2026-52994	medium
322598	Linux Distros 未修補弱點：CVE-2026-53053	high
322597	Linux Distros 未修補弱點：CVE-2026-53073	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

high

high

high

high

medium

high

medium

high

high

critical

medium

medium

high

critical

high

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

critical

high

high

high

high

medium

high

medium

high

medium

high

critical

medium

medium

medium

high

medium