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

  - Vim 是開放原始碼命令列文字編輯器。在 9.2.0840之前，runtime/plugin/netrwPlugin.vim 會載入 netrw，而 runtime/pack/dist/opt/netrw/autoload/netrw.vim 會透過將攻擊者控制的目錄路徑內插到已執行的 ：menu 命令中來建構書籤、歷史記錄和目標功能表項目。
    s：NetrwBookmarkMenu（）、s：NetrwTgtMenu（）、g：netrw_menu_escape、EX_TRLBAR 和 netrw#MakeTgt（） 無法中和 |五個建築工地的命令分隔符或單引號，允許在 GUI Vim 中瀏覽或加入書籤的特製路徑執行任意 Ex 和作業系統命令。9.2.0840 版已修正此問題。(CVE-2026-73078)

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

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

  - Vim 是開放原始碼命令列文字編輯器。在 之前， 9.2.0847runtime/autoload/vimball.vim 允許名為 的特製 vimball 成員。VimballRecord 以攻擊者選擇的命令覆寫安裝記錄。當 vimball#RmVimball（） 稍後處理相符的記錄項目時，儲存的 Ex 命令 （包括透過 ：！ 叫用的作業系統命令） 會以執行 Vim 的使用者權限執行。9.2.0847 版已修正此問題。(CVE-2026-73076)

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

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

  - 韌體內某些 Intel（R） 至強 （R） 處理器的輸入驗證不當可能會導致權限提升。具有特權使用者的啟動程式碼和 smm 攻擊者，結合高複雜度的攻擊，可能會造成資料變更。當攻擊需求存在且不需要特殊內部知識且不需要使用者互動時，可能會透過本機存取發生此結果。潛在弱點可能會影響易受攻擊系統的機密性 （無）、完整性 （無） 和可用性 （無），進而造成後續的系統機密性 （無）、完整性 （高） 和可用性 （無） 影響。（CVE-2026-20901）

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

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

  - media： chips-media： wave5： 將src_buf移除移至 finish_encode 在編碼器處理期間，IRQ 回應可能會透過v4l2_m2m_buf_done呼叫將緩衝區傳回使用者空間。在此時間裡，使用者空間可以在start_encode從就緒佇列中移除索引之前，將相同的緩衝區排入佇列。然後，這會導致就緒佇列中的緩衝區可能是自我迴圈，因為__list_add中的 WRITE_ONCE prev->next， new） 呼叫。當最終呼叫 __list_del 時，迴圈已經進行，因此沒有任何內容指向就緒的佇列清單頭，並且指標被毒害。在從 m2m 就緒佇列中移除緩衝區之前，不應將緩衝區標示為 DONE。將移除完全移至finish_encode。
    (CVE-2026-68228)

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

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

  - Browserslist 是在前端工具之間共用目標瀏覽器和Node.js版本的設定工具。之前， 4.28.7index.js 會在快取中保留每個不同的「（queries， context）」結果，並在 parseCache 中保留每個 parseQueries（） AST，而沒有大小上限、TTL 或驅逐，因此攻擊者能夠影響重複的 browserslist（） 查詢值 （包括自 '<year>-<month>-<day>' 起有效的查詢） 繞過呼叫端控制的BROWSERSLIST_DISABLE_CACHE緩解措施，並導致線性記憶體增長，然後發生記憶體不足處理程序損毀。4.28.7 版已修正此問題。(CVE-2026-73089)

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-r2gm-p682-3mpm： svxreflector： 透過可重入用戶端刪除的釋放後使用] （CVE-2026-73146）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-58ph-q79f-7x9x： HTTP 伺服器：無限請求累積] （CVE-2026-73145）

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

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

  - wifi： MT76： MT7925：修正重設連結重播中的損毀 在重設復原期間，mt7925_vif_connect_iter（） 會重播 mvif->valid_links 中追蹤之連結的韌體狀態。在 MLO 連結變更或 MCU 逾時復原之後，驅動程式點陣圖可以暫時包含 mac80211 bss_conf已消失的連結。
    這可以將 NULL bss_conf傳遞給 mt76_connac_mcu_uni_add_dev（），與第二個引數 x1 為 NULL 的損毀相符： pc ： mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr：
    mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 ： ffffff80a77f6018 x1 ： 0000000000000000 x0 ：
    ffffff8099402080 呼叫追蹤：mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] 在重播連結之前跳過缺少的bss_conf條目。Non-MLO AP/STA 重設重播不會變更，因為協助程式仍會傳回舊版連結的 &vif->bss_conf。（CVE-2026-68307）

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

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

  - Bluetooth： MGMT：當單一參數更新變更現有的 LE 中央連線時，重新驗證佇列LOAD_CONN_PARAM更新MGMT_OP_LOAD_CONN_PARAM佇列 conn_update_sync（）。佇列工作目前儲存從 hdev->le_conn_params 借用的hci_conn_params項目。稍後的 LOAD_CONN_PARAM 請求可以在 hci_cmd_sync_work（） 執行佇列回呼之前清除停用的參數並釋放該項目。請勿將借用的hci_conn_params指標保留在佇列工作中。改為將hci_conn排入佇列並保留參考，直到佇列的回呼完成為止。當工作執行時，請重新驗證連線是否仍然存在，查詢目前的hci_conn_params項目，如果使用者空間在工作擱置時移除了該項目，則取消更新。從 hdev->lock 下的目前參數項目複製間隔值，然後刪除鎖定並繼續使用 hci_le_conn_update_sync（） 發出更新。驗證重現了此核心報告： 錯誤：KASAN：conn_update_sync+0x2a/0xf0 中的 slab-use-after-free [bluetooth] 透過任務 kworker/u17：0/377 在 addr ffff88810c697126 讀取大小 1 工作佇列：hci0 hci_cmd_sync_work [bluetooth] 呼叫追蹤： <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [藍牙] hci_cmd_sync_work+0x187/0x210 [藍牙] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 由任務 466 分配： hci_conn_params_add+0xa6/0x240 [藍牙] load_conn_param+0x4e1/0x850 [藍牙] hci_sock_sendmsg+0x96b/0xf80 [藍牙] 由任務 474 釋放：
    kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [藍牙] load_conn_param+0x4bf/0x850 [藍牙] hci_sock_sendmsg+0x96b/0xf80 [藍牙] （CVE-2026-68394）

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

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

  - ALSA： had： cs35l41：驗證並釋放 ACPI 靜音物件 cs35l41_get_acpi_mute_state（） 會評估 _DSM 方法以取得 ACPI 靜音狀態，並從傳回的物件讀取第一個位元組。不過，傳回的 ACPI 物件是由呼叫端所擁有，而且使用後永遠不會釋放，因此每個成功的查詢都會洩漏_DSM結果物件。程式代碼也會假設傳回的物件是至少具有一個位元組的緩衝區。格式不正確的韌體回應可能會傳回不同的物件類型或空白緩衝區，而直接 ret->buffer.pointer 解除參照接著可以存取無效的指標。使用類型化的 _DSM 協助程式、驗證傳回的緩衝區是否至少包含一個位元組，並在讀取 ACPI 物件之後釋放它。
    (CVE-2026-68346)

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

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

  - ice：防止非 PF VSI 類型的 tstamp 環配置 pf->txtime_txqs 點陣圖會追蹤哪些 Tx 佇列已啟用 ETF （最早 TxTime First） 卸載。此點陣圖依佇列編號編製索引，並由 ice_offload_txtime（） 設定，僅在 PF VSI 佇列上運作。但是，ice_is_txtime_ena（） 不會在查閱點陣圖之前檢查 VSI 類型。在 PF Tx 佇列 0 上啟用 ETF 卸載時，會在 pf->txtime_txqs 中設定位元 0。在後續的 PCI 重設重建期間，會重新配置 CTRL VSI 的 Tx 佇列 0，並針對該環呼叫 ice_is_txtime_ena（）。由於它僅透過佇列索引檢查 pf->txtime_txqs，而不區分 VSI 類型，因此它會找到設定的位元 0 並傳回 true，與 PF VSI 的 ETF 佇列相符，而不是 CTRL VSI 的佇列。這會導致 ice_vsi_cfg_txq（） 以虛假的方式為 CTRL VSI 通道配置tstamp_ring。
    由於 CTRL VSI 環沒有關聯的 netdev，因此 ice_clean_tx_ring（） 在到達 ice_free_tx_tstamp_ring（） 之前會在 ！netdev 檢查中提前返回，從而洩露分配。每次 PCI 重設都會洩漏一個 64 位元組的tstamp_ring。透過限制 ice_is_txtime_ena（） 僅對 PF VSI 通道傳回 true 來修正此問題，因為txtime_txqs僅對 PF VSI 佇列有意義。（CVE-2026-68292）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-x5r8-rq62-q9cj： remotetrx：未經驗證的音訊長度 + 暴露的收發器控制] （CVE-2026-73151）

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

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

  - ublk：等待 ublk_dev_ready（） 而不是 ub->completion ub->completion 只有在成功START_USER_RECOVERY時才會重新武裝。如果 ublk 伺服器傳送沒有 END_USER_RECOVERY - 例如，其 START 失敗
    -EBUSY 且錯誤已忽略 - 前一個復原週期的過時完成滿足等待，且裝置被標記為 LIVE，且重新排隊清單在 FETCH 串流仍在執行且仍設定 ubq->canceling 時被踢出。kick 會重新分派先前重新排入佇列的要求，
    __ublk_queue_rq_common（） 看到 ->canceling 並透過 __ublk_abort_rq（） 再次停放它，在最後一個 FETCH 清除 ->canceling 之後，不會再次踢出重新排隊清單：請求在保留其標籤時滯留在那裡。如果這是沖洗機器的flush_rq，則後續的每個 fsync 都會在不間斷的睡眠中堆積起來，並且拆卸會因標籤耗盡而掛起。這與在精靈損毀復原後，ublk 上帶有 ext4 的 PREFLUSH 遺失的報告相符。ub->completion 是一個邊緣觸發的閂鎖，用作每個佇列都擷取所有 I/O 命令的層級條件的代理，這些命令可以迴歸 （F_BATCH 的 UNPREP，守護程式死亡），並且可以跳過其重新布防。刪除它並等待實際條件：新的協助程式 ublk_wait_dev_ready_and_lock（） 透過 wait_var_event_interruptible（） 等待 ublk_dev_ready（），從 ublk_mark_io_ready（） 喚醒，然後在 ub->mutex 下重新檢查它，再次等待回歸，並返回保留互斥並保證就緒。在清除最後一個佇列的 ->canceling 的相同 ub->mutex 關鍵區段中，就緒情況變為 true，因此END_USER_RECOVERY將裝置標記為 LIVE，並在 ->canceling 清除後嚴格踢出重新排隊清單。等待保持可中斷狀態，因此其常駐程式已終止的伺服器仍可收到訊號。對於 ublk_ctrl_start_dev（），這會將F_BATCH ready->UNPREP 迴歸上的 fail-fast -EINVAL 取代為等待裝置再次準備就緒。（CVE-2026-68173）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-pc2g-2p95-4cr5：反射器用戶端中的 TCL 命令插入] （CVE-2026-73147）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-qccg-7pw6-787v： FRN 模組：無限記憶體成長] （CVE-2026-73144）

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

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

  - pds_core：修正重設執行緒之間的鎖死，並在執行重設之前移除 pci_reset_function（） 取得device_lock。pdsc_remove（） 由已持有device_lock的 PCI 核心呼叫。如果呼叫 pdsc_remove（） 時 pdsc_pci_reset_thread（） 正在執行，則 destroy_workqueue（） 將阻止等待工作完成，而工作則在等待device_lock時被阻止 - 死鎖。使用內部使用 pci_dev_trylock（） 的 pci_try_reset_function（）。這會同時取得裝置鎖定及 PCI 配置存取鎖定而不封鎖 - 如果爭用任一鎖定，它會立即傳回 -EAGAIN。
    這可避免鎖死，同時確保在重設期間正確進行組態空間存取序列化。
    pci_dev_get/put 呼叫也會被移除，因為它們是不必要的 - 驅動程式擁有的工作佇列會在 pdsc_remove（） 中銷毀，保證在移除傳回之前完成工作。PCI 核心在整個解除綁定序列中保留其對pci_dev的參照。（CVE-2026-68319）

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

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

  - ksmbd：在非同步 oplock 中斷通知期間釘選 conn smb2_oplock_break_noti（） 和 smb2_lease_break_noti（） 將ksmbd_conn指標儲存在非同步ksmbd_work中，然後將該工作排入佇列 ksmbd-io。此工作只會遞增 conn->r_count，這可防止拆卸在遞增之後傳遞擱置要求等候，但不會將結構釘選ksmbd_conn物件。如果連線中斷與 oplock 中斷通知爭用，則可以在佇列背景工作完成之前卸除最後一個 conn 參照。然後，工作者在 ksmbd_conn_write（） 和 ksmbd_conn_r_count_dec（） 中使用釋放的 conn。將 conn 指標發佈至非同步工作專案時，取得實際的 conn 參考，並在通知工作遞減 r_count之後捨棄它。將相同的存留期規則套用至租賃中斷通知，其使用相同的 work->conn 模式。（CVE-2026-68381）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-xmcv-mjpv-x46q： 音訊解碼器：堆疊 VLA 耗盡] （CVE-2026-73141）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-6wgq-wg3w-jgvx： svxreflector：透過懸空 JSON 參照的釋放後使用寫入] （CVE-2026-73148）

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

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

  - afs：修正 afs_edit_dir_remove（） 以取得而不是尋找區塊 0 修正 afs_edit_dir_remove（） 以使用 afs_dir_get_block（） 而不是 afs_dir_find_block（） 來取得區塊 0，因為後者會在afs_dir_iter中找到的區塊中快取，並且如果完成另一個 afs_dir_find_block（），則可以[*] 切換它所在的頁面。這與 afs_edit_dir_add（） 所做的類似。[*]每頁有多個區塊。（CVE-2026-68168）

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

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

  - rds： tcp：在拆卸偵聽通訊端之前取消註冊 sysctl rds_tcp_exit_net（） 會透過 rds_tcp_kill_sock（） 釋放 per-netns RDS TCP 偵聽通訊端，然後再取消註冊 per-netns sysctl 表格。由於 rds_tcp_skbuf_handler（） 從 rtn->rds_tcp_listen_sock->sk 派生 netns，因此並行 sysctl 寫入可能會與 netns 拆卸爭用，並取消參照釋放的通訊端/sk。KASAN 將爭用報告為： 錯誤：KASAN：rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c：721 中的 slab-use-after-free proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c 在呼叫 rds_tcp_kill_sock（） 之前取消註冊 RDS TCP sysctl 表來修正此問題。
    unregister_net_sysctl_table（） 會防止新的 sysctl 處理常式啟動，並等待進行中的處理常式完成，以便安全地釋放偵聽通訊端。已針對連結的再現程式測試修正程式。（CVE-2026-68290）

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

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

  - net/mlx5e：使用 sender devcom 進行 MPV 主控 PCIe DPC 還原後，mlx5 會重新載入受影響的功能並重播多埠隸屬關係事件。在報告的故障中，第一個相關裝置錯誤為： pcieport 0000：10：01.1： DPC： 包含事件 pcieport 0000：10：01.1： PCIe 匯流排錯誤：
    severity=未更正（致命）pcieport 0000：10：01.1： [ 5] SDES（第一個）mlx5 恢復了 PCI 功能並恢復了 0000：11：00.1。在該恢復期間，RDMA 多埠綁定重播了MLX5_DRIVER_EVENT_AFFILIATION_DONE，mlx5e 發送MPV_DEVCOM_MASTER_UP。主持人隨後驚慌失措：錯誤：
    核心 NULL 指標解除參照，位址：0000000000000010 RIP：mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI：00000000000000000 包含的呼叫追蹤：mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom 註冊會將 mlx5e 私有資料發佈到元件對等體清單，然後 mlx5e_devcom_init_mpv（） 將傳回的元件裝置儲存在 priv->devcom 中。因此，並行主控事件可以到達其私人資料可見，但其 priv->devcom 反向指標仍為 NULL 的對等。MPV_DEVCOM_MASTER_UP 已將發送者/主 mlx5e 私人數據作為event_data。就緒位會儲存在共用 devcom 元件上，而不是個別對等體上。將 MPV 元件標記為就緒時，請使用寄件者 devcom。這可保留整備轉換，同時避免在 PCI 錯誤復原之後的隸屬關係重播期間，對等 devcom 指標的 NULL 解除參照。（CVE-2026-68139）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-4g8q-rgxf-fmgf： EchoLink 代理：訊息長度中的整數截斷] （CVE-2026-73152）

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

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

  - misc： nsm：裝置開啟時固定模組 misc_open（） 會使用 fops_get（） 安裝 misc 驅動程式的檔案作業，這會在取代檔案的f_op之前固定 file_operations：：owner。NSM 雜項裝置會保留 nsm_dev_fops.owner 未設定，因此開啟 /dev/nsm 不會在 nsm 驅動程式上參照模組。
    如果驅動程式建置為模組，則開啟的檔案描述元可以在提供其 ioctl 回呼之模組的 rmmod 中存活。透過該描述元的稍後 ioctl 可以呼叫卸載的模組文字。
    將 nsm_dev_fops.owner 設定為 THIS_MODULE，以便在任何 /dev/nsm 檔案描述元開啟時，其他核心會保留模組，以符合已安裝檔案作業的存留期預期。（CVE-2026-68178）

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

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

  - pds_core：修正移除期間工作佇列上的釋放後使用 在 pdsc_remove（） 中，工作佇列會在呼叫 pdsc_teardown（） 之前被銷毀。此排序允許兩個路徑將已銷毀工作佇列上的工作排入佇列：
    1. 如果 pdsc_teardown（） -> pdsc_devcmd_reset（） 逾時，則 pdsc_devcmd_locked（） 佇列中的錯誤路徑health_work。2. NotifyQ 事件可以在 pdsc_teardown（） 中呼叫 free_irq（） 之前觸發 ISR 並排入佇列工作。透過在 pdsc_teardown（） 之後移動 destroy_workqueue（） 來修正，以便工作佇列的壽命超過每個佇列程式;然後，destroy_workqueue（） 會清除任何仍待處理的工作。排空佇列的工作也需要排序拆卸，以便最後釋放工作所接觸的資源： - 在 pdsc_qcq_free（） 中，釋放中斷之後，cancel_work_sync（） 佇列的工作，然後才清除 qcq->intx，因此 pdsc_process_adminq（） 讀取 qcq->intx 以傳回中斷信用不能與清除爭用。- 在 notifyqcq 之前釋放 adminqcq： 當釋放 adminqcq 時，會釋放共用 adminq ISR，且 adminq 工作存取 notifyqcq，因此在釋放 notifyqcq 之前必須停止兩者。（CVE-2026-68318）

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

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

  - drm/imagination：將配對的工作柵欄計為 prepare_job（） 中的相依性 DRM 排程器的 prepare_job（） 回呼會計算工作的剩餘非訊號原生相依性，以防止作業提交，直到這些相依性 （加上工作資料和柵欄更新） 可以放入工作佇列的 CCCB 中。這意味著檢查韌體中可以等待哪些依賴項，即它們是否由 UFO 物件支援，即
    是否已將其 drm_sched_fence：:p arent 指派給 pvr_queue_fence：：base 柵欄。當擁有柵欄的工作提交至韌體時，就會發生這種情況。配對的幾何圖形和片段工作會同時提交，這表示在提交之前無法以這種方式檢查它們之間的相依性。更新 job_count_remaining_native_deps（） 以考量配對工作之間的相依性。這修正了以下情況：prepare_job（） 低估了幾乎完整的片段 CCCB 中留下的空間，錯誤地解除封鎖了 run_job（），然後提前返回，而沒有將完整的命令序列寫入 CCCB。上述情況會導致核心警告，例如以下情況，並可能出現工作逾時 （視服務員對缺少的命令而定）： [ 375.702979] 警告：drivers/gpu/drm/imagination/pvr_cccb.c：178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr]， CPU#1： kworker/u16：3/47 [ 375.703160] 連結的模組： [ 375.703571] CPU： 1 UID： 0 PID： 47 Comm： kworker/u16：3 Tainted： G W 7.0.0-rc2-g817eb6b11ad5 #40 搶佔 [ 375.703613] 污染： [W]=WARN [ 375.703627] 硬體名稱： Texas Instruments AM625 SK （DT） [375.703645] 工作佇列： powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate： 80000005 （Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--） [ 375.703764] pc ：
    pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr：
    pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp ： ffff800084a97650 [ 375.703934] x29：
    ffff800084a97740 x28： 0000000000000958 x27： ffff80008565d000 [ 375.703979] x26： 0000000000000030 x25：
    ffff800084a97680 x24： 0000000000001000 [ 375.704017] x23： ffff800084a97820 x22： 1ffff00010952ecc x21：
    0000000000000008 [ 375.704056] x20： 00000000000006a8 x19： ffff00002ff7da88 x18： 00000000000000000 [375.704093] x17： 0000000020020000 x16： 0000000000020000 x15： 000000000000000 [ 375.704132] x14：
    000000000000000000 x13： 000000000000000000 x12： 00000000000000000000 [ 375.704168] x11： 0000000000000f2f2 x10：
    00000000f3000000 x9 ： 00000000f3f3f3f3 [ 375.704206] x8 ： 00000000f2f2f200 x7 ： ffff700010952ecc x6 ：
    0000000000000008 [ 375.704243] x5 ： 0000000000000000 x4 ： 1ffff00010acba00 x3 ： 000000000000000000 [375.704279] x2 ： 0000000000000007 x1 ： 0000000000000fff x0 ： 000000000000002f [ 375.704317] 呼叫追蹤： [375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] （P） [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ 結束追蹤 000000000000000000 ]--- （CVE-2026-68281）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-38fq-mrrg-8rmr： RtlTcp：格式錯誤的問候語導致守護程式退出] （CVE-2026-73143）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-4f8x-49pf-3x5v： APRS 訊息建構中發生緩衝區溢位] （CVE-2026-73150）

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

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

  - tcp：修正 PSP 原則失敗時的 TIME_WAIT 通訊端參照洩漏 在 IPv4 和 IPv6 接收路徑中 PSP 原則失敗時，釋放 TIME_WAIT 通訊端參照並跳至discard_it。這可防止tcp_tw_bucket結構的記憶體洩漏。（CVE-2026-68379）

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

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

  - 藍牙：hci_sync：按住 hdev->lock 進行hci_conn_params查詢hci_conn_params_lookup需要保留 hdev->lock，否則清單反覆運算或參數存取不安全。保留 hdev->lock 以進行 hci_sync 中的參數查詢。（CVE-2026-68390）

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

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

  - 在 Undertow HTTP 伺服器的 ChunkReader 元件中發現缺陷，WildFly 和 JBoss EAP 使用該元件來處理區塊傳輸編碼。出現此問題的原因是剖析器使用單一內部變數來儲存剩餘的區塊大小和狀態旗標。透過傳送具有極大區塊大小的特製請求，攻擊者可以導致這些值重疊，誘使剖析器認為請求已過早完成。這可能會允許不同步處理第二個走私請求，從而可能繞過安全控制。（CVE-2026-14180）

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

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

  - s390/總和檢查碼：修正沒有向量工具的 csum_partial（） 目前 csum_partial（） 呼叫 csum_copy（） 且 copy=false dst=NULL。在沒有向量工具的機器上，csum_copy（） 會回復至 cksm（dst， ...），導致從位址零而不是來源緩衝區計算總和檢查碼。VX 實作已對從 src 載入的資料進行總和檢查碼。透過將 src 傳遞給 cksm（），使後援執行相同的操作。（CVE-2026-68385）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-624p-cp8x-6hp6： EchoLink RTCP/SDES：越界讀取] （CVE-2026-73153）

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

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

  - 在 DBI 中發現缺陷。這是針對 RHEL 9.8.z 和 10.2.z 的 CVE-2026-14380 部分修正。有關詳細的聲明、描述和緩解措施，請參閱原件 https://access.redhat.com/security/cve/cve-2026-19546。（CVE-2026-19546）

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

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

  - 在 OpenStack 之前指定 22.0.1中，區域建立檢查 （_is_subzone、_is_superzone及重複區域資料庫限制） 的範圍僅限於目標集區。已驗證的使用者可以透過 AttributeFilter 排程器將區域排程到不同的集區，以建立與另一個租用戶區域衝突的重疊區域，藉此略過這些檢查。這會啟用跨租用戶 DNS 劫持 （將流量重新導向至攻擊者控制的 IP） 和 DNS 拒絕服務 （NODATA 回應）。利用需要在 scheduler_filters 中啟用 AttributeFilter 的多集區部署，這是非預設但已記錄且支援的自助服務階層設定。（CVE-2026-71193）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-mh75-5pr3-qv2p： NetRx：透過未經驗證的 MsgAudio 長度越界讀取] （CVE-2026-73149）

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

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

  - 藍牙：管理：修正 unpair_device/disconnect_sync 中的鎖定 在關鍵區段之外解除參照受 RCU 保護的指標是無效的，可能會導致 UAF。採用 hdev->lock 進行hci_conn查詢和 hci_abort_conn（）。此時請勿使用 RCU 來確保 conn 已完全初始化。（CVE-2026-68392）

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

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

  - usb： core： port：元件 unbind 上解除連接 Type-C 連接器 connector_unbind（） 是 connector_bind（） 的鏡像，但它缺少 connector_bind（） 透過以下方式對 typec_deattach（） 進行的對稱呼叫： if （port_dev->child） typec_attach（port_dev->connector， &port_dev->child->dev）;當 Thunderbolt 擴充座被拔下時，兩個拆卸路徑爭用：1. 元件框架首先呼叫 connector_unbind（），它設定 port_dev->connector = NULL，而不呼叫 typec_deattach（）。這會在結構typec_port中留下 port->usb2_dev/port->usb3_dev 指向即將釋放的 USB 裝置。
    2. usb_disconnect（） 接著呼叫 typec_deattach（port_dev->connector， ...），但 port_dev->connector 已經為 NULL，因此呼叫為無操作，並且連接埠>usb2_dev永遠不會被清除。3. 同時，UCSI 偵測到 PD 夥伴斷開連接事件並呼叫 typec_unregister_partner（），該事件讀取 port->usb2_dev（現在是釋放記憶體的懸空指標）並將其傳遞給釋放裝置上的 typec_partner_unlink_device（） -> sysfs_remove_link（） -> dev_name（），從而破壞 typec/UCSI 夥伴狀態。此損毀會讓 Thunderbolt 通道在下一個擴充基座熱插拔時處於不一致的狀態。在受影響的硬體上，擴充座的 I225/igc NIC 無法列舉： 當 igc 驅動程式仍在初始化 （PCIe 連結遺失） 時，AER 會觸發插槽重設，而後續的 igc_reset 嘗試在已中斷連結的裝置上命中igc_rd32：igc 0000：2e：00.0 eth0：PCIe 連結遺失，裝置現在已中斷連結 igc：讀取 reg 0x0 失敗！警告： CPU：9 PID：
    129 在 drivers/net/ethernet/intel/igc/igc_main.c：7005 igc_rd32+0xa4/0xc0 [igc] 呼叫追蹤：
    igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4.UCSI 稍後會處理 PD 夥伴中斷連線並呼叫 typec_unregister_partner（），它仍然會看到過時的連接埠>usb2_dev，並嘗試第二次移除其 sysfs 連結： kernfs：無法移除 'typec'，無目錄 警告： CPU：6 PID：55 at fs/kernfs/dir.c：1706 kernfs_remove_by_name_ns+0xe9/0xf0 工作佇列：事件ucsi_handle_connector_change [typec_ucsi] 呼叫追蹤： sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 在釋放後備記憶體後，會取消參照相同的過時指標， 將警告變成釋放後使用。修正不對稱性：在清除 port_dev->connector 之前呼叫 typec_deattach（），與 connector_bind（） 在綁定端所做的動作相符。typec_partner_deattach（） 已受 port->partner_link_lock 保護，因此可以使用並行的 typec_unregister_partner（） 路徑安全地序列化。
    (CVE-2026-68372)

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

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

  - net：txgbe：修正移除時的 FDIR 濾波器洩漏 可以在介面關閉時新增完美的 FDIR 濾波器，並保留在軟體清單中以供以後還原。unregister_netdev（） 只會在裝置啟動時呼叫 ndo_stop，因此在這種情況下，會跳過 txgbe_close（） 中的 txgbe_fdir_filter_exit（），並且在驅動程式移除時會洩漏篩選器。同時釋放 txgbe_remove（） 中的篩選器清單。（CVE-2026-68321）

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

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

  - net：airoha：修正 airoha_ppe_deinit（） 中潛在的釋放後使用 airoha_ppe_deinit（） 透過 rcu_replace_pointer（） 將 NPU 指標替換為 NULL，但不會等待現有 RCU 讀取器退出後再呼叫 ppe_deinit（） 和 airoha_npu_put（）。如果 RCU 讀取端關鍵區段中的讀取器在釋放 NPU 時仍保留對 NPU 的參照，則可能會導致釋放後使用。init 路徑 （airoha_ppe_init） 已經在 rcu_assign_pointer（） 之後呼叫 synchronize_rcu（），但在提交 6abcf751bc08 中引入的 deinit 路徑 （net：airoha：在 airoha_ppe_deinit（）） 中修正 schedule while atomic 在從 rcu_read_lock（）/rcu_dereference（） 切換到 rcu_replace_pointer（） 時省略了匹配屏障。在 ppe_deinit（） 之前新增 synchronize_rcu（），以確保所有現有的 RCU 讀取器在釋放 NPU 資源之前都已完成。（CVE-2026-68332）

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

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

  - pds_core：修正輔助裝置 add/del 爭用 兩條路徑新增或刪除同一個插槽 （pf->vfs[vf_id].padev）：
    VF 的 pdsc_reset_done（） 和 PF 的 devlink enable_vnet/disable_vnet 處理常式。它們在config_lock上序列化，但都沒有正確保護其下方的插槽。add（） 註冊並儲存新的輔助裝置，而不先檢查插槽，因此第二次新增已填入的插槽會洩漏第一個裝置。del（） 在外部config_lock進行檢查，因此兩個並發的 del 都可以通過它;第一個清除插槽，第二個解除參照 NULL 指標。檢查並更新兩個路徑中config_lock下的插槽。（CVE-2026-68317）

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

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

  - 在 OpenStack 之前指定 22.0.2中，mDNS 處理常式會在解析記錄查詢和 NOTIFY 要求時執行集區盲查詢。當不同集區中存在兩個具有相同名稱的區域時，查閱會失敗並出現確定性錯誤，導致處理常式針對透過該路徑的所有 DNS 查詢傳回 REFUSED。_handle_notify路徑可透過單一未經驗證的 UDP 封包遭到惡意利用。這可透過最近不同 CVE 中所述的跨租用戶區域重疊獨立連線，而且也會影響合法的相同租用戶跨集區設定。BIND9 檢視無法緩解此問題，因為 mDNS 是任何檢視設定的共用服務上游。（CVE-2026-71194）

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

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

  - net： gre：修正具有 SEQ/CSUM 的 GRE 通道的 lltx 迴歸 提交 00d066a4d4ed 之前 （netdev_features：
    將 NETIF_F_LLTX 轉換為 dev->lltx），NETIF_F_LLTX在 __gre_tunnel_init（） 和 ip6gre_tnl_init_features（） 中無條件地與GRE_FEATURES一起設定：dev->features |= GRE_FEATURES |NETIF_F_LLTX;當該提交將NETIF_F_LLTX轉換為 dev->lltx 旗標時，它會將 'dev->lltx = true' 放在 SEQ/CSUM 早期傳回之後，而不是在它們之前。這會導致具有 SEQ 或 CSUM+encap 的 GRE/GRETAP/ip6gre 通道丟失無鎖定 TX，從而在其ndo_start_xmit周圍重新引入_xmit_lock獲取。由於 GRE xmit 透過 ip_tunnel_xmit（） 重新進入堆疊，因此持有_xmit_lock可能會與底層裝置發生 ABBA 鎖死的風險。CPU0 CPU1
    ---- ---- lock（&qdisc_xmit_lock_key#6）; lock（&qdisc_xmit_lock_key#3）; lock（&）; lock（&qdisc_xmit_lock_key#6）;
    lock（&qdisc_xmit_lock_key#3）;透過在兩個函式的早期傳回之前移動 dev->lltx = true來修正，恢復原始的無條件行為。（CVE-2026-68296）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-5xr9-fmm8-7p8x： remotetrx NetUplink：連線物件洩漏 DoS] （CVE-2026-73142）

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

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

  - Debian Linux - svxlink - 無 Ubuntu Linux - [GHSA-5g48-xjmf-7p4q： StationData：：setData 堆疊溢位] （CVE-2026-73154）

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

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

  - drm/xe/vm：修正 xe_vm_create（） 提交 9e9787414882 中 resv obj 分配失敗時的 SVM 洩漏 （drm/xe/userptr：
    將 xe_hmm 替換為 GPUSVM），使 xe_svm_init（） 在 xe_vm_create（） 中無條件，並將其擴展為同時初始化非故障模式 VM 的簡單 GPUSVM 狀態。xe_vm_close_and_put（） 中相符的 xe_svm_fini（） 呼叫已更新為無條件執行，但 xe_vm_create（） 中的錯誤展開路徑則未執行。在 drm_gpuvm_resv_object_alloc（） 失敗路徑上，xe_svm_init（） 已經成功，但只有在設定XE_VM_FLAG_FAULT_MODE時才會呼叫 xe_svm_fini（）。對於非故障模式虛擬機器，這會使 vm->svm.gpusvm 部分初始化，並洩漏 drm_gpusvm_init（） 配置的資源。對於故障模式 VM，xe_svm_init（） 還會透過 drm_pagemap_acquire_owner（） 取得頁面地圖擁有者，並透過 xe_svm_get_pagemaps（） 取得頁面地圖。這些資源是由 xe_svm_close（） 而非 xe_svm_fini（） 釋放的。在相同的錯誤路徑上，也不會呼叫 xe_svm_close（），因此錯誤模式 VM 會洩漏頁面對應擁有者和頁面對應。修正這兩個洩漏： - 在err_svm_fini路徑上無條件呼叫 xe_svm_fini（），與無條件的 xe_svm_init（） 呼叫相符。將 vm->size = 0 指派移出條件，讓 xe_svm_fini（） （和 xe_svm_close（）） 中的 xe_vm_is_closed（） 判斷提示適用於這兩種模式。- 在 xe_svm_fini（） 之前呼叫故障模式 VM 的 xe_svm_close（），以符合 xe_vm_close_and_put（） 中使用的順序。（從提交 ca2a3587d577ba764e0fe628fb676244fc33ddd4 中挑選）（CVE-2026-68298）

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

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

  - mtd：修正 add_mtd_device（） 錯誤路徑中的雙重釋放和WARN_ON 當分割區的 add_mtd_device（） 內的 device_register（） 或 mtd_nvmem_add（） 失敗時，錯誤處理會透過 put_device（） 或 device_unregister（） 觸發 mtd_release（）。mtd_release（） 呼叫 release_mtd_partition（），釋放 mtd_info 結構。
    不過，mtd_add_partition（） 和 add_mtd_partitions（） 等呼叫端也會在其錯誤路徑中呼叫 free_partition（），導致雙重釋放。此外，release_mtd_partition（） 命中 WARN_ON（！list_empty（&mtd->part.node）），因為當從 add_mtd_device（） 錯誤路徑觸發發行回呼時，分割區節點仍連結在父項的分割區清單中。透過在錯誤路徑中的 put_device（） 之前覆寫 dev->type 和 dev->release 來修正此問題，以便 device_release（） 叫用 no-op 函式，而不是 mtd_release（）。對於 mtd_nvmem_add（） 失敗的情況，device_unregister（） 被替換為 device_del（），以將裝置移除與最終的 kobject 引用刪除分開，從而允許在呼叫 put_device（） 之前覆蓋生效。呼叫端的錯誤路徑 （list_del + free_partition） 仍然是 add_mtd_device（） 失敗時mtd_info存留期的唯一擁有者，這是預期的合約。一般分割區拆卸路徑不受影響：del_mtd_device（） 經過 kref_put（） -> mtd_device_release（） -> device_unregister（），且 dev->type 仍設定為 &mtd_devtype，因此 mtd_release（） -> release_mtd_partition（） 在常規移除情況下繼續正常運作。（CVE-2026-68416）

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

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

  - ALSA： timer：不要重新輸入仍在執行的執行個體回呼 使用者空間驅動計時器 （utimer） TRIGGER ioctl 直接呼叫 snd_timer_interrupt（），無需序列化，因此觸發相同 utimer 的兩個執行緒可以在一個snd_timer上同時執行 snd_timer_interrupt（）。snd_timer_process_callbacks（） 在每個實例回呼周圍刪除計時器>鎖定，並使用單個 SNDRV_TIMER_IFLG_CALLBACK 位標記正在進行的回呼;snd_timer_close_locked（） 會等待該位元排空進行中的回呼，然後再釋放執行個體。位元不能代表兩個並發回呼：當第二個中斷將回呼仍在執行的實例重新排入佇列時，兩者同時執行，第一個完成的會清除位元，然後關閉路徑耗盡釋放實例 （及其callback_data），而另一個回呼仍處於活動狀態 - 任何能夠開啟 /dev/snd/timer 的使用者都可以存取釋放後使用， 透過使用者計時器執行個體和繫結至 UTIMER 的排序器佇列計時器。snd_timer_interrupt（） 在刪除計時器>鎖定之前設定IFLG_CALLBACK，因此並發中斷已經在鎖定下觀察到它。當實例 （及其從屬） 回呼正在進行時，跳過將執行個體 （及其從屬） 重新排入 ack/sack 清單;累積的 ptick 會在下一個 tick 傳遞，因此不會遺失任何事件。（CVE-2026-68200）

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

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

  - hwmon：（nzxt-kraken3） 呼叫 hid_hw_stop 之前停止裝置 IO 呼叫 hid_hw_stop（） 不會停止裝置 IO。這會導致 hid_input_report（） 與驅動程式探查函式內執行 hid_device_io_start（） 之後的點之間出現爭用情形。如果探查作業在起始 io 啟動後失敗，此爭用情形會導致 UAF 弱點。在呼叫 hid_hw_stop（） 之前呼叫 hid_device_io_stop（） 來解決問題。（CVE-2026-68358）

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

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

  - debugobjects：針對並行 OOM 的插入爭用停用 syzbot 報告了一個令人費解的 splat：警告：
    kernel/time/hrtimer.c：443 at stub_timer+0xa/0x20 stub_timer（） 作為計時器回呼函式安裝在 hrtimer_fixup_assert_init（） 中，當 debug_object_assert_init（） 找不到影子物件時，會叫用該函式。
    在此情況下，偵錯物件會在叫用修正之前發出有關它的警告。雖然提供的主控台記錄缺少此警告，而是在 splat 前幾秒鐘顯示以下內容： ODEBUG：記憶體不足。ODEBUG 已停用 因此，在 debug_object_assert_init（） 中查詢物件，但由於併發記憶體不足情況，導致查詢失敗，該情況停用了除錯物件並釋放了影子物件：
    debug_object_assert_init（） if （！debug_objects_enabled） return;obj = alloc（）;if （！obj） { // 記憶體不足 debug_objects_enabled = false; free_objects（）; obj = lookup_or_alloc（）; // 查詢失敗，因為對方 // 移除了物件，所以這會傳回 // 錯誤代碼，因為有問題的物件 // 不是靜態初始化的 if （！IS_ERR_OR_NULL（obj）） return; if （！obj） { debug_oom（）; return; } print（...） if （！debug_objects_enabled） return; fixup（...）會跳過除錯物件 splat，因為 debug_objects_enabled 為 false，但會無條件叫用 fixup 回呼，這會讓計時器失效。這只是 debug_object_assert_init（） 和 debug_object_activate（） 中的一個問題，因為兩者都必須處理靜態初始化的對象，因此必須正常地處理錯誤指標傳回情況。所有其他位置僅處理找到/未找到的情況，而 NULL 指標傳回是 OOM 的訊號。否則，它們會獲得有效的陰影物件。在這兩個位置叫用列印和修正函式之前，檢查偵錯物件是否仍已啟用，以填妥漏洞。（CVE-2026-68090）

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

ID	名稱	嚴重性
334639	Linux Distros 未修補弱點：CVE-2026-73078	high
334638	Linux Distros 未修補弱點：CVE-2026-73076	high
334637	Linux Distros 未修補弱點：CVE-2026-20901	medium
334636	Linux Distros 未修補弱點：CVE-2026-68228	high
334635	Linux Distros 未修補弱點：CVE-2026-73089	high
334601	Linux Distros 未修補弱點：CVE-2026-73146	high
334600	Linux Distros 未修補弱點：CVE-2026-73145	critical
334599	Linux Distros 未修補弱點：CVE-2026-68307	medium
334598	Linux Distros 未修補弱點：CVE-2026-68394	high
334597	Linux Distros 未修補弱點：CVE-2026-68346	high
334596	Linux Distros 未修補弱點：CVE-2026-68292	medium
334595	Linux Distros 未修補弱點：CVE-2026-73151	critical
334594	Linux Distros 未修補弱點：CVE-2026-68173	high
334593	Linux Distros 未修補弱點：CVE-2026-73147	critical
334592	Linux Distros 未修補弱點：CVE-2026-73144	high
334591	Linux Distros 未修補弱點：CVE-2026-68319	medium
334590	Linux Distros 未修補弱點：CVE-2026-68381	critical
334589	Linux Distros 未修補弱點：CVE-2026-73141	critical
334588	Linux Distros 未修補弱點：CVE-2026-73148	high
334587	Linux Distros 未修補弱點：CVE-2026-68168	medium
334586	Linux Distros 未修補弱點：CVE-2026-68290	high
334585	Linux Distros 未修補弱點：CVE-2026-68139	medium
334584	Linux Distros 未修補弱點：CVE-2026-73152	critical
334583	Linux Distros 未修補弱點：CVE-2026-68178	high
334582	Linux Distros 未修補弱點：CVE-2026-68318	high
334581	Linux Distros 未修補弱點：CVE-2026-68281	high
334579	Linux Distros 未修補弱點：CVE-2026-73143	high
334578	Linux Distros 未修補弱點：CVE-2026-73150	critical
334577	Linux Distros 未修補弱點：CVE-2026-68379	high
334576	Linux Distros 未修補弱點：CVE-2026-68390	high
334575	Linux Distros 未修補弱點：CVE-2026-14180	medium
334574	Linux Distros 未修補弱點：CVE-2026-68385	critical
334573	Linux Distros 未修補弱點：CVE-2026-73153	critical
334572	Linux Distros 未修補弱點：CVE-2026-19546	high
334571	Linux Distros 未修補弱點：CVE-2026-71193	critical
334570	Linux Distros 未修補弱點：CVE-2026-73149	critical
334569	Linux Distros 未修補弱點：CVE-2026-68392	high
334568	Linux Distros 未修補弱點：CVE-2026-68372	medium
334567	Linux Distros 未修補弱點：CVE-2026-68321	medium
334566	Linux Distros 未修補弱點：CVE-2026-68332	high
334565	Linux Distros 未修補弱點：CVE-2026-68317	medium
334564	Linux Distros 未修補弱點：CVE-2026-71194	medium
334563	Linux Distros 未修補弱點：CVE-2026-68296	medium
334562	Linux Distros 未修補弱點：CVE-2026-73142	high
334561	Linux Distros 未修補弱點：CVE-2026-73154	critical
334559	Linux Distros 未修補弱點：CVE-2026-68298	high
334558	Linux Distros 未修補弱點：CVE-2026-68416	high
334557	Linux Distros 未修補弱點：CVE-2026-68200	high
334556	Linux Distros 未修補弱點：CVE-2026-68358	high
334510	Linux Distros 未修補弱點：CVE-2026-68090	medium

偵測

Nessus 的 Misc. 系列

high

high

medium

high

high

high

critical

medium

high

high

medium

critical

high

critical

high

medium

critical

critical

high

medium

high

medium

critical

high

high

high

high

critical

high

high

medium

critical

critical

high

critical

critical

high

medium

medium

high

medium

medium

medium

high

critical

high

high

high

high

medium