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

  - mac802154：llsec：在就地加密 llsec_do_encrypt_unauth（）、llsec_do_encrypt_auth（）、llsec_do_decrypt_unauth（） 和 llsec_do_decrypt_auth（） 之前新增 skb_cow_data（），都會對 SKB 資料執行就地密碼編譯轉換。他們建立一個散點表，其中 sg_init_one（） 指向 skb 的線性資料區域，然後將與 src 和 dst 相同的散點表傳遞給加密 API（例如
    crypto_skcipher_encrypt/decrypt， crypto_aead_encrypt/decrypt）。在 RX 路徑上，
    __ieee802154_rx_handle_packet（） 會複製收到的 skb，然後透過 ieee802154_subif_frame（） 將其交給每個訂閱者。複製的 skb 透過參照計數共用相同的基礎資料緩衝區。
    當 llsec_do_decrypt（） 隨後就地修改此共用緩衝區時，它會損毀其他複製 （可能屬於其他通訊端或子系統） 仍參照的資料。在 TX 路徑上，當 skb 的頭部被複製時，可能會發生類似的資料共用 （skb_cloned（） 傳回 true）。修正方法是在執行任何就地加密作業之前呼叫 skb_cow_data（）。skb_cow_data（） 確保 skb 的資料區域不被共享：如果 skb 頭被克隆或資料跨越多個片段，它會將資料複製到可以就地安全修改的私有緩衝區中。這與以下人員使用的模式相同： - ESP （net/ipv4/esp4.c， net/ipv6/esp6.c） - MACsec （drivers/net/macsec.c） - WireGuard （drivers/net/wireguard/receive.c） - TIPC （net/tipc/crypto.c） 如果沒有此防護，共用 skb 資料上的就地加密會導致： - 其他 skb 複製的無訊息資料損毀 - 當加密 API 散佈遍歷寫入已由另一個複製的 kfree_skb（） 釋放的頁面時，釋放後使用 - 核心在並行 802.15.4 下當機啟用安全性的流量 （KASAN/KMSAN 報告釋放後 slab-use） 使用自動化來源分析在 0 秒 （https://0sec.ai） 之前找到。（CVE-2026-63831）

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

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

  - AppArmor：修正 Rawdata 重複資料刪除迴圈中的釋放後使用 aa_replace_profiles（） 遍歷 ns->rawdata_list 以針對已附加到現有設定檔的項目刪除傳入的原則 blob。根據結構 aa_loaddata 上的 kernel-doc，清單成員資格不保留參照：設定檔保留 pcount，當最後一個 pcount 刪除時，do_ploaddata_rmfs（） 會排入佇列，該工作佇列會接受 ns->lock 並移除項目。
    在捨棄最後一個 pcount 和執行工作佇列之間，清單上會保留 pcount == 0 的項目。
    aa_get_profile_loaddata（） 是 pcount 上的無條件 kref_get（），因此當重複資料刪除迴圈命中此類項目時，refcount 強化報告refcount_t：0 上的加法;釋放後使用。在 aa_replace_profiles（） 中，中毒計數器接著會在後續使用相同載入資料時觸發飽和和下溢警告。在提交 a0b7091c4de4 之前 （AppArmor：修正原始資料解除參照上的爭用），重複資料刪除路徑在單一計數器上使用了 get_unless_zero 樣式的協助程式，因此現有的 if （tmp） 防護是有意義的。
    拆分引用計數重構引入了具有簡單 kref_get（） 語義的 aa_get_profile_loaddata（），守衛悄悄地變成了無操作。引入 aa_get_profile_loaddata_not0（），以配合現有的
    _not0 aa_get_profile_not0（） 使用的約定，並將其用於rawdata_list重複資料刪除查詢，以便跳過即將消亡的項目。在 x86_64 上重現 v7.1-rc5 的 QEMU+KVM 運行 Ubuntu 24.04 + stress-ng 0.17.06： stress-ng --apparmor 1 --klog-check --timeout 60s 如果沒有此修補程式，三個refcount_t警告會在幾秒鐘內觸發。有了它，同樣的 60 秒運行是乾淨的。覆蓋範圍僅為煙霧測試;任何有自行車的人都歡迎用CONFIG_KASAN、CONFIG_KCSAN和CONFIG_PROVE_LOCKING浸泡更長時間。（CVE-2026-63827）

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

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

  - netfilter： nf_tables：新增掛鉤事務以刪除裝置 還原指示掛鉤即將消失的標誌，即。NFT_HOOK_REMOVE，但新增一個交易物件來追蹤鉤子的刪除，而無需在準備階段更改基鏈/流程表hook_list。將鉤子從基鏈/流程表hook_list移動到事務hook_list的現有方法破壞了此 RCU 保護清單的網路連結轉儲路徑讀取器。應該可以使用nft_trans_hook數組來存儲已刪除的鉤子以壓縮表示，但我不希望有很多鉤子對象，特別是現在對設備的通配符支持已經到位。請注意，nft_trans_chain_hooks（） 清單包含 DELCHAIN 和 DELFLOWTABLE 命令的結構nft_trans_hook物件清單，而此清單儲存 NEWCHAIN 和 NEWFLOWTABLE 的結構nft_hook物件。請注意，可以更新新命令以使用nft_trans_hook保持一致性。此修補程式也會調整事件通知路徑，以處理勾點交易清單。（CVE-2026-63858）

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

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

  - 提示：修正 tipc_aead_decrypt_done tipc_aead_decrypt（） 中的 slab-use-after-free Read 直接從 tipc_bearer_hold（b） 到 crypto_aead_decrypt（req），而不對 netns 進行參照，這與加密路徑不同。當 crypto_aead_decrypt（） 以非同步方式卸載時 （例如，SIMD aead 包裝函式排入 cryptd），cryptd 工作程式稍後會執行 tipc_aead_decrypt_done（）。如果持有者的 netns 在此期間被拆除，則 cleanup_net（） -> tipc_exit_net（） -> tipc_crypto_stop（） 釋放 per-netns tipc_crypto，然後完成讀取它：tipc_aead_decrypt_done（） 解除參照 aead->crypto->stats 和 aead->crypto->net，tipc_crypto_rcv_complete（） 取消參照 aead->crypto->aead[] 和節點表 -- 讀取釋放的記憶體。解碼的 KASAN splat （v7.1-rc7， CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO）： 錯誤：
    KASAN：tipc_aead_decrypt_done中的 slab-use-after-free （net/tipc/crypto.c：999） 在 addr ffff8881056258a8 由任務 kworker/u16：2/51 讀取大小 8 工作佇列：events_unbound 呼叫追蹤：tipc_aead_decrypt_done （net/tipc/crypto.c：999） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3397 kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） 由作業 169：__kasan_kmalloc （mm/kasan/common.c：398 mm/kasan/common.c：415） tipc_crypto_start （net/tipc/crypto.c：1502） tipc_init_net （net/tipc/core.c：72） ops_init （net/core/net_namespace.c：137） setup_net （net/core/net_namespace.c：446） copy_net_ns （net/core/net_namespace.c：579） create_new_namespaces （kernel/nsproxy.c：132） __x64_sys_unshare （kernel/fork.c：3316） do_syscall_64 （arch/x86/entry/syscall_64.c：63） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） 由任務 8 釋放： kfree （mm/slub.c：6566） tipc_exit_net （net/tipc/core.c：119） cleanup_net （net/core/net_namespace.c：704） process_one_work （kernel/workqueue.c：3314） kthread （kernel/kthread.c：436） 這是為加密端修正的提交 e279024617134 （net/tipc：修正 tipc_aead_encrypt_done 中的 slab-use-after-free Read ） 的同一類錯誤。加密路徑在 crypto_aead_encrypt（） 之前採用 maybe_get_net（aead->crypto->net），並在同步傳回路徑和 tipc_aead_encrypt_done（） 中與 put_net（） 一起將其丟棄;-EINPROGRESS/-EBUSY 傳回會保留非同步回呼以釋放的參照。解密路徑沒有等效的防護。在解密路徑上鏡像加密端修正：在 crypto_aead_decrypt（） 之前取得網路參照 （如果無法取得，則以 -ENODEV 失敗，並放置相符的持有人），將其保留在 -EINPROGRESS/-EBUSY 非同步傳回中，並在同步成功/錯誤傳回時和 tipc_aead_decrypt_done（） 結尾使用 put_net（） 將其刪除。在 v7.1-rc7 的 KASAN 下重現：具有叢集金鑰的 UDP 承載被來自未知對等體的特製加密框架淹沒（驅動叢集金鑰解密路徑），而承載的 netns 被反覆拆除。完成必須以非同步方式執行，才能超過tipc_crypto_stop（）;在 x86 上，庫存 AESNI GCM（AES） 現在會同步解密，因此非同步路徑是透過 cryptd 卸載來執行的。tipc_aead_decrypt_done（） 中不受保護的 aead->crypto 解除參照是未修補的上游路徑;tipc_aead_decrypt（） 仍然缺少 maybe_get_net（aead->crypto->net），因此在 crypto_aead_decrypt（） 非同步的任何配置上，完成時間都可能超過釋放時間。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。（CVE-2026-63801）

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

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

  - drm/amdgpu/vce：防止部分位址修補 如果只有一個 lo/hi 有效，修補可能會導致 FW 中寫入錯誤位址。（CVE-2026-53375）

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

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

  - NFSD：在延遲的回寫錯誤上重設寫入驗證程式 nfsd_vfs_write（） 和 nfsd_commit（） 都會呼叫 filemap_check_wb_err（） 來偵測延遲的回寫錯誤，但當此檢查失敗時，兩者都不會輪替伺服器的寫入驗證程式 （nn->writeverf）。這些函式中的所有其他持久儲存失敗路徑都會在傳回錯誤之前呼叫 commit_reset_write_verifier（）。遺漏的輪替表示在目前驗證程式下保留 UNSTABLE 寫入資料的用戶端將認可、接收未變更的驗證程式，並得出結論，其資料是持久性的，以無訊息的方式捨棄回寫失敗的資料。這違反了 UNSTABLE+COMMIT 持久性合約 （RFC 1813 3.3.7、RFC 8881 18.32）。在兩個 filemap_check_wb_err（） 錯誤站點新增 commit_reset_write_verifier（） 呼叫，以符合相同函式中相鄰錯誤路徑所使用的模式。協助程式已經在內部篩選了 -EAGAIN 和 -ESTALE，因此呼叫是無條件安全的。（CVE-2026-53393）

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

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

  - net：airoha：不要讀取 airoha_dev_xmit（） 中未初始化的片段位址 airoha_dev_xmit（） 中的傳輸迴圈在其最終迭代期間讀取片段位址和長度，當迴圈索引等於 skb_shinfo（skb）->nr_frags 時，此時片段資料被取消初始化。雖然永遠不會使用這些值，但讀取本身是不安全的，可能會觸發頁面錯誤。若要修正此問題，請避免在上次反覆運算時讀取片段。此外，將 skb 指標從第一個到最後一個使用的封包描述元移動，以便 airoha_qdma_tx_napi_poll（） 延遲釋放 skb，直到處理最終描述元為止。（CVE-2026-63857）

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

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

  - drm/amdgpu/jpeg：設定 JPEG v3.0 環的no_user_fence JPEG 環不支援 64 位元使用者圍欄寫入，拒絕帶有使用者圍欄的 CS 提交。（從提交 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef 中挑選）（CVE-2026-63846）

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

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

  - ocfs2：拒絕過大的群組點陣圖描述元 ocfs2_validate_gd_parent（） 僅針對父配置器的鏈幾何圖形bg_bits邊界。惡意描述元仍可宣告超過實際適合群組描述元區塊的點陣圖位元組的 bg_size/bg_bits 配對，因此稍後的點陣圖掃描和位元更新可能會在bg_bitmap之後執行。針對父配置器類型新增基於 ocfs2_group_bitmap_size（） 的實體上限檢查，並拒絕其bg_size或bg_bits超過該容量的描述元。保留現有的鏈結幾何檢查，讓磁碟上的點陣圖配置和配置器中繼資料都必須同意，才能使用描述元。驗證重現了此核心報告：KASAN 在
    _find_next_bit+0x7f/0xc0 讀取大小 8 呼叫追蹤：dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xd0/0x630 （？：？） _find_next_bit+0x7f/0xc0 （？：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？）
    __virt_addr_valid+0x188/0x2f0 （？：？） kasan_report+0xe4/0x120 （？：？） ocfs2_find_max_contig_free_bits+0x35/0x70 （fs/ocfs2/suballoc.c：1375） ocfs2_block_group_set_bits+0x472/0x4b0 （fs/ocfs2/suballoc.c：1457） ocfs2_cluster_group_search+0x16b/0x440 （fs/ocfs2/suballoc.c：86） ocfs2_bg_discontig_fix_result+0x1ef/0x230 （fs/ocfs2/suballoc.c：1786） ocfs2_search_chain+0x8f8/0x10a0 （fs/ocfs2/suballoc.c：1886） get_page_from_freelist+0x70e/0x2370 （？：?)lock_release+0xc6/0x290 （？：？） do_raw_spin_unlock+0x9a/0x100 （？：？） kasan_unpoison+0x27/0x60 （？：？）
    __bfs+0x147/0x240 （？：？） get_page_from_freelist+0x83d/0x2370 （？：？） ocfs2_claim_suballoc_bits+0x38c/0xe70 （fs/ocfs2/suballoc.c：96） sched_domains_numa_masks_clear+0x70/0xd0 （？：？） check_irq_usage+0xe8/0xb70 （？：？）
    __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c：？）down_write+0xf5/0x180 （？：？） ocfs2_write_begin+0x180/0x240 （fs/ocfs2/suballoc.c：？） __mark_inode_dirty+0x758/0x9a0 （？：？） inode_to_bdi+0x41/0x90 （？：？） balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 （？：？） generic_perform_write+0x252/0x440 （？：？） mnt_put_write_access_file+0x16/0x70 （？：？） file_update_time_flags+0xe4/0x200 （？：？） ocfs2_file_write_iter+0x80a/0x1320 （fs/ocfs2/suballoc.c：?)lock_acquire+0x184/0x2f0 （？：？） ksys_write+0xd2/0x170 （？：？） apparmor_file_permission+0xf5/0x310 （？：？） read_zero+0x8d/0x140 （？：？） lock_is_held_type+0x8f/0x100 （？：？）（CVE-2026-63796）

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

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

  - 藍牙：ISO：使用 iso_pi（sk）->dst、iso_pi（sk）->src 和 iso_pi（sk）->src_type 來修正hci_get_route呼叫 iso_connect_bis（）、iso_listen_bis iso_connect_cis（） 和 iso_conn_big_sync（） 呼叫 hci_get_route（） 中iso_pi欄位的資料爭用，而不按住 lock_sock（）。這些欄位可能會由相同通訊端上的 connect（） 或 setsockopt（） 同時修改，導致 KCSAN 報告資料爭用。
    在呼叫 hci_get_route（） 之前，先對 lock_sock（） 下的必要欄位進行快照，以修正此問題。錯誤：KCSAN：
    來源不明的 memcmp+0x45/0xb0 爭用中的數據爭用，CPU 1 上的任務 333 讀取到 1 位元組的0xffff8880122135cf：memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110
    __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f （CVE-2026-63871）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: serialize volume label accesses Protect vol->volume_label with a mutex and snaphost the label before copy_to_user. This prevent a use-after-free when FS_IOC_SETFSLABEL replaces the vol->volume_label and FS_IOC_GETTSLABEL reads it concurrently. (CVE-2026-63793)

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

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

  - net： ip_gre：需要在裝置 netns 中CAP_NET_ADMIN以用於 changelink 通道 changelink（） 最多在兩個 netn 上運行，即 dev_net（dev） 和通道連結 netns t->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查CAP_NET_ADMIN，因此在 t->net 中具有權限但不在 t-net 中的呼叫者可以重寫位於 t->net 中的隧道。在 net/core/rtnetlink.c 中的 rtnl_get_net_ns_capable（） 旁邊新增 rtnl_dev_link_net_capable（）。它需要在連結 netns 中CAP_NET_ADMIN，當連結 netns 為 dev_net（dev） 時，會略過它，其中 rtnl 路徑已經檢查過它。此系列中的其他修補程式使用相同的協助程式。在剖析任何屬性之前，將 ipgre_changelink（） 和 erspan_changelink（） 放在操作的頂端，因為剖析器會先更新即時通道欄位。ipgre_netlink_parms（） 會在 ip_tunnel_changelink（） 執行之前設定 t->collect_md。提交 8b484efd5cb4 （ip6： vti：在 vti6_siocdevprivate（）.） 中使用 ip6_tnl.net。在 ioctl 路徑上新增了相同的檢查。這增加了RTM_NEWLINK。（CVE-2026-63829）

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

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

  - rpmsg： char：修正探查錯誤路徑上的釋放後使用 rpmsg_chrdev_probe（） 會在呼叫 rpmsg_chrdev_eptdev_add（） 之前，將新配置的 eptdev 儲存在預設端點的 priv 指標中。如果 rpmsg_chrdev_eptdev_add（） 隨後失敗，其錯誤路徑會釋放 eptdev，而預設端點仍可能使用過時的 priv 指標分派回呼。避免透過預設端點發佈 eptdev，直到 rpmsg_chrdev_eptdev_add（） 成功為止。在發佈 priv 指標之前收到的訊息應被 rpmsg_ept_cb（） 忽略。流量控制更新可能會在同一視窗中命中 rpmsg_ept_flow_cb（），因此當 priv 為 NULL 時，使兩個回呼都傳回成功。（CVE-2026-63797）

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

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

  - i2c： core：修正配接器註冊爭用 可以使用 i2c_get_adapter（） 根據配接器的 ID 查詢配接器，該 （） 會參照內嵌結構裝置。請確定配接器 （包括其結構裝置） 在將配接器新增至 IDR 之前已初始化，以避免存取未初始化的資料，例如可能導致 NULL 指標解除參照或釋放後使用。請注意，從匯流排通知程式註冊的 i2c-dev chardev 目前使用 i2c_get_adapter（），因此需要在註冊前將配接器新增至 IDR。（CVE-2026-53400）

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

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

  - fbdev：修正 store_modes（） 中的釋放後使用 store_modes（） 將 framebuffer 的 modelist 替換為來自使用者空間的模式。成功時，它會使用 fb_destroy_modelist（） 釋放舊的模式清單。有兩個欄位仍指向該釋放清單。其中一個指標是 fb_display[i].mode，這是主控台正在使用的模式。fbcon_new_modelist（） 會將這些指標移至新清單。它僅對仍映射到幀緩衝區的控制台執行此操作。系統會略過未對應的主控台，並保留其過時指標。例如，解除綁定 fbcon 會將 con2fb_map[i] 設定為 -1，但保留 fb_display[i].mode 設定。具有 FB_ACTIVATE_INV_MODE 的FBIOPUT_VSCREENINFO ioctl 稍後會到達 fbcon_mode_deleted（）。該函數通過 fb_mode_is_equal（） 讀取過時的 fb_display[i].mode。
    讀取是釋放後使用。另一個指標是 fb_info->mode，即目前模式。它是透過 mode sysfs 屬性設定的。store_modes（） 不會更新fb_info>模式，因此它會指向釋放清單。屬性的讀取處理常式 show_mode（） 透過 mode_string（） 解除參照過時的 fb_info-> 模式。讀取是釋放後使用。釋放清單之前，請先清除這兩個指標。提交 a1f305893074 （fbcon：釋放模式時將 fb_display[i]->mode 設定為 NULL） 新增了協助程式 fbcon_delete_modelist（）。它會清除指向給定清單的每個 fb_display[i].mode。到目前為止，它僅從取消註冊路徑呼叫。也從 store_modes（） 呼叫它，並將 fb_info->mode 設定為 NULL。
    (CVE-2026-63826)

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

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

  - keys： 在實例化路徑中釘選request_key_auth承載 A：request_key（） B：KEYCTL_INSTANTIATE_IOV ================ =========================建立驗證金鑰儲存區 在驗證金鑰中 等待協助程式 取得驗證金鑰 從驗證金鑰複製載入 RKA，使用者承載 #PF 協助程式上休眠 完成分離並釋放 rka 銷毀驗證金鑰喚醒 使用 rka->target_key **釋放後使用** 為request_key_auth負載提供參照計數。獲取承載參考，同時 authkey->sem 穩定承載和撤銷狀態。在實例和拒絕路徑中保留該參照。從撤銷和銷毀中刪除擁有參照的驗證金鑰。
    [jarkko：將前兩段文字替換為實際的並行案例。（CVE-2026-63823）

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

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

  - batman-adv： tp_meter：避免除以零 dec_cwnd cwnd 始終為 MSS <= cwnd <= 0x20000000。但 batadv_tp_update_cwnd（） 中的計算假設無符號 32 位算術。（（mss * 8） ** 2） / （cwnd * 8） 如果 cwnd 實際上0x20000000，它將向左移動 3 位，最終達到 0x100000000 或 U32_MAX + 1。因此，它會換行並變成 0 - 結果為：（（mss * 8） ** 2） / 0 這當然是無效的，無法計算。計算應該簡化以避免此溢位：（mss
    ** 2） * 8 / cwnd 它將保持縮放的精度增強（按 8），但避免除數中的溢位。從理論上講，股息仍可能溢出。目前已將其固定為在 batadv_tp_recv_ack（） 中BATADV_TP_PLEN - 因此這不是一個迫在眉睫的問題。但允許它使用整個 u32 位範圍，意味著它仍然可以使用多達 67 位。為了確保此計算對 32 位算術的安全，mss 不得使用超過 floor（（32 - 3） / 2） 位，換句話說：不得大於 16383。（CVE-2026-63836）

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

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

  - drm/amdkfd：新增 num_of_nodes drm/amdkfd：新增 kfd_ioctl_get_process_apertures_new 中 num_of_nodes 的上限檢查。（從提交 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f 中挑選）（CVE-2026-53376）

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

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

  - vc_screen：在並行vcs_write期間修正 vcs_notifier（） 中的 null-ptr-deref 在 vcs_notifier（） 中觀察到 KASAN null-ptr-deref： 錯誤： KASAN：vcs_notifier+0x98/0x130 中的 null-ptr-deref 在 addr qmp_cmd_name 處讀取大小為 2： qmp_capabilities， arguments： {} 問題是 vcs_write（） 中的爭用情形。當暫時刪除console_lock（以從使用者空間複製資料）時，從 vcs_vc（） 取得的vc_data指標可能會過時。重新取得鎖定之後，會再次呼叫 vcs_vc（） 以重新驗證指標。如果 vc 在此期間已被解除配置，則 vcs_vc（） 傳回 NULL，並且 while 迴圈中斷（寫入 > 0）。不過，在迴圈之後，仍會使用現在為 NULL 的 vc 指標呼叫 vcs_scr_updated（vc），導致通知程式鏈結中出現 NULL 指標解除參照 （vcs_notifier解除參照 param->vc）。在呼叫 vcs_scr_updated（） 之前新增 vc 的 NULL 檢查來修正此問題。（CVE-2026-53385）

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

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

  - batman-adv： v：防止停用 hardif 上的 OGM 聚合 當介面被停用時，工作者會透過 batadv_hardif_disable_interface（） -> ... -> batadv_v_ogm_iface_disable（） 正確停用。在此過程中，skb aggr_list也被釋放。但 batadv_v_ogm_send_meshif（） 仍然可以將新的 skb （透過 batadv_v_ogm_queue_on_if（）） 排入佇列到 aggr_list。只有在所有核心都無法再找到受 RCU 保護的硬介面清單時，這才會停止。這些排入佇列的 skb 永遠不會被batadv_v_ogm_aggr_work釋放或消耗。batadv_v_ogm_iface_disable（） 函式必須封鎖 batadv_v_ogm_queue_on_if（） 以避免 skb 洩漏。（CVE-2026-63835）

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

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

  - GCOV：使用不可部分完成計數器更新來修正並行存取損毀 GCC 的 GCOV 檢測可以將全域分支計數器與迴圈歸納變數合併作為最佳化。在 inflate_fast（） 中，內部複製迴圈會進行轉換，以便多次載入 GCOV 計數器值，以計算迴圈基位址、起始索引和結束界限。由於 GCOV 計數器是全域的 （不是每個 CPU），因此在不同 CPU 上並行執行會導致計數器在負載之間變更，從而產生不一致的值和越界記憶體寫入。當 inflate_fast（） 在多個 CPU 上同時執行時，會在 IPComp （IP 負載壓縮） 處理期間發生當機： 錯誤：無法處理位址的頁面錯誤：ffffd0a3c0902ffa RIP：
    inflate_fast+1431 呼叫追蹤：zlib_inflate __deflate_decompress crypto_comp_decompress ipcomp_decompress [xfrm_ipcomp] ipcomp_input [xfrm_ipcomp] xfrm_input 在損毀點，編譯器會從相同的全域 GCOV 計數器 （__gcov0.inflate_fast+216） 產生三個載入，以計算索引迴圈的基數、開始和結束。另一個 CPU 在載入之間修改計數器，使值不一致 - 寫入超過 3.4 65 KB 緩衝區的 MB。將 -fprofile-update=prefer-atomic 新增至頂層 Makefile 中全域層級的CFLAGS_GCOV，並由試用執行編譯測試保護。此測試使用完整KBUILD_CFLAGS編譯具有和不具有 -fprofile-update=prefer-atomic 的最小程式，然後比較產生的物件檔中未定義的符號。如果 prefer-atomic 引入新的未定義參照 （例如
    __atomic_fetch_add_8 在 i386 上或 __aarch64_ldadd8_relax 在 arm64 上使用 outline-atomics），則不會新增旗標 -- 核心不會連結到 libatomic。在 GCC 內嵌 64 位元不可部分完成計數器更新的架構 （x86_64、s390 等） 上，測試通過並啟用旗標，防止編譯器將計數器與迴圈誘導變數合併，並修正觀察到的並行存取損毀。在標誌會引入 libatomic 依賴項的架構上，它會被默默地省略，並且行為並不比此補丁之前差。將 CFLAGS_GCOV 區塊從其原始位置 （在 arch Makefile include 之前） 移動到核心KBUILD_CFLAGS指派之後，但在 scripts/Makefile.gcc-plugins include 之前。此放置可確保試用執行測試看到特定於 arch 的旗標 （-m32， -march=， -mno-outline-atomics），同時避免 GCC 外掛程式旗標 （-fplugin=），當外掛程式共用物件尚不存在時，會中斷全新組建的測試。（CVE-2026-63825）

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

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

  - KVM：將 ioeventfd 資料比對中的 guest-triggerable BUG_ON（） 替換為 get_unaligned（） 刪除自 2009 年首次新增以來一直可存取的 BUG_ON（），而是使用 get_unaligned（） 來執行可能未對齊的存取。對於指定的存放區，KVM x86 的模擬器會追蹤目的地運算元 x86_emulate_ctxt.dst 中的整個值。如果目的地是記憶體，且目標分割多個頁面和/或模擬 MMIO，則 KVM 會獨立處理每個片段。例如，在從頁面偏移0xffc開始的頁面分割中，KVM 將 4 個位元組寫入第一頁，然後將剩餘的位元組寫入第二頁，使用 ctxt->dst 作為兩者的來源（具有適當的偏移）。如果目的地分割頁面*並且*在第二頁上點擊模擬的MMIO，則KVM將完成對第一頁的寫入，然後模擬對第二頁的MMIO訪問。如果在第二頁的位移 0 處有啟用資料比對的 ioeventfd，則 KVM 會將存放區的其餘部分處理為潛在的 ioeventfd 訊號。總而言之，如果客體發出的儲存區從頁面偏移量 N 開始分割頁面，並且第二個頁面在偏移量 0 處具有啟用資料比對的 ioeventfd，則 KVM 將使用 &dst.valptr[N] 作為來源來檢查資料比對。由於 dst （以及 dst.valptr） 是 32 位元組對齊，如果 N 未與 @len 對齊，則會觸發 BUG_ON（）。例如，在頁面偏移0xffc處有一個 16 位元組的儲存區，到 len 8 的 ioeventfd，ioeventfd_in_range（） 中的所有初始檢查都會成功，並且 BUG_ON（） 會因為 @val 是 4 位元組對齊，但不是 8 位元組對齊而觸發的。------------[ 切到這裡 ]------------ arch/x86/kvm/ 的核心錯誤。/../../virt/kvm/eventfd.c：783！哎呀：無效的操作碼：0000 [#1] SMP CPU：0 UID：1000 PID：615 通訊：重現 未受污染 7.1.0-rc2-ff238429d1ea #365 PREEMPT 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009），BIOS 0.0.0 02/06/2015 RIP：0010：ioeventfd_write+0x6c/0x70 [kvm] 呼叫追蹤： <TASK> __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm]x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm]
    __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP：
    0033：0x7f19c931a9bf </TASK> 連結的模組：kvm_intel kvm irqbypass ---[ end trace 00000000000000000]--- 在完美的環境中，解決方法是簡單地刪除 BUG_ON（），因為 KVM x86 不會對 CPL0 的正常記憶體存取執行對齊檢查。可悲的是， C99 毀了所有的樂趣;雖然 x86 架構運作良好，但直接取消引用未對齊的指標在 C 中是未定義的行為，例如
    以 CONFIG_UBSAN_ALIGNMENT=y 執行時觸發 splats。 （CVE-2026-63806）

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

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

  - fbdev：修正fb_new_modelist以防止 info->var fb_videomode_to_var 中的 null-ptr-deref （影像緩衝區目前模式）應在 info->modelist 中具有相符的項目。var_to_display（） 依賴於此，並將失敗的 fb_match_mode（） 視為不應該發生。fb_set_var（） 透過在每次變更時將模式新增至清單來保持其真實性，而 do_register_framebuffer（） 在註冊時也會執行相同的操作。store_modes（） 取代了使用者空間中的模式清單。fb_new_modelist（） 會驗證新模式，但不會檢查 info->var 是否仍然相符。它依賴 fbcon_new_modelist（） 重新指向主控台，但這僅處理映射到幀緩衝區的主控台。使用未綁定的 fbcon 就沒有了，因此 info->var 只剩下描述一個不再在清單中的模式。稍後的主控台接管會執行 var_to_display（），其中 fb_match_mode（） 傳回 NULL 並將 fb_display[i].mode 保留為 NULL。fbcon_switch（） 將其傳遞給 display_to_var（），fb_videomode_to_var（） 解除參照 NULL 模式。在 fb_new_modelist（） 中保留清單中的目前模式，就像 fb_set_var（） 一樣。（CVE-2026-53403）

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

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

  - f2fs：驗證孤立的 inode 項目計數 f2fs_recover_orphan_inodes（） 在重播檢查點套件中的孤立 inode 時信任孤立區塊entry_count。大於 F2FS_ORPHANS_PER_BLOCK 的損毀entry_count會使復原迴圈讀取通過 ino[] 陣列，並將頁尾或後續資料解譯為 inode 編號。在特製的映像檔上，掛載未修補的核心可能會驅動孤立的復原到 f2fs_bug_on（） 中，並使核心出現錯誤。在使用項目之前先驗證entry_count，以便損毀的檢查點資料以 -EFSCORRUPTED 掛載失敗，並改為要求 fsck。也設定ERROR_INCONSISTENT_ORPHAN，以便可以在超級區塊 s_errors[] 欄位中記錄損毀原因。這會為 fsck 提供持續提示，即使裝載時孤立復原失敗可能沒有機會透過檢查點持續存在SBI_NEED_FSCK。（CVE-2026-63818）

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

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

  - net： skmsg：跨 SG 轉換保留 sg.copy sk_msg sg.copy 點陣圖是散佈清單項目擁有權狀態的一部分。設定位元告訴 sk_msg_compute_data_pointers（） 不要透過可寫入的 BPF ctx->data 公開項目。這可保護由非sk_msg專用頁面所支援的項目，例如拼接備份的檔案頁面快取頁面。數個sk_msg轉換路徑會移動、複製、分割或壓縮 msg->sg.data[] 項目，而不移動相符的 sg.copy 位元。這可使外部支援的項目到達具有清除複製位元的新插槽。然後，稍後的SK_MSG判定可以將 sg_virt（sge） 公開為可寫入的 ctx->data，而 BPF 儲存區可以修改原始頁面快取。每當項目被傳輸、移動、分割或複製到新sk_msg時，保持 sg.copy 與 sg.data[] 同步。當項目被新配置的私人頁面替換或釋放時，清除該位元。這涵蓋了 BPF pull/push/pop 協助程式、sk_msg_shift_left/right（）、sk_msg_xfer（） 和 tls_split_open_record（），包括在TLS開啟記錄分割期間建立的部分尾部項目。（CVE-2026-63830）

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

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

  - f2fs：修正因不正確的 nat_entry 旗標使用而導致的 fsck 不一致 f2fs_need_dentry_mark（） 讀取nat_entry旗標而不與檢查點路徑相互排除，這可能導致不正確的 inode 區塊標記狀態。場景如下： 建立 &; 寫入 &; fsync 'file A' 寫入檢查點 - f2fs_do_sync_file // 內嵌 inode - f2fs_write_inode // inode 作品集已髒 - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_fsync_node_pages // 沒有髒節點 - f2fs_need_inode_block_update // 返回 true - f2fs_fsync_node_pages // inode 已髒 - f2fs_need_dentry_mark //return true - f2fs_flush_nat_entries - f2fs_write_checkpoint end -
    __write_node_folio // inode 設定DENT_BIT_SHIFT SPO， fsck --dry-run find inode 已檢查點，但仍設定DENT_BIT_SHIFT f2fs_need_dentry_mark（） 觀察到的狀態可能與取得 sbi->node_write 後在 __write_node_folio（） 中觀察到的狀態不同。根本原因是只有在檢查點寫入完全完成後，才能保證IS_CHECKPOINTED和HAS_FSYNCED_INODE的語意。此修補程式將 set_dentry_mark（） 移至 __write_node_folio（），並使用 sbi->node_write 鎖定對其進行保護。（CVE-2026-53368）

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

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

  - IIO：輕度：VEML6075：將邊界檢查新增至索引veml6075_it_ms veml6075_it_ms有 5 個元素，但VEML6075_CONF_IT可以產生值 0-7。如果傳回值 >= 5，則會導致越界陣列存取。新增邊界檢查，如果索引超出範圍，則傳回 -EINVAL。問題值是保留的，因此絕不應該從暫存器讀取。因此，這是針對故障設備、錯誤編程或總線損壞的強化。（CVE-2026-53387）

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

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

  - KVM： SVM：修正 sev_dbg_crypt（） 中 ENCRYPT 路徑的頁面溢位 在 sev_dbg_crypt（） 中，每次反覆運算的傳輸長度受來源頁面位移 （PAGE_SIZE - s_off） 限制，但不受目的地頁面位移 （PAGE_SIZE - d_off） 的限制。d_off > s_off時，加密路徑 （__sev_dbg_encrypt_user） 會使用單頁中間緩衝區 （dst_tpage） 執行讀取-修改-寫入：1. __sev_dbg_decrypt（） 在發出 PSP 命令之前，將大小擴展為 round_up（len + （d_off &; 15）， 16）。如果 len + （d_off &; 15） > PAGE_SIZE，則 PSP 的寫入範圍超過 4096 位元組dst_tpage配置的結尾。2. 在相同條件下，後續的 memcpy（）/copy_from_user（） 轉換為 page_address（dst_tpage） + （d_off &; 15） 的 'len' 位元組最多會溢位 15 個位元組。觸發器範例：s_off = 0， d_off = 1， debug.len = PAGE_SIZE - PSP 被指示將 round_up（4097， 16） = 4112 位元組寫入 4096 位元組緩衝區。透過將 len 定為 （PAGE_SIZE - d_off） 來修正，這與 sev_send_update_data（） 已針對其單頁客體區域執行的檢查相同。================================================================== 錯誤： KASAN：sev_dbg_crypt+0x993/0xd10 中的 slab-use-after-free [kvm_amd] 任務 sev_dbg_test/228214 在 addr ff110062293bb009 寫入大小 4095 CPU：96 UID：0 PID：228214 通訊：sev_dbg_test 污染：G U W 7.0.0-smp-- 5ce9b0c48211-dbg #156 PREEMPTLAZY 污染：[U]=USER， [W]=WARN 硬體名稱：Google Astoria/astoria，BIOS 0.20250817.1-0 08/25/2025 呼叫追蹤： <TASK> dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [KVM] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> 有錯誤的位址屬於實體頁面： page： refcount：： 1 mapCount：0 mapping：00000000000000000000 index：0x7fe72b6a0 pfn：0x62293bb memcg：ff11000112827d82 flags： 0x1400000000000000（node=1|zone=1） raw： 140000000000000000000000000 dead00000000000000122 0000000000000000000 raw： 000000007fe72b6a0 000000000000000000 000000001ffffffffff ff11000112827d82 頁面轉儲原因：KASAN：偵測到錯誤存取 錯誤位址周圍的記憶體狀態：ff110062293bbf00：
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000： fa fb fb fb fb fb fc ^ ff110062293bc080： fa fb fb fb fc fc ff110062293bc100： fa fb fb fb fb fb fb fb fb fc fc fc ================================================================== 由於核心污染而停用鎖定除錯 [sean：新增範例 KASAN splat、修正和stable@] （CVE-2026-63794）

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

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

  - FUSE：在取代頁面快取對開本之前重新鎖定要求 fuse_try_move_folio（） 會在進入時解除鎖定要求，但不會在成功路徑上重新鎖定要求。這意味著 fuse_chan_abort（） 可以結束請求並釋放fuse_io_args（例如 fuse_readpages_end（）），而 fuse_try_move_folio（） 之後的後續複製鏈邏輯存取fuse_io_args，從而導致釋放後使用問題。透過在 replace_page_cache_folio（） 之前呼叫 lock_request（） 來解決此問題。這可確保要求鎖定在成功路徑上，以防止在稍後的複製邏輯執行時釋放fuse_io_args，並且也可確保 ap->folios[i]->映射永遠不會為 null，因為 ap->folios[i] 一律會在 replace_page_cache_folio（） 之後指向 newfolio。（CVE-2026-53388）

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

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

  - pNFS：修正 pnfs_update_layout（） 中的釋放後使用：當命中 pnfs_update_layout（） 中的 NFS_LAYOUT_RETURN 分支時，程式碼會呼叫 pnfs_prepare_to_retry_layoutget（lo）。如果成功，則會在 trace_pnfs_update_layout（） 之前呼叫 pnfs_put_layout_hdr（lo），而 （） 仍會參照 'lo'。當追蹤點存取 lo 的欄位時，這會導致釋放後使用。透過將追蹤點呼叫移動到 pnfs_put_layout_hdr（lo） 之前來修正此問題。（CVE-2026-63800）

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

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

  - 已解決 Linux 核心中的下列弱點：iio: adc: ti-ads1298: add bounds check to pga_settings index ads1298_pga_settings has 7 elements but ADS1298_MASK_CH_PGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system. (CVE-2026-53386)

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

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

  - drm/amdgpu/vcn：設定 VCN v2.5 enc/dec 環的no_user_fence VCN 編碼器和解碼器環不支援 64 位元使用者柵欄寫入，拒絕具有使用者柵欄的 CS 提交。（從提交 efc9dd5590894109bce9a0bfe1fa5592dd6b20b1 中挑選）（CVE-2026-63855）

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

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

  - fbdev：omap2：修正 omapfb_mmap omapfb_mmap（） 中的釋放後使用與 ioctl 有爭用情形OMAPFB_SETUP_PLANE可能導致釋放後使用：fb_mmap（） 進入點保留mm_lock但不鎖定 （fb_info->lock），而 ioctl 處理常式 （如 OMAPFB_SETUP_PLANE） 保持鎖定但不mm_lock。這允許並行執行。在 omapfb_mmap（） 中： 1. rg = omapfb_get_mem_region（ofbi->region）;獲取舊區域參考 2。開始 = omapfb_get_region_paddr（ofbi）;從新區域 3 閱讀。len = fix->smem_len;從新區域 4 閱讀。vm_iomap_memory（vma， start， len）;映射新區域記憶體 5.atomic_inc（&rg->map_count）;增量舊區域！同時，OMAPFB_SETUP_PLANE可以： - 重新分配 ofbi->region = new_rg - 更新 fix->smem_len - 然後OMAPFB_SETUP_MEM檢查新區域的map_count （0！） 並釋放它 這會留下使用者空間與釋放實體記憶體的對應。修正是從相同的區域參照 （rg） 讀取所有必要的值 （start、len），該區域參照 （rg） 的 map_count 將遞增，以防止在仍對應時釋放區域。(CVE-2026-53401)

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

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

  - batman-adv： tp_meter：限制未確認清單項目的數量 當unacked_list未綁定時，攻擊者可以發送長度較小的訊息，並挪用 seqno + 間隙，以強制接收者配置越來越多的unacked_list項目。最終要么導致內存不足情況，要么增加（大）列表的管理開銷，以至於在搜索列表中浪費了大部分 CPU 週期。將清單限制為特定數字時，請務必正確地將新項目新增至清單。但是，如果清單變得大於限制，則必須捨棄清單的最後一個項目 （具有最高的 seqno），以仍允許較早的 seqno 完成，因此繼續處理程序。否則，處理程序可能會因 batadv_tp_ack_unordered（） 未處理的過高 seqnos 而停滯。（CVE-2026-63834）

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

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

  - media：vidtv：修正 syzbot 在 vidtv_psi_ts_psi_write_into [1] 中報告一般保護錯誤vidtv_mux_push_si中的 NULL 指標解除參照。vidtv_mux_get_pid_ctx（） 可以傳回 NULL，但 vidtv_mux_push_si（） 在取消引用傳回的指標以存取連續性計數器之前不會檢查這一點。這會導致存取接近 NULL 位址時的一般保護錯誤。根本原因是 vidtv_mux_pid_ctx_init（） 不會檢查 PMT 區段 PID 的 vidtv_mux_create_pid_ctx_once（） 傳回值。如果配置失敗，則永遠不會建立 PID 內容，但 init 會傳回成功。隨後的 vidtv_mux_push_si（） 呼叫接著從 vidtv_mux_get_pid_ctx（） 取得 NULL 並當機。修正根本原因（在vidtv_mux_pid_ctx_init中新增 PMT PID 的錯誤檢查），並在vidtv_mux_push_si為所有 vidtv_mux_get_pid_ctx（） 呼叫新增防禦性 NULL 檢查。[1] 哎呀：一般保護錯誤，可能針對非規範位址 0xdffffc0000000000：0000 [#1] SMP KASAN PTI KASAN：範圍內的 null-ptr-deref [0x0000000000000000-0x0000000000000007] 工作佇列：事件vidtv_mux_tick RIP：
    0010：vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c：197 呼叫追蹤：
    <TASK> vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c：799 [內嵌] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c：1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c：196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c：408 （CVE-2026-53382）

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

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

  - nfsd：修正 SETACL 解碼失敗 nfsaclsvc_decode_setaclargs（） 和 nfs3svc_decode_setaclargs（） 每次調用 nfs_stream_decode_acl（） 兩次的posix_acl洩露，首先是 NFS_ACL，然後是 NFS_DFACL。每個成功的呼叫都會將新配置posix_acl的所有權轉移到 argp->acl_access 或 argp->acl_default。如果第一個呼叫成功，但第二個呼叫失敗，解碼器會傳回 false，且 argp->acl_access 會懸空。ACLPROC2_SETACL.pc_release 已連線至 nfssvc_release_attrstat，ACLPROC3_SETACL.pc_release 已連線至 nfs3svc_release_fhandle。兩者都只調用 fh_put（），並且不知道 argp 上的 ACL 欄位。posix_acl_release（） 對位於 out：標籤位於 nfsacld_proc_setacl（） 和 nfsd3_proc_setacl（） 內，但當 pc_decode svc_process（） 傳回 false 時，（） 會跳過pc_func，因此解碼失敗時無法進行清理： svc_process_common（） pc_decode（） /* decode_setaclargs： false */ /* pc_func跳過 */ pc_release（） /* 僅fh_put -- ACL 洩漏 */ 孤立的posix_acl在伺服器的生命週期內洩露。透過新增 nfsaclsvc_release_setacl（） 和 nfs3svc_release_setacl（） 來修正，除了 fh_put（） 之外，它們還會釋放 argp->acl_access 和 argp->acl_default，並將它們作為各自 SETACL 程序的pc_release進行連線。pc_release 會在解碼後 svc_process（） 所採用的每條路徑上運行，包括解碼失敗，因此 posix_acl_release（） 對會從 proc 函式的 out： 標籤中移除，以將所有權保留在一個地方。這符合同級 GETACL 程序所使用的現有 release_getacl（） 模式。（CVE-2026-53397）

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

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

  - virtiofs：修正子掛載上的 UAF，如果超級區塊已經被破壞，則從 fuse_release_end（） 調用的 umount iput（） 可能會哎呀。通常，在開始超級區塊關閉之前，等待num_waiting降至零可以防止這種情況發生。不過，這僅適用於最後一個子掛載執行個體，因為等待計數器是每個連線，而不是每個超級區塊。還原為針對auto_submounts情況使用同步釋放要求，目前僅為虛擬狀態。（CVE-2026-53381）

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

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

  - crypto： nx - 修正nx_crypto_ctx_exit引數nx_crypto_ctx_shash_exit使用 crypto_shash_ctx（...） 調用 nx_crypto_ctx_exit，但crypto_shash_ctx給出nx_crypto_ctx *，而不是crypto_tfm *。修正nx_crypto_ctx_exit中的類型並刪除虛假crypto_tfm_ctx呼叫。這修正了以下 oops： 錯誤：無法在 0xc0403effffffffc8 處理核心資料存取 錯誤指令位址：0xc000000000396cb4 哎呀：
    錯誤區域的核心存取，sig：11 [#15] 呼叫追蹤：nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 ..它來自 hardlink（1） 機會主義地使用 AF_ALG。nx_crypto_ctx_skcipher_exit獲得一個它沒有預料到的上下文也存在同樣的問題，但顯然多年來沒有人遇到這種情況。（CVE-2026-63805）

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

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

  - Netty 是用於開發通訊協定伺服器和用戶端的網路應用程式架構。在 4.1.136.Final 和 4.2.16.Final 之前，io.netty.handler.codec.stomp.StompSubframeDecoder 無法限制標頭總數或每幀的累積大小，而且 maxLineLength 參數僅限制個別標頭行。攻擊者可以傳送大量短標頭，這些標頭會累積在 DefaultStompHeadersSubframe 內的記憶體中，直到 JVM 擲回 OutOfMemoryError，從而對公開基於 StompSubframeDecoder 的 STOMP 端點的伺服器造成拒絕服務。此問題已在 4.1.136.Final 版和 4.2.16.Final 版中修正。(CVE-2026-44891)

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

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

  - urwid Web 顯示後端 （urwid/display/web.py） 透過連接兩個使用 Python 的 Mersenne Twister PRNG 的 random.randrange（10**9） 呼叫，在 Screen.start（） 中產生 Web 工作階段識別碼 （urwid_id），這在加密上並不安全。每次呼叫消耗大約 30 位元 PRNG 狀態，而 Mersenne Twister 內部狀態約為 19,937 位元，因此觀察到大約 334 個會話 ID 的攻擊者 （例如透過 X-Urwid-ID HTTP 回應標頭） 可以完全重建內部狀態並預測所有過去和未來的會話 ID （路徑 B）。相同的識別碼也用作在全球可列出的 /tmp 目錄中建立的 FIFO 檔案名稱 （例如 /tmp/urwid375487765176907690.in），因此主機上的任何本機使用者都可以列出 /tmp 以直接列舉作用中的工作階段權杖 （路徑 A）。使用有效的工作階段 ID，攻擊者可以透過輪詢端點讀取受害者的終端螢幕，將擊鍵注入受害者的工作階段（如果工作階段執行 shell，則以工作階段所有者的權限執行作業系統級程式碼），並注入退出序列或淹沒 FIFO 以終止或崩潰工作階段。先前關於此用法的 Bandit S311 警告已使用 # noqa 隱藏：
    S311 而不是固定 （CVE-2026-9323）

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

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

  - SimpleSAMLphp 之前的版本 1.18.6 包含資訊洩漏弱點。在 2.4.7 和 2.5.2之前，當未簽名的 Response/InResponseTo 與缺少 SubjectConfirmationData/InResponseTo 的已簽名判斷提示相結合時，SimpleSAMLphp 的 SAML SP ACS 路徑不會強制為 SP 啟動的登入選擇的 IdP，從而允許一個受信任 IdP 發出的回應繫結到為另一個 IdP 建立的 SP 狀態，並繞過將使用者路由到特定 IdP 的流程， 包括將 enable_unsolicited 設為 false 的部署。此問題已在 2.4.7 和 2.5.2 版中修正。(CVE-2026-49284)

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

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

  - pyzipper 是 Python zipfile 的替代品，可以讀取和寫入 AES 加密的 zip 檔案。之前， 0.4.0pyzipper/zipfile_aes.py 中的 Python 運算子優先順序錯誤導致在加密期間永遠不會自動選擇 AE-2 格式，導致加密條目以 AE-1 格式編寫，並在 ZIP 標頭中暴露純文字 CRC32 總和檢查碼，對於無法搜尋的 zip 檔案，在 datadescripter 部分，允許擁有檔案的攻擊者透過比較 CRC32 值來暴力破解小型或低熵檔案的候選純文字。0.4.0 版已修正此問題。
    (CVE-2026-44722)

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

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

  - rust-openssl 為 Rust 程式設計語言提供 OpenSSL 系結。從 0.10.50 直到 0.10.80，openssl/src/cipher_ctx.rs 中的 CipherCtxRef：：cipher_update_inplace 與 AES key-wrap-with-padding 加密一起使用時，輸出緩衝區的大小不正確 EVP_aes_{128,192,256}_wrap_pad。對於非 8 的倍數輸入，OpenSSL 會在呼叫端緩衝區或 Vec 結尾之後寫入最多 7 個位元組，當純文字長度受到攻擊者影響時，會產生攻擊者可控制的堆積損毀。0.10.80 版已修正此問題。
    (CVE-2026-45784)

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

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

  - oras-go 是用於管理 OCI 構件的 Go 程式庫。在之前 2.6.1，content/file/file.go 中的 resolveWritePath（） 使用詞彙檔案路徑。Rel 檢查 workingDir，且不考慮符號連結遊走，因此當 AllowPathTraversalOnWrite=false 時，攻擊者會透過 ocispec 控制 blob 標題。AnnotationTitle （例如 out/pwn.txt） 可以遵循 workingDir 符號連結 out -> /some/outside/dir，並導致 pushFile（） 在 workingDir 之外建立 /some/outside/dir/pwn.txt。2.6.1 版已修正此問題。(CVE-2026-50162)

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

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

  - oras-go 是用於管理 OCI 構件的 Go 程式庫。之前， 2.6.1blobStore.completePushAfterInitialPost 中的 registry/remote/repository.go 會在整合型 blob 上傳期間遵循登錄控制的位置標頭，並將初始 POST 要求中的 Authorization 標頭重複用於後續 PUT 要求，允許惡意登錄傳回跨主機位置，並在攻擊者控制的端點接收呼叫端的憑證。2.6.1 版已修正此問題。(CVE-2026-50151)

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

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

  - oras-go 是用於管理 OCI 構件的 Go 程式庫。在 之前， 2.6.1驗證。用戶端會遵循登錄檔 WWW-Authenticate： Bearer 挑戰中的領域 URL，而不驗證配置或主機，允許惡意或遭入侵的登錄檔將 SSRF 降級至內部網路 （例如 http://169.254.169.254/、 http://10.0.0.x/和 http://127.0.0.1/），或透過 Client.Do（）、Client.fetchBearerToken（）、fetchDistributionToken 和 fetchOAuth2Token 將透過 https:// 連線的登錄降級至 registry/remote/auth/client.go 中的 http:// 權杖端點。2.6.1 版已修正此問題。(CVE-2026-48978)

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

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

  - PyMdown Extensions 是「Python-Markdown」Markdown 專案的一組擴充。在受影響的版本中，使用包含檔案語法時，可能會發生任意檔案讀取。透過使用語法「--8<--/etc/passwd」或「--8<--/proc/self/environ」語法，這些檔案的內容將呈現在產生的文件中。此外，相對於指定允許的基底路徑的路徑也可用於轉譯指定基底路徑之外的檔案內容：'--8<-- ../../../../etc/passwd'。
    在程式碼片段延伸模組中，存在「base_path」選項，但實作容易受到目錄遊走的影響。易受攻擊的區段存在於 snippets.py 中第 155 至 174 行的「get_snippet_path（self， path）」中。執行外掛程式的主機上的任何可讀檔案都可能公開其內容。
    這可能會影響任何將程式碼片段的使用暴露給外部使用者的程式碼片段使用。絕不建議使用程式碼片段來處理面向使用者的動態內容。它旨在在主機的控制下處理後端的已知內容，但如果有人不小心為面向使用者的內容啟用了它，則可能會暴露不需要的資訊。此問題已在 10.0 版中解決。建議所有使用者進行升級。無法升級的使用者可能會透過篩選輸入來限制相對路徑。（CVE-2023-32309）

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

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

  - secure_headers 管理具有許多安全預設值的安全標頭的應用。在之前 7.3.0，secure_headers 會透過使用 ; 分隔符號拼接指令來建置 Content-Security-Policy 值，並build_sandbox_list_directive、build_media_type_list_directive和 build_report_to_directive 插入呼叫端提供的字串，而不使用清理 ;、 \r或 \n。當不受信任的輸入到達 ：sandbox、:p lugin_types 或 ：report_to 的 SecureHeaders.override_content_security_policy_directives 或附加 API 時，攻擊者可以在合法的 script-src 之前插入 CSP 指令 （例如 script-src 'unsafe-inline' *），透過這些接收或 CSP 報告洩漏啟用 XSS 連線能力。7.3.0 版已修正此問題。(CVE-2026-54163)

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

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

  - joserfc 是一個 Python 程式庫，可提供數個 JSON 物件簽署和加密 (JOSE) 標準的實作。在 1.6.8之前，當調用方提供的驗證金鑰是空字串或 None 時，joserfc.jwt.decode 會接受攻擊者偽造的 HMAC 簽署權杖，因為 src/joserfc/_rfc7518/jws_algs.py 中的 HMACAlgorithm.sign 和 HMACAlgorithm.verify 會將 OctKey.get_op_key（...） 的輸出傳遞至 hmac.new（...），而 src/joserfc/_rfc7518/oct_key.py 中的 OctKey.import_key 只會針對短於 14 位元組的金鑰發出 SecurityWarning，而不會拒絕零長度輸入。1.6.8 版已修正此問題。
    (CVE-2026-49852)

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

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

  - websocket-driver 是具有可插拔 I/O 的 WebSocket 通訊協定處理常式。 0.7.5之前 ，如果此程式庫與 permessage-deflate 延伸搭配使用，則可以讓 WebSocket 伺服器或用戶端接受大於所設定訊息大小上限的訊息，因為會根據訊息框架的長度標頭檢查限制，這會提供壓縮資料的大小， 不是 lib/websocket/driver/hybi.js 中解壓縮後的大小。這可能導致應用程式接受比預期更大的訊息，並超出其預期的資源使用量。0.7.5 版已修正此問題。(CVE-2026-54490)

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

ID	名稱	嚴重性
327863	Linux Distros 未修補弱點：CVE-2026-63831	high
327862	Linux Distros 未修補弱點：CVE-2026-63827	high
327861	Linux Distros 未修補弱點：CVE-2026-63858	high
327860	Linux Distros 未修補弱點：CVE-2026-63801	high
327859	Linux Distros 未修補弱點：CVE-2026-53375	high
327858	Linux Distros 未修補弱點：CVE-2026-53393	medium
327857	Linux Distros 未修補弱點：CVE-2026-63857	critical
327856	Linux Distros 未修補弱點：CVE-2026-63846	high
327855	Linux Distros 未修補弱點：CVE-2026-63796	high
327854	Linux Distros 未修補弱點：CVE-2026-63871	medium
327853	Linux Distros 未修補弱點：CVE-2026-63793	high
327852	Linux Distros 未修補弱點：CVE-2026-63829	high
327851	Linux Distros 未修補弱點：CVE-2026-63797	high
327850	Linux Distros 未修補弱點：CVE-2026-53400	high
327849	Linux Distros 未修補弱點：CVE-2026-63826	high
327848	Linux Distros 未修補弱點：CVE-2026-63823	high
327847	Linux Distros 未修補弱點：CVE-2026-63836	high
327846	Linux Distros 未修補弱點：CVE-2026-53376	medium
327845	Linux Distros 未修補弱點：CVE-2026-53385	medium
327844	Linux Distros 未修補弱點：CVE-2026-63835	medium
327843	Linux Distros 未修補弱點：CVE-2026-63825	critical
327842	Linux Distros 未修補弱點：CVE-2026-63806	high
327841	Linux Distros 未修補弱點：CVE-2026-53403	medium
327840	Linux Distros 未修補弱點：CVE-2026-63818	high
327839	Linux Distros 未修補弱點：CVE-2026-63830	critical
327838	Linux Distros 未修補弱點：CVE-2026-53368	high
327837	Linux Distros 未修補弱點：CVE-2026-53387	high
327836	Linux Distros 未修補弱點：CVE-2026-63794	high
327835	Linux Distros 未修補弱點：CVE-2026-53388	high
327834	Linux Distros 未修補弱點：CVE-2026-63800	critical
327833	Linux Distros 未修補弱點：CVE-2026-53386	high
327831	Linux Distros 未修補弱點：CVE-2026-63855	high
327830	Linux Distros 未修補弱點：CVE-2026-53401	high
327829	Linux Distros 未修補弱點：CVE-2026-63834	medium
327828	Linux Distros 未修補弱點：CVE-2026-53382	medium
327827	Linux Distros 未修補弱點：CVE-2026-53397	high
327826	Linux Distros 未修補弱點：CVE-2026-53381	high
327825	Linux Distros 未修補弱點：CVE-2026-63805	high
327823	Linux Distros 未修補弱點：CVE-2026-44891	high
327792	Linux Distros 未修補弱點：CVE-2026-9323	critical
327791	Linux Distros 未修補弱點：CVE-2026-49284	high
327790	Linux Distros 未修補弱點：CVE-2026-44722	medium
327789	Linux Distros 未修補弱點：CVE-2026-45784	medium
327787	Linux Distros 未修補弱點：CVE-2026-50162	medium
327786	Linux Distros 未修補弱點：CVE-2026-50151	high
327785	Linux Distros 未修補弱點：CVE-2026-48978	low
327784	Linux Distros 未修補弱點：CVE-2023-32309	high
327783	Linux Distros 未修補弱點：CVE-2026-54163	medium
327782	Linux Distros 未修補弱點：CVE-2026-49852	high
327781	Linux Distros 未修補弱點：CVE-2026-54490	medium

偵測

Nessus 的 Misc. 系列

high

high

high

high

high

medium

critical

high

high

medium

high

high

high

high

high

high

high

medium

medium

medium

critical

high

medium

high

critical

high

high

high

high

critical

high

high

high

medium

medium

high

high

high

high

critical

high

medium

medium

medium

high

low

high

medium

high

medium