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

  - 已解決 Linux 核心中的下列弱點：xfrm: Fix work re-schedule after cancel in xfrm_nat_keepalive_net_fini() After cancel_delayed_work_sync() is called from xfrm_nat_keepalive_net_fini(), xfrm_state_fini() flushes remaining states via __xfrm_state_delete(), which calls xfrm_nat_keepalive_state_updated() to re-schedule nat_keepalive_work. The following is a simple race scenario: cpu0 cpu1 cleanup_net() [Round 1] ops_undo_list() xfrm_net_exit() xfrm_nat_keepalive_net_fini() cancel_delayed_work_sync(nat_keepalive_work); xfrm_state_fini() xfrm_state_flush() xfrm_state_delete(x)
    __xfrm_state_delete(x) xfrm_nat_keepalive_state_updated(x) schedule_delayed_work(nat_keepalive_work);
    rcu_barrier(); net_complete_free(); net_passive_dec(net); llist_add(&net->defer_free_list, &defer_free_list); cleanup_net() [Round 2] rcu_barrier(); net_complete_free() kmem_cache_free(net_cachep, net); nat_keepalive_work() // on freed net To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). (CVE-2026-31406)

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

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

  - 藍牙：SCO：修正 sco_recv_frame（） 中由於缺少 sock_hold sco_recv_frame（） 讀取 sco_conn_lock（） 下的 conn->sk，但立即釋放鎖定而不保留對通訊端的引用，因此修正了 （） 中的釋放後使用。並行 close（） 可以釋放鎖定釋放和後續 sk->sk_state 存取之間的通訊端，從而導致釋放後使用。同一檔案中的其他函式 （sco_sock_timeout（）、sco_conn_del（）） 會正確使用 sco_sock_hold（） 來安全地將參照保存在鎖定之下。透過在釋放鎖定之前使用 sco_sock_hold（） 進行參照，並在所有退出路徑上新增 sock_put（） 來修正。
    (CVE-2026-31408)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN. (CVE-2026-31407)

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

遠端主機上安裝的 AOS 版本低於 7.5.1。因此會受到 NXSA-AOS-7.5.1 公告中提及的多個弱點影響。

  - 在 GNU Binutils 中發現一個弱點 2.45。受影響的元素是元件連結器之程式庫 bfd/elfcode.h 中的 elf_swap_shdr 函式。攻擊者可利用此弱點造成堆積型緩衝區溢位。
    攻擊必須在本機執行。攻擊程式已向公眾披露且可能會遭到利用。修補程式的識別碼是 9ca499644a21ceb3f946d1c179c38a83be084490。若要修正此問題建議部署修補程式。程式碼維護者以 2.46[] 的  ixed 回覆。 (CVE-2025-11083)

  - 在限制不足的情況下配置 multipart 標頭的資源時，會啟用 Apache Commons FileUpload 中的 DoS 弱點。此問題會影響 Apache Commons FileUpload： 從 1.0 到 1.6；從 2.0.0-M1 到 2.0.0-M4 之前的 。建議使用者升級至 1.6 或 2.0.0-M4 版，即可修正此問題。(CVE-2025-48976)

  - urllib.parse.urlsplit() 和 urlparse() 函式未正確驗證括弧中的主機 (`[]`)進而允許非 IPv6 或 IPvFuture 的主機。此行為不符合 RFC 3986，且如果 URL 由多個 URL 剖析器處理，可能會導致伺服器端要求偽造 (SSRF) 攻擊。(CVE-2024-11168)

  - CPython 3.9 和更舊版本並未禁止設定 SSLContext.set_npn_protocols() 的空白清單 ([])其為基礎 OpenSSL API 的無效值。這會導致在使用 NPN 時發生緩衝區過度讀取 (針對 OpenSSL，請參閱 CVE-2024-5535 )。此弱點的嚴重性為低，這是因為 NPN 並未廣泛使用，而且指定空白清單在實務中可能並不常見 (通常會設定通訊協定名稱)。(CVE-2024-5642)

  - 在 CPython「venv」模組和 CLI 中發現一個弱點其中建立虛擬環境時未正確引用所提供的路徑名稱進而允許建立者將命令插入虛擬環境啟動指令碼 (即來源 venv/bin/activate)。這表示當啟用虛擬環境時，受攻擊者控制的虛擬環境能夠執行命令。
    非攻擊者建立或使用前未啟動的虛擬環境 (即 ./venv/bin/python) 不會受到影響。 (CVE-2024-9287)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 AOS 版本低於 7.5.1.1。因此，它會受到 NXSA-AOS-7.5.1.1 公告中提及的多個弱點的影響。

  - Apache CXF 會將大型資料流型訊息儲存為本機檔案系統上的暫存檔。系統引入一個錯誤，導致整個暫存檔被讀入記憶體，並寫入記錄檔。攻擊者可能利用此弱點，透過觸發記憶體溢位例外狀況，發動拒絕服務攻擊。
    此外，雖然 CXF 支援加密暫存檔以避免敏感憑證以明文儲存在本機檔案系統中，但此錯誤會導致這些暫存檔以未加密的形式被寫入記錄檔。建議使用者升級至 3.5.11、3.6.6、4.0.7 或 4.1.1 版，即可修正此問題。(CVE-2025-48795)

  - 電子郵件模組（特別是 BytesGenerator 類別）在序列化電子郵件訊息時未正確引用電子郵件標頭的換行符，從而在序列化電子郵件時插入標頭。這僅適用於使用 LiteralHeader 寫入不遵守電子郵件折疊規則的標頭時，新行為將拒絕 BytesGenerator 中錯誤折疊的標頭。（CVE-2026-1299）

  - imaplib 模組在傳遞使用者控制的命令時，可以使用新行插入其他命令。緩解措施會拒絕包含控制字元的命令。（CVE-2025-15366）

  - poplib 模組在傳遞使用者控制命令時，可以使用換行符插入其他命令。緩解措施會拒絕包含控制字元的命令。（CVE-2025-15367）

  - 使用者控制的標頭名稱和包含換行符的值可以允許插入 HTTP 標頭。
    (CVE-2026-0865)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

  - Avahi 是一種可透過 mDNS/DNS-SD 通訊協定套件在區域網路上協助探索服務的系統。在 0.9-rc4 版之前任何無權限的本機使用者皆可透過傳送具有衝突發布旗標的單一 D-Bus 方法呼叫來損毀 avahi-daemon。此問題已在 0.9-rc4 版中修補。
    (CVE-2026-34933)

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

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

  - JupyterHub 是一款可用於為 Jupyter 筆記本建立多使用者伺服器的軟體。在 5.4.4版之前JupyterHub 中的開放重新導向弱點允許攻擊者建構連結點擊該連結時會將使用者帶到 JupyterHub 登入頁面然後將其傳送至 JupyterHub 外部的任意攻擊者控製網站而非 JupyterHub 頁面繞過 JupyterHub 的檢查以防止此情況。此問題已在 5.4.4 版中修正。(CVE-2026-33709)

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

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

  - soc: microchip: mpfs修正 mpfs_sys_controller_probe() 中的記憶體洩漏。在 mpfs_sys_controller_probe() 中如果 of_get_mtd_device_by_node() 失敗該函式會立即傳回而不釋放給 sys_controller 配置的記憶體進而導致記憶體洩漏。透過跳至 out_free 標籤修正此問題以確保正確釋放記憶體。此外整合 mbox_request_channel() 失敗案例的錯誤處理以使用相同的標籤。 (CVE-2026-23464)

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

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

  - drm/vmwgfx不覆寫 KMS 表面已變更追踪器。我們在此處覆寫了表面的已變更追踪器造成記憶體洩漏。 (CVE-2026-23430)

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

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

  - drm/amdgpu限制 BO 清單項目計數以防止資源耗盡使用者空間可透過 bo_number 欄位傳送任意數量的 BO 清單項目。雖然先前的乘法溢位檢查可防止超出邊界配置大量的項目仍可造成過多的記憶體配置 (可能高達 GB)以及不必要地過長的清單處理時間。引入每個 BO 清單 128k 項目的硬性限制這對於任何實際使用案例 (例如包含大型場景中所有緩衝區的單一清單) 來說都已足夠。如此可防止記憶體耗盡攻擊並確保可預測的效能。如果要求的項目計數超過限制 (從認可 688b87d39e0aa8135105b40dc167d74b5ada5332 精選)則傳回 -EINVAL (CVE-2026-23468)

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

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

  - 藍牙L2CAP在提交 ab4eedb790ca 之後修正 l2cap_unregister_user 中的釋放後使用 (藍牙
    L2CAP修正 hci_chan_del) 中損毀的清單l2cap_conn_del() 使用 conn->lock 保護 conn->users 的存取權。不過l2cap_register_user() 與 l2cap_unregister_user() 未使用 conn->lock造成爭用情形這些函式可利用 l2cap_conn_del()同時存取 conn->users 和 conn->hchan。據 syzbot 報告這可導致釋放後使用和清單損毀錯誤。透過變更 l2cap_register_user() 和 l2cap_unregister_user() 來修正此問題以使用 conn->lock 而非 hci_dev_lock()確保 l2cap_conn 結構的一致鎖定。 (CVE-2026-23461)

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

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

  - drm/xe修正 xe_vm_madvise_ioctl 中的記憶體洩漏。當 check_bo_args_are_sane() 驗證失敗時跳至新的 free_vmas 清理標籤以正確釋放已配置的資源。如此可確保正確清除此錯誤路徑。 (從認可 29bd06faf727a4b76663e4be0f7d770e2d2a7965 中精選的內容) (CVE-2026-31390)

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

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

  - ipv6在 SRv6 路徑中新增 idev 的 NULL 檢查裝置沒有 IPv6 組態時 (例如 MTU < IPV6_MIN_MTU 或在 NETDEV_UNREGISTER 之後)__in6_dev_get() 會傳回 NULL。針對 傳回的 idev 新增 NULL 檢查
    在 seg6_hmac_validate_skb() 和 ipv6_srh_rcv() 中執行__in6_dev_get()以防止可能發生的 NULL 指標解除參照。 (CVE-2026-23442)

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

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

  - netmvpp2在每個 cpu 和共用緩衝區集區模式之間切換時mvpp2_bm_switch_buffers() 會在緩衝區切換中使用 global_tx_fc 保護流量控制更新。此函式透過 mvpp2_cm3_read()/mvpp2_cm3_write() 對 CM3 流量控制暫存器進行程式設計這會在沒有任何 NULL 檢查的情況下解除參照 priv->cm3_base。當裝置樹狀結構中不存在 CM3 RAM 資源時 (第三個 reg 項目由認可 60523583b07c (dts: marvell新增 CM3 RAM 記憶體至 cp11x 乙太網路裝置樹狀結構))priv->cm3_base 保持為 NULL 且 priv->global_tx_fc 為false。任何觸發 mvpp2_bm_switch_buffers() 的作業 (例如超過 jumbo 框架閾值的 MTU 變更) 都會當機 Unable to handle kernel NULL 指標解除參照在虛擬位址 0000000000000000 記憶體中止資訊ESR = 0x0000000096000006 EC = 0x25DABT (目前 EL) 、IL = 32 位元 pcreadl+0x0/0x18 lr
    mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/ 0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 驅動程式中的每個其他流量控制呼叫網站已以 priv->global_tx_fc 或 port->tx_fc 防護硬體存取。
    mvpp2_bm_switch_buffers() 是唯一會省略此檢查的地方。將遺漏的 priv->global_tx_fc 防護新增至 mvpp2_bm_switch_buffers() 中的停用和重新啟用呼叫與驅動程式的其餘部分一致。 (CVE-2026-23438)

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

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

  - netfilternf_conntrack_h323檢查 DecodeQ931() 中的零長度在 DecodeQ931() 中UserUserIE 程式碼路徑會從封包讀取 16 位元長度然後將其遞減 1 以略過通訊協定辨別器位元組再將其傳送至 DecodeH323_UserInformation() 。若編碼長度為 0則遞減換行至
    -1然後以大值的形式將其傳送至解碼器進而導致超出邊界讀取。新增檢查以確保遞減後 len 為正。 (CVE-2026-23455)

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

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

  - wifi： wlcore： 修正鎖定錯誤 確保 wl->mutex 在解鎖之前已被鎖定。Clang 執行緒安全分析器已偵測到此問題。（CVE-2026-23420）

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

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

  - Emissary 是一個基於 P2P 的數據驅動工作流程引擎。在版本及以下版本 8.42.0 中，Executrix.getCommand（） 容易受到作業系統命令插入的影響，因為它會將暫存檔案路徑插入 /bin/sh -c shell 命令字串中，而無需進行任何逸出或輸入驗證。IN_FILE_ENDING 和 OUT_FILE_ENDING 組態金鑰會直接流入這些路徑，讓可以寫入或修改 .cfg 檔案的位置作者插入任意殼層中繼字元，以在 JVM 處理程序的安全內容中執行作業系統命令。在將 placeName 內嵌到相同的 shell 字串中之前，該框架已透過允許清單清理 placeName，但不會對檔案結尾值套用對等的清理。除了位置設定作者權限之外，不需要執行階段權限，也不需要 API 或網路存取權即可利用此弱點。這是架構層級的缺陷，下游實作者無法使用安全的緩解措施，因為 Executrix 既沒有針對檔案結尾輸入中的元字元提供逸出，也沒有記錄前置條件。8.43.0 版已修正此問題。(CVE-2026-35582)

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

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

  - net/rose修正重新連線時 rose_transmit_link 中的 NULL 指標解除參照 syzkaller 報告的錯誤 [1]可在 [2] 取得重現器。ROSE 通訊端使用四個 sk->sk_state 值TCP_CLOSE、TCP_LISTEN、TCP_SYN_SENT 和 TCP_ESTABLISHED。 rose_connect() 已拒絕 TCP_ESTABLISHED (-EISCONN) 和具有 SS_CONNECTING (-ECONNREFUSED) 的 TCP_CLOSE 呼叫但缺少 TCP_SYN_SENT 的檢查。當第一次連線嘗試仍在進行中 (TCP_SYN_SENT) 第二次呼叫 rose_connect() 時它會透過 rose_get_neigh() 覆寫 rose->neighbour。如果其傳回 NULL通訊端會保留為 rose->state == ROSE_STATE_1但 rose->neighbour == NULL。通訊端隨後關閉時rose_release() 會看到 ROSE_STATE_1 並呼叫 rose_write_internal() -> rose_transmit_link(skb, NULL)造成 NULL 指標解除參照。根據 connect(2)在連線進行中時第二個 connect() 應傳回
    -EALREADY。新增 TCP_SYN_SENT 缺少的檢查以完成 rose_connect() 中的狀態驗證。 [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516 (CVE-2026-23460)

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

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

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION.
    ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] <TASK> [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ?
    _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ?
    __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ?
    __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ?
    __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] </TASK> [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646]
    __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region
    ---truncated--- (CVE-2026-23427)

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

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

  - netfilternf_conntrack_sip修正 sip_help_tcp() 中的 Content-Length u32 截斷。sip_help_tcp() 使用 simple_strtoul() 剖析 SIP Content-Length 標頭這會傳回未簽署的 long但將結果儲存在未簽署的 int clen 中。在 64 位元系統上超過 UINT_MAX 的值會在計算 SIP 訊息邊界之前以無訊息方式截斷。例如Content-Length 4294967328 (2^32 + 32) 會截斷為 32造成剖析器錯誤計算目前訊息的結束位置。接著迴圈會將 TCP 區段中的結尾資料視為第二個 SIP 訊息並透過 SDP 剖析器加以處理。透過將 clen 變更為 unsigned long 以符合 simple_strtoul() 的傳回類型來修正此問題並拒絕超過剩餘 TCP 承載長度的 Content-Length 值。 (CVE-2026-23457)

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

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

  - 藍牙HIDP修正可能的 UAF 這可修正下列因呼叫 user->remove 回呼時未放置 l2cap_conn 參照所導致的追踪[ 97.809249] l2cap_conn_free釋放 conn ffff88810a171c00 [ 97.809907] CPU1 UID0 PID1419 Commrepro_standalon 未受污染的 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] 硬體名稱: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/ 01/2014 [ 97.809947] 呼叫追踪 [ 97.809954] <TASK> [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (辨別器 1 ) net/bluetooth/l2cap_core.c:7340 (辨別器 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (辨別器 2) net/bluetooth/hci_conn.c:2644 (辨別器 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ?
    __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (判別器 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (判別器 5) ./include/linux/atomic/ atomic-long.h:268 (識別碼 5) ./include/linux/atomic/atomic-instrumented.h:3391 (識別碼 5) kernel/locking/rwsem.c:1385 (識別碼 5) kernel/locking/rwsem.c :1643 (辨別器 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree .c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ?
    __pfx_vhci_release (drivers/bluetooth/hci_vhci.c678) [ 97.810404] __fput (fs/file_table.c:470) [97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] lock_acquire (kernel/locking/lockdep.c:470 (辨別器 6) kernel/locking/lockdep.c:5870 (辨別器 6) kernel/locking/lockdep.c:5825 (辨別器 6)) [97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (辨別器 4) kernel/locking/spinlock_debug.c:118 (辨別器 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ?
    __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/
    ---truncated--- (CVE-2026-23462)

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

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

  - drm/logicvc修正logicvc_drm_config_parse() 中的裝置節點參照洩漏。logicvc_drm_config_parse() 函式會呼叫 of_get_child_by_name() 以尋找層節點但無法釋放參照進而導致裝置節點參照洩漏。透過使用 __free(device_node) 清理屬性在變數超出範圍時自動釋放參照來修正此問題。 (CVE-2026-23426)

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

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

  - drm/imagination修正軟重設序列中的鎖死問題軟重設序列目前是從執行緒 IRQ 處置程式執行因此無法呼叫 disable_irq()而後者會在內部等候 IRQ 處置程式即
    本身來完成。改為在軟重設期間使用 disable_irq_nosync()。 (CVE-2026-23470)

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

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

  - PMruntime修正與裝置移除相關的爭用情形。pm_runtime_work() 中的下列程式碼可能會在釋放父項裝置後解除參照 dev->parent 指標/*也許父項現在可以暫停。 */ if (parent && !parent->power.ignore_children) { spin_unlock(&dev->power.lock);
    spin_lock(&parent->power.lock); rpm_idle(parent, RPM_ASYNC); spin_unlock(&parent->power.lock);
    spin_lock(&dev->power.lock);透過在 pm_runtime_remove() 中插入 flush_work() 呼叫來修正此問題。若無此修補程式blktest block/001 會偶爾觸發下列投訴錯誤KASANkworker/u553:1/3081 工作在 lock_acquire+0x70/0x160 讀取位址 ffff88812bef7198 的大小 1 工作佇列 pm pm_runtime_work呼叫追踪 <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0
    __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160
    _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK> Allocated by task 4314kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0
    __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50
    __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/ 0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506 /0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 (CVE-2026-23452)

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

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

  - net/rds修正 rds_tcp_tune 中的循環鎖定相依性。syzbot 報告 rds_tcp_tune() 中有一個循環鎖定相依性問題其中會在保留通訊端鎖定時呼叫 sk_net_refcnt_upgrade()
    ================================================== ==== 警告偵測到可能的循環鎖定相依性 ======================================= =============== kworker/u10:8/15040 正在嘗試取得鎖定ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}位於__kmalloc_cache_noprof+0x4b/ 0x6f0但工作已保留鎖定 ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 此問題是因為 sk_net_refcnt_upgrade() 執行記憶體配置 (透過 get_net_track() - > ref_tracker_alloc()) 在保留通訊端鎖定時建立與 fs_reclaim 的循環相依性。將 sk_net_refcnt_upgrade() 移至通訊端鎖定重要區段外可修正此問題。這是安全的因為此時任何並行程式碼路徑都無法存取 sk_net_refcnt_upgrade() 呼叫修改的欄位 (sk_net_refcnt、ns_tracker)。 v2 - 已更正標籤 - 檢查修補程式換行 nits - ai 評論 nits (CVE-2026-23419)

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

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

  - netmacb修正 PTP 時鐘的釋放後使用存取 PTP 時鐘會在每次開啟介面時註冊並在每次關閉時損毀。不過其可透過 get_ts_info ethtool 呼叫存取而當介面剛剛存在於核心中時即有可能。BUG: KASAN在 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 中發生釋放後使用錯誤。由工作 syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not受污染的 6.1.164+ #109 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 呼叫追踪 <TASK> __dump_stack lib/ dump_stack.c:88 [內嵌] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [內嵌] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9 /0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/ net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [內嵌] __dev_ethtool net/ethtool/ioctl.c:3017 [內嵌] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/ core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:870 [內嵌] __se_sys_ioctl fs/ioctl.c:856 [內嵌]
    __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [內嵌] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 </TASK> 由工作 457 分配kmalloc include/linux/slab.h:563 [內嵌] kzalloc include/linux/slab.h:699 [內嵌] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501
    __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core /rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net /netlink/af_netlink.c:1318 [內嵌] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [內嵌]
    __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [內嵌] __se_sys_sendto net/socket.c:2160 [內嵌] __x64_sys_sendto+0xdc/ 0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [內嵌] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 已由工作 938 釋放include/linux/kasan.h:177 [內嵌] slab_free_hook mm/slub.c:1729 [內嵌] slab_free_freelist_hook mm/slub.c:1755 [內嵌] slab_free mm/slub.c:3687 [內嵌] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [內嵌] kobject_release lib/kobject.c:712 [內嵌] kref_put include/linux/kref。 h:65 [內嵌] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/ 0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_ close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [內嵌] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl
    ---truncated--- (CVE-2026-31396)

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

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

  - mac80211修正 ieee80211_chan_bw_change 中 AP_VLAN 工作站的損毀問題 ieee80211_chan_bw_change() 會反覆所有工作站並透過 sta->sdata->link[link_id] 存取 link->reserved.oper。針對 AP_VLAN 介面上的工作站 (例如 4addr WDS 用戶端)sta->sdata 會指向 VLAN sdata其連結從不參與 chanctx 保留。這會使 link->reserved.oper 以 chan == NULL 零初始化造成在 CSA 期間存取 chandef->chan->band 時在 __ieee80211_sta_cap_rx_bw() 中發生 NULL 指標解除參照。在存取連結資料之前使用 get_bss_sdata() 將 VLAN sdata 解析為其父項 AP sdata。 [即使沒有問題也變更 ARRAY_SIZE 中的 sta->sdata] (CVE-2026-31394)

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

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

  - 已解決 Linux 核心中的下列弱點：net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].
    smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free:
    sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note:
    smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.
    Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9 (CVE-2026-23450)

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

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

  - Dokuwiki v.2025-05-14b「Librarian」中的一個問題允許遠端攻擊者透過 media.php 檔案中的 media_upload_xhr() 函式造成拒絕服務 (CVE-2026-26477)

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

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

  - netmana重新排序卸除修正 mana_hwc_destroy_channel() 中的釋放後使用問題。mana_hwc_destroy_channel() 中可能存在爭用情形其中 hwc->caller_ctx 在 HWC 的完成佇列 (CQ) 和事件佇列 (EQ) 遭到破壞之前就釋放了。這會允許執行中的 CQ 中斷處置程式解除參照已釋放的記憶體進而導致 mana_hwc_handle_resp() 中發生釋放後使用或 NULL 指標解除參照。 mana_smc_teardown_hwc() 會向硬體發出停止的訊號但不會與已在其他 CPU 上執行的 IRQ 處置程式同步。IRQ 同步只會在 mana_hwc_destroy_cq() 中透過 mana_gd_destroy_eq() -> mana_gd_deregister_irq() 發生。由於此程式在 kfree(hwc->caller_ctx) 之後執行因此並行 mana_hwc_rx_event_handler() 可解除參照 mana_hwc_handle_resp() 中已釋放的 caller_ctx (和 rxq->msg_buf)。藉由將卸除重新排序為建立反向順序來修正此問題
    在釋放 hwc->caller_ctx 之前損毀 TX/RX 工作佇列與 CQ/EQ。這可確保所有執行中的中斷處置程式在其存取的記憶體釋放前完成。 (CVE-2026-23454)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在版本 2.4.16 和之前版本中，在具有共用目標佇列的網路公開 cupsd 中，未經授權的用戶端可以在不進行驗證的情況下將列印作業傳送至該共用 PostScript 佇列。伺服器接受以 textWithoutLanguage 形式提供的頁面框線值，透過選項逸出和重新剖析保留內嵌的換行，然後將產生的第二行 PPD: text 重新剖析為受信任的排程器控制記錄。因此，後續的原始列印工作可使伺服器執行攻擊者選擇的現有二進位檔，例如 /usr/bin/vim 作為 lp。發佈之時，尚無公開可用的修補程式。(CVE-2026-34980)

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

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

  - igc修正 XDP TX 時間戳記處理中的頁面錯誤如果要求 TX 時間戳記的 XDP 應用程式關閉而使用中的介面連結仍在使用中則會報告下列核心展開攻擊 [883.803618] [ T1554] 錯誤無法處理 ffffcfb6200fd008 位址的頁面錯誤 ... [ 883.803650] [T1554] 呼叫追踪 [ 883.803652] [ T1554] <TASK> [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc] [ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc] ... TX 環關閉期間xsk_meta 指標會留下因此 IRQ 處置程式會嘗試接觸這些指標。此問題現在已透過在 TX 關機時清除過時的 xsk 中繼資料的方式獲得修正。其他佇列上的 TX 時間戳記不受影響。 (CVE-2026-23445)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在版本和之前的版本 2.4.16 中，CUPS 常駐程式 （cupsd） 包含一個授權繞過弱點，這是因為在授權檢查期間不區分大小寫的使用者名稱比較。此弱點可讓無特權的使用者使用使用者名稱與授權使用者大小寫不同的使用者，來取得對受限制作業的未經授權存取權。在發佈時，沒有公開可用的修補程式。
    (CVE-2026-27447)

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

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

  - mtd避免 RedBoot 磁碟分割表格剖析器中的開機損毀。在 CONFIG_FORTIFY_SOURCE=y 和最近的編譯器情況下提交 439a1bcac648 (fortify若可用則使用 __builtin_dynamic_object_size()) 會產生以下警告和 oops。搜尋 RedBoot 磁碟分割表中 50000000.flash 的位移 0x7e0000
    ------------[cut here ]------------ 警告lib/string_helpers.c:1035 at 0xc029e04c、 CPU#0swapper/0/1 memcmp偵測到緩衝區溢位 15 位元組讀取緩衝區大小 14 連結的模組CPU0 UID0 PID1 通訊swapper/0 未受污染 6.19.0 #1 NONE 如 Kees 所述'names' 指向許多最後的 'namelen'配置的位元組...「namelen」基本上可以是任何長度。這個 fortify 警告在我看來是合法的 -- 此程式碼之前會在超出配置結尾處讀取。由於動態配置的大小是使用 strlen() 計算我們可以使用 strcmp() 而非 memcmp()並維持在邊界內。 (CVE-2026-23474)

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

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

  - OpenPrinting CUPS 是一種適用於 Linux 和其他類似 Unix 的作業系統的開放原始碼列印系統。在 2.4.16 版及更舊版本中從工作屬性構建篩選選項字串時CUPS 排程器中有堆積型緩衝區溢位情形。發佈時無任何可公開取得的修補程式。
    (CVE-2026-34979)

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

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

  - netshaper防止階層建立後期。我們在 Netlink ops (預先回呼) 準備期間查閱 netdev並取得它的參照。稍後在回呼的內文中我們採取其鎖定或 RCU這是實際的保護。netdev 可能會在我們取得該參照到我們鎖定該參照之間取消註冊。我們可能會在排清執行後配置階層這會導致洩漏。預先取得執行個體鎖定避免發生爭用且完全不需要專用的鎖定/解鎖回呼。如果有任何機會與排清同時發生寫入我們又會回到洩漏階層。我們可能會針對不支援 Shaper 的裝置採取鎖定但我們在這裡僅處理 SET 作業如果不採取鎖定會針對錯誤情況進行最佳化。 (CVE-2026-23436)

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

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

  - drm/imagination在暫停 GPU 之前同步中斷。運行時間 PM 暫停回呼不知道 IRQ 處理常式是否在不同的 CPU 核心上進行中且不會等待其完成。
    視定時而定IRQ 處置程式可在 GPU 暫停時執行進而導致嘗試存取 GPU 暫存器時核心損毀。請參閱以下簽章範例。在由運行時間 PM 暫停回呼起始的電源關閉序列中請藉由呼叫 synchronize_irq()等待其他 CPU 核心上進行中的任何 IRQ 處置程式完成。同時移除執行緒 IRQ 處置程式中的運行時間 PM resume/put 呼叫。除了不是一開始就使用的正確方法而且放在錯誤的位置 (應該包裝所有 GPU 暫存器存取)之外此外驅動程式也會在從運行時間 PM 暫停回呼呼叫的 synchronize_irq() 保留裝置之間發生鎖死電源鎖定而需要相同電源鎖定的恢復回呼。TI AM68 SK 平台上的損毀簽章範例[ 337.241218] CPU0 上的 SError 中斷代碼 0x00000000bf000000 -- SError [ 337.241239] CPU0 UID0 PID112 Comm
    irq/234-gpu 受污染 GM 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] 受污染
    [M]=MACHINE_CHECK [ 337.241249] 硬體名稱Texas Instruments AM68 SK (DT) [ 337.241252] pstate
    60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pcpvr_riscv_irq_pending+0xc/0x24 [ 337.241277] lrpvr_device_irq_thread_handler+0x64/0x310 [ 337.241282] spffff800085b0bd30 [337.241284] x29 ffff800085b0bd50 x28 ffff0008070d9eab x27 ffff800083a5ce10 [ 337.241291] x26
    ffff000806e48f80 x25ffff0008070d9eac x240000000000000000 [ 337.241296] x23ffff0008068e9bf0 x22
    ffff0008068e9bd0 x21ffff800085b0bd30 [ 337.241301] x20 ffff0008070d9e00 x19 ffff0008068e9000 x18
    0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11:
    00000000000000c0 x10 0000000000000af0 x9 ffff800085b0bd00 [ 337.241318] x8 ffff0008071175d0 x7
    000000000000b955 x6 0000000000000003 [ 337.241323] x5 0000000000000000 x4 0000000000000002 x3
    000000000000000 [ 337.241327] x2 ffff800080e39d20 x1 ffff800080e3fc48 x0 0000000000000000 [337.241333] 核心錯誤 - 未同步非同步 SError 中斷 [ 337.241337] CPU 0 UID 0 PID 112 攻擊者入侵6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] 污染
    [M]=MACHINE_CHECK [ 337.241343] 硬體名稱德州儀器 AM68 SK (DT) [ 337.241345] 呼叫追踪[337.241348] show_stack+0x18/0x24 (C) [ 337.241357] dump_stack_lvl+0x60/0x80 [ 337.241364] dump_stack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] add_taint+0x0/0xbc [ 337.241384] arm64_serror_panic+0x70/0x80 [ 337.241389] do_serror+0x3c /0x74 [337.241392] el1h_64_error_handler+0x30/0x48 [ 337.241400] el1h_64_error+0x6c/0x70 [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P) [ 337.241410] irq_thread_fn+0x2c/0xb0 [ 337.241416] irq_thread+0x170/0x3334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] ret_from_fork+0x10/0x20 [337.241434] ] SMP停止次要 CPU [ 337.241451] 核心位移停用 [ 337.241453] CPU 功能
    0x040000、02002800、20002001、0400421b [ 337.241456] 記憶體限制無 [ 337.457921] ---[ 結束核心錯誤 - 未同步非同步 SError 中斷 ]--- (CVE-2026-23469)

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

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

  - HIDbpf現在防止 hid_hw_request 中發生緩衝區溢位傳回的值會被視為一律有效。但是使用 HID-BPF 時傳回值可以是任意大的值因為這是呼叫 struct_ops 的 dispatch_hid_bpf_raw_requests() 的傳回值而且我們不保證該值一定有意義。 (CVE-2026-31401)

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

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

  - OpenPrinting CUPS 是一種適用於 Linux 和其他類似 Unix 的作業系統的開放原始碼列印系統。在 2.4.16 版和更舊版本中無權限的本機使用者可使用可重複使用的 Authorization: Local ... token 來強制 cupsd 向受攻擊者控制的 localhost IPP 服務進行驗證。該 token 足以在 localhost 上驅動 /admin/ 要求攻擊者可結合 CUPS-Create-Local-Printer 與 printer-is-shared=true 以持續存在 file:///... 佇列即使一般 FileDevice 原則拒絕此類 URI 也一樣。
    列印至該佇列會使任意 root 檔案覆寫以下 PoC 使用該原語放置 sudoers 片段並示範 root 命令執行。發佈時無任何可公開取得的修補程式。 (CVE-2026-34990)

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

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

  - netusbaqc111不執行暫停回呼內的 PM syzbot 報告 rpm_resume 中的工作懸置這是由 aqc111_suspend 呼叫其 write_cmd 常式的 PM 變體所造成。簡化的呼叫追踪如下所示：rpm_suspend() usb_suspend_both() - 此處為 udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - call for the usb 裝置介面 aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() -此處我們會呼叫父項 rpm_resume() 上的 rpm_resume() - 此處我們會等待永遠不會發生的狀態變更。此時我們封鎖了另一個保留 rtnl_lock 並鎖定整個網路堆疊的工作。將 write_cmd 呼叫取代為其 _nopm 變體以修正此問題 (CVE-2026-23446)

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

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

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] <TASK> [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ?
    __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] </TASK> [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated--- (CVE-2026-23428)

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

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

  - mtd： rawnand：針對其他 NAND 操作 nand_lock（） 和 nand_unlock（） 調用 chip->ops.lock_area/unlock_area 序列化鎖定/解鎖，而無需保持 NAND 裝置鎖定。在透過多個低階 PIO 命令實作SET_FEATURES的控制器上，這些命令可能會與並行 UBI/UBIFS 背景擦除/寫入操作爭用，從而導致 NAND 控制器上的 cmd_pending 衝突。在鎖定/解鎖作業周圍新增 nand_get_device（）/nand_release_device（），以針對所有其他 NAND 控制器存取進行序列化。（CVE-2026-23434）

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

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

  - cryptoatmel-sha204a - 修正 OOM ->tfm_count 洩漏如果記憶體配置失敗請遞減 ->tfm_count 以避免封鎖未來的讀取。 (CVE-2026-31391)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在 2.4.16 版及更舊版本中，RSS 通知程式允許 notify-recipient-uri 中的路徑遊走 (例如 rss:///../job.cache)，進而讓遠端 IPP 用戶端在 CacheDir/rss 之外寫入 RSS XML 位元組 (lp-writable 的任何位置)。特別是，由於根據預設，CacheDir 為群組可寫入 (通常是 root:lp 和模式 0770)，因此通知程式 (以 lp 身分執行) 可透過 temp-file + rename() 取代 root 管理的狀態檔案。此概念驗證 (PoC) 會以 RSS XML 損毀 CacheDir/job.cache，並且在重新啟動 cupsd 後，排程器無法剖析工作快取，且先前排入佇列的工作會消失。發佈之時，尚無公開可用的修補程式。(CVE-2026-34978)

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

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

  - 已解決 Linux 核心中的下列弱點：dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handler Commit 31a7a0bbeb00 (dpaa2-switch: add bounds check for if_id in IRQ handler) introduces a range check for if_id to avoid an out-of-bounds access. If an out-of-bounds if_id is detected, the interrupt status is not cleared. This may result in an interrupt storm. Clear the interrupt status after detecting an out-of-bounds if_id to avoid the problem. Found by an experimental AI code review agent at Google. (CVE-2026-23422)

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

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

  - netfilterctnetlink修正 ctnetlink_dump_exp_ct() 中的釋放後使用錯誤。ctnetlink_dump_exp_ct() 會針對 netlink 轉儲存回呼 ctnetlink_exp_ct_dump_table() 將 conntrack 指標儲存在 cb->data 中但在 netlink_dump_start() 之後立即中斷 conntrack 參照。當轉儲存跨越多個回合時第二個 recvmsg() 會觸發轉儲存回呼其會透過 nfct_help(ct) 將現已釋放的 conntrack 解除參照進而導致 ct->ext 發生釋放後使用。錯誤是 netlink_dump_control 沒有 .start 或 .done 回呼來管理轉儲存各輪次的 conntrack 參照。為此目的相同檔案中的其他轉儲存函式 (例如 ctnetlink_get_conntrack) 正確使用 .start/.done 回呼。新增在轉儲存期間保留和釋放 conntrack 參照的 .start 和 .done 回呼可修正此問題並在轉儲存回呼中的 cb->args[0] early-return 檢查後移動 nfct_help() 呼叫以避免不必要地解除參照 ct->ext。BUGKASAN在工作 ctnetlink_poc/133 CPU1 UID0 PID133 Commctnetlink_poc 未受污染的 7.0.0-rc2+ 中於 addr ffff88810597ebf0 讀取大小為 8 的 ctnetlink_exp_ct_dump_table+0x4f/0x2e0 中發生釋放後使用 7.0.0-rc2+ #3 PREEMPTLAZY 呼叫追踪 <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 由工作 133 分配 kmem_cache_alloc_noprof+0x134/0x440
    __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0:
    slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0 (CVE-2026-23458)

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

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

  - nvdimm/bus修正非同步初始化中可能發生的釋放後使用問題 Dingisoul with KASAN 報告 device_add() 在 nd_async_device_register() 中失敗時會發生釋放後使用。認可 b6eae0f61db2 (libnvdimm排程 async init 時保留父項上的參照) 已在父項裝置上正確新增一個參照直到完成非同步初始化為止。不過如果 device_add() 導致配置失敗則裝置的參照計數會在存取父項指標之前降至 0。因而導致釋放後使用。錯誤機器人 AI 正確識別該修正。儲存父項指標的參照以用於放置父項參照無論 device_add() 的結果為何。 (CVE-2026-31399)

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

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

  - NFSD延遲最後參照中斷時 (RCU 寬限期前) 在匯出放置回呼 svc_export_put() 中立即呼叫 path_put() 和 auth_domain_put()。e_show() 和 c_show() 中的 RCU 讀取程式在不保留參照的情況下同時存取 ex_path (透過 seq_path/d_path) 和 ex_client->name (透過 seq_escape)。如果 cache_clean 移除項目並同時中斷最後一個參照則會在仍在使用中釋放子物件進而在 d_path 中產生 NULL 指標解除參照。提交 2530766492ec (nfsd修正存取 ex_uuid 或 ex_stats 時的 UAF) 將 ex_uuid 和 ex_stats 的 kfree 移至 call_rcu 回呼但讓 path_put() 和 auth_domain_put() 在寬限期前執行因為可能會在 softirq 內容中休眠並執行 call_rcu 回呼。將 call_rcu/kfree_rcu 取代為 queue_rcu_work()將回呼延遲到 RCU 寬限期過後並在允許休眠的處理程序內容中執行。這允許將 path_put() 和 auth_domain_put() 移至其他資源釋放旁邊的延遲回呼中。將相同的修正套用至 expkey_put()其與 ek_path 和 ek_client 具有相同模式。專用的工作佇列將關機排出範圍僅限於 NFSD 匯出版本工作項目排清共用的 system_unbound_wq 會因來自其他子系統的不相關工作而停止。 nfsd_export_shutdown() 使用 rcu_barrier() 和 flush_workqueue()確保在匯出快取損毀前完成所有延遲的釋放回呼。修訂者：Jeff Layton <jlayton@kernel.org> (CVE-2026-31404)

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

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

  - nfsd修正 NFSv4.0 LOCK 重播快取中的堆積溢位 NFSv4.0 重播快取使用固定的 112 位元組內嵌緩衝區 (rp_ibuf[NFSD4_REPLAY_ISIZE]) 來儲存已編碼的作業回應。此大小是根據 OPEN 回應計算而未考量 LOCK 拒絕回應其中包含衝突鎖定擁有者作為最多 1024 位元組的變數長度欄位 (NFS4_OPAQUE_LIMIT)。當 LOCK 作業因為與擁有大型擁有者的現有鎖定衝突而遭拒絕時nfsd4_encode_operation() 會透過 read_bytes_from_xdr_buf() 將完整編碼的回應複製到尺寸過小的重播緩衝區中而無需進行邊界檢查。這會導致在超出緩衝區結尾處最多 944 位元組的平台超出邊界寫入進而損毀相鄰堆積記憶體。未經驗證的攻擊者可使用兩個合作的 NFSv4.0 用戶端遠端觸發此瑕疵一個使用大型擁有者字串設定鎖定另一個則要求衝突鎖定以引發拒絕。我們可以透過增加 NFSD4_REPLAY_ISIZE 來修正此問題以允許完全不透明但是這會增加每個狀態擁有者的大小而大多數鎖定擁有者並沒有那麼大。而是在復製到重播緩衝區之前檢查 NFSD4_REPLAY_ISIZE 的編碼回應長度以解決此問題。如果回應太大請將 rp_buflen 設為 0 以略過快取重播承載。其狀態仍在快取中且用戶端已收到針對原始要求的正確回應。 (CVE-2026-31402)

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

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

  - wifimac80211發生 ieee80211_tx_prepare_skb() 失敗時一律釋放 skb ieee80211_tx_prepare_skb() 具有三個錯誤路徑但其中只有兩個釋放 skb。第一個錯誤路徑 (傳回 TX_DROP 的 ieee80211_tx_prepare()) 不會釋放它但是 invoke_tx_handlers() 失敗和分割檢查兩者都會釋放。將 kfree_skb() 新增至第一個錯誤路徑使這三個路徑全部一致並移除呼叫端中現已多餘的釋放 (ath9k、mt76、mac80211_hwsim) 以避免重複釋放。在函式的 kdoc 中記錄 skb 擁有權保證。 (CVE-2026-23444)

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

ID	名稱	嚴重性
305061	Linux Distros 未修補的弱點：CVE-2026-31406	high
305060	Linux Distros 未修補的弱點：CVE-2026-31408	high
305059	Linux Distros 未修補的弱點：CVE-2026-31407	high
305057	Nutanix AOS多個弱點 (NXSA-AOS-7.5.1)	medium
305049	Nutanix AOS：多個弱點（NXSA-AOS-7.5.1.1）	medium
305007	Linux Distros 未修補的弱點：CVE-2026-34933	medium
305006	Linux Distros 未修補的弱點：CVE-2026-33709	medium
304994	Linux Distros 未修補的弱點：CVE-2026-23464	medium
304993	Linux Distros 未修補的弱點：CVE-2026-23430	medium
304992	Linux Distros 未修補的弱點：CVE-2026-23468	medium
304991	Linux Distros 未修補的弱點：CVE-2026-23461	high
304990	Linux Distros 未修補的弱點：CVE-2026-31390	medium
304989	Linux Distros 未修補的弱點：CVE-2026-23442	medium
304988	Linux Distros 未修補的弱點：CVE-2026-23438	medium
304987	Linux Distros 未修補的弱點：CVE-2026-23455	critical
304986	Linux Distros 未修補的弱點：CVE-2026-23420	medium
304985	Linux Distros 未修補弱點：CVE-2026-35582	high
304984	Linux Distros 未修補的弱點：CVE-2026-23460	medium
304983	Linux Distros 未修補弱點：CVE-2026-23427	high
304982	Linux Distros 未修補的弱點：CVE-2026-23457	high
304981	Linux Distros 未修補的弱點：CVE-2026-23462	high
304980	Linux Distros 未修補的弱點：CVE-2026-23426	medium
304979	Linux Distros 未修補的弱點：CVE-2026-23470	medium
304978	Linux Distros 未修補的弱點：CVE-2026-23452	medium
304977	Linux Distros 未修補的弱點：CVE-2026-23419	medium
304976	Linux Distros 未修補的弱點：CVE-2026-31396	high
304975	Linux Distros 未修補的弱點：CVE-2026-31394	medium
304974	Linux Distros 未修補弱點：CVE-2026-23450	critical
304973	Linux Distros 未修補的弱點：CVE-2026-26477	high
304972	Linux Distros 未修補的弱點：CVE-2026-23454	high
304971	Linux Distros 未修補弱點：CVE-2026-34980	medium
304970	Linux Distros 未修補的弱點：CVE-2026-23445	medium
304969	Linux Distros 未修補的弱點：CVE-2026-27447	medium
304968	Linux Distros 未修補的弱點：CVE-2026-23474	medium
304967	Linux Distros 未修補的弱點：CVE-2026-34979	medium
304966	Linux Distros 未修補的弱點：CVE-2026-23436	medium
304964	Linux Distros 未修補的弱點：CVE-2026-23469	medium
304963	Linux Distros 未修補的弱點：CVE-2026-31401	high
304962	Linux Distros 未修補的弱點：CVE-2026-34990	medium
304960	Linux Distros 未修補的弱點：CVE-2026-23446	medium
304959	Linux Distros 未修補弱點：CVE-2026-23428	high
304958	Linux Distros 未修補的弱點：CVE-2026-23434	medium
304957	Linux Distros 未修補的弱點：CVE-2026-31391	medium
304956	Linux Distros 未修補的弱點：CVE-2026-34978	medium
304955	Linux Distros 未修補的弱點：CVE-2026-23422	high
304954	Linux Distros 未修補的弱點：CVE-2026-23458	high
304933	Linux Distros 未修補的弱點：CVE-2026-31399	high
304932	Linux Distros 未修補的弱點：CVE-2026-31404	high
304931	Linux Distros 未修補的弱點：CVE-2026-31402	high
304930	Linux Distros 未修補的弱點：CVE-2026-23444	medium

偵測

Nessus 的 Misc. 系列

high

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

critical

medium

high

medium

high

high

high

medium

medium

medium

medium

high

medium

critical

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

high

high

high

high

medium