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

  - LoongArch：BPF：重構尾部調用中的跳轉偏移計算舊的基於巨集的jmp_offset計算從過時的預先密碼步幅中得出跳躍距離，這可能會導致錯誤的分支偏移和額外 JIT 傳遞下的軟鎖定。透過直接計算絕對目標上的偏移來解決此問題：
    ctx->offset[insn + 1] - ctx->idx。若要避免在大小估計期間發生錯誤的 16 位元範圍檢查中止，請新增 ctx->image == NULL 保護以插入安全的虛擬位移。（CVE-2026-89906）

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

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

  - f2fs：修正以避免 f2fs_fsync_node_pages（） 中潛在的死迴圈： 爭用情形中存在潛在的死迴圈： 執行緒 A、執行緒 B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get（last_folio） - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - 對開>映射 = NULL - is_node_folio一律傳回 false - 不可部分完成 && ！marked 一律為true，則轉至重試 （CVE-2026-89833）

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

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

  - NFSD：使用 NFSD_NET_UP 寫入 /proc/fs/nfsd/unlock_filesystem，或傳送 NFSD_CMD_UNLOCK_FILESYSTEM 或 NFSD_CMD_UNLOCK_EXPORT netlink 命令，會遍歷 NFSv4 用戶端雜湊表以撤銷開啟狀態並取消非同步 COPY 作業。所有三個處理常式都會在 nn->nfsd_serv 上行走，但透過 portlist 或 netlink listener_set 新增的接聽程式會在任何 nfsd 執行緒啟動之前設定 nn->nfsd_serv。nfsd_startup_net（） 尚未配置 nn->conf_id_hashtbl，因此步行者取消參照 NULL 表。具有CAP_SYS_ADMIN的本機管理員可以透過這種方式使核心當機，而無需啟動伺服器。nn->nfsd_serv 是在建立服務時設定的，這會在表格配置之前設定。NFSD_NET_UP改為將表格所在的視窗括起來：設定在 nfsd_startup_net（） 的結尾，並在釋放後在 nfsd_shutdown_net（） 中清除，兩者都在 nfsd_mutex 下。對NFSD_NET_UP上的三個解鎖路徑進行門控，可修正啟動時空取消參照，同時保留較早的關機後釋放後使用修正。（CVE-2026-90039）

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

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

  - dm：修正 resume-vs-remove 爭用 如果使用者同時發出 resume ioctl 和移除 ioctl，則裝置可能會在 __dm_destroy 中暫停後繼續。結果是，在不呼叫 postsuspend 方法的情況下，會銷毀資料表。Dm 目標預期只有在呼叫 postsuspend 方法方法之後才能移除它們。如果我們打破這種期望，可能會導致各種目標的不當行為。例如，在 dm-integrity 目標中，重新開機通知程式不會取消註冊，從而導致釋放後使用。如果裝置遭到破壞，則拒絕繼續，以修正此錯誤。（CVE-2026-89997）

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

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

  - f2fs：使用 s_umount 保護 critical_task_priority 更新 sysfs 儲存路徑已s_umount用於 GC 執行緒控制項目，並且也涵蓋了ckpt_thread_ioprio。critical_task_priority也會更新檢查點或 GC kthread 排程狀態，但該序列化不涵蓋它。它可以與停止這些執行緒的重新掛載或拆卸路徑爭用。也使用 s_umount 保護critical_task_priority sysfs 寫入。（CVE-2026-89831）

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

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

  - f2fs：修正資料區塊分配失敗時的有效區塊計數洩漏 在 __allocate_data_block（） 中，當配置新的資料區塊 （dn->data_blkaddr == NULL_ADDR） 時，首先呼叫 inc_valid_block_count（） 以遞增total_valid_block_count和i_blocks。如果後續的 f2fs_allocate_data_block（） 失敗，則函數會直接傳回錯誤，而不會回滾已經遞增的區塊計數，從而造成永久洩漏。在傳回錯誤之前呼叫 dec_valid_block_count（） 復原增量來修正此問題。條件 old_blkaddr == NULL_ADDR 精確識別呼叫 inc_valid_block_count（） 的情況。（CVE-2026-89830）

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

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

  - drm/amd/display：驗證私人顏色道具的平面去伽瑪 LUT 大小 與由 amdgpu_dm_verify_lut_sizes（） 保護的 CRTC 去伽瑪路徑不同，每個平面的去伽瑪 LUT 大小在使用前從未經過驗證。__set_dm_plane_degamma（） 將使用者提供的大小直接傳遞到 __is_lut_linear（） 中，對於非線性 LUT，則傳遞到 __set_input_tf（） -> __drm_lut_to_dc_gamma（），後者始終反覆運算MAX_COLOR_LUT_ENTRIES條目，而不管實際的 LUT 大小為何。因此，格式錯誤的AMD_PLANE_DEGAMMA_LUT blob （例如單一項目） 可能會觸發 __is_lut_linear（） 中的除以零或越界讀取
    __drm_lut_to_dc_gamma（）。拒絕任何大小與 MAX_COLOR_LUT_ENTRIES 不相符的平面去伽瑪 LUT，鏡像程式碼在下面幾行已經宣告的不變量（並且 CRTC 路徑強制執行）。AMD_PLANE_DEGAMMA_LUT 屬性只會在已定義 AMD_PRIVATE_COLOR 的組建上公開。（CVE-2026-89819）

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

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

  - 惡意建構的 IMAP 行可能會導致越界緩衝區讀取。此漏洞已在 Thunderbird 156、Thunderbird 140.16和 Thunderbird 153.3中修復。（CVE-2026-92239）

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

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

  - mm/damon/core：處理 apply_min_nr_regions（） 中的區域分割失敗 damon_apply_min_nr_regions（） 重複分割每個區域，直到其大小變得足夠小，以滿足使用者定義的區域數量下限。迴圈假設分割作業 （damon_split_region_at（）） 一律會成功並建立新區域。但是，例如，對於記憶體配置失敗，操作可能會無訊息地失敗。
    如果發生這類失敗，且區域是最後一個區域，則連結清單型下一個區域擷取會傳回無效指標。因此，可能會發生無效的記憶體解除參照和損毀。即使處理了極端情況，它也會透過嘗試其他目標的分割區域來對配置器施加壓力。藉由中斷任何區域分割失敗的所有迴圈來修正此問題。這表示可能會有min_nr_regions違規。這種情況很少發生，因為分配可以說太小而不能失敗。
    即使發生了，也只是暫時的。damon_apply_min_nr_regions（） 會在彙總間隔後再次呼叫。該問題對用戶的影響應該很小，因為分配可以說太小而不能失敗。但是，理論上它仍然可能發生，而且後果非常糟糕。這個問題是由 Sashiko 發現的 [1]。（CVE-2026-90004）

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

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

  - batman-adv： dat：避免 IP 擷取中未對齊的錯誤 與 SKB 中 ARP 封包的對齊方式無關，batadv_arp_ip_src 或 batadv_arp_ip_dst 將具有未對齊存取 （在沒有原生未對齊讀取支援的硬體上）。使用 get_unaligned（） 在所有架構上正確處理此問題。
    (CVE-2026-89949)

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

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

  - Debian Linux - network-manager-fortisslvpn - 無 Ubuntu Linux - [憑證換行插入允許本機根程式碼執行] （CVE-2026-91839）

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

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

  - net： skbuff：請勿skb_tx_error skb_zerocopy（） skb_zerocopy（） 中的來源 skb 將片段從 @from 複製到 @to。在 skb_orphan_frags（） 失敗時，它會呼叫 skb_tx_error（@from），這是複製協助程式不擁有的來源 skb 上的破壞性操作。這樣就完成了 @from 的零副本 uarg 並清除SKBFL_ALL_ZEROCOPY，包括SKBFL_SHARED_FRAG頁面擁有權標記。兩個呼叫端都已在自己的丟棄路徑上報告失敗。nfnetlink_queue 在 nla_put_failure 處執行此操作，而 Open vSwitch 在 ovs_dp_process_packet（） 的 flow-miss drop arm 中執行此操作，因此將其丟棄到此處不會丟失任何內容。在 Open vSwitch 的OVS_ACTION_ATTR_USERSPACE路徑上，skb 不會因以下錯誤而釋放：do_execute_actions（） 會忽略 output_userspace（） 的傳回值，除非上調是最後一個動作，否則會透過流程的其餘動作繼續轉送相同的 skb。當該 skb 仍在飛行時，uarg 已完成，告訴生產者其緩衝區是空閒的，並且SKBFL_SHARED_FRAG在堆疊其餘部分仍在處理的 skb 上清除。該標誌使 esp_input（） 呼叫 skb_cow_data（） 而不是就地解密，因此稍後的本地 ESP 傳遞可以解密 skb 不私有的片段。將錯誤報告留給呼叫者。（CVE-2026-90049）

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

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

  - KVM：s390：匯入觀察點資料時採取 srcu __import_wp_info（） 會使用 read_guest_abs（） 備份觀察點的原始客體記憶體內容，即 kvm_read_guest（），因此透過 __kvm_memslots（） 解析記憶體插槽。這需要保留 kvm->srcu（或 kvm->slots_lock），否則一旦 SRCU 寬限期過去，並發 memslot 更新可能會釋放我們下面的 memslots 陣列。由於這不是快速路徑，因此遵循鎖定排序（首先是互斥，然後是 srcu）拿起大錘子並按住 srcu 以進行完整匯入。（CVE-2026-89922）

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

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

  - mm/damon/core：避免無限 kdamond_merge_regions（） 內部迴圈 修補程式系列 mm/damon：無限迴圈、NULL 取消參照和爭用的緊急修正，v1.1。Sashiko 在 DAMON 中發現了一些可能導致無限迴圈、空取消參照和監控結果降級的問題。前兩個聽起來很可怕，但無限循環只會在不合理的用戶設置下發生。空取消參照僅在單元測試中。
    監控結果的退化是微不足道的，因為它只是盡最大努力，而且這些只會發生在不太可能的比賽中。儘管如此，如果可能的話，這些都是最好修復的錯誤。修正這些問題。此修補程式 （共 6 個）：由於類似事件的線上參數更新，DAMON 區域的數量可能高於使用者設定的上限。kdamond_merge_regions（） 會重複合併區域，直到數量達到限制為止，同時將合併臨界值加倍，達到理論上的最大臨界值。它只能嘗試到理論上的最大閾值，因為即使是積極的合併也可能因減少低於使用者定義上限的區域數量而失敗。例如，可能有許多無法合併的使用者定義非連續區域。以臨界值為基礎的迴圈中斷條件是透過將下一次合併嘗試的臨界值與理論最大臨界值進行比較來評估。如果max_thres大於 UINT_MAX / 2，則將臨界值加倍可能會使其溢位，並繞過迴圈中斷條件。在這種情況下，如果無法像上面解釋的那樣將區域數量減少到上限以下，則循環將無限運行。
    在將臨界值加倍之前，先執行中斷條件檢查，以防止這種情況發生。此外，請防止臨界值超過最大臨界值，因為臨界值可能會溢位並套用錯誤的合併臨界值。此問題在現實世界中不太可能發生，因為與取樣間隔相比，max_thres高於 UINT_MAX / 2 需要不切實際的大聚合間隔。此外，它需要設定大量不連續的區域。儘管如此，後果很糟糕，修復方法也很簡單。這個問題是由 Sashiko 發現的 [1]。（CVE-2026-89796）

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

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

  - drm/amdkfd：防止 CRIU 佇列還原中出現 NULL restore_mqd 當 CRIU 還原進行時 （qd ！= NULL），create_queue_cpsch（） 和 create_queue_nocpsch（） 都會無條件呼叫 mqd_mgr->restore_mqd（），且沒有 NULL 保護。在未針對指定佇列類型實作 restore_mqd 的任何系統上，持有CAP_CHECKPOINT_RESTORE的使用者可以觸發核心 NULL 指標解除參照，並透過發出具有特製佇列還原物件的KFD_IOC_CRIU_OP_RESTORE來使機器發生錯誤。請注意，checkpoint_mqd同樣未在 上 GFX12實作，因此任何合法的 CRIU 映像檔都無法到達此路徑，只有手工製作的還原承載。在解析mqd_mgr之後立即為restore_mqd新增空保護，透過現有的錯誤標籤展開，如果未實作回呼，則傳回 -EOPNOTSUPP。這反映了 checkpoint_mqd（） 中現有的checkpoint_mqd保護。（CVE-2026-89807）

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

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

  - mm/migrate_device：避免複合對開本的越界寫入 migrate_device_range（） 和 migrate_device_pfns（） 清除複合對開本之後的項目，以便 PFN 陣列保留其頁面精細表示法。如果複合對開本超出呼叫端提供的範圍結尾，迴圈會清除所有後續對開本項目，而不會將它們限制為 npages 大小陣列中剩餘的插槽數，從而造成越界寫入。如果複合對開本的頁面精細表示法不完全適合其餘的 PFN 陣列，請勿繼續使用複合對開本。如果發生這種情況，請捨棄為對開本取得的任何參照和鎖定，清除其餘項目，然後停止收集。使用 HMM 在 KASAN x86 QEMU 核心上觀察到migrate_anon_huge_zero自我測試。將匿名大頁面移轉至裝置記憶體後關閉 /dev/hmm_dmirror0 練習：dmirror_fops_release（） -> dmirror_device_evict_chunk（） -> migrate_device_range（） （CVE-2026-89967）

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

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

  - s390/vfio-ap：修正 vfio_ap_mdev_set_kvm（） 中錯誤時過時的 pqap_hook 指標 在 vfio_ap_mdev_set_kvm（） 中，kvm->arch.crypto.pqap_hook 設定為 &matrix_mdev->pqap_hook，然後再取得更新鎖定並檢查 mdev 清單是否有衝突的指派。如果另一個 mdev 已附加至相同的 KVM 執行個體，則函式會傳回 -EPERM，而不還原勾點指標，讓 kvm->arch.crypto.pqap_hook 指向失敗的matrix_mdev，而不是合法擁有 KVM 的 mdev。由於此錯誤路徑上從未設定 matrix_mdev->kvm，因此稍後關閉 matrix_mdev 時，vfio_ap_mdev_unset_kvm（） 將不會清理勾點。如果隨後釋放matrix_mdev，客體執行的任何 PQAP 指令都會透過pqap_hook_rwsem取消參照過時指標，從而導致釋放後使用。由於 kvm->arch.crypto.pqap_hook 僅在 vfio_ap_mdev_set_kvm（） 函式中設定，並在 vfio_ap_mdev_unset_kvm（） 函式中清除，因此只需檢查「kvm->arch.crypto.pqap_hook ！= NULL」即可確定它是否屬於另一個 mdev。這樣可以減輕反覆運算 matrix_dev->mdev_list 清單以查看 kvm 物件是否指派給另一個 mdev 的需要。這是在 v3 中引入的，以減輕在反覆執行清單時進行mdevs_lock的需求;不過，這並不能防止潛在的爭用情形。pqap_hook_rwsem（寫入）現在在 get_update_locks_for_kvm（） 內執行，而 （） 已更新以取得 kvm->lock 和 mdevs_lock 之間的pqap_hook_rwsem（寫入）。此順序與 PQAP 攔截路徑一致，該路徑在讀取模式下獲取 pqap_hook_rwsem，而 srcu 保存在 vcpu->mutex 下，從而建立相依性：kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem（讀取）。
    pqap_hook_rwsem現在在 release_update_locks_for_kvm（） 中釋放，而 （） 已更新為釋放 mdevs_lock 和 kvm->lock 之間的 pqap_hook_rwsem（write）。此外，vfio_ap_mdev_unset_kvm（） 中的 kvm_put_kvm（） 會移動到 release_update_locks_for_kvm（） 之後。之前，它是在保留 kvm->lock 時呼叫的;如果它是最後一個參照，kvm_destroy_vm（） 將在 kvm->lock 下運行，這將鎖死。（CVE-2026-89960）

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

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

  - 攻擊者可傳送特製的 DNS-over-HTTPS 要求，其中包含密碼編譯上無效的 SIG（0） 記錄，然後過早關閉傳輸連線，藉此導致 'named' 中止。此問題影響 BIND 9 版本 9.20.09.20.27（至 、 9.21.09.21.25和 9.20.9-S1 至 9.20.27-S1）。
    (CVE-2026-77692)

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

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

  - scsi：qla2xxx：傳送 NVMe LS 拒絕時保持 qpair 鎖定 qla_nvme_ls_reject_iocb（） 會從 __qla2x00_alloc_iocbs（） （假設保留 hardware_lock） 和 qla2x00_start_iocbs（） （進階響鈴並響鈴請求門鈴） 來分配請求響鈴並推進請求響鈴，但本身不進行鎖定。它的兩個呼叫端在沒有持有生產者鎖定的情況下叫用它：- qla_nvme_xmt_ls_rsp（），NVMe-FC .xmt_ls_rsp傳輸回呼，在其錯誤路徑上，以及 - qla2xxx_process_purls_pkt（），從 purex 工作/DPC 上下文執行。兩者都使用 ha->base_qpair，其qp_lock_ptr為 hardware_lock，因此它們可以在基本環上與正常 I/O 提交同時運行，並破壞環生產者狀態，從而導致命令重複或刪除。第三個調用方 qla2xxx_process_purls_iocb（） 在 qla24xx_process_response_queue（） 內運行，qpair 鎖已經保持並且是安全的;這也是為什麼無法在協助程式本身內部進行鎖定的原因 （它會在回應路徑上遞迴重新取得hardware_lock）。qp_lock_ptr兩個未鎖定的來電者周圍，並將協助者記錄為來電者鎖定。兩者都在進程內容中執行，因此會使用 spin_lock_irqsave（），鎖定區域中的任何內容都不會休眠。
    (CVE-2026-89857)

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

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

  - 暫存：rtl8723bs：修正 rtw_restruct_wmm_ie（） 中的 OOB 讀取 rtw_restruct_wmm_ie（） 掃描 in_ie WMM IE 的 WMM IE：while （i < in_len） { ...if （i + 5， < in_len &&; in_ie[i] == 0xDD &&; ...）{ ...休息;} i += （in_ie[i + 1] + 2）;/* 到下一個 IE 元素 */ } 當 i + 5 < in_len比對檢查失敗時，只是因為 i 距離緩衝區結尾的 5 個位元組以內 （即在 in_ie 尾部附近沒有找到 WMM IE），則執行會下降到 i += （in_ie[i + 1] + 2），讀取為 in_ie[i + 1]。如果此時 i == in_len - 1，這是從關聯/掃描資料建置的受攻擊者影響 IE 緩衝區的 1 位元組越界讀取。提交 a75281626fc8f （暫存：rtl8723bs：修正 rtw_restruct_wmm_ie 中潛在的越界讀取） 將 i + 5 < in_len防護新增至匹配條件本身，但未在貫穿前進之前新增對等防護，因此相同類別的 OOB 讀取仍可透過不相符的路徑連線。在前進至下一個 IE 之前，先新增明確的界限檢查。（CVE-2026-90016）

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

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

  - mtd： mtdoops：移除支援 MTD 時釋放的頁面點陣圖 mtdoops_notify_add（） 會在註冊已設定的 MTD 裝置時配置 oops_page_used。mtdoops_notify_remove（） 會從該裝置分離，但會保留點陣圖的配置狀態。如果稍後再次註冊相同的 MTD 裝置，則新增路徑會配置新的點陣圖並覆寫舊指標，從而在每個移除/新增週期中洩漏一個 vmalloc 配置。只有在 mtdoops 保持載入狀態時，支援 MTD 裝置可以消失並再次註冊時，這才會顯示，因此通常的靜態 MTD 案例不會公開它。取消註冊傾印程式並排清擱置中的背景工作角色之後，釋放點陣圖，然後在稍後的附加可以配置新的狀態之前清除指標和頁面計數。清除指標也會防止模組結束路徑在移除事件之後第二次釋放相同的點陣圖。（CVE-2026-89953）

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

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

  - iio： chemical： atlas-sensor：使用 iio_trigger_poll_nested（） 修復 刪除 UAF atlas 驅動程式使用 devm_request_threaded_irq（） 要求其硬體資料就緒的 IRQ;其執行緒處理常式會將呼叫 iio_trigger_poll（data->trig） 的irq_work atlas_work_handler（） 排入佇列。IRQ 是 devm 管理的，因此 free_irq（） 會在 atlas_remove（） 傳回後從 devres 展開，而不會排清該irq_work。一旦啟用緩衝區，轉換完成的 IRQ 就會不斷觸發並排隊;因此，擱置中的irq_work可以在解除釋放 atlas_data/indio_dev 和觸發程序之後執行，當 atlas_work_handler（） 透過 container_of（） 衍生 atlas_data 指標並取消參照 data->trig （釋放後使用） 時。直接從執行緒處理常式呼叫 iio_trigger_poll_nested（），而不是在irq_work中反彈。
    然後free_irq（） 清空執行緒處理常式，關閉視窗;其他具有執行緒資料就緒 IRQ 的 IIO 驅動程式也會執行相同的動作 （例如 bmi270）。此問題是由內部靜態分析工具發現的。
    (CVE-2026-89938)

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

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

  - iio：chemical：sgp30：處理 IAQ 執行緒建立失敗 kthread_run（） 可能會失敗並傳回錯誤指標，但 sgp_probe（） 會儲存它並傳回成功，因此裝置註冊時沒有其 IAQ 執行緒，而 sgp_remove（） 稍後會將錯誤指標傳遞給 kthread_stop（）。請改為傳回探查的錯誤。
    (CVE-2026-89937)

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

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

  - dm：修正載入和卸載表時的爭用 如果使用者空間呼叫兩個並發表載入 ioctl，其中一個成功，另一個失敗，則存在爭用情形，因為dm_setup_md_queue在沒有任何鎖定的情況下遍歷 &md->table_devices。如果遍歷與 -> free_devices -> dm_put_table_device dm_table_destroy爭用，則可以存取無效記憶體。透過將鎖定延伸至清單遍歷來修正此爭用。（CVE-2026-89998）

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

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

  - mm/hugetlb_cma：修正 hugetlb_cma_alloc_frozen_folio alloc_buddy_hugetlb_folio_with_mpol（） 中的 NULL 節點遮罩解除參照，可以將 NULL 節點遮罩傳遞給 alloc_fresh_hugetlb_folio（） 作為後援，以便從所有節點進行分配。如果順序很大，alloc_fresh_hugetlb_folio（） 會透過 alloc_gigantic_frozen_folio（） 將 NULL 節點遮罩向下傳播到 hugetlb_cma_alloc_frozen_folio（）。此外，hugetlb_cma_alloc_frozen_folio（） 先前嘗試在 hugetlb_cma[nid] 上進行分配，但未驗證呼叫端的節點遮罩中是否包含 nid。新增 node_isset（nid， *nodemask） 檢查可確保初始偏好節點配置遵循記憶體原則 / 節點遮罩。但是，hugetlb_cma_alloc_frozen_folio（） 會解除參照 node_isset（nid， *nodemask） 和 for_each_node_mask（node， *nodemask） 中的節點遮罩，當 nodemask 為 NULL 時，會導致 NULL 指標解除參照核心錯誤。透過檢查 hugetlb_cma_alloc_frozen_folio（） 中的 nodemask 是否為 NULL 並將其預設為 cpuset_current_mems_allowed 來解決此問題。將配置嘗試包含在 cpuset seqcount 重試迴圈內，以便如果 cpuset 在配置期間同時變更，則會使用更新的節點遮罩重試嘗試。這可確保初始節點檢查和後援迴圈安全地接受任務的 cpuset，而不會違反 cpuset 條件約束或造成 NULL 指標解除參照或非預期的配置失敗。從使用者空間的角度來看，此錯誤允許無權限的使用者透過在僅在 NUMA 節點子集上配置 CMA 的系統上請求帶有MPOL_PREFERRED_MANY的巨大頁面分配來使核心崩潰（觸發錯誤）。這可以透過啟動具有兩個 NUMA 節點的 VM、將 CMA 限制為節點 1 （例如，hugetlb_cma=1：1G default_hugepagesz=1G hugepagesz=1G hugepages=0），以及執行配置 1GB 大頁面區域而不保留的程式、使用 mbind（） 和 MPOL_PREFERRED_MANY 限制分配到節點 0，並觸發頁面錯誤來重現： void *ptr = mmap（NULL， 1UL << 30， PROT_READ |PROT_WRITE， MAP_PRIVATE |MAP_ANONYMOUS |MAP_HUGETLB |MAP_HUGE_1GB |MAP_NORESERVE， -1， 0）;無符號長節點遮罩 = 1;/* 節點 0 */ mbind（ptr， 1UL << 30， MPOL_PREFERRED_MANY， &nodemask， sizeof（nodemask） * 8， 0）;memset（ptr， 0， 1UL << 30）;/* 觸發錯誤 */ 這會導致 NULL 指標解除參照： 錯誤：核心 NULL 指標解除參照，位址：
    000000000000000000 #PF：核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 哎呀：哎呀：0000 [#1] SMP NOPTI RIP：0010：hugetlb_cma_alloc_frozen_folio+0x75/0x120 呼叫追蹤： <TASK> only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650 （CVE-2026-89966）

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

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

  - USB：影像：mdc800：將 kmalloc（） 更改為 kzalloc（） 將 usb_mdc800_init（） 中的 kmalloc（） 調用更改為 irq_urb_buffer，將 download_urb_buffer 更改為 kzalloc（），避免在 mdc800_usb_irq（） 和 mdc800_usb_download_notify（）CVE-2026-90034 中收到較短消息時潛在的堆疊洩漏

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

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

  - batman-adv：修正合併片段上過時的接收裝置 片段重組會重複使用編號最高的緩衝片段中的 skb 作為合併的封包。當在鏈結完成之前刪除的硬介面上接收該片段時，合併的 skb 可以使用過時的 skb->dev 和 skb_iif 重新進入接收路徑。batadv_batman_skb_recv（） 再次通過正常接收處理常式傳遞此類合併的封包。DAT 和橋接環避免都從 skb->dev 派生 ARP 標頭長度，因此它們可以在封包到達本機網狀介面之前取消參照釋放的net_device。在執行封包處理常式之前，先重新整理目前接收裝置的接收裝置中繼資料。這可使內部重新插入的合併片段在硬式介面拆卸後與正常接收路徑保持一致。
    (CVE-2026-89951)

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

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

  - LoongArch： KVM：在將 MSI 資料路由到 EIOINTC 之前先對其進行驗證 pch_msi_set_irq（） 將 e->msi.data 直接傳遞到 eiointc_set_irq（） 中作為 irq 編號。MSI 資料來自使用者空間，可以透過 KVM_SET_GSI_ROUTING 集的 KVM_IRQ_ROUTING_MSI 項目 （由 irqfd 和 KVM_IRQ_LINE 使用），或直接透過 KVM_SIGNAL_MSI，並且永遠不會根據EIOINTC_IRQS進行檢查。eiointc_set_irq（） 會使用
    __set_bit（）/__clear_bit（） 在 256 位元 isr 點陣圖上，eiointc_update_irq（） 然後索引 sw_coremap[] 並使用它對 per-cpu coreisr/sw_coreisr 點陣圖進行索引。因此，資料值 >= 256 會讀取和寫入超出這些陣列末端的記憶體，也就是說，任何持有 VM fd 的進程都可能損毀超出loongarch_eiointc配置範圍的核心記憶體。拒絕不符合 EIOINTC irq 空間的 MSI 資料。DMSINTC 路徑不受影響，因為它會從位址解碼向量並遮罩它。（CVE-2026-89907）

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

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

  - iio： 緩衝區：使 IIO DMA 圍欄版本 RCU 安全 「dma_fence」文件指出，如果提供自訂版本實作，則必須以 RCU 安全的方式釋放「dma_fence」物件。目前的「iio_dma_fence」實作使用 'kfree（）'，這可能會導致釋放後使用。移除自訂「發布」實作。這使得 DMA 柵欄核心回歸到“dma_fence_free（）”，它調用柵欄上的“kfree_rcu（）”。這要求柵欄是「struct iio_dma_fence」的第一個成員。
    針對延伸的 DMA 柵欄結構使用預設釋放方法是常見的模式。（CVE-2026-89941）

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

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

  - media：go7007：延遲 ALSA v4l2 put，直到卡片發行 go7007_snd_init（） 已經為 ALSA 端取得v4l2_device參照，但 go7007_snd_remove（） 在呼叫 snd_card_free_when_closed（） 後立即刪除它。當使用者空間進程仍開啟擷取 PCM 時，這還為時過早。
    ALSA 卡及其 PCM 回呼在最後一個檔案關閉之前保持活動狀態，因此釋放路徑仍然可以透過 pcm->private_data 到達結構 go7007，並在 V4L2 釋放路徑釋放物件後呼叫 go7007_snd_hw_free（）。將相符的 v4l2_device_put（） 移至 ALSA 卡片private_free回呼，讓現有的 ALSA 參照涵蓋整個延遲卡片存留期。（CVE-2026-89890）

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

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

  - KVM：s390：修正客體偵錯處理中的記憶體洩漏bp_data僅因 kfree（bp_data） 的錯誤情況而釋放。每一次成功的KVM_SET_GUEST_DEBUG都會洩露bp_data。（CVE-2026-89925）

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

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

  - media： platform： mtk-mdp3：修正失敗 SCP 查詢的 NULL 解除參照 在查詢 SCP 之後新增缺少的健全性檢查，以避免在尚未綁定 NULL 指標的情況下取消參照 NULL 指標。
    (CVE-2026-89884)

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

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

  - media：cedrus：修正 cedrus_init_ctrls（） 中的記憶體洩漏 在 cedrus_init_ctrls（） 中，在為 ctx->ctrls 配置記憶體之前，會初始化 V4L2 控制處理常式。如果此配置失敗，函式會傳回
    -ENOMEM 而不釋放先前配置的處理常式資源，從而導致記憶體洩漏。透過在 ctx->ctrls 分配失敗路徑上呼叫 v4l2_ctrl_handler_free（） 來修正此問題。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1.1 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們沒有可測試的 Allwinner SoC 或帶有 Cedrus VPU 的主板，因此無法執行運行時測試。（CVE-2026-89896）

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

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

  - media：v4l2-async：避免在將 asc->asc_subdev_entry 新增至 sd->asc_list 之前，避免在連結錯誤 v4l2_async_match_notify（） 建立輔助媒體連結時刪除未連結的 ASC 項目。如果輔助連結建立失敗，則函式會跳至err_call_unbind，而asc_subdev_entry尚未連結。非同步連線是零配置的，因此清單項目在此路徑上仍具有 NULL next 和 prev 指標。
    因此，在其上調用 list_del（） 可以取消參照 NULL，而不是傳回原始連結建立錯誤。不要從err_call_unbind中刪除asc_subdev_entry。此路徑上沒有要復原的清單插入;綁定的回呼和子裝置註冊是需要回滾的操作。
    (CVE-2026-89874)

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

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

  - scsi：qla2xxx：修正驗證快閃記憶體映像錯誤路徑時的 BSG 工作洩漏 qla28xx_validate_flash_image（） 無條件傳回 QLA_SUCCESS （0），告知 FC BSG 傳輸 （fc_bsg_host_dispatch（）） 驅動程式擁有並將完成要求。但是 bsg_job_done（） 受到 if （！rval） 的保護，因此在錯誤路徑 （rval == -EINVAL） 上，驅動程式和傳輸都不會完成工作。請求懸空直到逾時，從而洩露區塊層資源。提交 c2c68225b145 （scsi： qla2xxx： 修正 bsg_done（） 導致雙重釋放） 將 if （！rval） 防護新增至一批 BSG 處理常式。這對於也傳回錯誤碼的處理常式來說是正確的 （傳輸然後透過fail_host_msg完成一次作業） ，但此函式會無條件傳回QLA_SUCCESS，因此防護會將正確的單一完成變成洩漏。
    一律調用 bsg_job_done（）：bsg_reply->result DID_OK，並在 vendor_rsp[0] 中報告錯誤，並且由於函數傳回 0，因此傳輸將不會第二次完成工作。（CVE-2026-89862）

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

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

  - KVM：arm64：vgic-its：不要在 ITT 上取消參照 NULL 集合 儲存 MAPC with V=0 會捨棄 ite->collection ，但會將 ITE 留在裝置的 ITT 清單上，並且 vgic_its_save_ite（） 無條件地取消參照它。因此，當 VMM 發出 KVM_DEV_ARM_ITS_SAVE_TABLES 以移轉主機時，發出 MAPD、MAPTI 和 MAPC （V=0） 的客體會失敗主機。根據架構，該順序是不可預測的，但 KVM 已經處理了 translate、MOVI 和 DISCARD 路徑中的結果狀態。儲存一個歸零的項目，該項目 vgic_its_restore_ite（） 讀回無效。改為略過 ITE 會讓 ITT 插槽保留客體記憶體中的任何內容，而還原會拒絕命名還原集合表沒有的集合的項目。（CVE-2026-89912）

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

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

  - nvmet-tcp：修正收到過長 PDU 時的越界寫入 nvmet_tcp_try_recv_pdu（） 將 PDU 標頭讀取到固定的 128 位元組 queue->pdu 並集，然後計算剩餘的負載長度為 queue->left = hdr->hlen - queue->offset + hdgst;並將更多位元組讀取到 &queue->pdu + queue->offset 中，而無需將結果限制為 sizeof（queue->pdu）。結構nvme_tcp_icreq_pdu本身有 128 位元組，正好是聯集的大小。一旦交涉了標頭摘要 （hdgst = 4），第二個 ICReq 就會通過 hlen == nvmet_tcp_pdu_size（） 檢查，但會產生 queue->left = 128 - 8 + 4 = 124，因此位元組 8..132 會寫入 128 位元組緩衝區 -- 通過 queue->hdr_digest 和 queue->data_digest 寫入其末尾 4 個位元組。這些位元組由攻擊者控制（ICReq 不攜帶摘要），重複的 ICReq 只會在溢位之後才會被拒絕。因此，未經驗證的遠端主機可能會損毀接收緩衝區附近的核心記憶體。拒絕任何宣告長度在第二個 recv 之前讀取超過 queue->pdu 結尾的任何 PDU。（CVE-2026-89969）

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

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

  - scsi：qla2xxx：修正在名為 kstrtoul（） 的 debugfs qla2x00_dfs_fce_write（） 中以 NULL 結果指標啟用 FCE 追蹤啟用剖析，因此成功的剖析會取消參照 NULL 和哎呀。更糟糕的是，int 傳回值 （成功時為 0，失敗時為負 errno） 被指派給未簽名的 long enable 旗標，反轉了預期的邏輯：當剖析失敗啟用 FCE 時，有效數字被視為停用。將值剖析為 enable，並將剖析錯誤傳播到使用者空間。（CVE-2026-89851）

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

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

  - 如果 BIND 剖析器已快取 SVCB/HTTPS AliasMode 記錄的樹狀結構，然後查詢該樹狀結構的根目錄，則剖析器將花費不成比例的 CPU 時間來建構回應。此問題會影響 BIND 9 版本 9.18.09.18.50（至 、 至 9.20.09.20.27、 9.21.09.21.25至 、 9.18.11-S1 至 9.18.50-S1 和 9.20.9-S1 至 9.20.27-S1）。（CVE-2026-81736）

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

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

  - media： ti： vpe： 釋放串流之前靜止溢位回復 當偵測到 FIFO 溢位時，VIP 溢位回復工作程式會從 hardirq 處理程式武裝起來，且清單完整路徑會透過 VPDMA 清單專用指標向上查閱串流。兩者都會不斷接觸資料流、連接埠和裝置狀態;復原工作程式也會重設剖析器和 VPDMA、重新填入描述元清單，並重新啟用每個清單的 IRQ。vip_stop_streaming（） 遮罩並清除每個清單的 IRQ，但它既不會同步 hardirq 處理常式，也不會停用 recovery_work。因此，已經將recovery_work排入佇列的溢位 IRQ，或當資料流被拆除時正在進行的清單完整 IRQ，在釋放其資源後仍然可以取消參照資料流：描述元清單在檔案釋放時由 vip_release_stream（） 釋放，而資料流本身在取消綁定/刪除時由 free_stream（） 釋放。在釋放任何資料流擁有的資源之前，透過共用的 vip_quiesce_stream（） 協助程式，在兩個拆卸點清空復原工作程式和 IRQ 處理常式。disable_work_sync（） 會取消擱置中的recovery_work、清空執行中的執行個體，並提高其停用深度，因此由爭用 IRQ 處理常式發出的後續 schedule_work（） 會在工作佇列排程器上遭到拒絕：disable_work_sync（） 生效後，無法將recovery_work重新排入佇列。在 disable_work_sync（） 傳回之前，背景工作者仍可重新啟用每個清單的 IRQ;然後，disable_irqs（） 會遮罩這些來源，而 synchronize_irq（） 會等候任何仍在取消參照串流狀態的進行中處理常式。在 vip_stop_streaming（） 中，協助程式會在剖析器停止之前執行，因為 disable_work_sync（） 耗盡的工作程式可能會在退出之前重新啟用剖析器，否則會撤銷停止。
    recovery_work 是在 IRQ 之前的 vip_start_streaming（） 中建立停用和啟用，在整個串流生命週期中將啟用與拆卸停用配對。此問題由內部靜態分析工具發現，並透過手動程式碼審查確認。（CVE-2026-89875）

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

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

  - USB：小工具：f_midi2：修正字串屬性中的釋放後使用 show path f_midi2_opts_str_show（） 在內部採用字串鎖定，但其調用方取消參照 opts->info。<field> 指標，在鎖定之外。這與 f_midi2_opts_str_store（） 爭用，當並發寫入屬性時，（） 會釋放 opts->lock 下的舊字串，顯示路徑可以讀取一個指標，該指標甚至在 str_show（） 內部的鎖定被採用之前就被釋放。更改 f_midi2_opts_str_show（） 以獲取指向字串欄位的指標，與 f_midi2_opts_str_store（） 中的現有模式相符，並且僅在保持鎖定後才取消參照它。相應地更新所有三個呼叫者（iface_name、區塊名稱和 EP 字串選項 巨集）。
    (CVE-2026-90022)

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

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

  - media： platform： mtk-mdp3：修正 SCP 裝置參照計數 mdp_probe（） 首先嘗試使用 scp_get（） 取得 SCP 控點。當失敗時，它會回復為使用 __get_pdev_by_id（） 查詢 SCP 平台設備，然後讀取其驅動程式資料。後援查詢會傳回具有參照的平台裝置，就像 scp_get（） 一樣。不過，後援路徑目前會在 platform_get_drvdata（） 之後立即刪除該參照。驅動程式稍後仍會從探查錯誤路徑和 mdp_video_device_release（） 無條件呼叫 scp_put（mdp->scp），這會再次刪除 SCP 裝置參照。在現有的 scp_put（） 呼叫之前保留後援參照，以便後援路徑遵循與 scp_get（） 路徑相同的擁有權規則。（CVE-2026-89885）

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

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

  - ublk：清除唯讀 ublk 字元裝置 mmap 上的VM_MAYWRITE mmap ublk_ch_mmap（） 會拒絕設定VM_WRITE的 mmap 要求，但絕不會清除產生的唯讀對應上的VM_MAYWRITE。這允許使用者空間常駐程式 mmap 每個佇列命令緩衝區PROT_READ，然後透過 mprotect（） 將其升級為 PROT_WRITE，因為VM_MAYWRITE從未清除過。命令緩衝區會保存核心撰寫 ABI 的結構ublksrv_io_desc項目;可寫入對應可讓無權限的常駐程式處理損毀的欄位，例如 addr、op_flags、nr_sectors 和 start_sector。與 drm/panthor 和 drm/vc4 VM_MAYWRITE修正以及 2026-08-13 ptp/vmclock 修正 （a5edadbae57e） 相同的錯誤類別。透過 mprotect（） PoC 驗證：在修正之前，PROT_READ 對應可以升級為 PROT_READ|PROT_WRITE和寫入命令緩衝區會損毀io_desc欄位 （在 KASAN 下確認）。修正之後，mprotect（） 會傳回 -EACCES。（CVE-2026-89793）

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

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

  - mtd： rawnand：驗證 ONFI 擴充參數頁面區段 nand_flash_detect_ext_param_page（） 會配置 ONFI 參數頁面所宣告的長度，然後將資料視為固定標頭，後面接著可變長度區段。它會讀取該標頭並移動到各個部分，而無需先證明固定頁面和每個當前部分是否適合分配。拒絕比固定標頭短的頁面、在遍歷區段時追蹤剩餘的變數區域，並要求 ECC 區段包含從結構onfi_ext_ecc_info讀取的每個欄位。使用裝置範圍的診斷來識別格式錯誤的 ONFI 區段。（CVE-2026-89952）

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

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

  - media： chips-media： wave5： 僅當 DEC_PIC 排入佇列時才延遲 job_finish（） 共用 VPU 的解碼器執行個體也會共用一個 v4l2_m2m 工作時段，當執行中的內容呼叫 v4l2_m2m_job_finish（） 時釋放。在清空時，一旦發送 EOS （sent_eos），device_run（） 就會延遲 job_finish（），並預期稍後的 finish_decode（） （來自 DEC_PIC 完成 IRQ） 釋放插槽。但 m2m 核心僅在作業排入佇列時檢查 job_ready（），而不是在分派時檢查。在 finish_decode（） 已將執行個體移至 STOP 並傳送 EOS 之後，排空時排入佇列的工作可以執行。然後，device_run（） 在 STOP 中執行，不發出 DEC_PIC，但仍跳過 job_finish（） - 因此沒有 IRQ，沒有 finish_decode（），並且共用插槽會洩漏，從而使每個執行個體停止。當多個 v4l2h264dec 實例並行時，GStreamer 會掛在 EOS。追蹤執行是否實際將DEC_PIC （cmd_issued） 排入佇列，然後才延遲 job_finish（）。否則立即完成工作 （CVE-2026-89867）

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

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

  - scsi：qla2xxx：當晶片關閉時，不要查詢韌體狀態 qla2x00_fw_state_show（） 會初始化 rval 以 QLA_FUNCTION_FAILED，並在晶片關閉或 EEH 忙碌時跳轉到 out： 標籤。out： 區塊然後重新發出 qla2x00_get_firmware_state（），因為 rval ！= QLA_SUCCESS，在 ISP 重設或 PCI 錯誤復原期間，擊敗 chip-down/EEH-busy 防護並發出信箱命令 （外部 optrom_mutex），這可能會懸置轉接卡。它也會將正常的鎖定信箱失敗變成第二次未同步的信箱嘗試。出局：後備僅將韌體狀態標記為未知。現在，郵箱最多在optrom_mutex內發出一次，並且僅在晶片啟動且非 EEH 忙碌時發出。（CVE-2026-89850）

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

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

  - bpf：修正pcpu_freelist推送中的無限迴圈，當只有一個 CPU 可能時，__pcpu_freelist_push（） 可以永遠迴圈，並且 NMI 重新輸入 pcpu_freelist_push（），而中斷的上下文保留該 CPU 的空閒清單鎖定。目前 CPU 快速路徑失敗後，後援迴圈會cpu_possible_mask走，同時略過目前的 CPU。當 CONFIG_SMP=n 時，或當 SMP 核心限制為一個可能的 CPU 且 nr_cpus=1 或 possible_cpus=1 時，沒有其他可能的 CPU 可供檢查。因此，迴圈不會嘗試鎖定取得，而且永遠無法取得進展。在 UP 系統上觀察到以下堆疊： NMI 上下文：pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF 程式] __perf_event_overflow perf_event_nmi_handler exc_nmi 中斷的上下文：__pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF 程式]
    __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock（） 會偵測相同 CPU 遞迴取得並傳回 -EDEADLK，但後續後援迴圈在具有一個可能 CPU 的系統上沒有候選磁頭。還原 rqspinlock 轉換之前存在的額外後援頭。保持當前 CPU 快速路徑，然後嘗試其他可能的 CPU，最後嘗試額外的磁頭。額外的磁頭可讓推送 （在不遺失預先配置元素的情況下失敗） 在中斷的內容保留唯一的每個 CPU 磁頭時取得進展。還要檢查彈出路徑中的額外磁頭，以便可以重複使用放置在那裡的節點。（CVE-2026-89991）

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

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

  - drm：修正部分 drm_dev_register（） 失敗與 ioctl 之間的爭用 如果註冊次要項目後 drm_dev_register（） 失敗 （例如，render minor registered、primary minor fails），使用者空間可能已經開啟第一個次要項目並進入 drm_dev_enter（） 關鍵區段。由於從未設定 unplugged 旗標，因此 ioctl 會繼續進行，而錯誤路徑會卸除裝置資源。透過引入 drm_dev_synchronize_unplug（） 來解決此問題，它會設定 unplugged 旗標並等待 SRCU 屏障，確保在清理繼續之前完成所有進行中的 drm_dev_enter（） 關鍵區段;在 drm_dev_register（） 的錯誤路徑上呼叫它。（CVE-2026-89823）

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

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

  - KVM：s390：修正長度檢查 __import_wp_info（） 結構 kvm_hw_breakpoint：：len 是一個完全由使用者空間控制的__u64。然後將其分配給 wp_info->len，這是一個 int。邊界檢查是針對截斷的值完成，而分配則使用未截斷的值：wp_info->len = bp_data->len;[...]if （wp_info->len < 0 || wp_info->len > MAX_WP_SIZE） return -EINVAL;wp_info->old_data = kmalloc（bp_data->len， GFP_KERNEL_ACCOUNT）;如預期使用已驗證的值進行分配。如果沒有此修正，使用者空間可能會觸發 >4GB 配置，但該配置會失敗，並因MAX_PAGE_ORDER而導致 WARN。（CVE-2026-89926）

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

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

  - futex：在重新排隊 PI 期間防止 rcuwait 釋放後使用 在 PREEMPT_RT 上，FUTEX_CMP_REQUEUE_PI可以在 futex_requeue_pi_complete（） 叫用 rcuwait_wake_up（） 時觸發 KASAN 報告 （slab-out-of-bounds）。futex_wait_requeue_pi（） 使用的futex_q分配在服務員的堆疊上。提前喚醒可以與 PI 重新排隊競爭，如下所示： 服務員重新排隊任務 ------ ------------ futex_wait_requeue_pi（） futex_do_wait（） schedule（） futex_requeue futex_proxy_trylock_atomic（） futex_requeue_pi_prepare（） Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal 喚醒服務員 * futex_requeue_pi_wakeup_sync（） Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete（） cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event（） if （atomic_read（&q->requeue_state） ！= Q_REQUEUE_PI_WAIT） break /* 無 schedule（） */ /* q.pi_state->owner == current */ futex_private_hash_put（） /* 來自 syscall 的傳回 */ rcuwait_wake_up（&q->requeue_wait） /* q 已消失 */ futex_requeue_pi_complete（） 在呼叫 rcuwait_wake_up（） 之前發布Q_REQUEUE_PI_LOCKED。服務員在叫用 rcuwait_wait_event（） 中的 schedule（） 之前，會在 rcuwait_wait_event（） 中觀察此狀態。在這裡，服務員可以騰出離開系統調用，然後重新排隊任務才能完成喚醒。若要解決此爭用，請跳過Q_REQUEUE_PI_LOCKED情況下的 rcuwait_wake_up（）。此狀態僅由 requeue_pi_wake_futex（） 發布，它在 futex_requeue_pi_complete（） 之前儲存 q->task，並透過 wake_up_state（） 喚醒服務員。此喚醒旨在將服務員從 futex_do_wait（） 睡眠中喚醒。如果服務員仍然睡在那裡，它就無法進入Q_REQUEUE_PI_WAIT狀態（並且需要刪除喚醒）。如果服務員透過其他方式從 futex_do_wait（） 喚醒（如本例所示）並在 futex_requeue_pi_wakeup_sync（） 中睡覺，那麼 requeue_pi_wake_futex（） 中的 wake_up_state（） 也會喚醒它。如果服務員任務在 wake_up_state（） 有機會喚醒任務之前終止，則任務指標不會失效，因為 futex_hash_bucket：：lock 被保留並且任務指標受到 RCU 保護。[bigeasy：更新了註解和提交訊息]（CVE-2026-90003）

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

ID	名稱	嚴重性
346532	Linux Distros 未修補弱點：CVE-2026-89906	high
346531	Linux Distros 未修補弱點：CVE-2026-89833	medium
346530	Linux Distros 未修補弱點：CVE-2026-90039	medium
346529	Linux Distros 未修補弱點：CVE-2026-89997	high
346528	Linux Distros 未修補弱點：CVE-2026-89831	medium
346527	Linux Distros 未修補弱點：CVE-2026-89830	medium
346526	Linux Distros 未修補弱點：CVE-2026-89819	high
346525	Linux Distros 未修補弱點：CVE-2026-92239	high
346524	Linux Distros 未修補弱點：CVE-2026-90004	medium
346523	Linux Distros 未修補弱點：CVE-2026-89949	medium
346522	Linux Distros 未修補弱點：CVE-2026-91839	high
346521	Linux Distros 未修補弱點：CVE-2026-90049	critical
346520	Linux Distros 未修補弱點：CVE-2026-89922	high
346519	Linux Distros 未修補弱點：CVE-2026-89796	medium
346518	Linux Distros 未修補弱點：CVE-2026-89807	medium
346517	Linux Distros 未修補弱點：CVE-2026-89967	high
346516	Linux Distros 未修補弱點：CVE-2026-89960	high
346515	Linux Distros 未修補弱點：CVE-2026-77692	high
346514	Linux Distros 未修補弱點：CVE-2026-89857	critical
346513	Linux Distros 未修補弱點：CVE-2026-90016	high
346512	Linux Distros 未修補弱點：CVE-2026-89953	medium
346511	Linux Distros 未修補弱點：CVE-2026-89938	high
346510	Linux Distros 未修補弱點：CVE-2026-89937	medium
346509	Linux Distros 未修補弱點：CVE-2026-89998	high
346508	Linux Distros 未修補弱點：CVE-2026-89966	medium
346507	Linux Distros 未修補弱點：CVE-2026-90034	medium
346506	Linux Distros 未修補弱點：CVE-2026-89951	high
346505	Linux Distros 未修補弱點：CVE-2026-89907	high
346504	Linux Distros 未修補弱點：CVE-2026-89941	high
346503	Linux Distros 未修補弱點：CVE-2026-89890	high
346502	Linux Distros 未修補弱點：CVE-2026-89925	medium
346501	Linux Distros 未修補弱點：CVE-2026-89884	medium
346500	Linux Distros 未修補弱點：CVE-2026-89896	medium
346499	Linux Distros 未修補弱點：CVE-2026-89874	medium
346498	Linux Distros 未修補弱點：CVE-2026-89862	high
346497	Linux Distros 未修補弱點：CVE-2026-89912	high
346496	Linux Distros 未修補弱點：CVE-2026-89969	critical
346495	Linux Distros 未修補弱點：CVE-2026-89851	medium
346494	Linux Distros 未修補弱點：CVE-2026-81736	high
346493	Linux Distros 未修補弱點：CVE-2026-89875	high
346492	Linux Distros 未修補弱點：CVE-2026-90022	high
346491	Linux Distros 未修補弱點：CVE-2026-89885	high
346490	Linux Distros 未修補弱點：CVE-2026-89793	high
346489	Linux Distros 未修補弱點：CVE-2026-89952	medium
346488	Linux Distros 未修補弱點：CVE-2026-89867	medium
346487	Linux Distros 未修補弱點：CVE-2026-89850	medium
346486	Linux Distros 未修補弱點：CVE-2026-89991	medium
346485	Linux Distros 未修補弱點：CVE-2026-89823	high
346484	Linux Distros 未修補弱點：CVE-2026-89926	medium
346483	Linux Distros 未修補弱點：CVE-2026-90003	high

偵測

Nessus 的 Misc. 系列

high

medium

medium

high

medium

medium

high

high

medium

medium

high

critical

high

medium

medium

high

high

high

critical

high

medium

high

medium

high

medium

medium

high

high

high

high

medium

medium

medium

medium

high

high

critical

medium

high

high

high

high

high

medium

medium

medium

medium

high

medium

high