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

  - Erlang OTP public_key （pubkey_cert 和 public_key 模組） 中的不當憑證驗證弱點允許在主機名稱驗證中透過主體 CommonName 後援繞過 DNS nameConstraints TLS。
    兩個缺陷結合在一起，允許其 DNS nameConstraints 受到限制的次級 CA （例如
    允許的;DNS：allowed.example.com） 以核發 OTP TLS 用戶端接受的分葉憑證作為超出範圍主機名稱 （例如 victim.example.com） 的有效身分： 首先，lib/public_key/src/pubkey_cert.erl 中的 pubkey_cert：validate_names/6 僅根據 nameConstraints 檢查 SAN DNS 項目。根據 RFC 5280，允許的 DNS 子樹狀結構僅限制包含 DNS 類型名稱的憑證。因此，沒有 subjectAltName 的葉子會簡單地滿足任何允許的條件;DNS：...條件約束，無論其主體 commonName 為何。其次，當不存在 subjectAltName 時，lib/public_key/src/public_key.erl 中的 public_key：pkix_verify_hostname/3 會回復到主體 commonName，將 id-at-commonName 屬性擷取為呈現的 ID，並將它們與參照主機名稱進行比對。嚴格的 pkix_verify_hostname_match_fun（https） 比對器不會隱藏此後援。結果是路徑驗證接受 DNS 限制的中間下僅限 CN 的分葉 （沒有 SAN 表示不會觸發 nameConstraints），然後主機名稱驗證會透過 CN 後援接受它。可從庫存 ssl：connect 使用 verify_peer、受信任的CA、SNI 和規範的嚴格 https 主機名稱匹配器來存取繞過。此問題會影響 OTP 19.3 之前的 OTP 29.0.1、 OTP 28.5.0.1、 OTP 27.3.4.12 和 OTP 26.2.5.21，對應public_key 1.4 於之前 1.21.1的 、 1.20.3.1和 1.17.1.31.15.1.7。
    (CVE-2026-42790)

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

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

  - f2fs：修正節點區塊 FGGC 引起的 fsck 不一致 在 FGGC 節點區塊移轉期間，fsck 可能會錯誤地將移轉的節點區塊視為 fsync 寫入的資料。複製場景：
    root@vm：/mnt/f2fs# seq 1 2048 |xargs -n 1 ./test_sync // 寫入內嵌 inode 並同步 root@vm：/mnt/f2fs# rm -f 1 root@vm：/mnt/f2fs# 同步 root@vm：/mnt/f2fs# f2fs_io gc_range // 在同步模式下移動資料區塊而不寫入 CP SPO， fsck --dry-run find inode 已檢查點但仍設定DENT_BIT_SHIFT 根本原因是 GC 在節點區塊遷移期間未清除 dentry 標記和 fsync 標記， 導致 fsck 將它們誤解為使用者發出的 fsync 寫入。在 BGGC 模式下，節點區塊遷移由 f2fs_sync_node_pages（） 處理，這保證了在寫入之前清除 dentry 和 fsync 標記。
    此修補程式將 fsync|dentry 標記的 set/clear 移至 __write_node_folio，以使邏輯更清晰，並確保在 FGGC 中清除 fsync|dentry 標記。（CVE-2026-46175）

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

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

  - hfsplus：透過驗證目錄記錄大小來修正 uninit-value Syzbot 報告了 hfsplus_strcasecmp（） 中的 KMSAN uninit-value 問題。根本原因是 hfs_brec_read（） 不會驗證磁碟上的記錄大小是否符合所讀取記錄類型的預期大小。掛載損毀的檔案系統時，hfs_brec_read（） 讀取的資料可能比預期少。例如，讀取型錄執行緒記錄時，除錯輸出顯示： HFSPLUS_BREC_READ： rec_len=520， fd->entrylength=26 HFSPLUS_BREC_READ： 警告 - entrylength （26） < rec_len （520） - 部分讀取！hfs_brec_read（） 只會驗證 entrylength 是否不大於緩衝區大小，但不會檢查它是否小於預期。它成功將 26 個位元組讀取到 520 位元組結構中並傳回成功，留下 494 個位元組未初始化。然後，tmp.thread.nodeName 中的此未初始化資料會由 hfsplus_cat_build_key_uni（） 複製並由 hfsplus_strcasecmp（） 使用，當未初始化的位元組在 case_fold（） 中用作陣列索引時，會觸發 KMSAN 警告。透過引入 hfsplus_brec_read_cat（） 包裝函式來修正： 1. 呼叫 hfs_brec_read（） 讀取資料 2.根據類型欄位驗證記錄大小： - 資料夾和檔案記錄的固定大小 - 執行緒記錄的可變大小 （取決於字串長度） 3.如果大小不符合預期，則傳回 -EIO 針對執行緒記錄，請在讀取 nodeName.length 之前檢查 HFSPLUS_MIN_THREAD_SZ，以避免在未初始化項目結構的呼叫網站上讀取未初始化的資料。同時將 hfsplus_find_cat（） 中的 tmp 變數初始化為防禦性程式設計，以確保即使繞過驗證也沒有未初始化的資料。（CVE-2026-46169）

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

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

  - SPI： cadence-quadspi：修正解除綁定時的未計時存取 在驅動程式解除綁定期間停用控制器之前，請確定控制器已繼續執行階段，以避免暫存器存取未計時。Sashiko 在檢閱控制器取消註冊修正程式時，已標記此問題。（CVE-2026-46203）

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

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

  - KVM：x86：修正由於意外的 GFN 而導致的陰影分頁釋放後使用 影子 MMU 使用 sp->gfn 加上 SPTE 索引計算直接影子頁面的 GFN。如果在虛擬機器項目之間修改客體頁面表格，則此假設會中斷影子分頁 （類似於提交 aad885e77496，KVM：x86/mmu：即使建立 MMIO SPTE 時，也會刪除/zap 現有的現有 SPTE，2026-03-27）。流程如下： - 針對 2MB 對映安裝偏微分方程，並存取該區域中的頁面。KVM 建立一個由 512 個 4KB 頁面組成的kvm_mmu_page;kvm_mmu_page被 FNAME（fetch） 標記為直接映射，因為客體的映射是一個巨大的頁面（因此是連續的）。- PDE 對映會從客體外部變更。- 訪客存取相同 2MB 區域中的另一個頁面。KVM 會安裝新的葉子 SPTE 和 rmap 項目;SPTE 使用正確的 GFN （即基於新映射，如上一步中所更改），但該 GFN 超出 [sp->gfn， sp->gfn + 511] 範圍;因此，當 zapped 時，無法找到並移除 rmap 項目kvm_mmu_page。- 覆蓋前 2MB 映射的內插槽被刪除，並且現在無效的 GPA 的kvm_mmu_page被刪除。但是，rmap_remove（） 只會查看步驟 1 中建立的 [sp->gfn， sp->gfn + 511] 範圍，找不到步驟 3 所記錄的 rmap 項目。- 針對步驟 3 所存取之相同頁面造成 rmap 遍歷的任何作業，然後遍歷過時的 rmap 並取消參照已釋放的kvm_mmu_page。這包括髒記錄或 MMU 通知程式無效 （例如，來自 MADV_DONTNEED）。根本問題是，KVM 的影子 PTE 行走假設，如果 KVM 想要安裝非葉 SPTE 時存在 SPTE，則現有kvm_mmu_page必須用於正確的 gfn。因為 gfn 出錯的唯一方法是 KVM 搞砸並且無法電擊 SPTE...這不應該發生，但是
    *實際上* 只會在回應來賓寫信時發生。這個錯誤實際上可以追溯到永遠，因為即使是 KVM 的第一個版本也假設 GFN 匹配並進入錯誤的影子頁面。然而，這只是一個不精確性，直到 2032a93d66fa（KVM：MMU：不要為直接 mmu 頁面分配 gfns 頁面）出現。透過檢查目標 gfn 不相符並刪除現有 SPTE 來修正它。這樣舊的 SP 和 rmap 條目就消失了，KVM 將 rmap 安裝在正確的位置，每個人都很高興。
    (CVE-2026-46113)

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

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

  - RDMA/hns：修正對 hns_roce_qp_remove（） 的解鎖呼叫 Sashiko 指出，hns_roce_qp_remove（） 要求呼叫者持有鎖定。hns_roce_create_qp_common（） 中的錯誤流程不會保留錯誤展開的這些鎖定，因此有損毀記憶體的風險。抓住其他兩個呼叫者使用的相同鎖。
    (CVE-2026-46112)

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

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

  - nvmet-tcp：修正 ICReq 處理與佇列拆卸之間的爭用 nvmet_tcp_handle_icreq（） 在傳送初始化連線回應 （ICResp） 之後更新佇列>狀態，但它不會針對目標端佇列拆卸進行序列化。如果 NVMe/TCP 主機發送初始化連接請求 (ICReq) 並立即關閉連接，則目標端拆卸可能會在 io_work 清空已緩衝的 ICReq 之前在 softirq 上下文中開始。在這種情況下，nvmet_tcp_schedule_release_queue（） 將 queue->state 設定為 NVMET_TCP_Q_DISCONNECTING，並將佇列參照放在 state_lock 下。如果io_work稍後處理該 ICReq，nvmet_tcp_handle_icreq（） 仍然可以將狀態覆寫回 NVMET_TCP_Q_LIVE。
    這會破壞 nvmet_tcp_schedule_release_queue（） 中的 DISCONNECTING-state guard，並允許稍後的通訊端狀態變更重新進入拆卸，並在已釋放的佇列上發出第二個 kref_put（）。ICResp 傳送失敗路徑也有相同的問題。如果拆卸操作已將佇列移至 DISCONNECTING，則傳送錯誤仍可將狀態覆寫為 NVMET_TCP_Q_FAILED，從而再次開啟窗口，允許第二次拆卸操作丟棄佇列引用。透過序列化使用 state_lock 的傳送後狀態轉換來修正此問題，並在拆卸已開始時退出。使用 -ESHUTDOWN 作為該救援路徑的內部哨兵，而不是將其傳播為傳輸錯誤，例如 -ECONNRESET。在接受該哨兵之前，將 nvmet_tcp_socket_error（） 設定rcv_state保持為NVMET_TCP_RECV_ERR，因此接收端剖析會保持靜止狀態，直到現有的發行路徑完成為止。（CVE-2026-46135）

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

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

  - Bluetooth： virtio_bt：在 skb_put virtbt_rx_work（） 呼叫 skb_put （skb， len） 之前限制 rx 長度，其中 len 直接來自 virtqueue_get_buf（），沒有針對我們張貼到裝置的緩衝區進行驗證。RX skb 在 virtbt_add_inbuf（） 中分配，並透過 sg_init_one（） 以 1000 位元組的形式暴露給 virtio。
    根據 skb_tailroom（skb） 檢查 len 是不夠的，因為 alloc_skb（） 可能會留下比實際交給設備的 1000 位元組更多的尾部空間。因此，惡意或有錯誤的後端可以報告 1001 和 skb_tailroom（skb） 之間的 used.len，導致 skb_put（） 包含裝置從未寫入的未初始化核心堆位元組。相同的路徑也接受 len == 0，在這種情況下，skb_put（skb， 0） 將 skb 留空，但 virtbt_rx_handle（） 仍從 skb->data 讀取 pkt_type 位元組，消耗未初始化的記憶體。定義一次VIRTBT_RX_BUF_SIZE並在 alloc_skb（） 和 sg_init_one（） 中重複使用它，並在相同的常數上門 virtbt_rx_work（），以便綁定檢查與實際暴露給設備的緩衝區相匹配。拒絕同一閘道中的 used.len == 0，以便空完成無法再到達 virtbt_rx_handle（）。使用 bt_dev_err_ratelimited（），因為長度值來自不受信任的後端，否則可能會溢流核心記錄。與提交 c04db81cd028 的錯誤類別相同 （net/9p：修正 USB 傳輸層中的緩衝區溢位），其針對未檢查的裝置報告長度強化了 USB 9p 傳輸。（CVE-2026-46123）

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

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

  - ipv6： xfrm6：當 skb 尚未附加 DST 時，xfrm6_rcv_encap（） 中出錯時釋放 DST xfrm6_rcv_encap（） 會執行 IPv6 路由查詢。ip6_route_input_lookup（） 會傳回參照的 dst 項目，即使查詢解析為錯誤路由也是如此。如果設定了 dst->error，xfrm6_rcv_encap（） 會刪除 skb，而不將 dst 附加到 skb，也不會釋放查詢傳回的參照。因此，重複封包到達此路徑會洩漏 dst 項目。在跳到掉落路徑之前釋放 dst。
    (CVE-2026-46172)

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

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

  - wifi：brcmfmac：修正停止監控程式任務時潛在的釋放後使用問題 監控程式任務可能會在 send_sig（） 和 kthread_stop（） 呼叫之間結束，從而導致釋放後使用問題。透過在呼叫 send_sig（） 之前增加監控程式任務參照計數並切換到 kthread_stop_put（） 來刪除它來解決此問題。（CVE-2026-46180）

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

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

  - 之前 29.0.2在 OpenStack Keystone 中發現問題。Keystone應用程式認證驗證外掛程式不會驗證驗證要求中提供的使用者是否符合應用程式認證的擁有者。攻擊者可以使用自己的應用程式認證 ID 和密碼進行驗證，同時在要求內文中指定不同的使用者名稱和網域。Keystone 會發出歸因於受害使用者的權杖。模擬的權杖是專案範圍的，並帶有應用程式認證角色與受害者在專案上的實際角色的交集。這可以避免稽核規避、讀取受害者的憑證，並在共用專案中充當受害者。
    (CVE-2026-42998)

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

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

  - RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 即使在套用提交 7244491dab34 （RDMA/rxe：在 rxe_rcv 中的 payload_size（） 之前驗證 pad 和 ICRC）之後，單一未經驗證的 UDP 封包仍然可能觸發錯誤。該修補程式僅處理具有短封包的有效操作碼的 payload_size（） 反向溢位，而不處理攜帶未知操作碼的封包。下面所述的未知操作碼 OOB 讀取早於該認可，並返回初始軟式 RoCE 驅動程式。新增的檢查為 pkt->paylen < header_size（pkt） + bth_pad（pkt） + RXE_ICRC_SIZE其中 header_size（pkt） 展開為 rxe_opcode[pkt->opcode].length。rxe_opcode[]陣列有 256 個項目，但僅針對定義的 IB 操作碼填充;任何其他項目（例如操作碼 0xff）都是零初始化的，因此長度 == 0，檢查退化為 pkt->paylen < 0 + bth_pad（pkt） + RXE_ICRC_SIZE，這對 pkt->paylen 的約束不夠。
    然後rxe_icrc_hdr（） 計算 rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES，當長度 == 0 時，該值會下溢，並將一個巨大的值傳遞給 rxe_crc32（），從而導致 skb 負載的越界讀取。在套用該修正的 v7.0-rc7 上重現，具有 CONFIG_RDMA_RXE=y 和 CONFIG_KASAN=y 的 QEMU/KVM，在 rdma 連結後新增 rxe0 類型 rxe netdev eth0 單一 48 位元組 UDP 封包到連接埠 4791，BTH opcode=0xff 和 QPN=IB_MULTICAST_QPN 觸發： 錯誤：KASAN：在 crc32_le+0x115/0x170 中出現 slab-out-of-bounds 在 addr 處讀取大小為 1 ... 有錯誤的位址位於配置的 704 位元組區域呼叫追蹤的右側 0 位元組：
    crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 具有相同形狀的後續封包會在未對應的記憶體上出錯，並使核心發生錯誤。觸發器只需要模組載入和 rdma 連結新增;
    沒有 QP、沒有連線、也沒有驗證。透過拒絕操作碼沒有 rxe_opcode[] 條目的封包來解決此問題，這些封包是透過零遮罩或零長度在執行任何長度算術運算之前偵測到的。
    (CVE-2026-46133)

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

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

  - USB： usblp：透過 LPGETSTATUS ioctl 修正未初始化的堆積洩漏 就像在此驅動程式中的先前問題中一樣，usblp_ctrl_msg（） 會將 usb_control_msg（） 傳回值摺疊為 0/-errno，捨棄實際傳輸的位元組數。理想情況下，應該檢測到該短命令並出錯，但眾所周知，許多打印機會發回不正確的響應，因此我們不能就這樣這樣做。statusbuf 在探測時為 kmalloc（8），且在第一個 LPGETSTATUS ioctl 之前從未填入。usblp_read_status（） 要求 1 個位元組。如果惡意印表機以零位元組回應，則 *statusbuf 是一個位元組的過時 kmalloc 堆積，簽署延伸至本機 int 狀態，然後 LPGETSTATUS 路徑會直接將其copy_to_user （） 給 ioctl 呼叫端。
    只需在探測時分配記憶體緩衝區時刪除記憶體緩衝區即可解決所有問題。如果稍後的呼叫進行簡短讀取，則資料將與裝置上次傳送的資料相同，因此不會發生資訊洩漏。（CVE-2026-46167）

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

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

  - RDMA/mlx4：修正 mlx4_ib_create_srq（） 錯誤時的資源洩漏 Sashiko 指出，在錯誤展開期間，mlx4_srq_alloc（） 未撤銷，請將缺少的呼叫新增至 mlx4_srq_free（）。（CVE-2026-46178）

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

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

  - ASoC： qcom： q6apm-lpass-dai： 修正多個圖形開啟 由於準備可以稱為多個時間，因此可能會導致播放路徑的多個圖形開啟。這將導致記憶體洩漏，請透過在開啟前新增檢查來解決此問題。（CVE-2026-46143）

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

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

  - eventfs：重新掛載遍歷事件時保留 eventfs_mutex 和 SRCU 提交 340f0c7067a9 （eventfs：更新事件描述元中的所有eventfs_inodes） 在重新掛載時透過 ei->children 遞迴 eventfs_set_attrs（）。遍歷僅包含 tracefs_apply_options（） 在 tracefs_inodes 上所採取的 rcu_read_lock（），這是錯誤的： - list_for_each_entry over ei->children 與 eventfs_remove_rec（） 中的 list_del_rcu（） 爭用 -- LIST_POISON1 deref，形狀與 d2603279c7d6 相同。- eventfs_inodes透過 call_srcu（&eventfs_srcu， ...） 釋放。rcu_read_lock（） 不會延長 SRCU 寬限期，因此可以在遍歷下回收 ti->private。- 寫入 ei->attr 與 eventfs_set_attr（） 爭用，該爭用保留eventfs_mutex。Reproduction： while ：;do mount -o remount，uid=$((RANDOM%1000)） /sys/kernel/tracing;完成 & while ：;執行 echo p：kp submit_bio > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done 將 tracefs_apply_options（） 的事件部分包裝在接受 eventfs_mutex 和 srcu_read_lock（&eventfs_srcu） 的 eventfs_remount_lock（）/_unlock（） 中。
    eventfs_set_attrs（） 不休眠，所以巢狀 rcu_read_lock（） 沒問題;lockdep_assert_held（） 釘選合約。tracefs_drop_inode（） 中的評論說 RCU 週期——它是 SRCU。（CVE-2026-46106）

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

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

  - ipmi：si：如果訊息配置失敗，則將狀態還原為正常 如果訊息配置失敗，有些地方將不會啟動任何動作，因此驅動程式必須返回正常狀態。（CVE-2026-46108）

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

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

  - batman-adv：在網格拆解期間停止tp_meter工作階段 在網路連結請求完成後，TP 儀表工作階段在 bat_priv->tp_list 上保持連結。移除網格介面後，batadv_mesh_free（） 目前會拆除網格，而不先排空這些工作階段。然後，執行中的傳送者執行緒或延遲傳入的tp_meter封包可以繼續針對已關閉的網狀執行個體進行處理。停止 batadv_mesh_free （） 的所有作用中工作階段，並等候傳送端執行緒結束，才能繼續拆卸，以將tp_meter與網格存留期同步。（CVE-2026-46208）

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

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

  - mm/damon/sysfs-schemes：使用 damon_sysfs_lock 修補程式系列保護 memcg_path kfree（） mm/damon/sysfs-schemes：修正 [memcg_]path 的釋放後使用。讀取 DAMON sysfs 介面中的「memcg_path」和「path」檔案可能會與其寫入爭用，從而導致釋放後使用。修正這些問題。此修補程式（共 2 個）：
    使用者可以透過 DAMON sysfs memcg_path檔案讀取和寫入 damon_sysfs_scheme_filter->mmecg_path。
    也可以間接讀取它，用於提交給 DAMON 的參數 {on，off}line。參數提交的讀取受 damon_sysfs_lock 保護，以避免在讀取任何參數時銷毀 sysfs 檔案。但使用者驅動的直接讀取和寫入不受任何鎖定保護，而寫入會解除配置memcg_path指向緩衝區。因此，讀取器可以讀取已釋放的緩衝區 （釋放後使用者）。請注意，由於 kernfs 的開啟檔案鎖定，當寫入器使用相同的開啟檔案時，使用者讀取不會爭用。儘管如此，使用單獨的打開文件進行讀取和寫入是很常見的。使用 damon_sysfs_lock 保護使用者直接讀取和寫入來修正此問題。（CVE-2026-46121）

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

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

  - drm/amdgpu/vcn4：剖析 dec msg 時防止 OOB 讀取 每當我們存取訊息時，都會檢查 BO 結尾的邊界。CVE-2026-46199

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

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

  - drm/amdgpu/sdma4：在柵欄排放中將 BUG_ON 替換為 WARN_ON sdma_v4_0_ring_emit_fence（） 包含兩個 BUG_ON（addr &; 0x3） 判斷提示，用於驗證柵欄回寫位址是否與 DWORD 對齊。您可以透過特製的 DRM_IOCTL_AMDGPU_CS 提交從無權限的使用者空間存取這些判斷提示，從而在排程器工作執行緒中造成致命的核心錯誤。將兩個 BUG_ON（） 呼叫替換為 WARN_ON（），以記錄條件而不使核心損毀。此時未對齊的柵欄位址表示驅動程式錯誤，但當可從使用者空間存取判斷提示時，當機核心永遠不會是正確的回應。CS IOCTL 路徑是篩選無效提交的正確位置;環形發射回調為時已晚，無法採取任何措施。（從提交 b90250bd933afd1ba94d86d6b13821997b22b18e 中挑選）（CVE-2026-46220）

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

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

  - batman-adv：在拆卸期間拒絕新的tp_meter工作階段 防止tp_meter在mesh_state離開BATADV_MESH_ACTIVE後啟動新的傳送者或接收者工作階段。（CVE-2026-46206）

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

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

  - tracepoint：在 tracepoint_add_func（） 中的 func_add（） 失敗時平衡 regfunc（） 當追蹤點經歷 0 -> 1 轉換時，tracepoint_add_func（） 會呼叫子系統的 ext->regfunc（），然後再嘗試透過 func_add（） 安裝新的探測。如果 func_add（） 隨後失敗（例如，當 allocate_probes（） 無法在記憶體壓力下配置新的探查陣列並傳回 -ENOMEM 時），則函數傳回錯誤而不呼叫相符的 ext->unregfunc（），從而留下 regfunc（） 的副作用，而沒有安裝探查來證明它們的合理性。對於系統調用追蹤點來說，這尤其令人不快：syscall_regfunc（） 會在每個任務上sys_tracepoint_refcount並設定SYSCALL_TRACEPOINT。
    在洩漏失敗之後，參照計數會停滯在非零值且沒有消費者，而且每個工作都會繼續支付系統呼叫追蹤進入/結束額外負荷，直到重新啟動為止。提供 regfunc（）/unregfunc（） 對的其他子系統表現出類似範圍的持久性狀態。鏡像現有的 1 -> 0 清除，並在 func_add（） 錯誤路徑中呼叫 ext->unregfunc（），以相同的條件進行門控，以便展開與註冊對稱。（CVE-2026-46196）

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

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

  - RDMA/mana：修正 mana_ib_create_qp_rss（） 中的錯誤展開 Sashiko 指出 mana_ib_cfg_vport_steering（） 被洩露，正常的銷毀路徑會清理它。（CVE-2026-46144）

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

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

  - spi：microchip-core-qspi：手動控制內建 cs coreQSPI IP 僅支援單一晶片選擇，該晶片由硬體自動操作 - 當傳輸緩衝區首次寫入傳輸緩衝區時設定為低電平，當寫入 FRAMES 暫存器 TOTALBYTES 欄位的位元組數已在匯流排上傳送時設定為高電平。其他裝置必須使用 GPIO 來選擇晶片。據我報告，如果有兩個設備連接到此 QSPI 控制器，則當 linux 嘗試訪問連接到 GPIO 的設備時，內置芯片選擇設置為低。這沒有被發現，因為將多個設備連接到 SPI 控制器的板都專門使用 GPIO 進行芯片選擇，根本不依賴內置芯片選擇。事實證明，這是因為內建晶片選擇在自動控制時，在活動時設定為低電平，在非活動時設定為高電平，從而排除了其用於高電平有效裝置或需要在停用晶片選擇的情況下傳輸的裝置。修改驅動程式，使其直接控制晶片選擇，並在exec_op回呼的整個傳輸期間將晶片選擇設定為作用中的mem_ops行為。對於定期傳輸，請實作核心要使用的set_cs回呼。作為其中的一部分，現有的設定回呼 mchp_coreqspi_setup_op（） 會被移除。當有多個裝置時，在操作期間修改 CLKIDLE 欄位並不安全，因此會完全移除此程式碼。設定 MASTER 和 ENABLE 欄位可以在探測時完成一次，不需要為每個裝置重新執行。相反，新的設定回調會針對/裝置將內建晶片選擇設定為非活動狀態，因為軟體控制模式下晶片選擇的重設值較低。（CVE-2026-46148）

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

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

  - Bluetooth： btmtk：在結構存取之前驗證 WMT 事件 SKB 長度 btmtk_usb_hci_wmt_sync（） 將 WMT 事件回應 SKB 資料轉換為結構 btmtk_hci_wmt_evt （7 位元組） 和結構 btmtk_hci_wmt_evt_funcc （9 位元組），而無需先檢查 SKB 是否包含足夠的資料。短韌體回應會導致來自 SKB 尾部的越界讀取。使用 skb_pull_data（） 來驗證並前進通過基底 WMT 事件標頭。針對FUNC_CTRL情況，請先提取其他狀態欄位位元組，再存取它們。
    (CVE-2026-46140)

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

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

  - dm-thin：修正中繼資料參照計數反向溢位 dm-thin 的函式rebalance_children中有一個錯誤。如果內部 btree 節點有一個項目，則程式碼會嘗試將所有 btree 項目從節點的子節點複製到節點本身，然後遞減子節點的參照計數。如果子節點是共用的 （它的參照計數> 1），我們不會釋放它，因此每個孫節點都會有兩個指標。
    但孫子的參照計數不會增加，因此參照計數不符合指向孫子的指標數目。這會導致裝置對應程式：空間映射通用：
    無法遞減區塊錯誤。如果共用 btree 節點，則透過增加孫子上的參照計數來修正此錯誤。（CVE-2026-46107）

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

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

  - wifi： b43：對 b43_rx（） 中的韌體金鑰索引強制執行邊界檢查 b43_rx（） 中的韌體控制金鑰索引可能超過 dev->key[] 陣列大小 （58 個項目）。現有B43_WARN_ON在生產組建中不強制執行，因此允許越界讀取。當韌體傳回無效的金鑰索引時，捨棄框架，以強制執行B43_WARN_ON檢查。（CVE-2026-46122）

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

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

  - fbcon：如果主控台輪替失敗，請避免 OOB 字型存取 如果主控台輪替期間的重新配置在 fbcon_rotate_font（） 中失敗，請清除字型緩衝區。在此情況下，輪換緩衝區的 putcs 實作會提前傳回。有關示例，請參閱 [1]。目前，fbcon_rotate_font（） 會保留舊的緩衝區，對於旋轉的字體來說太小了。使用足夠高的字元代碼列印到旋轉的主控台會使字型緩衝區溢位。v2： - 修正提交訊息 （CVE-2026-46191） 中的錯別字

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

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

  - fanotify：修正權限事件的誤報 fsnotify_get_mark_safe（） 可能會針對不相關群組上的標記傳回 false，進而導致繞過權限檢查。透過略過不在目前群組中的分離標記來修正。（CVE-2026-46150）

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

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

  - ALSA：usb-audio：避免 convert_chmap_v3（） 中潛在的無限迴圈 convert_chmap_v3（） 有一個遞增大小為 cs_desc->wLength 的迴圈，但我們忘記驗證 cs_desc->wLength 本身，這可能會導致格式錯誤的描述元造成的潛在無限迴圈。新增適當的尺寸檢查以中止堵塞孔的環路。（CVE-2026-46146）

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

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

  - media： rc： xbox_remote：注意 DMA 限制 IO 的緩衝區不得是裝置結構的一部分，因為這會違反 DMA 一致性規則。（CVE-2026-46236）

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

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

  - btrfs：修正移除目錄時遺失的 last_unlink_trans 更新 移除目錄時，我們不會更新其 last_unlink_trans 欄位，這可能會導致不正確的 fsync 行為，以防有人在刪除目錄後對其進行 fsync，因為它包含檔案描述元。範例場景：
    mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # 對目錄進行一些更改並對其進行同步。chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # 將 dir2 移出 dir1，使 dir1 變為空。mv /mnt/dir1/dir2 /mnt/dir3/ 在 /mnt/dir1 上開啟 fd 調用路徑上的 rmdir（2） /mnt/dir1 fsync fd <trigger power failure> 嘗試掛載檔案系統時，記錄重播將失敗並出現 -EIO 錯誤，並且 dmesg/syslog 具有以下內容： [445771.626482] BTRFS 資訊 （裝置 dm-0）：首次掛載檔案系統 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS 資訊 （裝置 dm-0）：使用 crc32c 總和檢查碼演算法 [445771.627912] BTRFS 資訊 （裝置 dm-0）： 啟動樹狀結構記錄重播 [445771.628335] 頁面：
    refcount：2 mapcount：0 mapping：0000000061443ddc index：0x1d00 pfn：0x7072a5 [445771.629453] memcg：ffff89f400351b00 [445771.629892] aops：btree_aops [btrfs] ino：1 [445771.630737] 旗標：
    0x17fffc00000402a（uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff）[445771.632359] raw：
    017fffc00000402a ffffff47284d950c8 ffff472907b7c08 ffff89f458e412b8 [445771.633713] raw： 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff89f400351b00 [445771.635029] 頁面轉儲，因為：eb 頁面轉儲 [445771.635825] BTRFS 嚴重 （裝置 dm-0）：損毀的葉：root=5 block=30408704 slot=10 ino=258，無效的 nlink：有 2 個預期目錄不超過 1 [445771.638088] BTRFS 資訊 （裝置 dm-0）：葉30408704 Gen 10 總 PTR 17 可用空間 14878 所有者 5 [445771.638091] BTRFS 資訊 （裝置 dm-0）： 參照 4 lock_owner 0 目前3581087 [445771.638094] 項目 0 鍵 （256 INODE_ITEM 0） itemoff 16123 項目大小 160 [445771.638097] inode 第 3 代 傳輸 9 大小 16 nbytes 16384 [445771.638098] 區塊群組 0 模式 40755 連結 1 uid 0 gid 0 [445771.638100] rdev 0 序列 2 旗標 0x0 [445771.638102] atime 1775744884.0 [445771.660056] ctime 1775744885.645502983 [445771.660058] mtime 1775744885.645502983 [445771.660060] otime 1775744884.0 [445771.660062] 項目 1 鍵 （256 INODE_REF 256） itemoff 16111 項目大小 12 [445771.660064] 索引 0 name_len 2 [445771.660066] 項目 2 鍵 （256 DIR_ITEM 1843588421） ItemOff 16077 項目大小 34 [445771.660068] 位置鍵 （259 1 0） 類型 2 [445771.660070] 傳輸鍵 9 data_len 0 name_len 4 [445771.660075] 項目 3 鍵 （256 DIR_ITEM 2363071922） 項目關閉 16043 項目大小 34 [445771.660076] 位置鍵 （257 1 0） 類型 2 [445771.660077] 傳輸 9 data_len 0 name_len 4 [445771.660078] 項目 4 鍵 （256 DIR_INDEX 2） 項目關閉 16009 項目大小 34 [445771.660079] 位置鍵 （257 1 0） 類型 2 [445771.660080] 傳輸 9 data_len 0name_len 4 [445771.660081] 項目 5 鍵 （256 DIR_INDEX 3） itemoff 15975 項目大小 34 [445771.660082] 位置鍵 （259 1 0） 類型 2 [445771.660083] 傳輸 9 data_len 0 name_len 4 [445771.660084] 項目 6 鍵 （257 INODE_ITEM 0） 項目關閉 15815 項目大小 160 [445771.660086] inode 第 9 代 傳輸 9 大小 8 nbytes 0 [445771.660087] 區塊群組 0 模式 40777 連結 1 uid 0 gid 0 [445771.660088] rdev 0 序列 2 旗標 0x0 [445771.660089] atime 1775744885.641174097 [445771.660090] ctime [] mtime 1775744885.6455029831775744885.645502983 [445771.660091445771.660105] otime [445771.6601061775744885.641174097] 項目 7 鍵 （257 INODE_REF 256） 項目關閉 15801 項目大小 14 [445771.660107] 索引 2 name_len 4 [445771.660108] 項目 8 鍵 （257 DIR_ITEM 2676584006） 項目關閉 15767 項目大小 34 [445771.660109] 位置鍵 （2 ---truncated--- （CVE-2026-46160）

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

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

  - KVM： x86：在慢速排清超調用中檢查 nEPT/nNPT 檢查 is_guest_mode （vcpu） 不正確，因為 translate_nested_gpa（） 僅在 L2 客體正在執行時 *啟用了巢狀 EPT/NPT* 時有效。請改用與 translate_nested_gpa（） 本身相同的條件。（CVE-2026-46131）

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

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

  - drm/amdgpu/vcn3： 剖析 dec 訊息時防止 OOB 讀取 每當我們存取訊息時，檢查 BO 結尾的邊界。CVE-2026-46230

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

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

  - drm/xe：修正 xe_gem_prime_import（） 中的 dma-buf 附件洩漏 當 xe_dma_buf_init_obj（） 失敗時，不會分離來自 dma_buf_dynamic_attach（） 的附件。傳回錯誤之前新增 dma_buf_detach（）。
    注意：我們不能在這裡使用 goto out_err，因為 xe_dma_buf_init_obj（） 已經在失敗時釋放了 bo，out_err會雙重釋放它。（從提交 a828eb185aac41800df8eae4b60501ccc0dbbe51 中挑選）（CVE-2026-46201）

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

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

  - 之前 29.0.2在 OpenStack Keystone 中發現問題。當與應用程式認證模擬弱點結合使用時，具有專案成員角色的攻擊者可以透過將不受限制的應用程式認證與 Keystone 信任鏈結來升級為管理員。模擬的權杖帶有受害者的身份，該身份通過了委託人驗證檢查。然後，Keystone 會根據受害者在資料庫中的實際角色指派來驗證委派的角色、而不是要求權杖上的角色。這允許攻擊者建立信任，將受害者的管理員角色委派給自己。信任會獨立保存，而且可以建立其他信任和應用程式憑證來維持存取權。所有操作都會以受害者的身分記錄。（CVE-2026-43000）

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

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

  - ipmi：檢查事件訊息緩衝區回應是否有錯誤資料 稍後會在處理時檢查事件訊息緩衝區回應資料大小，但在回應傳回後立即檢查。某些 BMC 在擷取事件時可能會傳回空白訊息，而不是錯誤。顯然有一些新的 BMC 會犯這個錯誤，所以我們需要補償。（CVE-2026-46128）

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

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

  - 之前 29.0.2在 OpenStack Keystone 中發現問題。enforce_call中的Keystone RBAC原則執行器會透過policy_dict.update（json_input.copy（）無條件地將原始JSON要求內文合併到原則強制執行字典中、覆寫先前從資料庫查詢中設定的受信任目標資料。由於 flask.request.get_json 是使用 force=True 調用，因此無論 Content-Type 或 HTTP 方法如何，這都有效。任何經過驗證的使用者都可以將任意原則目標屬性 （例如 user_id、project_id） 插入要求本文，以繞過 RBAC 檢查，並對屬於其他使用者或專案的資源執行未經授權的作業。這是在提交 5ea59f52 （Rocky/14.0.0） 中引入的。
    (CVE-2026-42999)

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

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

  - wifi： rsi：修正 self-exit 和 external-stop RSI 驅動程式之間的 kthread 存留期爭用，在終止 kthread 時同時使用 self-exit（kthread_complete_and_exit） 和 external-stop （kthread_stop）。通常首先調用 kthread_stop（），在這種情況下，不會出現任何特定問題。但是，在極少數情況下，先呼叫 kthread_complete_and_exit（），然後呼叫 kthread_stop（），會發生 UAF，因為再次存取已經退出並釋放的 kthread 物件。因此，若要以最少的修改來防止此情況發生，您必須移除 kthread_stop（） 並將程式碼變更為等到自我退出作業完成。（CVE-2026-46187）

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

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

  - RDMA/ocrdma：不要對 ocrdma_copy_pd_uresp（） 中的錯誤解除引用 uctx 為 NULL Sashiko 指出，pd->uctx 直到函式後期才初始化，因此所有這些錯誤流引用都是 NULL 並且會崩潰。
    使用非 NULL 的 uctx。（CVE-2026-46127）

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

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

  - riscv： kvm：修正向量內容分配洩漏 當第二個 kzalloc （host_context.vector.datap） 在 kvm_riscv_vcpu_alloc_vector_context 中失敗時，第一個分配 （guest_context.vector.datap） 會洩漏。返回前釋放它。（CVE-2026-46171）

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

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

  - exit：防止搶佔 oopsing TASK_DEAD 任務 當已結束的工作 oops 時，make_task_dead（） 目前會在啟用搶佔的情況下呼叫 do_task_dead（）。這是被禁止的：do_task_dead（） 呼叫
    __schedule（），其中有一條註解說 WARNING：必須在停用搶佔的情況下調用！。如果在 do_task_dead（） 中搶佔了一個 oopsing 任務，則在成為TASK_DEAD和明確進入調度器之間，就會發生不好的事情：finish_task_switch（） 假設一旦調度器從TASK_DEAD任務切換，該任務就永遠無法再次運行，並且不再需要其堆疊;但如果死任務被搶佔（SM_PREEMPT情況），則該假設顯然不成立。這意味著調度器最終會重複刪除死任務堆疊上的引用，這可能導致整個任務堆疊的釋放後使用或雙重釋放;換句話說，兩個任務最終可能會在同一堆疊上運行，從而導致各種記憶體損毀。（這不僅會影響遞迴 oops 任務，在任務結束期間 oops 一次就足夠了，例如在 file_operations：：release 處理常式中）（CVE-2026-46173）

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

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

  - md/raid10：修正 setup_geo（） 中的除以零錯誤，far_copies setup_geo（） 從使用者提供的佈局參數中擷取near_copies （nc） 和 far_copies （fc），而不檢查零。當 fc=0 並選取改善的遠集配置時，「geo->far_set_size = disks / fc」會觸發除以零。擷取後立即驗證 nc 和 fc，如果其中任何一個為零，則傳回 -1。（CVE-2026-46161）

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

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

  - mptcp：pm：ADD_ADDR rtx：始終減少 sk refcount 當重新傳輸 ADD_ADDR 時，sk 會保存在 sk_reset_timer（） 中。然後它應該在最後在所有情況下釋放。一些 （不太可能的） 檢查會直接傳回，而不是呼叫 sock_put（） 來減少參照計數。跳到新的「退出」標籤以呼叫 __sock_put（） （在下次提交時將變成 sock_put（）） 來修正此潛在洩漏。在此過程中，刪除 '！msk' 檢查，該檢查不會發生，因為它永遠不會重置，並將剩餘的檢查明確標記為不太可能。（CVE-2026-46158）

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

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

  - mptcp：pm：ADD_ADDR rtx：如果最後釋放 sk 當重新傳輸 ADD_ADDR 時，sk 會保存在 sk_reset_timer（） 中，並在最後釋放。如果那一刻，這是最後一次被持有的參考，那麼 sk 將不會被釋放。然後應該呼叫 sock_put（） 而不是 __sock_put（）。但這還不夠：如果是最後一個引用，sock_put（） 將調用 sk_free（），最終會在同一個計時器上調用 sk_stop_timer_sync（），並無限期地等待完成。因此，需要標記計時器在計時器處理常式結束時完成，而不是在自身上呼叫 sk_stop_timer_sync（）。
    (CVE-2026-46170)

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

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

  - RDMA/mana：移除 mana_ib_create_qp_rss（） 中的使用者可觸發 WARN_ON（） Sashiko 指出，使用者可以指定共享相同 CQ 的 WQ 作為 uAPI 的一部分，這將觸發 WARN_ON（），然後繼續破壞核心。直接拒絕它並使 QP 創建失敗。（CVE-2026-46117）

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

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

  - scsi：target：configfs：以 tg_pt_gp_members_show（） target_tg_pt_gp_members_show（） 格式化的 snprintf（） 傳回 snprintf（） 將具有 snprintf（） 的 LUN 路徑格式化為 256 位元組的堆疊緩衝區，然後 memcpy（） 會從該緩衝區cur_len位元組。snprintf（） 會傳回輸出本應具有的長度，當光纖 WWN 很長時，該長度可能會超過緩衝區大小，因為 iSCSI IQN 名稱最多可達 223 位元組。memcpy（） 站點的檢查僅保護目標頁面寫入，而不保護來源讀取，因此 memcpy（） 將讀取堆疊緩衝區並將相鄰的堆疊內容複製到 sysfs 讀取器，當啟用 CONFIG_FORTIFY_SOURCE 時，將觸發 fortify_panic（）。提交 27e06650a5ea （scsi：目標：target_core_configfs：新增長度檢查以避免緩衝區溢位） 將相同的界限新增至 target_lu_gp_members_show（），但遺漏了tg_pt_gp變體，因此請在此處解決。（CVE-2026-46149）

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

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

  - ALSA：pcm： oss：修正存取 runtime.oss.trigger 時的資料爭用 目前，可以在沒有保護的情況下同時存取 runtime.oss.trigger 欄位，這可能會導致資料爭用。而且，在這種情況下，它可能會導致更嚴重的問題，因為它是位場;寫入資料時，它也可能覆蓋其他位元欄位，這會完全混淆操作，正如模糊測試所發現的那樣。透過使用 snd_pcm_oss_get_trigger（） 和 snd_pcm_oss_poll（） 中現有的 params_lock 互斥來覆蓋 runtime.oss.trigger 位元 fled 來修正它。（CVE-2026-46157）

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

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

  - 已解決 Linux 核心中的下列弱點：smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read. (CVE-2026-46185)

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

ID	名稱	嚴重性
317637	Linux Distros 未修補弱點：CVE-2026-42790	high
317636	Linux Distros 未修補弱點：CVE-2026-46175	high
317635	Linux Distros 未修補弱點：CVE-2026-46169	medium
317634	Linux Distros 未修補的弱點：CVE-2026-46203	high
317633	Linux Distros 未修補弱點：CVE-2026-46113	high
317632	Linux Distros 未修補弱點：CVE-2026-46112	high
317631	Linux Distros 未修補弱點：CVE-2026-46135	critical
317630	Linux Distros 未修補弱點：CVE-2026-46123	high
317629	Linux Distros 未修補弱點：CVE-2026-46172	medium
317628	Linux Distros 未修補弱點：CVE-2026-46180	high
317627	Linux Distros 未修補弱點：CVE-2026-42998	high
317626	Linux Distros 未修補弱點：CVE-2026-46133	high
317625	Linux Distros 未修補弱點：CVE-2026-46167	medium
317624	Linux Distros 未修補的弱點：CVE-2026-46178	high
317623	Linux Distros 未修補弱點：CVE-2026-46143	medium
317622	Linux Distros 未修補弱點：CVE-2026-46106	medium
317621	Linux Distros 未修補弱點：CVE-2026-46108	medium
317620	Linux Distros 未修補弱點：CVE-2026-46208	high
317619	Linux Distros 未修補弱點：CVE-2026-46121	high
317618	Linux Distros 未修補的弱點：CVE-2026-46199	high
317617	Linux Distros 未修補弱點：CVE-2026-46220	medium
317616	Linux Distros 未修補弱點：CVE-2026-46206	high
317615	Linux Distros 未修補的弱點：CVE-2026-46196	medium
317614	Linux Distros 未修補弱點：CVE-2026-46144	medium
317613	Linux Distros 未修補弱點：CVE-2026-46148	medium
317612	Linux Distros 未修補弱點：CVE-2026-46140	high
317611	Linux Distros 未修補弱點：CVE-2026-46107	high
317610	Linux Distros 未修補弱點：CVE-2026-46122	high
317609	Linux Distros 未修補弱點：CVE-2026-46191	high
317608	Linux Distros 未修補弱點：CVE-2026-46150	high
317607	Linux Distros 未修補弱點：CVE-2026-46146	medium
317606	Linux Distros 未修補弱點：CVE-2026-46236	medium
317605	Linux Distros 未修補弱點：CVE-2026-46160	medium
317604	Linux Distros 未修補弱點：CVE-2026-46131	medium
317603	Linux Distros 未修補的弱點：CVE-2026-46230	high
317602	Linux Distros 未修補弱點：CVE-2026-46201	high
317601	Linux Distros 未修補弱點：CVE-2026-43000	high
317600	Linux Distros 未修補弱點：CVE-2026-46128	medium
317599	Linux Distros 未修補弱點：CVE-2026-42999	high
317598	Linux Distros 未修補弱點：CVE-2026-46187	medium
317597	Linux Distros 未修補的弱點：CVE-2026-46127	medium
317596	Linux Distros 未修補弱點：CVE-2026-46171	medium
317595	Linux Distros 未修補弱點：CVE-2026-46173	high
317594	Linux Distros 未修補的弱點：CVE-2026-46161	medium
317593	Linux Distros 未修補弱點：CVE-2026-46158	medium
317592	Linux Distros 未修補弱點：CVE-2026-46170	medium
317591	Linux Distros 未修補弱點：CVE-2026-46117	high
317590	Linux Distros 未修補弱點：CVE-2026-46149	high
317589	Linux Distros 未修補弱點：CVE-2026-46157	high
317588	Linux Distros 未修補弱點：CVE-2026-46185	critical

偵測

Nessus 的 Misc. 系列

high

high

medium

high

high

high

critical

high

medium

high

high

high

medium

high

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

high

high

high

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

high

critical