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

  - USB：小工具：midi2：拆卸時移除預設 configfs 群組 f_midi2_alloc_inst（） 使用 configfs_add_default_group（） 為預設端點和預設區塊建立預設 configfs 子群組，並將其內部參照計數設定為 1。但是，在 f_midi2_free_inst（） 中的函數拆卸或 f_midi2_ep_opts_release（） 中的 EP 清理期間，永遠不會調用 configfs_remove_default_groups（），因此永遠不會刪除引用計數並洩露結構f_midi2_ep_opts和f_midi2_block_opts。在上述函式中新增缺少的 configfs_remove_default_groups（） 以正確釋放結構。
    (CVE-2026-89735)

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

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

  - Ceph：fs/ceph/mdsmap.c 中 MDS Info v2/v3 ceph_mdsmap_decode（） 的綁定num_export_targets陣列會從每個 per-MDS 資訊記錄中讀取num_export_targets，並將解碼游標推進 num_export_targets * sizeof（u32），而無需先檢查是否剩餘多少位元組。唯一會擷取失控游標 （*p > info_end） 的上界檢查是在 info_v >= 4 上進行閘控，因為info_v 2 和 3 會保留 NULL info_end。
    當監視器傳送 MDS 對應，其 per-mds 資訊版本為 2 或 3 且num_export_targets過大時，游標會越過訊息前端緩衝區，而後面的匯出目標迴圈會呼叫越界記憶體上未核取的 ceph_decode_32（）。核心用戶端從其監視器工作階段處理CEPH_MSG_MDS_MAP （net/ceph/mon_client.c 分派它;fs/ceph/super.c 將其路由到 ceph_mdsc_handle_mdsmap（），後者將 end 設定為前端緩衝區並呼叫 ceph_mdsmap_decode（））。因此，惡意或遭入侵的監視器，或未簽署/未加密的 Messenger 工作階段上的路徑攻擊者，可以在用戶端核心中驅動越界讀取;在與 KASAN x86_64時，它會報告為 ceph_mdsmap_decode（） 中的 slab-out-of-bounds 讀取。解碼的值會落在內部資訊>export_targets[] 數組中，因此後果是核心越界讀取，而不是資訊洩露給攻擊者。影響：
    惡意或已入侵的 Ceph 監視器傳送 MDS 對應，其中 per-mds 資訊版本為 2 或 3，且num_export_targets欄位過大，會在 CephFS 用戶端核心中觸發越界讀取。在前進游標之前，為 export-targets 陣列新增 ceph_decode_need（），以便對每個 info_v >= 2 強制執行界限，而不僅僅是 info_v >= 4。這反映了已用於相同函式中稍後m_data_pg_pools的計數後需要成語。使用 size_mul（） 計算 export-targets 位元組計數，並在前進游標時重複使用該檢查的長度，因此攻擊者控制的num_export_targets乘法在溢位時關閉失敗，而不是依賴後面的 kcalloc（） 保護。（CVE-2026-89650）

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

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

  - nfsd：修正伺服器間 COPY 設定失敗時的nfsd_file洩露 當 nfsd4_setup_inter_ssc（） 失敗時，nfsd4_copy（） 會直接傳回 nfserr_offload_denied，繞過 out： 標籤，其中 release_copy_files（） 會捨棄 nfs4_preprocess_stateid_op（） 所取得的nf_dst參照。每個失敗的伺服器間 COPY 都會洩漏一個nfsd_file，固定 file/inode/dentry/vfsmount。透過設定狀態並跳轉到 out： 而不是直接返回來修復。（CVE-2026-89680）

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

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

  - HID： intel-thc-hid： intel-quickspi：在複製之前驗證報告大小 write_cmd_to_txdma（） 在 qsdev->report_buf 中建立輸出報告，這是在 quickspi_alloc_report_buf（） 中配置給裝置描述元衍生max_report_len的堆積緩衝區 （觸控控制器的幾百位元組）。它會將呼叫端提供的報告複製到該緩衝區中：memcpy（write_buf->content， report_buf， report_buf_len）;預設情況下，HID 核心將報告限制為 HID_MAX_BUFFER_SIZE （16384），並且quickspi_hid_ll_driver不會設定max_buffer_size，因此長度不受限制地到達驅動程式。因此，攜帶大於 max_report_len 的報告的 hidraw SET_REPORT/SET_FEATURE ioctl 會因攻擊者控制的長度和內容而溢位report_buf。記錄report_buf分配大小，並在複製前拒絕不適合的報告，以符合 intel-quicki2c 同級 （quicki2c_init_write_buf（）） 和 hid-goodix-spi 修復中的等效保護。write_cmd_to_txdma（） 會將輸出報表標頭寫入相同緩衝區中的內容之前，因此請調整配置大小以涵蓋標頭。這可防止新增限制拒絕最大大小的報告。（CVE-2026-89620）

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

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

  - 當影像服務設定為 HTTP（S） 基本驗證時，OpenStack Ironic 可能會將 38.0.0 使用者名稱和密碼傳送至非預期的遠端主機。（CVE-2026-90461）

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

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

  - i3c：master：svc：綁定到請求的 max_payload_len svc_i3c_master_handle_ibi（） 的 IBI 負載將 IBI 負載從 RX FIFO 讀取到 IBI 插槽中。迴圈受硬體 FIFO 大小 （SVC_I3C_FIFO_SIZE） 限制，而非插槽大小。slot->data 指向 IBI 集區，其 i3c_generic_ibi_alloc_pool（） 大小為每個插槽 max_payload_len。svc_i3c_master_request_ibi（） 只會拒絕大於 SVC_I3C_FIFO_SIZE 的max_payload_len，因此驅動程式可以要求較小的。MCTP-I3C 要求 1.然後，每個 readsb（） 都會複製控制器 RXCOUNT 位元組 （最多 31 個），而不檢查插槽大小。
    傳送的位元組數超過插槽所保留的位元組數的裝置會寫入超過插槽>資料，這是對 IBI 集區的越界寫入。透過 dev->ibi->max_payload_len 綁定迴圈，並將每個讀取限制在插槽中剩餘的空間，就像 dw-i3c 一樣。裝置仍可傳送超過要求的承載量。清除 RX FIFO 中的剩餘位元組，以免它們洩漏到下一次傳輸中。（CVE-2026-80951）

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

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

  - iomap：如果區塊裝置上停用 PI 驗證fs_bio_integrity_alloc則不要釋放不存在的完整性承載，可能不會配置生物完整性承載。在 iomap_bio_read_folio_range_sync 中呼叫 fs_bio_integrity_free 之前，請先檢查該案例，以避免 NULL 指標解除參照。讓分支也涵蓋 PI 驗證 - 雖然fs_bio_integrity_verify在沒有完整性有效負載的情況下工作，但它需要一個實際完成有用的工作。（CVE-2026-89770）

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

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

  - dm-pcache：僅分發初始化的快取區段 get_cache_segment（） 會掃描區段對應直至 cache->n_segs（實體裝置區段計數），但 cache_segs_init（） 僅初始化前 cache_info >n_segs 區段。cache_info >n_segs小於裝置計數的特製映像會使剩餘的pcache_cache_segment結構歸零 （segment.data == NULL），而配置器可以將一個交給 cache_kset_close（），後者會寫入傳回的區段的資料指標，而不進行 NULL 檢查。將配置器的搜尋繫結為 cache_info->n_segs，以便只傳回初始化的區段。符合規範的快取集n_segs等於裝置區段計數，因此這不會拒絕任何合法的內容。（CVE-2026-80956）

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

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

  - mm/mglru：修正並移除多餘的不可驅逐對開本處理 sort_folio（） 有一個捷徑，用於移動不再可驅逐但仍位於生成清單中的對開本。然而，這個快捷方式有錯誤。它不遵循PG_lru使用慣例，並且有一個更嚴重的問題。不可驅逐的對開本不會執行緒在 lists[LRU_UNEVICTABLE] 上執行緒，因此可以重複使用 Folio->lru 來保存對開本>mlock_count （請參閱 lruvec_init（） 中的註解）。因此，lruvec_add_folio（） 會跳過它們的 list_add（），並且所有其他將對開本不可移除初始化的地方都會明確地初始化mlock_count：lru_add（） 將其設定為 0，
    __mlock_folio（） 和 __mlock_new_folio（） 將其設定為 ！！folio_test_mlocked（對開頁）。sort_folio（） 不設定任何內容，其正上方的 lru_gen_del_folio（） 可能已經透過 list_del（） 毒害了對開本>lru，因此mlock_count最終會給 LIST_POISON2 別名，讀作 0x122，即 290。結果是使用者可見的。在 munlock 上，__munlock_folio（） 遞減虛假計數，發現它仍然不為零，並在清除PG_mlocked之前退出，因此對開本保持不可驅逐，並且 Mlocked 帳戶保持膨脹，直到對開本被釋放為止。捷徑也會以錯誤的順序接觸 LRU 旗標。當 PG_lru 仍處於設定狀態時，它會呼叫 lru_gen_del_folio（），因此並行 folio_test_clear_lru（） （例如壓縮、folio_isolate_lru（）） 可以在已從生成清單中移除的對開本上成功，這可能會導致意外行為。因此，透過將它們隔離為通用對開本並讓通用收縮路徑剔除它們來修復它。這符合傳統 LRU 行為，而且應該不會對一般收回或隔離行為產生明顯影響。也沒有性能問題，這樣的對開本經歷了一次，然後它就永遠從生成列表中消失了。（CVE-2026-89757）

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

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

  - dm-pcache：修正 kset_replay（） 中的釋放後使用和無效的 seg 操作 在 kset_replay 中，當 key->seg_gen 過時 （key->seg_gen < key->cache_pos.cache_seg->gen） 時，會呼叫 cache_key_put（key），但隨後會存取 key->cache_pos.cache_seg 作為 cache_seg_get（） 的引數。這是釋放金鑰記憶體的釋放後使用。儘管內存池回收的記憶體在實踐中不會立即回收或覆蓋，但這仍然是一個潛在的 UAF 錯誤。此外，對於過期的無效金鑰，設定快取>seg_map位元並呼叫 cache_seg_get（） 是不合理的，因為對應的區段資料不再有效。在生成檢查之後移動 cache_seg_get（） 和 __set_bit（），以便它們只針對有效金鑰執行，並使用 continue 跳過無效金鑰，以解決這兩個問題。（CVE-2026-80955）

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

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

  - iommufd：修正自我測試 IOPF 報告 IOMMUFD 自我測試中的 UAF TRIGGER_IOPF從群組>pasid_array借用附加控制碼，而不與 PASID 分離同步處理，然後在分離清除控制碼並釋放支援結構iommufd_attach_handle之後，並行 iommu_report_device_fault（） 可以取消參照借用控制碼的網域指標。接著TRIGGER_IOPF解除參照釋放的控點，造成 UAF。透過在 mock_dev 中新增iopf_rwsem來修正，以遵循實際驅動程式的預期設計。在整個 iommu_report_device_fault（） 呼叫中保留其讀取端，並在連接、分離或取代裝置網域的每條路徑周圍保留其寫入端。這可能會封鎖新報告，並在移除舊的連接控點或 IOPF 錯誤參數之前排空進行中的報告。在註冊模擬裝置時，也採用寫入端，因為它可以叫用模擬驅動程式的預設網域附加回呼。（CVE-2026-89445）

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

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

  - nfsd：修正 nfsd4_ff_encode_layoutget 中的 XDR 長度計算 nfsd4_ff_encode_layoutget（） 中的 XDR 緩衝區大小計算有多個錯誤，可能導致越界寫入或將未初始化的核心記憶體洩漏給用戶端： - fh_len 不考慮檔案句柄資料上的 XDR 填充 - uid 和 gid 長度使用 8 + len，但 xdr_encode_opaque（） 實際上寫入 4 + xdr_align_size（len） 位元組 - ds_len 省略了標誌和stats_collect_hint欄位（8 位元組），而 len 的標頭常數高估了 8 個位元組——這些部分取消，但留下淨不匹配最壞的情況發生在短字串上（例如 uid=0、gid=0 和奇數大小的檔案句柄），其中函數最多寫入 5 個位元組超過保留的 XDR 緩衝區。相反地，當字串長度恰好是 4 位元組對齊時，保留太大，且過時的緩衝區內容會傳送至用戶端。透過在ds_len計算中明確分解每個編碼欄位、對所有可變長度不透明欄位使用 xdr_align_size（） 以及更正標頭常數來解決此問題。（CVE-2026-89674）

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

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

  - ipmi： ipmb：在驗證長度位元組之前，先驗證寫入訊息長度 ipmb_write（） 讀取訊息欄位。零或短寫入可以讀取未初始化的堆疊位元組。小於 SMBus 標頭的長度會反向溢位區塊寫入長度。需要非空白緩衝區和最小 IPMB 要求長度。在剖析訊息之前，也需要長度位元組加上承載。（CVE-2026-81007）

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

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

  - s390/cpum_cf： 透過 prepare/dead 回呼處理 CPU 熱插拔 當在執行期間加入 CPU 熱插拔時，「perf stat -e cycles -- <command>」命令會使核心當機。根本原因是在第一次事件初始化時配置結構cpu_cf_events。配置是動態的，具有工作內容的第一個事件會為每個線上 CPU 建立這類結構。這還不夠。CPU 在事件建立期間可能處於離線狀態，但可以在 perf 執行期間設為線上。例如，命令 # echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online 為 CPU 0,2-X 建立事件。由於事件是使用 task-context 建立，因此排程器最終會在 CPU1 上排程程式。此 CPU 尚未建立及初始化任何每個 CPU 事件基礎架構，因為該 CPU 在 perf 叫用時未在線上。因此，當排程器在 CPU1 上執行 stress-ng 時，函數 cpumf_pmu_add（） 會參考 NULL 指標：struct cpu_cf_events *cpuhw = this_cpu_cfhw（）;在 CPU1 上可執行任務 stress-ng 之後，會叫用此函式呼叫。this_cpu_cfhw（） 傳回 NULL。結果是錯誤： 無法處理虛擬核心位址空間中的核心指標解除參照 失敗位址：0000000000000000 TEID：0000000000000483 .... Krnl PSW ： 0404d001800000000 000003ef8291fd0c （cpumf_pmu_add+0x3c/0x80） ....
    呼叫追蹤：[<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80 [<000003ef82bb5e3e>] event_sched_in+0xae/0x190 [<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390 [<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0 [<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50 [<000003ef82bb6a30>] ctx_sched_in+0x180/0x260 [<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0 [<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0 [<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250 .... Last breaking-event-address： [<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40 只有在使用 CPUMF 工具並且排程器為此類進程挑選隨機 CPU 時，才會出現此問題。排程器會透過 PMU 回呼函式 pmu：：add（） 和 pmu：:d el（） 啟用 CPUMF 基礎結構。引入 CPU 熱插拔準備/失效回呼對，可在 CPU 離線時建立和移除每個 CPU 計數器資料。在受 pmc_reserve_mutex 保護的新計數器 cpu_cf_root：：tskcnt 中，計算追蹤每個 CPU （cpu == -1） 的使用者，即具有任務內容和 /dev/hwctr 裝置工作階段的 perf_event_open（） 事件。這可確保在選取新 CPU 來執行每個任務內容處理程序時，基礎架構可用。在 cpum_cf_free_root（） 和 cpum_cf_free_cpu（） 中，確保在資料釋放之前將資料結構的參照指標設定為 NULL，以防止中斷處理常式存取過時的資料。[gor@linux.ibm.com：變更提交訊息]（CVE-2026-89460）

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

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

  - drm/amd/display：跳過更新 HDCP 設定 處於轉換狀態 轉換狀態沒有應跳過設定 HDCP 常式的有效dm_stream_ctx。只有在建立有效資料流程時，常式才有效。（CVE-2026-89773）

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

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

  - media：cec：stm32：防止 RX 溢位上的越界寫入 stm32_rx_done（） 使用 rx_msg.len 作為寫入索引，將每個收到的 CEC 位元組附加到 rx_msg.msg[]，並在每個 RXBR （receive-byte-ready） 中斷時遞增它，而不根據緩衝區大小檢查它：cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF;rx_msg.msg[] 是結構cec_msg中的固定 CEC_MAX_MSG_SIZE （16） 位元組陣列，而 rx_msg.len 僅在 RXACKE/RXOVR 上或在完成訊息 （RXEND） 後重設。在 RXEND 之前收到的位元組數是由遠端 CEC 裝置 （它設定 EOM） 所決定，而非由驅動程式決定。不斷發送位元組而不結束訊息的對等會重複驅動 RXBR，將 rx_msg.len 推至 16 以上，並將對等控制的位元組越界寫入周圍記憶體。一旦驅動程式已探測並啟用接收，就可以在正常作業中從 IRQ 執行緒存取，而不需要任何本機權限。CEC 核心中的長度檢查會在儲存位元組之後在消費者端執行，因此不會防止溢位。
    在存放區之前系結驅動程式中的索引，就像其他平臺 CEC 驅動程式已經執行的一樣 （例如
    tegra_cec），丟棄過長框架的多餘位元組。由靜態分析工具 CodeQL 找到。
    (CVE-2026-89725)

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

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

  - NFSD：在委派撤銷期間防止用戶端釋放後使用 委派 stateid 僅保留指向其擁有nfs4_client的裸指標，不會使其保持作用中。用戶端在其 stateid 中倖存下來，只是因為 __destroy_client（） 在 free_client（） 執行之前排空cl_delegations和cl_revoked。
    nfs4_laundromat（） 打破了這種不變量：它從 cl_delegations 取消雜湊過期的委派，刪除deleg_lock，然後 revoke_delegation（） 將其重新連結到 cl_lock 下的 cl_revoked。在該視窗中，委派不在這兩個清單中，因此 client_has_state（） 無法報告任何剩餘狀態。每條拆解路徑首先要求cl_rpc_users為零，但自助洗衣店沒有這樣的參考。因此，當 revoke_delegation（） 仍要取消參照 cl_lock 時，其召回委派剛剛逾時的用戶端可能會達到 free_client（），這是釋放後使用。在撤銷上釘選用戶端cl_rpc_users，以便拆解區塊直到完成為止，然後從cl_revoked獲得委派。已經到期的用戶端會獲得自己的收益，因此請跳過它並保留委派 del_recall_lru。（CVE-2026-89659）

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

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

  - SMB： client：還原 is_valid_oplock_break（） 中綁定的data_offset提交 83bfbd0bb902 （cifs：從 smb_hdr） 中移除 RFC1002 標頭，變更了測量此綁定的數量。它曾經是 srv->total_read減去total_read當時包含的 4 位元組 RFC1002 前導碼，因此它是 SMB 訊息長度。相同的提交停止計算前導碼，以及 srv->total_read 的機械替換
    - srv->pdu_size 留下一個相同的零運算式：standard_receive3（） 讀取 MID_HEADER_SIZE（） 位元組，然後完全讀取 pdu_length - MID_HEADER_SIZE（） 更多，將兩者新增至 total_read。len 因此為 0，其下方的減法會換行，並且任何 __u32 DataOffset 都不能超過結果，因此來自提交 097f5863b1a0 （cifs：is_valid_oplock_break（） 中的讀取溢位） 的檢查不再拒絕任何內容。使用 total_read，現在是訊息長度本身。（CVE-2026-89630）

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

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

  - ip6_gre：修正 NBMA 通道的硬體標頭長度 ip6gre_tnl_link_config_route（） 會在設定header_ops時將較低裝置的硬體標頭長度累積到 dev->hard_header_len 中。這對 header_ops 的兩個使用者來說都是不正確的。ip6gretap 和 ip6erspan 具有固定的乙太網路硬體標頭長度。對於 NBMA ip6gre 通道，ip6gre_header（） 只會建立 GRE 標頭、選用的 FOU 或 GUE 標頭，以及外部 IPv6 標頭。較低的裝置標頭是稍後需要的餘量，而不是通道裝置硬體標頭的一部分。將下方裝置標頭保持在needed_headroom。僅針對具有header_ops的ARPHRD_IP6GRE裝置設定hard_header_len通道標頭長度，並保留分接和 erspan 裝置的固定乙太網路標頭長度不變。（CVE-2026-89562）

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

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

  - wifi：rtw89：pci：新增 .shutdown 回呼以在重新開機時停止 RFkill 輪詢 自從引入硬體 rfkill 輪詢以來，arm64 平台在熱重啟期間可能會因非同步 SError 而發生錯誤： CPU8 上的 SError 中斷，程式碼 0x00000000be000011 -- SError 工作佇列：events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211]cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] 核心錯誤 - 不同步：
    非同步 SError 中斷 在重新開機路徑上，核心僅執行 device_shutdown（），它會呼叫每個驅動程式的 .shutdown 回呼;不會叫用 .remove。rtw89 PCI 驅動程式沒有 .shutdown 回呼，因此當平台拆除 PCIe 連結時，沒有任何東西可以阻止 rfkill 輪詢工作。連結消失之後，從輪詢處理常式讀取的下一個 MMIO 會以無回應的裝置為目標，並報告為 arm64 上的重大非同步 SError。新增 rtw89_pci_shutdown（），連線至所有 rtw89 PCI 裝置驅動程式，以設定新的 RTW89_FLAG_SHUTDOWN 旗標 （鏡像 USB RTW89_FLAG_UNPLUGGED 模式）。設定旗標後，rtw89_ops_rfkill_poll（） 會提前返回，因此在關機開始後不會向晶片發出 MMIO 讀取，並且不再發生 SError。這不會從 .shutdown 呼叫完整的 .remove 路徑，以保持關機處理常式最小，並避免執行兩次非冪等拆卸。（CVE-2026-80939）

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

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

  - svcrdma：拒絕溢位上拉緩衝區的內嵌回覆 RPC-over-RDMA 用戶端可以要求回覆，例如 NFS READ 承載，而無需提供寫入清單或回覆區塊來承載它。當此類回覆需要比裝置傳送佇列支援的更多的分散/收集項目時，svc_rdma_pull_up_needed（） 會選取上拉，而 svc_rdma_pull_up_reply_msg（） 會將整個回覆線性化為 sctxt->sc_xprt_buf。該緩衝區只有 sc_max_req_size 個位元組，而此路徑上的回覆僅受用戶端要求的限制，因此 svc_rdma_xb_linearize（） 會複製到緩衝區的末端，並損毀相鄰的 slab 記憶體。
    然後，超大的長度會儲存在 sc_sges[0].length 中並張貼，因此裝置也會讀取超出對應區域的範圍。SGE 耗盡分支是唯一可以超過緩衝區的上拉路徑：閾值分支僅上拉小於 RPCRDMA_PULLUP_THRESH 的回复，並且直接發送符合設備 SGE 預算的回复，無需線性化。當 svc_rdma_pull_up_needed（） 報告 -E2BIG 時，它將拉出的回覆無法容納sc_max_req_size，並按照 RFC 8166 部分 4.5.3 的指示ERR_CHUNK使請求失敗，而不是中斷連接。協助程式不再回答簡單的是/否問題：它現在會報告 pull-up、no pull-up 或 -E2BIG （回覆太大而無法線性化）。將 svc_rdma_pull_up_needed（） 重新命名為 svc_rdma_check_pull_up（），使其名稱不再暗示布林述詞。
    (CVE-2026-89530)

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

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

  - ocfs2：讀取中繼資料時驗證目錄索引項目計數 ocfs2_validate_dx_leaf（） 和 ocfs2_validate_dx_root（） 在索引目錄區塊到達更高層級呼叫者之前檢查其 ECC 和簽章，但這兩個驗證器都不會根據保存它們的區塊的容量來限制ocfs2_dx_entry_list計數。ocfs2_dx_dir_search（） 然後遍歷 （i = 0; i < le16_to_cpu（entry_list->de_num_used）; i++） dx_entry = &entry_list->de_entries[i];超過 de_num_used 個項目，沒有邊界檢查。entry_list 是 dx_leaf->dl_list （來自 ocfs2_read_dx_leaf），或者對於內嵌根，則為 dx_root->dr_entries。特製的磁碟映像可以設定 de_num_used （和 de_count，即
    __counted_by_le（） 的 de_entries） 邊界）0xffff，並使遍歷讀取遠遠超過 4KB 中繼資料區塊的結尾，從而在裝載映像檔後，從索引目錄上的任何路徑查詢、stat（） 或 open（） 提供可存取的 slab 越界讀取。提交 775c17386a6f （ocfs2：在區塊讀取期間驗證dx_root範圍清單欄位） 已為非內嵌dx_root dr_list界，但未勾選內嵌dr_entries路徑和dx_leaf dl_list。為兩個項目清單新增相同的讀取時間驗證：
    de_count 必須等於區塊的容量 （ocfs2_dx_entries_per_leaf（）/per_root（）），並且de_num_used不得超過 de_count，在 ocfs2_dx_dir_search（） 遍歷超出範圍的項目陣列之前，使用 -EFSCORRUPTED 拒絕損毀的中繼資料。當葉或內嵌根格式化時，de_count一律會寫入區塊容量，因此相等檢查不會拒絕任何有效影像。由 0sec 自動化安全性研究工具 （https://0sec.ai)。(CVE-2026-89492)

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

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

  - jbd2：由檢查點緩衝區綁定的縮減器掃描 jbd2 縮減器目前僅考慮它針對nr_to_scan成功釋放的檢查點緩衝區。因此，忙碌的緩衝區不會消耗掃描預算。如果檢查點交易包含大部分忙碌的緩衝區，則縮減程式可以在保留日誌>j_list_lock時掃描其整個檢查點清單。大型檢查點清單可能會導致鎖定保持時間過長，並使其他 CPU j_list_lock時旋轉，進而造成軟鎖定或 RCU 停止。將nr_to_scan傳遞至 journal_shrink_one_cp_list（），並針對檢查的每個緩衝區（包括忙碌的緩衝區）遞減。從檢查點清除路徑傳遞 NULL，以便保留其現有的完整清單行為。這會還原 journal_shrink_one_cp_list（） 變更為一律掃描完整檢查點清單之前存在的掃描預算語意。（CVE-2026-89567）

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

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

  - NFSD：在用戶端拆卸期間防止鎖定擁有者釋放後使用 __destroy_client（） 會釋放用戶端的開啟擁有者，但唯一參照為封鎖鎖定鎖定 （nbl） 的鎖定擁有者仍處於cl_ownerstr_hashtbl狀態。
    client_has_state（） 不計算裸所有者，因此DESTROY_CLIENTID可以在此類所有者存在的情況下到達 __destroy_client（）。然後，__destroy_client（） 遍歷表格，在沒有參照的情況下對每個所有者呼叫 remove_blocked_locks（）。釋放封鎖的鎖定會刪除透過flc_owner保留的所有者參照。每個網路自助洗衣店從 nn->blocked_locks_lru 收穫封鎖的鎖定，與用戶端狀態無關。這兩條路徑僅在清單拼接中共用blocked_locks_lock，而不是所有者的存留期。因此，自助洗衣店會在 __destroy_client（） 解除參照時釋放所有者，這是 remove_blocked_locks（） 中的 NULL 解除參照。
    nfsd4_release_lockowner（） 在同一調用中保留一個參照;__destroy_client（） 沒有。在步行過程中按住cl_lock，獲取參考並取消哈希每個所有者，然後將其放在 remove_blocked_locks（） 和 nfs4_put_stateowner（） 之前，這需要 blocked_locks_lock 和 cl_lock。
    (CVE-2026-89662)

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

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

  - nfsd：檢查 nfsd4_create（） 中的 nfsd4_acl_to_attr（） 傳回值 nfsd4_create（） 將 nfsd4_acl_to_attr（） 的傳回值儲存在 status 中，但 switch（create->cr_type） 區塊會在每個分支中無條件地覆蓋它。ACL 轉譯錯誤會以無訊息方式捨棄，且 CREATE 會在沒有要求的 ACL 的情況下繼續進行。在 nfsd4_acl_to_attr（） 之後新增提前退出檢查，以符合 nfsd4_setattr（） 中已使用的模式。[ cel：比起NFS4ERR_ATTRNOTSUPP更喜歡NFS4ERR_BADTYPE ]（CVE-2026-89693）

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

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

  - SMB： client：拒絕位元組計數太小的樹狀結構連接回應 CIFSTCon（） 將其 strnlen（） 在位元組區域上以伺服器的 ByteCount 減去 2 的位元組區域為界，對於 ByteCount 0 或 1，該值為負數為整數，並轉換為巨大的 size_t。後面的減法會包裝 __u16 bytes_left，這就是 cifs_strndup_from_utf16（） 的邊界：針對 ~16 KB cifs_req_poolp物件的 65535 邊界從 slab 物件的末尾運行，並且位元組透過 /proc/fs/cifs/DebugData 中的 tcon->nativeFileSystem 到達使用者空間。拒絕對於剖析器耗用而言太小的位元組區域。兩個位元組是它可以消耗的最少位元組，並且沒有符合要求的回應攜帶更少的位元組。新的追蹤點是第 129 個smb_eio_trace項目，__mode（位元組） 無法表示，因此屬性會隨之而來。（CVE-2026-89631）

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

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

  - ceph：__build_xattrs（） __build_xattrs（） 中綁定的 xattr 值長度，一次解碼一個屬性 MDS 提供的 xattr blob。針對每一個屬性，它會讀取 32 位元名稱長度、前進超過名稱位元組、讀取 32 位元值長度、記錄值指標，以及前進超過值位元組。兩個長度欄位是使用 ceph_decode_32_safe（） 讀取的，但值位元組本身會以裸露的 p += len 來推進，並且沒有 ceph_decode_need（） 檢查 len 位元組是否保留在 blob 中。針對除最後一個屬性之外的每個屬性，下列名稱長度上的下一個反覆運算的 ceph_decode_32_safe（） 會隱含地驗證前一個值未執行過 blob 結尾。最終屬性沒有後續屬性，因此絕不會針對 Blob 界限檢查其解碼值長度。惡意或遭入侵的中繼資料伺服器可以將最後一個屬性的值長度設定為大於 Blob 中實際存在的位元組長度。blob 是專用的 kvmalloc（） 分配，大小取決於線路長度 （ceph_fill_inode（） 中的 ceph_buffer_new（））。
    __set_xattr（） 以 xattr->val_len 逐字記錄超大的長度，稍後的 getxattr（2） 將 memcpy（value， xattr->val， xattr->val_len） 執行到使用者提供的緩衝區中，將超出分配末尾的位元組複製回使用者空間。影響：惡意中繼資料伺服器透過 CephFS 檔案上的 getxattr（2） 向本機使用者洩露相鄰的核心堆積位元組。新增遺漏的 ceph_decode_need（），以便最終屬性上的越界值長度解碼失敗，並傳回 -EIO 而不是儲存。
    (CVE-2026-89649)

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

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

  - RDMA/cxgb4：在移除 c4iw_uld_state_change（） 佇列上釋放裝置之前取消reg_work，reg_work註冊 RDMA 裝置。c4iw_remove（） 可以在這項工作擱置或執行時釋放 ctx->dev，讓 c4iw_register_device（） 存取釋放的裝置。移除裝置前取消reg_work。註冊失敗時，註冊工作可能會拆除 ctx->dev，因此在此情況下，請勿再次取消註冊或取消配置。此問題是由內部靜態分析工具發現的。（CVE-2026-89510）

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

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

  - Btrfs：資料回寫提交 095be159f3eb 期間的寫入保護對開本 （Btrfs：統一對開本已變更旗標清除） 以純 folio_test_dirty（） 檢查取代了 extent_write_cache_pages（） 中的 folio_clear_dirty_for_io（） 呼叫。除了清除已變更旗標外，folio_clear_dirty_for_io（） 也會呼叫 folio_mkclean（），以寫入保護對應對應對應作品集的共用 mmap PTE。請注意，當我們在對開本的最後一個扇區（非子頁面情況的唯一扇區）上清除 dirty 時，我們仍然會在 submit_one_sector（） 中稍後調用 folio_clear_dirty_for_io（）。但我們在 extent_write_cache_pages（） 中失去了這個早期的呼叫。
    如果沒有額外的寫入保護，具有 mmap-ed 檔案的處理程序可以在回寫使用磁區時修改磁區，其方式需要穩定的對開本 （總和檢查碼、壓縮、複製等...），而不會出現錯誤，這表現為一些具體的錯誤。1. 對於較大的對開本或子頁面扇區大小，可以提交不涵蓋整個對開本的簡歷。當這種情況發生時，我們將有一個我們*未*調用 folio_clear_dirty_for_io（） 的對開本的簡歷。如果具有現有 mmap-ed PTE 的工作在此視窗中寫入 （沒有錯誤..） ，可能會導致損毀。如果寫入在總和檢查碼或寫入本身進行時到達，這可能會導致總和檢查碼無效，並在讀取時報告稍後的損毀報告。如果寫入在總和檢查碼/寫入完成之後，但在清除最後一個已變更磁區之前到達，則該寫入存在於頁面快取中，但不會影響已變更追蹤，且當對開本完全完成提交且已清除已變更位時，寫入將會遺失。這會導致即使呼叫 fsync（） 也會遺失寫入。2. 對於與主 extent_writepage（） 迴圈分批完成的分區提交，我們還面臨這些提交違反 csum 的風險。分區寫入會限制為max_zone_append_size，且未與對開本對齊，因此提交可以跨越兩個對開本。在 extent_write_cache_pages（） 中處理的第一個對開本將呼叫 extent_write_locked_range（），該對開本將提交下一個對開本的部分範圍，而該對開本的其餘部分可能仍然是髒的。因此，在提交的扇區上清除髒東西不會調用 folio_clear_dirty_for_io（），我們有同樣的問題。由於 extent_write_cache_pages（） 會略過這些批次提交的對開本 （這些對開本已由前一個對開本標示為從提交中回寫），因此我們必須在 lock_delalloc_folios（） 中新增額外的寫入保護。3. 對於內嵌範圍，這將微妙地面臨丟失寫入的風險，這些寫入發生在我們複製內嵌範圍之後/期間，但在我們清除對開本上的髒東西之前。4.
    對於跨越 EOF 的對開本，mmap 可能會竄改 EOF 之後的歸零位元組，並導致它們在未來的錯誤會不正確地看到它們而不是零的情況下被保留。5. 最後，對於壓縮範圍，我們在壓縮對開本時可能會修改對開本，這將導致壓縮資料損毀。具體來說，在 run_delalloc_compressed（） 中，我們將工作排隊以在 BTRFS_COMPRESSION_CHUNK_SIZE （512K） 區塊中執行 compress_file_range（），這些區塊將呼叫該範圍內的 btrfs_folio_clamp_clear_dirty（）。
    對於非子頁面，這將始終安全地清除整個作品集。對於子頁面，我們在這裡也冒著部分清除的風險。特別是，想像一個 2M 作品集被分解成 512K 個工作區塊，這些工作區塊可能會在所有區塊 compress_file_range（） 工作者足夠遠以完成清除作品集的所有髒點陣圖並到達 folio_clear_dirty_for_io（） 之前開始在一個區塊上進行壓縮工作。提交範圍邊緣的大型對開本同樣面臨僅部分清除的風險。這個特殊的差距是由同一系列中的第二個修補程式引入的：提交 a4ef54dbb576 （btrfs：使 extent_range_clear_dirty_for_io（） 處理磁區大小<頁面大小情況） 我們不能簡單地恢復對 folio_clear ---truncated--- （CVE-2026-89772） 的調用

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

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

  - nfsd：透過 argp->mask 門 NFS2 SETACL NFSACL v2 SETACL 路徑共用其 v3 同級所使用的解碼器慣例：nfsaclsvc_decode_setaclargs（） 僅在要求遮罩中設定 NFS_ACL 時才填入 argp->acl_access，而 argp->acl_default 僅在設定 NFS_DFACL 時，將另一個指標保留為 NULL，因為引數緩衝區在解碼前歸零至 pc_argzero。然後nfsacld_proc_setacl（） 無條件地將兩個指標交給 set_posix_acl（）。set_posix_acl（idmap， dentry， type， NULL） 是 VFS 移除此 ACL 類型作業，因此省略的 ARM 與刪除該 ACL 的明確要求無法區分。僅承載 NFS_ACL 的 SETACL 會以無訊息方式剝離目錄的預設 ACL;mask=0 會同時剝離兩者。這與剛剛在 nfsd3_proc_setacl（） 中修復的缺陷相同;應用相同的補救措施。對其遮罩位元上的每個 set_posix_acl（） 呼叫進行門禁，並將錯誤初始化為 0，以便未設定任何位元的請求保持磁碟上的 ACL 不變並傳回成功。out_drop_lock 路徑和 nfsaclsvc_release_setacl（） 中的無條件 posix_acl_release（） 已經容忍跳過的 arm。（CVE-2026-89672）

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

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

  - net：dsa：realtek：使用 gpiod_set_value_cansleep 重設 GPIO rtl83xx_reset_assert（） 和 rtl83xx_reset_deassert（） 僅從探測路徑調用，探測路徑可能會休眠，並且對時序不重要。
    當休眠控制器 （例如 I2C I/O 擴展器） 提供重設 GPIO 時，gpiod_set_value（） 會警告： 警告：drivers/gpio/gpiolib.c：4030 at gpiod_set_value+0x44/0x80， CPU#1：kworker/u16：4/61 硬體名稱：B&O MAP CA33 Rev f （UNKNOWN） （DT） 工作佇列：events_unbound deferred_probe_work_func pc：
    gpiod_set_value+0x44/0x80 LR：rtl83xx_probe+0x1d8/0x3a0 呼叫追蹤：gpiod_set_value+0x44/0x80 （P） rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0
    __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 將兩個協助程式切換到 gpiod_set_value_cansleep（），以便可以在沒有的情況下使用這樣的重設 GPIO觸發警告。自從在 v4.19 中新增驅動程式以來，重設 GPIO 一直使用非休眠 gpiod_set_value（） 驅動。此後，該呼叫已跨多個檔案重構 - 從 realtek-smi.c / realtek-mdio.c 到通用的 rtl83xx.c 模組，然後到rtl83xx_reset_assert（） 和 rtl83xx_reset_deassert（） 協助程式（均在 v6.9 中）。因此，此修補程式僅按原樣適用於攜帶這些協助程式的核心 （v6.9+）;較舊的穩定核心需要在對應的開放編碼呼叫站點進行相同的 gpiod_set_value_cansleep（） 轉換。
    (CVE-2026-80999)

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

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

  - nfsd：非同步 COPY 迴圈之前的回寫錯誤游標範例 _nfsd_copy_file_range（） 將 dst->f_wb_err 取樣到複製迴圈之後，然後在 vfs_fsync_range（） 傳回時使用它透過 filemap_check_wb_err（） 偵測回寫錯誤。由於 nfsd_file 快取會在以相同 inode 為目標的請求中重複使用單一結構檔，因此 dst 上的並行 COMMIT 或穩定 WRITE 會在其自己的 vfs_fsync_range（） 期間透過 file_check_and_advance_wb_err（） 將 dst->f_wb_err 推進至目前的對應>wb_err。如果該進度介於 mapping->wb_err 中出現的回寫錯誤和 COPY 工作者取樣之間，則背景工作者會捕獲已經進階的游標，errseq_check（） 會看到 cur == since 並傳回零，即使回寫失敗也會設定NFSD4_COPY_F_COMMITTED。CB_OFFLOAD然後編碼 wr_stable_how = FILE_SYNC4，用戶端會將複製的資料視為持久資料，而失敗會變成無訊息資料遺失。從函數開始時開始的一次取樣。然後，游標會在此 COPY 發出任何寫入之前反映有效的狀態，並且 filemap_check_wb_err（） 會偵測複製期間發生的任何錯誤，而不論哪個執行緒首先觀察到它。這符合 nfsd_vfs_write（） 和 nfsd4_clone_file_range（） 所使用的模式。
    (CVE-2026-89704)

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

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

  - ipmi：修正 _ipmi_destroy_user（） 中釋放後使用 cmd_rcvr 提交 9e91f8a6c868 （ipmi：msghandler： 移除 ipmi_interfaces 清單的 srcu） 刪除了從 intf->cmd_rcvrs 取消命令接收器的連結和釋放它們之間的 synchronize_rcu（），僅更新解釋為什麼需要屏障的註解。
    cmd_rcvrs清單仍然在普通 RCU 下遍歷：find_cmd_rcvr（） 在 rcu_read_lock（） 中遍歷它，而 handle_ipmb_get_msg_cmd（） 從同一讀取端部分的該查找中借用 rcvr->user。
    如果沒有寬限期，_ipmi_destroy_user（） 可以在讀取器仍持有指向它的指標時對cmd_rcvr進行 kfree（），從而導致釋放後使用。返工只是使介面清單不需要 srcu;cmd_rcvrs清單仍然依賴於純 RCU。在釋放接收器之前還原 synchronize_rcu（）。
    (CVE-2026-89486)

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

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

  - orangefs：修正 readdir 複製失敗時的雙重釋放 trailer_buf 在 readdir 向下調用時，當 copy_from_iter_full（） 失敗時，orangefs_devreq_write_iter（） 會釋放帶有 vfree（） 的 op->downcall.trailer_buf，但不會在 goto Efault 之前清除指標。然後，do_readdir（） 中的服務員會以負狀態喚醒，並在其 r < 0 路徑上再次釋放相同的指標，從而造成確定性的雙重釋放。持有 /dev/pvfs2-req 的用戶端會透過傳送 readdir 向下呼叫來觸發它，其宣告的trailer_size超過其提供的位元組。釋放後清除指標，使 readdir 端 vfree（） 變成無操作。（CVE-2026-89498）

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

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

  - NTFS：驗證非常駐屬性位移 ntfs_attr_update_meta（） 會在非稀疏和稀疏屬性之間轉換時轉移屬性名稱。轉換為疏鬆也會在名稱和對應配對之前新增compressed_size欄位，因此屬性記錄中需要另外八個位元組。
    但是，驗證器不會檢查name_offset是否在這些操作的安全範圍內，或者是否有額外的空間可用。惡意 MFT 記錄可能會設定這樣的name_offset： 1. 名稱位於非稀疏屬性的最結尾。轉換為稀疏會將名稱向前移動 8 個位元組，寫入屬性界限之外。2、名稱與映射對重疊，導致轉換時損毀。新增驗證以確保： - 針對具名屬性，name_offset在有效範圍內 - 名稱不會超出屬性或與對應配對重疊 - 對於非稀疏、未壓縮的屬性，compressed_size欄位在mapping_pairs_offset之後有 8 個位元組可用 空格檢查也涵蓋未具名屬性，其中 name_offset = 0 有效且不需要檢查名稱範圍。（CVE-2026-89611）

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

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

  - mm： memcg：當限制更新被取代時停止回收 Kernfs 只會序列化每個開啟的檔案檔案作業，因此單獨的開啟檔案可以同時更新相同的 memory.high 或memory.max檔案。這兩個處理常式都會在同步回收之前儲存新的限制，但會繼續在回收迴圈中使用寫入器的本機目標。如果另一個寫入器提高或移除限制，第一個寫入器可以繼續向過時的目標回收。memory.max，一旦回收重試用盡，這可能會讓寫入器無限期地迴圈。OOM 路徑會在目前限制下看到足夠的邊界，並傳回 true 而不終止，而寫入器仍會比較使用量與其過時的目標，並記錄另一個 OOM 事件。
    在每個回收反覆專案開始時檢查目前的限制，如果它不再符合寫入器的目標，請停止。再現：使用匿名記憶體填充 cgroup 並停用交換。降低一個開啟檔案的memory.max，然後在新限制可見後透過另一個開啟的檔案將其還原到最大值。如果沒有修補程式，第一個寫入器會保持封鎖狀態，並重複遞增 OOM 事件計數器。透過修補程式，它會正常返回。這並不是由報告的生產工作負載所推動的。我們透過 cgroup 可觀察性工作的自動隨機測試發現了它，並將其簡化為上面的複製品。（CVE-2026-89752）

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

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

  - mm/migrate：在 migrate_pages_batch（） 中報告 RCU 任務靜止狀態 migrate_pages_batch（） 在移動每個作品集之前將其取消映射，並且每次取消映射都會執行mmu_notifier無效回呼。在 KVM 主機上，try_to_migrate（） 最終會變成 kvm_mmu_notifier_invalidate_range_start（） -> tdp_mmu_zap_leafs（），這很昂貴，因此取消映射大批次會使 CPU 長時間忙碌。迴圈已經呼叫 cond_resched（），但在 PREEMPTION 核心上，這是無操作，並且非自願搶佔不是 Tasks-RCU 靜止狀態。因此，長批次永遠不會報告靜止狀態，而移轉任務 （例如
    kcompactd） 會變成 Tasks-RCU 保留，使 Tasks-RCU 寬限期停止幾分鐘，這在Meta叢集中很常見：INFO：rcu_tasks偵測到的 tasks 停止：0000000055349ecc：..nvcsw：1157401/1157401保留：1 idle_cpu：-1/56 task：kcompactd0 state：R 正在執行任務 呼叫追蹤：tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start
    __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread 使用 cond_resched_tasks_rcu_qs（），這樣即使 cond_resched（） 什麼都不做，也會報告靜止狀態。這也在 [1] （CVE-2026-89756） 中討論過

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

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

  - openvswitch：只有 skb_tx_error（） 我們即將丟棄的封包 queue_userspace_packet（） 會借用封包 skb -- 它只會將其複製到私有網路連結訊息 （user_skb） 中，並不擁有它;返回時，do_execute_actions（） 會持續透過流程的其餘動作轉送它。儘管如此，它的錯誤路徑還是調用了 skb_tx_error（skb），它通過 skb_zcopy_clear（） 執行 skb_shinfo（skb）->flags &= ~SKBFL_ALL_ZEROCOPY，從該實時 skb 中剝離SKBFL_SHARED_FRAG（skb_tx_error（） 的 kerneldoc 說之後必須釋放 skb）。對於攜帶頁面快取片段的 skb MSG_ZEROCOPY，SKBFL_SHARED_FRAG使 esp_input（） skb_cow_data（） 在就地 AEAD 之前;一旦它被剝離，稍後的本地 ESP-in-UDP 傳遞就會在發送者不擁有的頁面上就地解密——無權限的頁面緩存寫入（Fragnesia 原語）。do_execute_actions（） 會忽略 output_userspace（） 的傳回值，因此 USERSPACE 向上調用失敗後的任何動作都會繼承剝離的 skb。將 skb_tx_error（） 移至 flow-miss 丟棄路徑 - ovs_dp_process_packet（） 的 switch（error） 的預設分支），在 kfree_skb（） 之前。自提交 36d5fe6a0007 （core， nfqueue， openvswitch： 孤立片段在 skb_zerocopy 並處理錯誤） 以來，該調用一直存在，但在 esp_input（） 開始依賴 SKBFL_SHARED_FRAG 來控制就地解密之前是無害的;只有這樣，在仍在轉發的 skb 上剝離它才成為頁面緩存寫入原語。（CVE-2026-89487）

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

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

  - timers/itimer： 複製到使用者空間之前，將舊的 itimerval 歸零 在原生 sparc64 上， struct
    __kernel_old_timeval在tv_usec後包含一個四位元組的孔，因為tv_sec是 64 位元，而
    __kernel_suseconds_t是 32 位元。put_itimerval（） 只會填入堆疊分配的具名欄位
    __kernel_old_itimerval並將整個物件複製到使用者空間，因此 getitimer（） 可以公開兩個填充孔。在指派欄位之前，先初始化彙總，讓隱含填補在跨越使用者/核心界限之前具有確定性。（CVE-2026-89765）

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

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

  - nfsd：關閉檔案快取中的 shrinker/GC/fsnotify 與 per-net 關機爭用 shrinker、GC 工作程式和 fsnotify/lease 回呼可以從 rhashtable 中取消雜湊nfsd_file，然後呼叫 nfsd_file_dispose_list_delayed（） 將其移至 per-net 處置清單。如果 nfsd_file_cache_shutdown_net（） 同時執行，則其 rhashtable 遍歷會遺漏已未雜湊的檔案，並且可以在檔案排入佇列之前執行其逐網處置清單的清空。然後，該文件位於每個網絡列表中，沒有線程可以清空它，從而洩露文件及其相關狀態。GC 工作程式和縮減程式在遍歷 LRU 時已經保留了 nfsd_gc_lock，但在原始程式碼中，它們會在呼叫 nfsd_file_dispose_list_delayed（） 之前釋放它。fsnotify/租用路徑 （nfsd_file_close_inode） 完全沒有同步化。透過以下方式解決此問題： 1. 擴大 nfsd_file_gc（） 和 nfsd_file_lru_scan（） 中的nfsd_gc_lock以涵蓋 nfsd_file_dispose_list_delayed（） 呼叫。2. 將 nfsd_file_close_inode（） 包裝在nfsd_gc_lock中，以便 nfsd_file_dispose_list_delayed（） 的所有三個呼叫者都持有鎖。3. 在清除後在 nfsd_file_cache_shutdown_net（） 中新增 spin_lock/unlock（nfsd_gc_lock） 屏障，以便在 per-net 清單耗盡之前，任何進行中的處置都已完全完成。鎖定內的所有作業都是非休眠的 （rhashtable 查詢、不可部分完成位元/參照計數操作、清單移動等svc_wake_up），因此微調鎖定是適當的。（CVE-2026-89667）

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

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

  - rust： devres：修正並行撤銷者之間的爭用 當兩條路徑嘗試同時撤銷 Devres 時，可能會有爭用情形。驅動程式核心的 devres_release_all（） 會透過發行回呼呼叫 Revocable：：revoke（），而 Devres：:d rop（） 會呼叫另一個 CPU 上的 revoke_nosync（）。未宣告is_available交換的撤銷者會立即返回，但撤銷的撤銷者可能仍在對內部資料執行 drop_in_place（）。當另一個撤銷者的呼叫端繼續刪除 drop_in_place（） 仍然引用的相鄰資源時，這可能會導致釋放後使用（例如，Devres<DmaMappedSgt> 與 SGTable 競爭釋放後備sg_table和頁面）。透過新增完成來修正此問題。revoke（） 完成後，釋放回呼會發出 Completion 信號，而 Devres：:d rop（） 會在失去is_available交換時等待它。這可確保在 Devres：:d rop（） 傳回之前完全拆除包裝的物件。
    (CVE-2026-89764)

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

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

  - net：tun：綁定接收餘量 tun_get_user（） 使用 tun->align 作為 skb 餘量，並在選擇要保持線性的資料包資料量時使用。OVS 可以將超大的餘量要求從另一個連接埠傳播到 TUN 或 TAP。當 align 大於單頁 skb 頭中的可用空間時，SKB_MAX_HEAD（align）反向溢位，儲存在 good_linear 中時結果會變為負數。該值稍後在分配給size_t線性變數時包裝，並且 tun_alloc_skb（） 可以將 skb->data 放在分配的頭之外。將 TUN 儲存的餘量綁定到一頁 skb 頭預算和最大的非哨兵 16 位元 skb 標頭位移。為原始 TUN 留下一個線性位元組，為 TAP 留下一個完整的乙太網路標頭，包括 NET_IP_ALIGN。
    此外，在存取 raw-TUN 通訊協定位元組和 TAP 乙太網路標頭之前，請先提取它們，以便這些檢查對於其他配置路徑所提供的非線性 skb 保持安全。（CVE-2026-81000）

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

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

  - pidfd：保留命名空間 ioctl 周圍的 exec_update_lock PIDFD_GET_*_NAMESPACE ioct pidfd_ioctl l 在分發命名空間檔案描述元之前，會執行檔案系統認證 ptrace 存取檢查。隨附的註解指出，程式碼會反映 nsfs 的行為，但與對應的 procfs 路徑不同，它不會保留目標任務的exec_update_lock。proc_ns_get_link（） 和 proc_ns_readlink（） 都採用 exec_update_lock 來讀取 ptrace 檢查和命名空間查閱，以便用於存取決策的認證在讀取其命名空間時與任務的認證相符。如果沒有它，調用方可以通過對目標的舊憑據的檢查，然後在目標執行 setuid 二進位檔並提交新憑據後讀取命名空間——訪問它應該被拒絕的命名空間信息。保留 exec_update_lock 以讀取 ptrace 檢查和命名空間查詢，以便 pidfd 真正反映 nsfs 行為，正如註解已經聲稱的那樣。
    open_namespace（） 本身在鎖定之外運行：一旦獲得命名空間引用，它就會攜帶自己的引用計數，並使用調用者自己的憑據打開，因此目標上的並發 execve（） 不能再影響結果。（CVE-2026-89766）

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

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

  - svcrdma：當傳輸分配失敗時拒絕連接 handle_connect_req（） 在 svc_rdma_create_xprt（） 無法配置新的傳輸時傳回而不採取任何動作。CM 核心會針對CONNECT_REQUEST事件傳回 0，因此不會破壞新的rdma_cm_id。記憶體壓力下的每次配置失敗都會洩漏一個rdma_cm_id，遠端對等驅動連線嘗試可能會放大這種情況。透過從 CM 事件處理常式傳回非零狀態來拒絕連接，這會告訴 CM 核心銷毀孤立的cm_id。CVE-2026-89531

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

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

  - ecryptfs：拒絕標籤 3 封包本文encrypted_key_size的 parse_tag_3_packet parse_tag_3_packet（） 集中過大的encrypted_key_size，而不將其與 ECRYPTFS_MAX_KEY_BYTES （64） 綁定。
    當encrypted_key_size > 64 時，decrypt_passphrase_encrypted_session_key（） 設定 decrypted_key_size = encrypted_key_size 並執行兩次越界寫入： 1. crypto_skcipher_decrypt（） 透過散點清單將encrypted_key_size位元組寫入 decrypted_key[64]，溢位到父ecryptfs_auth_tok結構中。2. memcpy（crypt_stat->key， decrypted_key， decrypted_key_size） 寫入 crypt_stat->key[64]，損毀 ecryptfs_crypt_stat 中的 root_iv、keysig_list 和互斥。只有 AES-192 （加密碼 0x08） 能夠啟用此功能，因為它會獨立於 encrypted_key_size 設定 crypt_stat->key_size = 24，從而允許 crypto_skcipher_setkey（） 在 encrypted_key_size 超過 ECRYPTFS_MAX_KEY_BYTES 時成功。PKI 解密路徑 （parse_tag_65_packet） 已驗證 decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES;密碼路徑省略此檢查。encrypted_key_size ECRYPTFS_MAX_KEY_BYTES （64） 而不是 ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES （512）。64 位元組限制也會保護 512 位元組 encrypted_key[] 緩衝區，因此先前的 512 位元組檢查會作為備援移除。
    [tyhicks：調整程式碼註解以引用表示緩衝區大小的巨集，而不是提及緩衝區大小值，因為它們將來可能會變更]（CVE-2026-89607）

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

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

  - kho：修正 kho_preserved_memory_reserve（） 中的大小計算 kho_preserved_memory_reserve（） 透過執行 1 << （order + PAGE_SHIFT） 來計算保存的大小。由於「1」是 32 位元整數，因此只能移位 31。也就是說，它僅適用於高達 2 GiB 的保存。較大的保存將觸發未定義的行為。雖然目前無法透過對開本取得大於 2 GiB 的保留，但可以透過 kho_preserve_pages（） 取得。例如，memblock reserve_mem使用 kho_preserve_pages（）。大於 2 GiB 的保留有效，如果正確對齊，將會觸發此錯誤。使用 1UL 進行換檔來修復它。（CVE-2026-89568）

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

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

  - nfsd：不要釋放仍在使用中的會話槽位 nfsd4_sequence（） 可以釋放它目前正在處理的槽位。當工作階段壓縮器已將se_target_maxslots減少到 se_fchannel.maxreqs 以下時，壓縮路徑會在呼叫 free_session_slots（） 之前檢查三個條件： 1. se_target_maxslots < maxreqs （已通告壓縮） 2.slot->sl_generation == se_slot_gen （slot 是最新的） 3.
    seq->maxslots <= se_target_maxslots （用戶端確認） 但是，絕不會針對 seq->slotid 檢查se_target_maxslots。使用 [se_target_maxslots， maxreqs） 範圍內的插槽的用戶端可以滿足所有三個條件：其插槽具有當前生成（由先前的 SEQUENCE 設定），並且它發送 sa_highest_slotid <= se_target_maxslots 以確認減少。然後，free_session_slots（） 會釋放索引 >= se_target_maxslots 的每個插槽，包括呼叫者自己的插槽。該函數繼續寫入 sl_seqid、sl_flags、sl_generation，並將懸空指標儲存在 cstate->slot 中。稍後，nfsd4_store_cache_entry（） 會將最多 maxresp_cached 位元組的複合回覆複製到釋放的 sl_data[] 陣列中，從而損毀現在佔用該位址的任何 slab 物件。此外，不同高編號插槽上的並行執行緒處理 SEQUENCE 可以將其插槽從其下方釋放出來。在釋放鎖定之前，NFSD4_SLOT_INUSE 會在 nn->client_lock 下設定，因此任何超過 SEQUENCE 的並行執行緒都會標示其插槽。但是，free_session_slots（） 不會在釋放之前檢查NFSD4_SLOT_INUSE。透過以下方式解決這兩個問題： 1. 檢查目前請求的 slotid 是否低於收縮邊界。2. 掃描待釋放範圍內的插槽是否有NFSD4_SLOT_INUSE，如果有活動，則延遲收縮。（CVE-2026-89689）

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

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

  - nfsd：修正非同步複製中的 UAF 取消和關閉 當拆卸呼叫端 （OFFLOAD_CANCEL、nfsd4_shutdown_copy、nfsd4_cancel_copy_by_sb） 爭用複製 kthread 時，非同步副本可以在釋放後釋放或使用： - find_async_copy（） 碰撞了 copy->refcount，但將副本留在 clp->async_copies 上，因此收割者的 cleanup_async_copy（） 可以與取消/關閉呼叫端同時執行 release_copy_files（）。put 和 NULL 都nf_src/nf_dst，沒有公共鎖，雙重放置nfsd_file並提前釋放它。- nfsd4_do_async_copy（） 在最終使用副本之前設定NFSD4_COPY_F_STOPPED （copy->nf_dst 上的 nfsd_update_cmtime_attr（），nfsd4_send_cb_offload（））。nfsd4_stop_copy（） 將設定的 STOPPED 位視為 kthread done，跳過 kthread_stop（），因此拆卸調用程式執行了 release_copy_files（） -- 它nf_dst放置和 NULL -- 而 kthread 仍然取消參照它 （NULL/UAF）。- 複製>copy_task從未被釘選。一擊 kthread 在返回時會自我收穫，因此 kthread_stop（） 的 get_task_struct（） 可以觸及釋放的task_struct。- co_cb 內嵌在副本中，但 nfsd4_send_cb_offload（） 僅在用戶端上保留參照，因此並行拆卸可以在CB_OFFLOAD回呼正在進行時釋放副本。將整個拆卸存留期修正為一體： - find_async_copy（） 取消連結 async_lock 下的副本 （清除 cp_clp， list_del_init）;cancel、shutdown 和 sb-cancel 路徑會透過 nfsd4_stop_copy（） 之後的 nfs4_put_copy（） 刪除 list-membership 參照。從 cleanup_async_copy（） 中刪除現在多餘的list_del修正。
    - 因為取消連結會向收割者隱藏副本，所以其 cleanup_async_copy（） 無法再移除副本的s2s_cp_stateids項目;cancel/shutdown/sb-cancel 路徑現在會自行調用 nfs4_free_copy_state（） （而 cp_clp 仍然有效），因此項目不會懸掛在釋放的記憶體上，以便自助洗衣店和 manage_cpntf_state（） 解除參照。- 為 kthread 提供自己的引用，在 wake_up_process（） 之前的 nfsd4_copy（） 中獲取，並在 nfsd4_do_async_copy（） 的末尾刪除;在呼叫 list_add（） 之前呼叫 wake_up_process（）。- 用 nfsd4_copy（） 中的 get_task_struct（） 固定 task_struct，並在 nfs4_put_copy（） 中釋放，因此每當 kthread 結束時，kthread_stop（） 都是安全的。僅在 nfsd4_stop_copy（） 中設定 NFSD4_COPY_F_STOPPED，現在一律在 release_copy_files（） 之前kthread_stop（）s;完成情況仍會透過 NFSD4_COPY_F_COMPLETED 報告，因此 nfsd4_has_active_async_copies（） 不受影響。每個拆卸呼叫端都會先從 clp->async_copies 移除副本，因此 kthread_stop（） 只會執行一次。- 在 nfsd4_send_cb_offload（） 中獲取副本引用，在 nfsd4_cb_offload_release（） 中刪除。kthread 仍然在那裡保留自己的引用，因此 refcount_inc（） 無法爭用最終的釋放。- 使用 smp_load_acquire（） 讀取cp_clp，以與無序的 set_bit（）/clear_bit（） 寫入器配對 （Documentation/atomic_bitops.rst）。（CVE-2026-89675）

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

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

  - efivarfs：速率限制 statfs（） 處理常式 Ravi 報告說，無權限的使用者可能會在 efivarfs 裝載點上呼叫 statfs（），這可能會導致對 QueryVariableInfo（） 執行階段服務的大量呼叫。
    在變數儲存由 SMM 支援的 x86 系統上，這些呼叫的成本過高，因為每個 SMM 項目都需要所有 CPU 的交會。因此，將對 QueryVariableInfo（） 的呼叫限制為每秒兩次，並針對省略的呼叫傳回最近取得的值。（CVE-2026-89604）

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

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

  - HID： mcp2221：I2C/SMBus 傳輸完成後清除 rxbuf mcp_i2c_smbus_read（） 會在傳輸期間將呼叫端提供的緩衝區指標儲存在 mcp->rxbuf 中，但在傳輸完成或逾時時絕不會清除它。一旦調用方釋放或重複使用緩衝區，mcp->rxbuf 就會變成懸空指標。
    然後，延遲或虛假的MCP2221_I2C_GET_DATA報告可能會驅動 mcp2221_raw_event（） 將 memcpy 裝置資料放入釋放的記憶體中，從而導致釋放後寫入使用。透過清除 mcp->rxbuf 和 mcp->rxbuf_size 的單一退出點路由所有傳回路徑，以便raw_event處理常式中現有的 ！mcp->rxbuf 防護可以拒絕傳輸結束後到達的任何報告。（CVE-2026-89622）

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

ID	名稱	嚴重性
345074	Linux Distros 未修補弱點：CVE-2026-89735	high
345073	Linux Distros 未修補弱點：CVE-2026-89650	critical
345072	Linux Distros 未修補弱點：CVE-2026-89680	high
345071	Linux Distros 未修補弱點：CVE-2026-89620	high
345070	Linux Distros 未修補弱點：CVE-2026-90461	medium
345069	Linux Distros 未修補弱點：CVE-2026-80951	medium
345068	Linux Distros 未修補弱點：CVE-2026-89770	high
345067	Linux Distros 未修補弱點：CVE-2026-80956	medium
345066	Linux Distros 未修補弱點：CVE-2026-89757	medium
345065	Linux Distros 未修補弱點：CVE-2026-80955	high
345064	Linux Distros 未修補弱點：CVE-2026-89445	high
345063	Linux Distros 未修補弱點：CVE-2026-89674	critical
345062	Linux Distros 未修補弱點：CVE-2026-81007	high
345061	Linux Distros 未修補弱點：CVE-2026-89460	medium
345060	Linux Distros 未修補弱點：CVE-2026-89773	high
345059	Linux Distros 未修補弱點：CVE-2026-89725	high
345058	Linux Distros 未修補弱點：CVE-2026-89659	critical
345057	Linux Distros 未修補弱點：CVE-2026-89630	critical
345056	Linux Distros 未修補弱點：CVE-2026-89562	high
345055	Linux Distros 未修補弱點：CVE-2026-80939	medium
345054	Linux Distros 未修補弱點：CVE-2026-89530	critical
345053	Linux Distros 未修補弱點：CVE-2026-89492	critical
345052	Linux Distros 未修補弱點：CVE-2026-89567	medium
345051	Linux Distros 未修補弱點：CVE-2026-89662	critical
345050	Linux Distros 未修補弱點：CVE-2026-89693	medium
345049	Linux Distros 未修補弱點：CVE-2026-89631	critical
345048	Linux Distros 未修補弱點：CVE-2026-89649	critical
345047	Linux Distros 未修補弱點：CVE-2026-89510	high
345046	Linux Distros 未修補弱點：CVE-2026-89772	high
345045	Linux Distros 未修補弱點：CVE-2026-89672	critical
345044	Linux Distros 未修補弱點：CVE-2026-80999	high
345043	Linux Distros 未修補弱點：CVE-2026-89704	high
345042	Linux Distros 未修補弱點：CVE-2026-89486	high
345041	Linux Distros 未修補弱點：CVE-2026-89498	medium
345040	Linux Distros 未修補弱點：CVE-2026-89611	critical
345039	Linux Distros 未修補弱點：CVE-2026-89752	medium
345038	Linux Distros 未修補弱點：CVE-2026-89756	medium
345037	Linux Distros 未修補弱點：CVE-2026-89487	high
345036	Linux Distros 未修補弱點：CVE-2026-89765	high
345035	Linux Distros 未修補弱點：CVE-2026-89667	high
345034	Linux Distros 未修補弱點：CVE-2026-89764	high
345033	Linux Distros 未修補弱點：CVE-2026-81000	high
345032	Linux Distros 未修補弱點：CVE-2026-89766	medium
345031	Linux Distros 未修補弱點：CVE-2026-89531	medium
345030	Linux Distros 未修補弱點：CVE-2026-89607	high
345029	Linux Distros 未修補弱點：CVE-2026-89568	medium
345028	Linux Distros 未修補弱點：CVE-2026-89689	critical
345027	Linux Distros 未修補弱點：CVE-2026-89675	critical
345026	Linux Distros 未修補弱點：CVE-2026-89604	medium
345025	Linux Distros 未修補弱點：CVE-2026-89622	high

偵測

Nessus 的 Misc. 系列

high

critical

high

high

medium

medium

high

medium

medium

high

high

critical

high

medium

high

high

critical

critical

high

medium

critical

critical

medium

critical

medium

critical

critical

high

high

critical

high

high

high

medium

critical

medium

medium

high

high

high

high

high

medium

medium

high

medium

critical

critical

medium

high