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

  - s390/debug： 修正取消註冊期間的鎖死 在寫入其中一個相關聯的 debugfs 檔案時取消註冊 s390dbf 偵錯區域可能會導致鎖死： $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs 寫入 debugfs_file_get（） debug_unregister（） mutex_lock（debug_mutex） debugfs_remove（） 等待 debugfs_file_put（） debug_file_ops.write（） debug_input（） mutex_lock（debug_mutex） ==> 鎖死 透過將 debug_unregister（） 分割成s390dbf 和 debugfs 部分，並僅執行鎖定 debug_mutex 的 s390dbf 部分。（CVE-2026-90209）

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

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

  - OPP：修正清理順序 提交 173e02d67494 （OPP：內嵌初始化範圍型指標） 已新增所有指標的初始化。在某些情況下，順序會變更，以便在 *opp 之後初始化 *opp_table。這也會變更已註冊清理功能的順序。當清理發生時，當釋放最後一個參照和釋放函式時，這可能會導致釋放後使用錯誤
    _opp_kref_release嘗試存取已釋放的 opp->opp_table。再次在 *opp 之前初始化 *opp_table 以修正此問題並確保清除順序正確。（CVE-2026-93069）

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

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

  - ALSA： seq： midi：當 rawmidi 子資料流關閉時，不得執行使用 event_input snd_midi_input_event（） 的序列化輸入拆卸，因為這可能會導致觸發狀態在 snd_rawmidi_input_trigger（） 中的此序列中變得不同步：snd_rawmidi_input_trigger（up=0） snd_midi_input_event（） -> snd_rawmidi_kernel_read（） -> snd_rawmidi_input_trigger（up=1） -> cancel_work_sync（） 以基礎裝置意外處於活動狀態而結束。當從 close_substream（） 呼叫此值時，在 rawmidi_release_priv（） 將 rfile->rmidi 設定為 NULL 後，進一步的輸入可以重新觸發輸入事件，使其繼續運行，這會導致： 無法處理虛擬位址 000000000000000b0 的核心 NULL 指標解除參照 呼叫追蹤：snd_midi_input_event+0x3c/0x134 [snd_seq_midi] （P） snd_rawmidi_input_event_work+0x1c/0x2c process_one_work+0x150/0x3a4 worker_thread+0x190/0x318 套用類似的方法提交ef7607ab1c8ad （ALSA： seq： midi： Serialize output teardown with event_input） 修正了輸出方向上的相同問題，但在 Takashi Iwai 提議的後續修補程式 [1] 之後更新為使用 RCU。進行此變更後，midisynth_unsubscribe（） 會清除輸入檔，因此 snd_midi_input_event（） 不會重新觸發串流，並會由 snd_rawmidi_input_trigger（） 中的 cancel_work_sync（） 靜默。[1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/ （CVE-2026-90207）

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

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

  - MTD： 部分：拒絕 mtd_add_partition（） 中的MTDPART_OFS_RETAIN mtd_add_partition（） 不會拒絕特殊偏移值 （-3） MTDPART_OFS_RETAIN，當透過 NAND 裝置上的 BLKPG ioctl 呼叫時，這會導致 add_mtd_device（） 中出現WARN_ON。RETAIN 值取決於 cur_offset 是前一個分割區的結尾，但在動態分割區路徑中，cur_offset 等於位移引數本身，從而造成未定義的行為。提交 5daa7b21496a （mtd：為 ioctl 要求準備分割區 add 和 del 函式） 引入了 mtd_add_partition（） 並正確拒絕了 MTDPART_OFS_APPEND （-1） 和 MTDPART_OFS_NXTBLK （-2），因為這些特殊偏移依賴於cur_offset追蹤前一個分割區的末端。然而，提交 1a31368bf92e （mtd：為分割區新增旗標，該旗標應該只在分割區後面留下 smth.）稍後為靜態分割區表格路徑新增MTDPART_OFS_RETAIN （-3），而不更新 mtd_add_partition（） 也拒絕此值。透過 BLKPG 傳遞 offset=-3 時，allocate_partition（） 中的 RETAIN 大小計算會發生反向溢位 （parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3）。如果下溢結果似乎沒有留下足夠的空間，allocate_partition（） 會透過 goto 跳到out_register，跳過擦除大小初始化。這會導致 erasesize=0，這會觸發：
    WARN_ON（（！mtd->erasesize || ！master->_erase） & ！（add_mtd_device（） 中的 mtd->flags &; MTD_NO_ERASE））。如果反向溢位結果似乎留下足夠的空間，則會計算虛假的分割區大小，但超出範圍的健全性檢查會擷取無效的位移，並建立已停用的空白分割區 （位移=0，大小=0），而不是傳回錯誤。透過將MTDPART_OFS_RETAIN新增至 mtd_add_partition（） 中的拒絕清單來修正此問題，這與 APPEND 和 NXTBLK 的現有處理方式一致。（CVE-2026-93048）

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

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

  - bpf：拒絕來自需要錯誤保護的指標的負載獲取 與一般BPF_LDX不同，驗證程式不會將BPF_LOAD_ACQ重寫為BPF_PROBE_MEM載入，因此 JIT 會發出沒有例外狀況表格項目的純載入，而且錯誤會使核心錯誤，而不是被處理。拒絕 BPF_LDX 本應套用該故障保護的來源指標類型，即 bpf_convert_ctx_accesses（） 變成BPF_PROBE_MEM的來源指標類型：裸PTR_TO_BTF_ID，PTR_TO_BTF_ID |PTR_UNTRUSTED， PTR_TO_BTF_ID |MEM_ALLOC |PTR_UNTRUSTED和PTR_TO_MEM |MEM_RDONLY |PTR_UNTRUSTED。這是可以實現的，例如，通過從受信任的task_struct中加載 ->mm 會產生一個不受信任的指向 mm_struct 的指標，並且對於核心執行緒來說它是 NULL：[...]SEC（tp_btf/sched_switch） int BPF_PROG（demo， bool preempt， struct task_struct
    *prev， struct task_struct *next） { struct mm_struct *mm = next->mm; /* 不受信任 */ out_ldx = （__u64）mm->pgd; /* BPF_LDX */ out_acq = load_acquire（&mm->pgd）; /* BPF_LOAD_ACQ */ 傳回 0; }[...]兩者都會解除參照相同的指標，但只有 BPF_LDX 受到保護 （x86-64 JIT，跳轉目標顯示為 prog-relative）： [...] ;out_ldx = （__u64）mm->pgd;17： movq $-10485760， %r10 1e： movq %rsi， %r11 21： addq $184， %r11 28： subq %r10， %r11 2b： movabsq $140737498841088， %r10 35： cmpq %r10， %r11 38： ja 0x3e <-- kernel addr？3a：xorl %edi，%edi <-- 否：dst = 0，跳過載入 3c：jmp 0x45 3e：movq 184（%rsi），%rdi <-- 是：
    載入 + 可擴展條目 [...] ;load_acquire（&mm->pgd） 53： movq %rsi， %rdi 56： movq 184（%rdi）， %rax <-- 無檢查，無可擴展項目 [...]請注意，BPF_PROBE_MEM在 bpftool xlated 轉儲中不可見，因為 bpf_insn_prepare_dump（） 會將其重寫回 BPF_MEM。PTR_TRUSTED指標故意不在清單中。這類負載也不會轉換，但不需要轉換，因為指標保證是即時的，因此允許從中取得負載。檢查對BPF_LOAD_ACQ進行門控，因此不可部分完成 RMW 和存放區釋放錯誤訊息不變;對此類指標的寫入 （RMW / store-release） 已經在其他地方被拒絕，因此只有 load-acquire 需要這個。(CVE-2026-90269)

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

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

  - MD：從 RAID1/10/456 中移除 REQ_NOWAIT 支援REQ_NOWAIT MD 個性中可能在內部封鎖的支援從根本上來說是不完整的。雖然讀取可以避免某些封鎖路徑，但寫入要求仍然會遇到一個鏡像成功而另一個鏡像傳回 -EAGAIN 的情況。此時，md 無法區分佇列壓力和實際裝置故障，因此它既無法記錄壞區塊，也無法在沒有REQ_NOWAIT的情況下安全地重試寫入，從而留下具有不同資料的鏡像。與其繼續為無法正確實施的人物宣傳REQ_NOWAIT支持，不如將其從 raid1、raid10 和 raid456 中刪除。保留線性和 raid0 的 REQ_NOWAIT，它們僅將 BIOS 重新映射到其底層設備;如果任何元件裝置缺乏REQ_NOWAIT支援，堆疊限制仍會清除該功能。（CVE-2026-90401）

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

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

  - scsi：mpt3sas：避免釋放未分配的 PCIe SGL 緩衝區 _base_release_memory_pools（） 會無條件釋放每個 ioc->pcie_sg_lookup[] 項目，包括部分故障後安裝迴圈從未配置的項目，從而導致除錯核心上出現錯誤的 dma 警告或 NULL 指標解除參照。
    (CVE-2026-90202)

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

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

  - mm/mm_init：處理 free_area_init_core_hotplug 中的 alloc_percpu 失敗 我們遺漏了 pgdat->per_cpu_nodestats 的分配檢查失敗，這會導致當我們偏移到 per-cpu 區域時，出現 NULL 解除參照。
    傳播 -ENOMEM 在堆疊上，並讓per_cpu_nodestats指向boot_nodestats，以便稍後的線上人員可以重試分配。hotadd_init_pgdat（） 在失敗時傳回 NULL，__try_online_node（） 已對應至 -ENOMEM。失敗時，不需要展開任何內容： - 節點永遠不會被標記為線上 - per_cpu_nodestats仍然指向boot_nodestats - __add_memory_resource（） 清理擱置中的 memblock 資源 - 稍後的線上嘗試重試per_cpu_nodestats分配 （CVE-2026-93172）

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

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

  - irqchip/gic-v5：在拆卸時清除每個 CPU 的 IRS 資料 IRS 關聯設定會在剩餘的 IRS 初始化失敗之前，在每個 CPU 資料中發佈 IRS 指標和 IAFFID 狀態。然後，錯誤路徑會釋放 IRS 資料，而不清除已發佈的狀態，讓 CPU 與釋放的記憶體相關聯。在初始化失敗和正常 IRS 拆卸時，移除過時的 irs_data 指標，以清除每個 CPU 的 IRS 關聯。此外，對於在釋放之前繫結至 IRS 的任何 CPU 的每個 CPU 的 IAFFID 狀態也會失效。（CVE-2026-90121）

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

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

  - md/raid1：建立序列集區，將 rdev 新增至 serialize_policy=1 的陣列 在啟用 serialize_policy 的情況下將新的 rdev 新增至現有 RAID1 陣列後，核心 7.1.3 觀察到以下錯誤： 哎呀：0002 [#1] CPU：0 UID：0 PID：19639 通訊：ext4lazyinit 未受污染 7.1.3-1-default RIP：
    _raw_spin_lock_irqsave+0x27/0x50 CR2：0000000000004960 呼叫追蹤：wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] 如果設定了 MD_SERIALIZE_POLICY，則 raid1.c 程式碼會呼叫 wait_for_serialization（），並且wait_for_serialization假設 rdev->serial 已初始化。通常，對於將 serialize_policy sysfs 屬性設定為 1 的陣列會出現這種情況。但是，當將新的 rdev 新增至 bind_rdev_to_array（） 中的現有陣列時，mddev_create_serial_pool（） 處的條件會導致跳過 rdev->serial 的建立。修復它。
    (CVE-2026-90385)

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

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

  - netfilter： nf_tables：建置鏈結 blob 之後移動硬體卸載步驟 在規則集卸載之前配置鏈結 blob，以減少進入不一致狀態的機會，其中 NIC 中的卸載規則集與軟體規則集不同。（CVE-2026-90062）

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

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

  - serial： core：當 tty_alloc_driver（） 失敗時，清除 uart_register_driver（） 失敗時釋放的指標 uart_register_driver（） 會留下 drv->state 指向釋放的記憶體。如果 tty_register_driver（） 失敗，drv->tty_driver 也會在刪除其參照後保留指標。然後，使用 drv->state 作為已註冊旗標的驅動程式可以跳過下一個探查的註冊，並將釋放的狀態傳遞至 uart_add_one_port（）。此問題是在 QEMU 的 raspi1ap 板上的 failslab 中發現的，方法是註冊失敗並再次綁定 PL011 連接埠。清除故障路徑上的兩個指標，就像 uart_unregister_driver（） 已經做的那樣。（CVE-2026-90336）

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

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

  - md：分配關鍵區段的範圍memalloc_noio 將 memalloc_noio_save（） 權杖儲存在 mddev->noio_flags 中，可讓一個工作儲存權杖，而另一個工作還原權杖。透過並行暫停 sysfs 寫入，任務 A 可以輸入 PF_MEMALLOC_NOIO，返回仍在該範圍內的使用者空間，稍後任務 B 可以還原 A 已儲存的權杖。避免將權杖存留期繫結至 mddev。讓 mddev_suspend（） 和 mddev_resume（） 只負責陣列暫停，並僅在陣列暫停後配置記憶體的 MD 路徑中輸入 PF_MEMALLOC_NOIO。還原權杖，再繼續陣列。重現者會重複從並行工作角色寫入suspend_lo和suspend_hi，並在 sysfs 寫入之前和之後檢查每個工作角色的 /proc/self/stat 旗標。（CVE-2026-90389）

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

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

  - perf/x86/intel/uncore：修正 ref/unref 排序uncore_box在 uncore_event_cpu_online（） 中，uncore_box_ref（） 是在 uncore_change_context（） 之前呼叫的。box->cpu 上的 uncore_box_ref（） 閘>= 0，但 box->cpu 仍然是
    此時為 -1，因為 uncore_change_context（） 尚未執行。因此，盒子永遠不會在第一個在晶片中聯機的 CPU 上初始化，在每個晶片單一 CPU 的情況下永久未初始化。因此，box->refcnt 比真實值低一個計數，並且在 CPU 離線路徑中，該框將在倒數第二個 CPU 上被拆除。在 uncore_event_cpu_offline（） 中，uncore_box_unref（） 是在 uncore_change_context（） 之後調用的，因此當收集器 CPU 離線時，box->cpu 已經是 -1，這阻止了它拆除盒子。透過交換兩個路徑中的呼叫順序來修正，以便 uncore_box_{ref，unref}（） 在 box->cpu 反映正確上下文的點上運行。將 allocate_boxes（） 移出 uncore_box_ref（） 以啟用此重新排序。（CVE-2026-93181）

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

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

  - hwrng： xilinx-trng - 在讀取任何資料之前傳播逾時 xtrng_readblock32（） 輪詢 16 位元組區塊，但即使第一次輪詢逾時，也會傳回讀取的位元組數。然後，其調用方將零返回視為短暫的成功讀取，而完整 32 位元組區塊的部分讀取可以使尾部副本使用固定的區塊偏移量，而不是已經產生的數量。當未讀取任何資料時傳回輪詢錯誤、在某些資料可用之後保留部分正傳回、在所有集合結束時停止產生器，並在目前輸出計數處附加尾部位元組。（CVE-2026-93157）

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

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

  - crypto： qat - 在重新啟用 SR-IOV 逾時時取消工作 QAT 重設背景工作佇列 SR-IOV 使用內嵌在堆疊adf_sriov_dev_data中的work_struct和完成來重新啟用工作。如果完成等候逾時，重設背景工作角色可以在device_sriov_wq仍保留或執行堆疊備份工作專案時傳回。在堆疊框架展開之前，在逾時時取消device_sriov_wq上的工作。（CVE-2026-93162）

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

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

  - pnfs/blocklayout：修正剖析失敗 bl_parse_concat（） 和 bl_parse_stripe（） 配置子裝置陣列，然後依序剖析每個子裝置陣列時的裝置洩漏。如果剖析子項失敗，則失敗的子項不會計入nr_children，並且父項可能會留下一個子陣列，當nr_children為零時，bl_free_device（） 不會釋放該子陣列。在傳回錯誤之前，釋放失敗的子系和已剖析的子系。此外，只要設定子指標，bl_free_device（） 就會釋放子陣列，以便正確清除部分初始化的 concat 或 stripe 裝置。bl_parse_scsi（） 在指派 d->bdev_file 並刪除檔案參照後也可能失敗。清除 fput（） 之後的指標，這樣外部清理路徑就不會再次放置它。（CVE-2026-90150）

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

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

  - PCI：dwc：ep：在取消對應 iATU 之前排清快取的 MSI 寫入 MSI-X 路徑在拆除其 iATU 對應之前，已排清任何已發佈的 MSI-X 寫入。這是由提交 c22533c66cca 新增的 （PCI：dwc：ep：
    在取消對應其 ATU 項目之前排清 MSI-X 寫入），以確保寫入在轉譯它的輸出視窗消失之前到達根複合體。MSI 路徑有相同的問題，但沒有對等的重新整理。當端點驅動程式快取 MSI 目標位址，稍後觀察到根複合體已變更它時，dw_pcie_ep_raise_msi_irq（） 會取消對應現有的 iATU 專案，並針對新位址重新編程。在最後一個 MSI writel（） 和取消映射之間，光纖中可能仍有已發佈的寫入，取消映射 iATU 項目可能會丟棄或錯誤路由該寫入。在取消對應之前，從對應的 MSI 視窗回讀來修正此問題。回讀會透過對應它們的相同 iATU 項目清空任何已發佈的 MSI 寫入，這與 MSI-X 路徑使用的邏輯相同。[mani：提交日誌]（CVE-2026-90332）

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

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

  - iio：輕：gp2ap002：修正重複事件寫入時不平衡的執行階段 PM IIO 核心不會篩選對事件啟用屬性的重複寫入，因此寫入相同的值兩次會叫用 write_event_config（） 兩次。啟用兩次會洩漏執行階段 PM 參照，防止裝置再次暫停;停用兩次會使使用計數反向溢位，並觸發執行階段 PM 使用計數反向溢位警告。當請求的狀態符合目前狀態時，儘早退出。在此情況下，切換到 pm_runtime_resume_and_get（），以便將失敗的恢復傳播到使用者空間，而不是以靜默方式將事件標記為啟用。（CVE-2026-90249）

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

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

  - esp：請勿取消參照 esp_ssg_unref（） 中的受管理片段頁面 esp_ssg_unref（） 會在 AEAD 作業完成後釋放來源散佈清單上保留的頁面參照。它會在每個片段頁面上呼叫 skb_page_unref（） 以進行錯位轉換 （req->src ！= req->dst），並在要求自己的散佈清單上呼叫 esp_output_tail（） 的錯誤路徑 （already_unref == true）。當 skb 攜帶受管理片段 （SKBFL_MANAGED_FRAG_REFS） 時，這是錯誤的。受管理的片段由零副本 ubuf 擁有，並且 skb 不持有每個片段頁面引用;具有已註冊緩衝區的io_uring SEND_ZC會透過 io_sg_from_iter（） 以這種方式附加 bvec 頁面。堆疊的其餘部分遵循此不變量：設定 SKBFL_MANAGED_FRAG_REFS 時，skb_release_data（） 會跳過每個片段的取消參照，而 skb_zcopy_managed（） 是其他取消參照站點使用的防護。esp_ssg_unref（） 缺少該保護，因此對於託管片段 skb，它會刪除 skb 從未取得的頁面參照。這可能會使頁面參照計數溢位，並釋放仍在使用的頁面。使用 skb_zcopy_managed（） 保護函式，以便針對符合 skb_release_data（） 的受管理片段 skb 跳過兩個 unref 路徑。（CVE-2026-93105）

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

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

  - ALSA： control：不要將無效的 kcontrols 新增至 LED 層 kcontrol LED 狀態層會嘗試追蹤所有相關聯的 kcontrol 元素，並假設它們是可讀的。但是可以創建一個沒有 get 回調的只寫元素（即使是用戶元素也可以這樣做），這可能會導致 snd_ctl_led_notify（） 調用鏈處的 NULL 取消參照，正如 syzkaller 所發現的那樣。為避免 Oops，請新增 kcontrol 資訊的健全性檢查並取得回呼，並在將 kctl 指派給 LED 層之前跳過無效的 kcontrol。（CVE-2026-90060）

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

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

  - 韌體： arm_scmi：如果驅動程式註冊失敗，則取消要求裝置 scmi_driver_register （） 在註冊驅動程式之前要求通訊協定裝置。如果 driver_register（） 失敗，這些要求會保留在全域 IDR 中，並保留模組 ID 表格的指標。一旦失敗的模組載入釋放該儲存體，稍後的要求比對或 SCMI 裝置建立就可以取消參照過時的指標。在傳回註冊失敗之前，取消要求完整的通訊協定表。此時資料表註冊成功，因此每個項目都由目前的註冊嘗試所擁有。（CVE-2026-92490）

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

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

  - 藍牙：L2CAP：在 get/setsockopt 中安全地存取 chan->conn 自提交 b66774b48dd9 （藍牙：L2CAP：
    透過保留 conn ref） 修正通道逾時中的 UAF，l2cap_chan：：conn 已保留參照，並且在刪除對應的hci_conn後仍保持非 NULL。在此狀態下，存取各種欄位，例如。
    hci_conn：：hdev 無效，這會導致 KASAN 在 conn->hcon->hdev 的 l2cap_sock_setsockopt（） 存取中損毀。在嘗試在 l2cap_sock.c 中使用活動hci_conn之前，請檢查 l2cap_chan：：conn.hcon 是否對應於它。在 getsockopt/setsockopt 中保留 l2cap_chan_lock（） 以確保其保持活動狀態，並避免l2cap_chan欄位中的資料爭用。（CVE-2026-90093）

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

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

  - RDMA/mlx5：在最後一個 DevX 事件檔案卸除其模組參照或輔助驅動程式分離其裝置之後，模組拆卸期間的 Drain RCU 回呼 devx_free_subscription（） 可能會保持佇列狀態。然後，mlx5_ib可以在回呼執行之前卸載。註冊錯誤解除具有相同的風險，因為驅動程式註冊可以在失敗之前附加現有的裝置。待所有驅動程式停止後等待。
    (CVE-2026-93109)

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

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

  - bpf：如果 JIT 不可用，則拒絕具有內嵌協助程式的程式 當架構 （例如 LoongArch、 ARM64和 RISC-V） 實作 bpf_jit_inlines_helper_call（） 時，驗證程式會跳過重寫 bpf_do_misc_fixups（） 中的協助程式呼叫位移 （insn->imm）。這是因為協助程式稍後會由 JIT 編譯器內嵌。因此，insn->imm 仍會保留為原始協助程式列舉 ID。但是，如果在運行時停用 JIT （net.core.bpf_jit_enable=0） 或 JIT 編譯動態失敗（例如，由於 OOM），則程式將回退到 BPF 解譯器。當解譯器使用未修補的原始 ID 執行 （__bpf_call_base + insn->imm） 時，它會跳入無效的位址空間，從而觸發指令對齊錯誤或核心錯誤。雖然這些協助程式在核心中具有有效的 C 實作，但忽略位移重寫會讓執行階段解譯器後援成為致命的。當 JIT 內嵌跳過協助程式呼叫重寫時，設定「prog->jit_required = 1」來修正此問題。這可確保在 JIT 無法使用時安全地拒絕此類程式，從而防止執行階段核心錯誤。（CVE-2026-93135）

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

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

  - NFC： LLCP：避免無效 optlen 上的使用者空間溢位 nfc_llcp_getsockopt（） 將 optval 轉換為 （u32 __user *） 用於 put_user（），因此無論呼叫端提供的 optlen 為何，核心始終儲存 4 個位元組。現有的 min_t（u32， len， sizeof（u32）） 僅限制回報回使用者空間的長度;它不限制商店。因此，使用 optlen < 4 的呼叫會寫入使用者緩衝區，違反所有五個支援的 optname 的 getsockopt（2） 合約。拒絕任何預先帶有 optlen < sizeof（u32） 的呼叫。'len' 是 int，因此普通大小比較會促進負 optlen size_t並通過檢查;首先新增明確的「len < 0」測試，以便在大小比較之前擷取負值。（CVE-2026-90226）

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

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

  - serial： AMBA-PL011：保持主控台時鐘啟用不可部分完成寫入 pl011_console_write_atomic（） 從 NBCON 不可部分完成內容執行，其中不允許休眠。它調用 clk_enable（），它採用通用 clk enable_lock。在PREEMPT_RT下，這是一個休眠鎖：clk_enable_lock（） 首先嘗試 spin_trylock_irqsave（），但在爭用時會回落到 spin_lock_irqsave（）。因此，具有 clk 支援的 pl011 的 RT 核心上的原子上下文 printk 可能會跳閘： 錯誤：從 spinlock_rt.c：48 處的無效上下文調用休眠函數，__might_resched從 rt_spin_lock rt_spin_lock 調用 clk_enable_lock clk_enable_lock 從 pl011_console_write_atomic 調用 clk_enable clk_enable ...來自 vprintk_emit 這是在 PREEMPT_RT 上發現並轉載的。Arm32 和 arm64 DT SoC 受到影響;arm64 SBSA/ACPI 沒有 clk，因此在鎖定之前clk_enable（NULL） 短路。此外，可以從 NMI 內容叫用 write_atomic（） 並記錄以避免鎖定。從回呼中移除 clk_enable（） 也可以避免可能不安全的 NMI 取得通用時鐘enable_lock。支援 NBCON 不可部分完成的主控台必須可從任何內容列印，因此無法在寫入之間限制時鐘。當主控台可用於輸出時啟用時鐘：在 pl011_console_setup（） 中使用 clk_prepare_enable（），透過主控台 .exit（） 回呼中的 clk_disable_unprepare（） 釋放時鐘，並從 write_atomic（） 和 write_thread（） 中刪除每次寫入的 clk_enable（）/clk_disable（） 對。當 printk 暫停控制台時，在 uart_suspend_port（） 停止控制台訪問後刪除引用並在 uart_resume_port（） 之前還原它 -- 但前提是暫停實際上將端口標記為已暫停（具有喚醒功能的 tty 保持運行並且必須保持其時鐘），並在 console_suspend_enabled 為 false 時保留它，這樣no_console_suspend才能正常工作。保持時鐘啟用的有功功率成本取決於平台：當 UART 時鐘是固定的總是開啟振盪器時，沒有，當它是一個可門控時鐘分支時，它不能被門控（也不可能它的父時鐘）當控制台可用於輸出時。當序列核心實際暫停連接埠時，會釋放參考，以便時鐘提供者可以對時鐘樹進行門控。（CVE-2026-90338）

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

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

  - mailbox： qcom-cpucp：修正 IRQ 處理常式 qcom_cpucp_mbox_irq_fn（） 呼叫 mbox_chan_received_data（） 中的PREEMPT_RT自我鎖死，同時保持 chan->lock。在PREEMPT_RT下，spin_lock_irqsave（） 被轉換為 rt_spinlock（基於 rtmutex），它追蹤所有權並可以休眠。mbox_chan_received_data（） 觸發的回呼鏈最終到達 mailbox_clear_channel（） -> mbox_send_message（） -> add_to_rbuf（），後者試圖重新取得相同的 chan->lock。由於 rtmutex 偵測到同一所有者的重新進入鎖定嘗試，因此執行緒會阻止等待它已經持有的鎖定，從而導致永久鎖死。此鎖死表現為「irq/N-apss_cpucp_mbox」卡在 D 狀態，並具有以下呼叫追蹤： rt_spin_lock -> mbox_send_message -> mailbox_clear_channel -> scmi_rx_callback -> mbox_chan_received_data [<- held chan->此處鎖定] 透過將 chan->cl 儲存在本機並清除鎖定內的硬體中斷暫存器，然後在釋放鎖定後呼叫 mbox_chan_received_data（） 來修正。這保留了 chan->cl 存取的相互排除，同時避免了導致 PREEMPT_RT 鎖死的鎖定重新進入。（CVE-2026-90193）

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

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

  - bpf：複製 copy_map_value_long（） 中的 per-CPU 對應值填充 在核心中，每個 CPU 對應元素以 round_up（map->value_size， 8） 個位元組儲存。在 UAPI 查詢路徑上，它會將每個 CPU 的四捨五入大小複製到暫存緩衝區中。但是，copy_map_value_long（） 會將 'map->value_size' 傳遞給 bpf_obj_memcpy（）。當映射有特殊欄位時，bpf_obj_memcpy（） 會使用 memcpy（） 複製這些欄位，並且不會複製 'map->value_size' 和 round_up 之間的尾部填充 （map->value_size， 8）。臨時 UAPI 查閱緩衝區的配置無需__GFP_ZERO。因此，當每個 CPU 對應的值大小不等於 round_up （map->value_size， 8） 時，UAPI LOOKUP_ELEM及其變體可以將過時的堆積內容從該填補傳回使用者空間。同樣的問題也適用於每個 CPU 對應的bpf_iter。將 round_up（map->value_size， 8） 從 copy_map_value_long（） 傳遞給 bpf_obj_memcpy（），因此有或沒有特殊欄位的 per-CPU 映射會複製整個 per-CPU 插槽。從 bpf_obj_memcpy（） 的long_memcpy路徑中移除現在多餘的 round_up（）。（CVE-2026-93174）

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

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

  - HID： 觸覺：不要將未初始化的值寫入未處理的使用方式 fill_effect_buf（） 只會初始化其開關處理的四個觸覺使用方式的值，但會針對每次使用將其寫入 field->value[]。因此，未處理的使用量可以接收未初始化的值，或先前使用量所剩下的值。然後，hid_output_report（） 會將該值序列化到效果的報告緩衝區中。請改為跳過未處理的使用方式。這也符合 switch_mode（），後者僅更新其識別的欄位。使用 Clang 的 -Wconditional-uninitialized 找到。（CVE-2026-90197）

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

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

  - iommu/amd： 修正 debugfs 函式中未定義devid_write行為 當 for_each_pci_segment（） 迴圈完成而找不到相符的區段時，pci_seg指標不是 NULL，而是指向無效的記憶體位置 （清單頭）。在迴圈之後存取 pci_seg->id 會導致未定義的行為。透過在迴圈內處理成功案例並在迴圈後傳回 -EINVAL （如果找不到相符的區段） 來修正此問題。（CVE-2026-92505）

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

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

  - spi： oc-tiny：切換至受管理控制器配置 當中斷向 devm_request_irq（） 登錄中斷時，控制器會使用非受管理 spi_alloc_host（） 配置。在移除期間，spi_bitbang_stop（） 只會取消註冊控制器;接著，後續的 spi_controller_put（） 會釋放控制器及其內嵌驅動程式私有 devdata，這是 IRQ 處理常式的dev_id。清空處理常式的 devm_request_irq（） 釋放動作 （free_irq（）） 要等到 .remove（） 傳回之後才會執行。因此，延遲或閂鎖的中斷可以到達 tiny_spi_irq（） 並取消參照已經釋放的記憶體（例如 hw->base）。切換到 devm_spi_alloc_host（），以便 devres LIFO 命令只有在 free_irq（） 耗盡處理常式後才釋放控制器，並從 .remove（） 中刪除現在冗餘的 spi_controller_put（）。探測錯誤路徑已簡化為直接傳回。此問題是由內部靜態分析工具發現的。（CVE-2026-90433）

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

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

  - USB：LJCA：ljca_enumerate_gpio（） ljca_enumerate_gpio（） 中的綁定 bank_num 從裝置讀取 desc->bank_num 並迴圈 valid_pin[i] = get_unaligned_le32（...） 用於 i < bank_num。 valid_pin[] 僅容納 LJCA_MAX_GPIO_NUM / 32 = 2 個項目。在迴圈之前會執行兩個檢查。回覆長度必須符合 struct_size（desc， bank_desc， bank_num）。產品pins_per_bank*bank_num不得超過LJCA_MAX_GPIO_NUM。兩者都沒有針對 的 valid_pin[]大小來限制bank_num。回覆的上限為 LJCA_MAX_PAYLOAD_SIZE （60） 個位元組，因此struct_size檢查將bank_num限制為 9。以 pins_per_bank 7 報告 bank_num 9 的裝置仍會通過這兩項檢查。gpio_num是 63，回覆是 56 位元組。然後，迴圈會將九個 u32 寫入兩個輸入陣列，並在堆疊上溢位 valid_pin[] 。因此，損毀或惡意的 LJCA 裝置可能會使堆疊溢位。拒絕不適合 valid_pin[]的bank_num。
    (CVE-2026-93119)

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

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

  - bpf：修正 bpf_netns_link_update_prog 中潛在的 UAF 在 bpf_netns_link_update_prog 中，old_prog 和 prog 類型的檢查目前在取得 netns_bpf_mutex 之前以無鎖定方式執行。這會產生爭用情形，進而導致 UAF 問題。如果兩個執行緒在同一個 netns 連結上同時執行 BPF_LINK_UPDATE，則以下執行路徑可以觸發 UAF：CPU0、CPU1 bpf_netns_link_update_prog if （old_prog &; &; old_prog ！= link->prog） return -EPERM;bpf_netns_link_update_prog if （old_prog & old_prog ！= link->prog） ...old_prog = xchg（&link->prog， new_prog）;bpf_prog_put（old_prog）;if （new_prog->type ！= link->prog->type） <-- trigger UAF Fix this by moving the old_prog and prog->類型檢查netns_bpf_mutex。同時，使用 guard（） 來簡化鎖定管理並避免所有 goto 跳轉。（CVE-2026-90393）

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

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

  - drm/amd/display：修正 DM I2C 拆解爭用 DM I2C 介面卡可以在 DM 拆解過程中保持對使用者空間可見。在備份 DM 狀態被拆除後，並行 i2c-dev 傳輸可能會進入 amdgpu_dm_i2c_xfer（），從而導致 NULL 指標解除參照。圍繞 DM I2C 配接器生命週期建立一個 devres 群組，並在 dm_hw_fini（） 開始時釋放它，然後再拆除 HPD、IRQ 和 DM 狀態。這會先移除 I2C 配接器，並等待飛行中的使用者耗盡，然後 amdgpu_dm_i2c_xfer（） 使用的結構消失。這修正了在移除裝置期間發現的拆卸排序爭用： 錯誤：核心 NULL 指標解除參照 RIP：amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] 呼叫追蹤：
    __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr （CVE-2026-93068）

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

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

  - USB： atm： usbatm：修正無效的 ci_range 初始化 syzbot 報告
    __vcc_connect（）：UBSAN：net/atm/common.c：382：32 移位指數 -1 為負 CPU：
    0 UID： 0 PID： 5987 通訊： syz.0.18 未受污染 syzkaller #0 PREEMPT（full） 硬體名稱：Google Compute Engine/Google Compute Engine、BIOS Google 2026 年 8 月 5 日 呼叫追蹤： <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c：120 ubsan_epilogue+0xa/0x30 lib/ubsan.c：233
    __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c：494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c：382 vcc_connect+0x328/0x8f0 net/atm/common.c：498 pvc_bind+0x272/0x380 net/atm/pvc.c：52
    __sys_bind+0x2e3/0x410 net/socket.c：1976 __x64_sys_bind+0x7a/0x90 net/socket.c：1979 ... ATM裝置ci_range欄位（vpi_bits和vci_bits）表示裝置上VPI和VCI定址支援的位數。net/atm/common.c 直接使用這些欄位作為位元移位計數： vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init（） 將 ci_range.vpi_bits 和 ci_range.vci_bits 設定為 ATM_CI_MAX （-1），這在 <uapi/linux/atmdev.>h 中定義為使用者空間ATM_SETCIRANGE要求的哨兵值， 不是有效的位元計數。移位 -1 是未定義的行為，會觸發 UBSAN 警告。ATM UNI 儲存區接頭允許 VPI （0..255） 最多使用 8 位，VCI （0..65535） 最多允許 16 位。將 vpi_bits 初始化為 8，將 vci_bits 初始化為 16，如 solos-pci 所完成。（CVE-2026-90055）

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

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

  - tpm： st33zp24：讀取失敗狀態時傳回零 st33zp24_status（） 會忽略傳輸讀取的結果，即使未收到任何位元組也傳回資料。例如，當暫存器選擇寫入短或失敗時，I2C 傳輸會跳過 i2c_master_recv（），使資料未初始化。產生的堆疊值可以解譯為TPM_STS旗標，並讓狀態檢查以虛假方式完成。狀態回呼無法傳播傳輸錯誤。除非 recv（） 只報告一個位元組，否則傳回零。
    未設定狀態位元的情況下，呼叫端會重試或採用現有的逾時或錯誤路徑，而不是處理無效的狀態值。此問題由靜態分析檢查程式發現，並經手動來源檢閱確認。（CVE-2026-90070）

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

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

  - wifi： ath12k：修正 AP vdev 復原 ath12k_mac_vdev_create（） 上dp_link_peer懸空參照 vdev 透過 ath12k_peer_create（） 建立 bss self-peer，最後呼叫 ath12k_dp_link_peer_assign（） 將 dp_link_peer 發佈在 dp_hw->dp_peers[peerid_index] RCU 表格中，在 dp_peer 的 link_peers[] 陣列中， 以及在 per-addr rhashtable 中。如果 ath12k_peer_create（） 之後的步驟失敗，函數會跳轉到 err_peer_del，這會對 WMI peer_delete進行開放編碼並等待取消映射/delete_resp事件。wait_for_peer_delete_done（） 路徑依賴於 ath12k_dp_link_peer_unmap_event（） 在取消映射到達時釋放dp_link_peer，但err_peer_del絕不會先呼叫 ath12k_dp_link_peer_unassign（）。dp_hw RCU 表格、dp_peer->link_peers[] 和 rhashtable 中已發佈的參照會指向unmap_event然後釋放的dp_link_peer，在後續查詢中產生懸空指標和釋放後使用。將開放編碼序列替換為對 ath12k_peer_delete（） 的呼叫，該呼叫在傳送 WMI 命令之前已經執行了 ath12k_dp_link_peer_unassign（）。這會在釋放dp_link_peer之前刪除已發佈的參照，順序與 ath12k_mac_remove_link_interface（） 中的正常拆卸路徑相同。測試對象： WCN7850 hw2.0 PCI WLAN。HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 （CVE-2026-93094）

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

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

  - vxlan：修正讀取 neigh ha 目前 arp/neigh_reduce直接讀取 neigh ha，這可能會導致更新 neigh 時出現部分讀取。使用 neigh_ha_snapshot 拍攝地址的穩定快照，類似於 route_shortcircuit，它已經執行了正確的操作。（CVE-2026-90105）

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

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

  - nvme-apple：移除時銷毀管理佇列 管理佇列使用 blk_mq_alloc_queue（） 配置，但從未銷毀。nvme_free_ctrl（） 只會刪除最後一個參照，而 blk_mq_exit_queue（） 和 blk_sync_queue（） 永遠不會執行：HCTX 永遠不會移動到 Q->unused_hctx_list，逾時計時器和工作保持在即將釋放的佇列上，該佇列最終會在 blk_mq_timeout_work（） 中失敗。
    這只有在控制器無法啟動然後立即再次被拆除時才能觸發，這就是為什麼以前沒有人遇到過這種情況。讓我們複製 PCIe 驅動程式的執行方式：在 nvme_uninit_ctrl（） 之前取消靜默並銷毀管理佇列。這樣，就不會再發生下列警告後再發生錯誤： 警告：block/blk-mq.c：4390 at blk_mq_release+0x194/0x238， CPU#4： kworker/u34：4/119 CPU：
    4 UID：0 PID：119 通訊：kworker/u34：4 未受污染 7.2.0-rc1-dirty #248 PREEMPT 硬體名稱：Apple Mac mini （M1， 2020） （DT） 工作佇列：nvme-wq apple_nvme_remove_dead_ctrl_work 狀態：61400005 （nZCv daif +PAN
    -UAO -TCO +DIT -SSBS BTYPE=--） pc ： blk_mq_release+0x194/0x238 lr ： blk_mq_release+0x58/0x238 sp ：
    ffffc000833a3b50 x29： ffffc000833a3b50 x28： ffff80001d0450f8 x27： ffff800020c95200 x26： 0000000000000088 x25： 0000000000000000 x24： ffff800020f36805 x23： 00000000000000000 x22： ffffc00081a86878 x21：
    ffff800020be9c60 x20： 000000000000000000 x19： ffff800022501698 x18： 000000000000000a x17： 7365757165722066 x16： 666f7265776f7020 x15： 0000000000000000 x14： 0000000000000028 x13： 0000000000004def x12：
    0000000000000003 x11： 0000000000000000 x10： 0000000000000000 x9 ： ffffc000805b4fc8 x8 ： ffffc00081915820 x7 ： ffffc00081c4f3c8 x6 ： 0000000000000001 x5 ： 0000000000000004 x4 ： ffff800022498d80 x3 ：
    ffffc000833a3b14 x2 ： 0000000000000000 x1 ： 000000000000000000 x0 ： ffff800022501698 呼叫追蹤：
    blk_mq_release+0x194/0x238 （P） blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 IRQ 事件戳記： 448 hardirq 上次啟用時間為 （447）：in_unlock_irqrestore+0x74/0x80 hardirq 上次停用時間為 （448）： [<ffffc000811cf5c0>] el1_brk64+0x20/0x60 softirq 上次啟用時間為 （0）： [ess+0xb28/0x2698 softirq 上次停用時間為 （0）：
    [<0000000000000000>] 0x0 ---[ 結束追蹤 0000000000000000000 無法處理虛擬位址 0000000000000000000 的核心 NULL 指標解除參照 記憶體中止資訊：ESR = 0x0000000096000005 EC = 0x25：DABT （目前 EL）、SET = 0、FnV = 0 EA = 0、S1PTW = 0 FSC = 0x05：1 級轉換錯誤 資料中止資訊：ISV = 0、ISS = 0x00000005、ISS2 = 0x00000000 CM = 0、WnR = 0、TnD = 0、TagA GCS = 0、 Overlay = 0， DirtyBit = 0， Xs = 0 [0000000000000000] 使用者位址 內部錯誤：哎呀：0000000096000005 [#1] SMP CPU：7 UID：0 PID：54 Comm：kwor 7.2.0-rc1-dirty #248PREEMPT Tainted：[W]=WARN 硬體名稱：Apple Mac mini （M1， 2020） （DT） 工作佇列：kblockd blk_mq_timeou pstate：01400005 （nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--） pc：
    percpu_ref_tryget_many.cons lr：percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp：ffffc000829cbce0 x29：
    ffffc000829cbce0 x28： ffff800020be9f48 x27： ffff800013e503c0 x26： 0000000000000108 x25： 000009c05 x23：
    0000000000000000 x22：ffffc000819f5000 x21：ffff800020be9f48 x20：ffff8001deda4808 x19：ffff8000a x17：
    00000000580e1fac x16： ffffc00082bbbb7c x15： 000000000000000000000 x14： 0000000000000028 x13： 000000001 x11：
    000000000000000000 x10： 0000000000000000 x9 ： ffffc000829cbc20 x8 ： ---truncated--- （CVE-2026-90229）

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

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

  - drm/bridge： tc358767：將報告的 AUX 讀取大小限制為要求 tc_aux_transfer（） 將 AUX 讀取限制為有效負載限制：size_t size = min_t（size_t， DP_AUX_MAX_PAYLOAD_BYTES - 1， msg->size）;傳輸後，它將 size 替換為控制器以 AUX_BYTES 報告的位元組計數：if （size） size = FIELD_GET（AUX_BYTES， auxstatus）;AUX_BYTES是 GENMASK（15， 8），因此最多可以是 255。沒有任何東西可以將其限制回請求。tc_aux_read_data（） 會將這麼多位元組讀取到 16 位元組 auxrdata 堆疊緩衝區中，然後將它們複製到呼叫端緩衝區中。報告的計數為 255 會使讀取執行至 256 位元組，並同時溢位兩者。控制員報告的次數永遠不應該超過要求轉移的次數，因此這是縱深防禦，而不是活洞。報告的計數只是輕微的信任，而且支票很便宜。將其限制回請求，就像 ti-sn65dsi86 在提交 aca58eac52b8 中所做的那樣（drm/bridge：ti-sn65dsi86：切勿在 AUX xfer 中儲存超過 msg->size 位元組）。（CVE-2026-93067）

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

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

  - ksmbd：在取消參照 IPC 欄位之前驗證 IPC 回應長度 ipc_validate_msg（） 會從使用者空間 ksmbd 精靈 （payload_sz、session_key_len、ngroups 等） 提供的回應緩衝區中讀取長度欄位，以計算預期的訊息大小。在驗證緩衝區足夠大以包含它們所屬的結構之前，會讀取這些欄位，因此簡短的回應會使讀取超出配置的結尾。handle_response（） 純粹根據 netlink 屬性長度 （nla_len（）） 調整 entry->response 大小，並且僅保護讀取的前導句柄，因此常駐程式可以安裝與下面所示的 kmalloc-8 物件一樣小的回應。當 ipc_msg_send_request（） 接著呼叫 KSMBD_EVENT_RPC_REQUEST 的 ipc_validate_msg（） 時，結構 ksmbd_rpc_command 的轉換會在 8 位元組配置的偏移 8 處讀取 resp->payload_sz： [ 3697.841381] ================================================================== [3697.844099] 錯誤：KASAN：ipc_msg_send_request+0x763/0x800 中的 slab-out-of-bounds [ 3697.846604] 由任務 kworker/4:3/20682 在 addr ffff888105f95910 讀取大小 4 [ 3697.849061] [ 3697.849801] CPU： 4 UID：0 PID：
    20682 Comm： kworker/4:3 未受污染 7.2.0-rc3-next-20260717-virtme #117 PREEMPT（lazy） [ 3697.850077] 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [3697.850303] 工作佇列：ksmbd-io handle_ksmbd_work [ 3697.850592] 呼叫追蹤：[ 3697.850794] [<TASK>3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ？ ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ？ down_write+0x146/0x1f0 [3697.852809] ？ ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [3697.853385] ？ __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ？ kasan_unpoison+0x48/0x70 [3697.853936] ？ __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ？
    __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ？ kasan_unpoison+0x48/0x70 [ 3697.854962] ？ copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ？ kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ？ __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ？ __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ？ __sanitizer_cov_trace_switch+0x7b/0x140 [3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ？ __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ？ get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ？
    __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ？ lock_release+0xf7/0x360 [ 3697.858466] ？ process_scheduled_works+0x954/0x1600 [ 3697.858698] ？ process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ？ __pfx_process_scheduled_works+0x10/0x10 [3697.859637] ？ __pfx_assign_work+0x10/0x10 [ 3697.859896] ？ lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ？ __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ？
    __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ？
    __pfx_worker_thread+0x10/0x10 [ 3697.861643] ？ __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ？ __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ？
    __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] </TASK> [ 3697.863039]3697.938882 [] 依任務 20761 分配： [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782]
    __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3
    ---truncated--- (CVE-2026-90170)

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

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

  - 韌體：arm_scmi：還原 P2A 接收者信箱設定失敗 mailbox_chan_setup（） 可以在成功取得主要 P2A 通道之後要求額外的 P2A 接收者通道。如果稍後的要求失敗，函式會立即傳回，並保留主要通道的配置。在傳回錯誤之前，先解除主要信箱通道，讓探查延遲或其他設定失敗不會讓通道忙碌，以便稍後的探查嘗試。（CVE-2026-93082）

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

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

  - dax/fsdev：綁定靜態 pgmap 時清除 vmemmap_shift 清除靜態 DAX 裝置的 pgmap->vmemmap_shift。將靜態裝置從 device_dax （可能會根據對齊方式設定 vmemmap_shift） 重新綁定為 fsdev_dax 時，過時的vmemmap_shift會持續存在於共用 pgmap 上。在 devm_memremap_pages（） 之前明確將其歸零，以便按照 fsdev 的要求為 order-0 對開本構建 vmemmap。（CVE-2026-93076）

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

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

  - ext4：在緩衝寫入後援 generic/746 開始在 ext3 （無範圍 inode） 上間歇性失敗之前，排空進行中的 DIO。此測試會觸發「直接 I/O 時頁面快取無效失敗」警告，後續 fsync 傳回 -EIO。在 ext4_dio_write_iter（） 中的 ext4_buffered_write_iter（） 和 filemap_write_and_wait_range（） 之間添加 50 毫秒的延遲，使爭用幾乎總是可重現的。在無範圍 inode 上，DIO 寫入漏洞無法使用未寫入的範圍，因此 ext4_iomap_alloc（） 會留下 m_flags=0，而 ext4_map_blocks（） 會傳回 0。然後，iomap 層會傳回 -ENOTBLK，導致後援至緩衝的 I/O。
    ext4_dio_write_iter（） 中的後援路徑會呼叫 ext4_buffered_write_iter（），這會使頁面變髒，然後進行排清並失效。但是，在 ext4_buffered_write_iter（） 傳回（釋放 inode 鎖定）和後續的 flush+invalidate 之間有一個不受保護的窗口。在此時段內，來自其他執行緒的並行非同步 DIO 完成可以執行 kiocb_invalidate_post_direct_write（）。如果頁面已重新變髒，則無效後會尋找變髒頁面並觸發警告，在錯誤序列中設定 -EIO。
    考慮一個具有兩個 4k 範圍的檔案：[hole][written]。執行緒 A 在寫入的範圍內執行 DIO，而執行緒 B 執行跨越兩者的 DIO： kworker A （4k DIO，分配的區塊） kworker B （8k DIO，後援）
    ----------------------------------- ---------------------------- inode_lock_shared（） inode_lock_shared（） iomap_dio_rw（）： iomap_dio_rw（）： kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio （非同步） dio->size = 0 inode_unlock_shared（） inode_unlock_shared（） [區塊層中的生物待處理] /* 後援：鎖定已釋放 */ ext4_buffered_write_iter（） inode_lock（獨佔） generic_perform_write（） -> 髒頁面 [0， 8k] inode_unlock（獨佔） /* 髒頁面， 無鎖定 */ [bio completes] filemap_write_and_wait_range（） iomap_dio_complete（） -> 排清髒頁面 kiocb_invalidate_post_direct_write（） invalidate_mapping_pages（） invalidate_inode_pages2_range（） -> 找到髒頁面！-> dio_warn_stale_pagecache（） -> errseq_set（-EIO） 此問題可以透過正常的 I/O 路徑觸發，而不僅僅是故意從使用者空間重疊 DIO 寫入。例如，generic/746 使用迴圈裝置，其中多個 kworker 向備份檔案發出並行 I/O。此外，block_size < folio_size時，共用大型對開本的非重疊 DIO 寫入也會觸發爭用。在 ext4_write_checks（） 之前在 ext4_buffered_write_iter（） 中新增 inode_dio_wait（），以清空所有正在進行的 DIO。這可確保所有 DIO 在提交 IO 之前清除現有頁面（透過 kiocb_invalidate_pages（）），所有 BIO 等待所有 DIO 完成（透過 inode_dio_wait（）），並且 ext4_write_checks（） 在所有完成 DIO 後觀察 inode 大小，以便 ext4_block_zero_eof（） 不會與正在進行的 DIO 爭用，從而消除爭用。（CVE-2026-92501）

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

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

  - null_blk：拒絕針對共用標籤集調整每個裝置佇列大小 啟用shared_tags後，null_setup_tagset（） 會讓裝置使用全域tag_set，其 driver_data 維持為 NULL。
    因此，null_map_queues（） 會回歸到模組範圍的 g_submit_queues/g_poll_queues，而不是任何每個裝置的值。在此類裝置上透過 configfs 調整submit_queues或poll_queues大小會呼叫共用集上的 blk_mq_update_nr_hw_queues（），從而縮小 set->nr_hw_queues。__blk_mq_realloc_hw_ctxs（） 只會增加 q->queue_hw_ctx[] 分配，因此在 shrink 時，它只會退出並對現在多餘的 hctx 插槽設為 NULL。 然而，null_map_queues（） 會持續將 CPU 與未變更的 g_submit_queues/g_poll_queues 對應，因此 mq_map[] 最終會指向那些 NULL 的 hctx 插槽。 blk_mq_map_swqueue（） 接著會解除參照 NULL hctx （hctx->cpumask）， 核心當機： [ 460.218374] KASAN： null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU： 24 UID： 0 PID： 1492 Comm： sh 未受污染 7.2.0-rc2+ #67 PREEMPT（full） [ 460.219792] 硬體名稱： QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP： 0010：blk_mq_map_swqueue+0x4db/0x1430 ......[ 460.228977] 呼叫追蹤：[ 460.229175] [ <TASK>460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ？
    __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ？
    __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ？ configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ？ __x64_sys_openat+0x108/0x1d0 [ 460.233106] ？
    __pfx_vfs_write+0x10/0x10 [ 460.233413] ？ fdget_pos+0x1cf/0x4c0 [ 460.233745] ？ fput_close+0x133/0x190 [460.234038] ？ __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 再現器：modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues 無論如何，每個裝置調整共用標籤集的大小是沒有意義的， 因此，當設備綁定到全域tag_set時，請在 nullb_update_nr_hw_queues（） 中使用 -EINVAL 拒絕它。（CVE-2026-90186）

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

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

  - 藍牙：當第二個 LE 連接被拒絕時，不要洩露hci_conn create_le_conn_complete（） 會將失敗的連接與 hci_lookup_le_connect（） 進行比較，以決定失敗的連接是否仍處於擱置狀態，（） 會傳回 BT_CONNECT 中的第一個 LE 連接。這是相同的連接，只有最多一個處於待處理狀態。兩個可能正在等待中。在被動掃描路徑上建立的連線會BT_CONNECT設定HCI_CONN_SCANNING，在 hci_le_create_conn_sync（） 發出指令時清除旗標之前，hci_lookup_le_connect（） 看不到，因此 hci_connect_le（） 中的 -EBUSY 防護不會防止第二個連線在第一個連線仍在掃描路徑上時排入佇列。每當兩個連線同時BT_CONNECT時，查詢可能會傳回一個連線，而 create_le_conn_complete（） 則報告另一個連線的失敗;然後，提前結束會刪除錯誤，並且 hci_conn_failed（） 永遠不會在失敗的連線上運行。根據核心規格第 4 卷 E 部分，控制器還拒絕在另一個連接創建仍未完成的情況下發出的第二個HCI_OP_LE_CREATE_CONN。該規範要求在那裡禁止命令;此處觀察到的 bcm43438 以 LMP/LL 錯誤代碼回答，該錯誤代碼bt_to_errno（） 映射到下面日誌中的 -EPROTO （-71）。洩漏的連線將永遠保留在BT_CONNECT中，並且由於 hci_connect_le（） 拒絕撥號，而 hci_lookup_le_connect（） 找到任何內容，因此每次後續嘗試連線任何對等體都會以 -EBUSY 失敗，並且根本沒有命令到達控制器。在 bcm43438 上看到，兩個 BLE 對等體以相同的間隔輪詢（狀態 5 為 BT_CONNECT，兩個控制點都是 UNSET 控制點，從上面的 ida 分配 HCI_CONN_HANDLE_MAX）：藍牙：hci1：操作碼0x2013失敗：-71 # hcitool con < LE 14：9C：EF：03：68：81 handle 3840 狀態 5 lm CENTRAL < LE C4：D3：6A：8C：B5：38 處理 3841 狀態 5 lm CENTRAL 在接下來 10 分鐘的連接嘗試中捕獲的 btmon 完全不包含任何HCI_OP_LE_CREATE_CONN;在重設配接卡之前，送出 LE 連線不會回復。使用此變更後，相同的案例會完全失敗，拒絕的連線會完全失敗，並進一步連線到兩個對等體。詢問連接本身而不是設備。（CVE-2026-90087）

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

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

  - phy： qcom： snps-femto-v2： 修正早期執行階段暫停時可能的 NULL 解除參照 在建立 PHY 之前，必須啟用執行階段 PM，因為 phy_create（） 只會在此父裝置上啟用執行階段 PM。不過，執行階段 PM 回呼會取消參照尚未準備就緒的 hsphy 實例，留下暫停回呼可能會觸發 NULL 指標解除參照的視窗。在啟用執行階段 PM 之前，使用 pm_runtime_get_noresume（） 取得執行階段 PM 使用參考，並在建立 PHY 之後釋放它，以便在 PHY 準備就緒之前無法執行執行階段暫停。這也可防止可能發生不必要的執行階段暫停的短時段。使用 devres 管理的版本，確保在移除驅動程式期間對稱停用 PM 執行階段，以便正確清除。（CVE-2026-90281）

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

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

  - arm64/efi：避免在安裝efi_mm自願搶佔 在支援 EFI 執行階段服務的機器上使用軟體 PAN （CONFIG_ARM64_SW_TTBR0_PAN=y） 時，Gus 報告核心記憶體存取錯誤：
    無法處理虛擬位址 000000000f322ff30 上 uaccess 常式之外的使用者記憶體的核心存取 記憶體中止資訊：ESR = 0x0000000096000004 FSC = 0x04：等級 0 轉換錯誤 內部錯誤：哎呀：
    0000000096000004 [#1] SMP 工作佇列：efi_rts_wq efi_call_rts狀態：80400005 （Nzcv daif +PAN -UAO -TCO
    -DIT -SSBS BTYPE=--） pc ： efi_call_rts+0xd8/0x288 呼叫追蹤：efi_call_rts+0xd8/0x288 （P） process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 這是因為從 __efi_fpsimd_begin（） 呼叫的 fpsimd 上下文管理程式碼可以自願搶佔，稍後返回 EFI 程式碼，並具有不正確的 TTBR0_EL1 值，這要歸功於軟體 PAN 實作使用的延遲 mm 切換。
    由於 EFI 執行階段服務無法自願搶佔，而且 fpsimd 切換程式碼不依賴 TTBR0_EL1 對應，因此只需重新排序 fpsimd 切換，以便在我們變更頁面表格之前發生。（CVE-2026-90212）

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

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

  - NFC：pn533：在 send_frame __pn533_send_async（） 發佈命令，然後呼叫 dev->phy_ops->send_frame（） 期間保留對要求 skb 的參照。設定 dev->cmd 後，傳入的框架可以與此命令相符：I2C 執行緒 IRQ 運行 pn533_recv_frame（），它將cmd_complete_work排入佇列，而 pn533_send_async_complete（） 則使用 consume_skb（） 釋放 cmd->req。在 I2C 傳輸上，pn533_i2c_send_frame（） 在 i2c_master_send（） 傳回後仍會解除參照相同的 skb，因此爭用傳送的完成可以在傳輸仍在使用 skb 時釋放 skb。要求 skb 由命令物件所擁有，而且可以在發佈 dev->cmd 之後隨時透過命令完成來釋放，因此傳輸傳送路徑不得假設它保持作用中。在 send_frame（） 呼叫中保留對要求 skb 的臨時參照，以便傳輸始終看到即時 skb，即使完成與發送爭用也是如此。新增 pn533_send_cmd_frame（） 協助程式，並從所有三個傳送路徑使用它。（CVE-2026-90222）

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

ID	名稱	嚴重性
347649	Linux Distros 未修補弱點：CVE-2026-90209	high
347648	Linux Distros 未修補弱點：CVE-2026-93069	high
347647	Linux Distros 未修補弱點：CVE-2026-90207	high
347646	Linux Distros 未修補弱點：CVE-2026-93048	medium
347645	Linux Distros 未修補弱點：CVE-2026-90269	medium
347644	Linux Distros 未修補弱點：CVE-2026-90401	high
347643	Linux Distros 未修補弱點：CVE-2026-90202	medium
347642	Linux Distros 未修補弱點：CVE-2026-93172	medium
347641	Linux Distros 未修補弱點：CVE-2026-90121	medium
347640	Linux Distros 未修補弱點：CVE-2026-90385	high
347639	Linux Distros 未修補弱點：CVE-2026-90062	high
347638	Linux Distros 未修補弱點：CVE-2026-90336	high
347637	Linux Distros 未修補弱點：CVE-2026-90389	high
347636	Linux Distros 未修補弱點：CVE-2026-93181	medium
347635	Linux Distros 未修補弱點：CVE-2026-93157	low
347634	Linux Distros 未修補弱點：CVE-2026-93162	medium
347633	Linux Distros 未修補弱點：CVE-2026-90150	medium
347632	Linux Distros 未修補弱點：CVE-2026-90332	high
347631	Linux Distros 未修補弱點：CVE-2026-90249	medium
347630	Linux Distros 未修補弱點：CVE-2026-93105	high
347629	Linux Distros 未修補弱點：CVE-2026-90060	high
347628	Linux Distros 未修補弱點：CVE-2026-92490	high
347627	Linux Distros 未修補弱點：CVE-2026-90093	high
347626	Linux Distros 未修補弱點：CVE-2026-93109	high
347625	Linux Distros 未修補弱點：CVE-2026-93135	medium
347624	Linux Distros 未修補弱點：CVE-2026-90226	high
347623	Linux Distros 未修補弱點：CVE-2026-90338	high
347622	Linux Distros 未修補弱點：CVE-2026-90193	medium
347621	Linux Distros 未修補弱點：CVE-2026-93174	high
347620	Linux Distros 未修補弱點：CVE-2026-90197	medium
347619	Linux Distros 未修補弱點：CVE-2026-92505	medium
347618	Linux Distros 未修補弱點：CVE-2026-90433	medium
347617	Linux Distros 未修補弱點：CVE-2026-93119	medium
347616	Linux Distros 未修補弱點：CVE-2026-90393	high
347615	Linux Distros 未修補弱點：CVE-2026-93068	medium
347614	Linux Distros 未修補弱點：CVE-2026-90055	medium
347613	Linux Distros 未修補弱點：CVE-2026-90070	low
347612	Linux Distros 未修補弱點：CVE-2026-93094	high
347611	Linux Distros 未修補弱點：CVE-2026-90105	high
347610	Linux Distros 未修補弱點：CVE-2026-90229	high
347609	Linux Distros 未修補弱點：CVE-2026-93067	high
347608	Linux Distros 未修補弱點：CVE-2026-90170	high
347607	Linux Distros 未修補弱點：CVE-2026-93082	medium
347606	Linux Distros 未修補弱點：CVE-2026-93076	high
347605	Linux Distros 未修補弱點：CVE-2026-92501	medium
347604	Linux Distros 未修補弱點：CVE-2026-90186	medium
347603	Linux Distros 未修補弱點：CVE-2026-90087	medium
347602	Linux Distros 未修補弱點：CVE-2026-90281	medium
347601	Linux Distros 未修補弱點：CVE-2026-90212	medium
347600	Linux Distros 未修補弱點：CVE-2026-90222	high

偵測

Nessus 的 Misc. 系列

high

high

high

medium

medium

high

medium

medium

medium

high

high

high

high

medium

low

medium

medium

high

medium

high

high

high

high

high

medium

high

high

medium

high

medium

medium

medium

medium

high

medium

medium

low

high

high

high

high

high

medium

high

medium

medium

medium

medium

medium

high