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

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

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

  - 在 Google go-attestation 中，輸入弱點中指定索引、位置或偏移的驗證不當。parseEfiSignatureList（） 不會在讀取項目之前將緩衝區推進超過供應商位元組。
    對於 hashSHA256SigGUID 清單，這允許將攻擊者控制的供應商標頭位元組附加到受信任 SHA256 的雜湊清單中。特製的 TPM 事件記錄可能會將任意 SHA256 雜湊注入驗證者的受信任測量資料庫，使遠端證明驗證者能夠接受受損的啟動狀態。
    此問題會影響 go-attestation：透過 0.6.0。（CVE-2026-12681）

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

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

  - ImageMagick 之前在 magick 命令 7.1.2-27 列介面中包含提供無效選項時的記憶體洩漏弱點。攻擊者可藉由重複提供格式錯誤的命令列引數來耗用系統資源，以觸發記憶體耗盡。（CVE-2026-66011）

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

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

  - Redis 之前 8.8.0，在經過驗證的攻擊者可以執行 RESTORE 的不尋常情況下，允許透過 RESTORE 承載執行遠端程式碼，其中多個消費者參照相同的 NACK （擱置項目），因為透過 XGROUP DELCONSUMER 刪除兩個消費者會導致雙重釋放。注意：此問題之所以存在，是因為 CVE-2026-25243 的修正不完整。(CVE-2026-66373)

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

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

  - net：nexthop：增加權重至 u16 在 CLOS 網路中，當網路中的各個點發生鏈路故障時，會調整相關節點的 ECMP 權重以進行補償。由於相關節點的扇出率很高，而且節點數量總數較多，因此我們想要設定的 （非） ECMP 權重比不適合 8 位元。我們可能想要配置類似 1000:999的 ，而不是 255:254。對於這些部署，8 位元權重可能不夠。為此，在此補丁中，將下一跳權重從 u8 增加到 u16。增加整數類型的寬度可能很棘手，因為當程式碼仍在編譯時，類型可能不再簽出，並且會出現數值錯誤。為了防止這種情況發生，轉換分兩個步驟完成。首先，類型從 u8 更改為單成員結構，這使得該字段的所有用途都無效。這允許逐一檢查它們並審核類型正確性。然後該結構再次被香草 u16 取代。這應該確保不會錯過任何位置。用於設定 nexthop 群組成員的 UAPI 是屬性NHA_GROUP攜帶結構nexthop_grp項目陣列： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重;
    /* 此 nexthop 的權重 */ __u8 resvd1;__u16 resvd2;};欄位 resvd1 目前已驗證，且必須為零。我們可以提升此要求，並在保留欄位中攜帶權重的高階位元： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重; /* 此 nexthop 的權重
    */ __u8 weight_high;__u16 resvd2;};選擇以這種方式分割欄位是為了防止現有使用者空間對權重欄位的寬度做出假設，並避免任何字節碼問題。
    權重欄位目前編碼為權重值減一，因為權重 0 無效。同樣的技巧對於新的weight_high場來說是不可能的，因為零必須意味著實際的零。有了這個： - 保證舊使用者空間承載 0 的weight_high，因此請視需要配置 8 位元權重。轉儲具有 16 位權重的 nexthop 時，它只會顯示較低的 8 位。但配置此類 nexthop 意味著首先存在意識到擴展的用戶空間。- 只要新使用者空間僅嘗試設定 8 位元權重（其中高階位元為零），即可與舊核心通訊。舊核心會退回設定 >8 位元權重的嘗試。在 Linux 中，通常會在為某些目的分配保留欄位時重新命名保留欄位。任何接觸保留場地的人都將自行承擔風險。特別是 nexthop_grp：：resvd1 目前至少由 strace 使用，但是它們帶有自己的 UAPI 標頭副本，並且轉換應該是微不足道的。提供了一個輔助程式來解碼兩個字段的權重。強制轉換似乎比向後彎曲並引入匿名聯合或其他什麼更可取。（CVE-2024-14040）

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

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

  - net/sched： cls_api：當碎片整理引擎保留 skb 時，tcf_qevent_handle tcf_classify（） 中的處理TC_ACT_CONSUMED可以傳回TC_ACT_CONSUMED （例如，act_ct無序片段）。發生這種情況時，skb 不再屬於呼叫者所有，不得再次觸摸。tcf_qevent_handle（） 未處理TC_ACT_CONSUMED：它通過交換器並將 skb 返回給調用方，就好像分類已通過一樣。今天唯一連接 qevents 的 qdisc 是 RED，通過三個調用站點（RED_PROB_MARK/HARD_MARK 上的 qe_mark，congestion_drop 上的qe_early_drop）red_enqueue（） 繼續在它不再擁有的 skb 上運行——將其排入隊列、刪除它或更新統計數據。
    導致 UAF。tc qdisc 新增 dev eth0 根控點 1：紅色 ...qevent early_drop區塊 10 tc 篩選器 新增區塊 10 ...動作 CT （啟用 CT 碎片整理和產生無序片段的流量，例如片段化的 UDP 資料流） 處理 tcf_qevent_handle（） 中的TC_ACT_CONSUMED，就像輸入和輸出快速路徑一樣：將其視為被盜，並在不接觸 skb 的情況下傳回 NULL。與TC_ACT_STOLEN情況不同，skb 不得在這裡丟棄/釋放，因為它不再屬於我們所有。（CVE-2026-64530）

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

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

  - 在轉寄訊息時剖析 MIME 標頭以供顯示的程式碼 （如果啟用了檢視所有標頭的設定） 出現差一錯誤，允許在標頭緩衝區之後的記憶體中讀取單一位元組，並可能使 Thunderbird 當機。此漏洞已在 Thunderbird 153 和 Thunderbird 140.13中修復。（CVE-2026-14899）

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

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

  - netfilter： ebtables：模組名稱必須以 null 終止我們需要明確檢查長度，否則我們可能會將非 null 終止的字串傳遞給 request_module（）。（CVE-2026-64412）

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

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

  - udf：根據 VAT inode 大小驗證 VAT 標頭長度 udf_load_vat（） 會直接從磁碟上的 VAT 2.0 標頭取得虛擬分割區的起始偏移量，而不針對 VAT inode 大小進行檢查：
    map->s_type_specific.s_virtual.s_start_offset = le16_to_cpu（vat20->lengthHeader）;
    map->s_type_specific.s_virtual.s_num_entries = （sbi->s_vat_inode->i_size - map->s_type_specific.s_virtual.s_start_offset） >> 2;lengthHeader 是一個完全由攻擊者控制的 16 位元值。如果它超過 VAT inode 大小，則s_num_entries減法將下溢到一個巨大的計數，這會破壞 udf_get_pblock_virt15（） 中> s_num_entries限制的區塊;在 ICB 內聯路徑上，該函數讀取 （（__le32 *）（iinfo->i_data + s_start_offset））[block]，因此大量s_start_offset索引超過 inode 的 ICB 內資料。然後，使用虛擬 （VAT） 分割區掛載特製的 UDF 映像檔會觸發越界讀取。拒絕標頭長度未為 VAT inode 內至少一個項目留出空間的 VAT。（CVE-2026-64323）

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

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

  - 藍牙：btusb：修正 marvell 探查失敗的釋放後使用 請務必在稍後的探查失敗時停止在 Marvell OOB 喚醒設定期間提交的任何 TX URB，以避免在完成回呼中發生釋放後使用。此問題是由 Sashiko 在檢閱 btusb 探查錯誤路徑中喚醒來源洩漏的修正時報告的。（CVE-2026-64470）

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

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

  - ACPI： NFIT： core：修正 acpi_nfit_init（） 錯誤清除 如果 acpi_nfit_init（） 在將 acpi_desc 物件新增至acpi_descs清單後失敗，則永遠不會從該清單中移除該物件，因為在此情況下，不會為 NFIT 裝置新增 acpi_nfit_shutdown（） devm 動作。接下來，acpi_nfit_init（） 失敗導致 acpi_nfit_probe（） 失敗，acpi_desc物件被釋放，並且acpi_descs中留下一個懸空指標。任何後續的 ACPI 電腦檢查例外狀況都會觸發 nfit_handle_mce（），反覆運算 acpi_descs，因此會發生釋放後使用。此外，如果 acpi_nfit_probe（） 在為 NFIT 裝置安裝通知處理常式後傳回 0，且未配置 acpi_desc 物件並設定 NFIT 裝置的驅動程式資料指標，則 acpi_desc 物件將由 acpi_nfit_update_notify（） 分配，並呼叫 acpi_nfit_init（） 來初始化它。在此情況下，無論 acpi_nfit_init（） 是否失敗，都不會為 NFIT 裝置新增 acpi_nfit_shutdown（） devm 動作，也永遠不會從acpi_descs清單中移除acpi_desc。如果acpi_desc物件隨後在驅動程式移除時釋放，則任何後續的 ACPI MCE 都會導致釋放後使用，如前一種案例所示。若要解決上述第一個問題，請在 acpi_nfit_init（） 失敗時直接進行 acpi_nfit_probe（） 呼叫 acpi_nfit_shutdown（），若要解決另一個問題，請將移除回呼新增至驅動程式，並使其呼叫 acpi_nfit_shutdown（） 。此外，由於現在可以將 NULL 傳遞給 acpi_nfit_shutdown（），或者傳給它的acpi_desc物件可能尚未初始化，因此請將 acpi_desc 及其nvdimm_bus欄位的 NULL 檢查新增至該函式，並在取消註冊 NVDIMM 匯流排後使 acpi_nfit_unregister（） 清除後者。CVE-2026-64510

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

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

  - 藍牙：btusb：修正註冊失敗時的釋放後使用 確保釋放同級介面，以防控制器註冊失敗，以避免在最終中斷連線時發生釋放後使用和雙重釋放。此問題是由 Sashiko 在檢閱 btusb 探查錯誤路徑中喚醒來源洩漏的修正時報告的。（CVE-2026-64471）

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

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

  - PCI/IOV：讀取錯誤時跳過 VF 可調整大小的 BAR 還原 sriov_restore_vf_rebar_state（） 會使用 VF 可調整大小的 BAR 控制暫存器來決定要還原的 VF BAR 數目 （nbars） ，以及每個反覆運算處理的 VF BAR （bar_idx）。bar_idx索引到 dev->sriov->barsz[]，其中只有 PCI_SRIOV_NUM_BARS （6） 個項目。當裝置沒有回應時，組態讀取通常會傳回 PCI_ERROR_RESPONSE （~0）。這兩個欄位的寬度均為 3 位元，因此 nbar 和 bar_idx 的計算結果均為 7。然後 barsz[] 存取就會越界。UBSAN 報告為： UBSAN： array-index-out-of-bounds 在 drivers/pci/iov.c：948：51 索引 7 超出類型「resource_size_t [6]」的範圍 在 NVIDIA RTX PRO 1000 GPU （GB207GLM） 上觀察到，該 GPU 在 GC6 電源狀態退出失敗期間停止回應。後續的 pci_restore_state（） 在配置讀取傳回 0xffffffff 時叫用了 sriov_restore_vf_rebar_state（），從而觸發了 splat。如果任何 VF 可調整大小的 BAR 控制項讀取傳回 PCI_ERROR_RESPONSE，則退出。不會再觸及 VF BAR，這是安全的，因為傳回 PCI_ERROR_RESPONSE 的組態讀取表示裝置無法連線，且還原毫無意義。這反映了 pci_restore_rebar_state（） 中的守衛。（CVE-2026-64460）

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

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

  - mm：swap_cgroup：修正無交換主機上 lookup_swap_cgroup_id 中的 NULL 解除參照 lookup_swap_cgroup_id（） 將 swap_cgroup_ctrl[type].map 傳遞給 __swap_cgroup_id_lookup（），而不檢查該類型是否曾經透過 swap_cgroup_swapon（） 註冊過。在無交換主機上，每個 ctrl->map 都是 NULL，因此 __swap_cgroup_id_lookup（） 取消參照 NULL + 縮放的 swp_offset（）。由於提交 bea67dcc5eea （mm：嘗試批次釋放 zap_pte_range（）） 的交換項目，因此 zap_pte_range（） -> swap_pte_batch（） 在任何不存在、非無 PTE 上呼叫 lookup_swap_cgroup_id（），該 PTE 解碼為真正的交換項目，而無需先根據 swap_info[]進行驗證。單一 PTE 損毀成類型 0 交換項目，會在處理程序結束時關閉主機。我們在無 6.12.58 交換主機上的生產中遇到了這個問題：~1s of get_swap_device：錯誤的交換文件條目 3f800204222bb（do_swap_page（） 對同一條目進行正確防禦）接著錯誤：無法處理地址的頁面錯誤：000003f800204220 RIP：0010：lookup_swap_cgroup_id+0x2b/0x60 調用跟踪：
    swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0 syzbot 報告了相同的堆疊。PTE 損毀的來源是一個單獨的錯誤;這項變更會讓拆卸路徑與故障路徑一樣健全。lookup_swap_cgroup_id（） 的所有其他呼叫端都是已驗證項目的 get_swap_device（） 的下游，因此新分支是冷的。（CVE-2026-64416）

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

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

  - ALSA： ice1712：檢查 snd_ctl_new1（） 傳回值 snd_ctl_new1（） 可以在記憶體配置失敗時傳回 NULL。ice1712 驅動程式在多個位置 （ice1712.c、ice1724.c、aureon.c） 取消參照指標之前，會呼叫 snd_ctl_new1（），而不檢查傳回值，這可能會導致 NULL 指標解除參照。
    在 snd_ctl_new1（） 呼叫後新增 NULL 檢查，如果有失敗，則傳回 -ENOMEM。（CVE-2026-64480）

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

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

  - KVM：arm64：排清 pKVM hyp vCPU 時綁定used_lrs flush_hyp_vcpu（） 會在每次執行時將主機 vGIC 狀態複製到 hyp 的私有 vCPU 中。vGIC 清單暫存器儲存及還原會使用 used_lrs 作為其迴圈界限，並預期它會保持在實作清單暫存器的數目內。雖然通常是這種情況，但 flush_hyp_vcpu（） 逐字複製vgic_v3並且不會強制執行此操作，因此主機提供的值在 EL2 上用於索引 vgic_lr[] 和存取 ICH_LR<n>_EL2 （主機 -> EL2）。透過將used_lrs限制在複製後實作的清單暫存器數量來修正，就像受信任路徑在 vgic_flush_lr_state（） 中已經做的那樣。實作清單暫存器的數量在初始化後是恆定的，因此它會從 kvm_vgic_global_state.nr_lr 複製一次到hyp_gicv3_nr_lr，而不是在每個項目上讀取。
    (CVE-2026-64287)

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

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

  - netfilter： flowtable：尚不支援 IPIP 通道硬體卸載 尚不支援 IPIP 通道的驅動程式支援，請儘早放棄設定此案例的硬體卸載。此修補程式新增了一個可以增強的存根，以新增更多目前不支援的設定。截至目前，卸載工作會排入背景工作角色佇列，然後在不支援硬體卸載組態時忽略。檢查 NF_FLOW_HW 旗標以瞭解是否已嘗試卸載此項目一次，以便在不支援時不會在重新整理時重試此項目。將NF_FLOW_HW旗標檢查移至 nf_flow_offload_add（）。如果未設定此NF_FLOW_HW旗標，則永遠不會呼叫_del和_stats變體。稍後可以更新，以跳過硬體卸載工作，以防硬體卸載不支援排入佇列。（CVE-2026-64410）

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

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

  - mm： shrinker：修正shrinker_info拆卸爭用，擴充 expand_shrinker_info（） 會反覆運算 shrinker_mutex 下所有可見的 memcg，包括尚未完成 ->css_online（） 的 memcg。一旦 pn->shrinker_info 發布，拆卸必須保持使用 expand_shrinker_info（） 序列化，直到該 memcg 完全在線或不再對迭代可見。今天 alloc_shrinker_info（） 打破了該規則，在釋放部分初始化的 shrinker_info 陣列之前刪除了 shrinker_mutex，這可能會導致以下爭用： CPU0 CPU1 ==== ==== css_create --> list_add_tail_rcu（&css->sibling， &parent_css->children）;online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> alloc node0 info rcu_assign_pointer（C->node0->shrinker_info， old0） alloc node1 info -> FAIL -> goto err mutex_unlock（shrinker_mutex） shrinker_alloc（） --> shrinker_memcg_alloc --> mutex_lock（shrinker_mutex） expand_shrinker_info --> mem_cgroup_iter 查看 memcg expand_one_shrinker_info --> old0 = C->node0->shrinker_info memcpy（new->unit， old0->單位，...）;free_shrinker_info --> kvfree（old0）;/* 雙倍免費！！*/ kvfree_rcu（old0， rcu）;後面的 mem_cgroup_css_online（） 中也存在同樣的問題。如果 alloc_shrinker_info（） 成功，但後續的 objcg 配置失敗，則free_objcg -> free_shrinker_info（） 展開路徑會拆除已發佈的 pn->shrinker_info 陣列，而不會shrinker_mutex。expand_one_shrinker_info（） 可以以相同的方式與該拆解競爭，導致舊shrinker_info的釋放後使用或雙重釋放。透過使用 shrinker_mutex 序列化shrinker_info拆卸，並將 alloc_shrinker_info（） 錯誤清除保留在鎖定區段內來修正此問題。
    (CVE-2026-64418)

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

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

  - USB：misc：uss720：探查失敗時取消註冊 parport uss720_probe（） 會在讀取用於偵測不支援的 Belkin F5U002 配接器的 1284 暫存器之前註冊 parport。如果 get_1284_register（） 失敗，錯誤路徑會捨棄驅動程式私有資料和 USB 裝置參照，但會保留 parport 裝置已註冊。讓連接埠註冊不僅僅是私有分配洩露：parport_register_port（） 已經保留了一個 parport 號碼並註冊了 parport 匯流排設備，而 pp->private_data 仍然指向常見錯誤路徑即將釋放的私有資料。在跳至通用私有資料清除路徑之前，先復原 get_1284_register（） 失敗分支中的預先宣告註冊。先清除 priv->pp，以符合中斷連線路徑，並避免私有資料中出現過時的指標。
    此問題是在我們正在進行的靜態分析研究中發現的，同時檢閱核心程式碼。
    (CVE-2026-64338)

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

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

  - USB：在提交失敗的 EHCI 和 FOTG210 同步提交時釋放 ISO 排程，在將 URB 連結至端點佇列之前建置ehci_iso_sched，並將暫存排程保留在 urb->hcpriv 中，直到 iso_stream_schedule（） 和連結協助程式取用它為止。如果控制器無法再存取，或 usb_hcd_link_urb_to_ep（） 失敗，請在交接發生之前提交跳轉至done_not_linked，並洩漏仍附加至 urb->hcpriv 的暫存排程。在連結 URB 之前，當提交失敗時，從done_not_linked釋放暫存排程釋放，並在釋放後清除 urb->hcpriv。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。
    該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1.1 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們沒有帶有 USB 同步設備的 EHCI 主機控制器進行測試，因此無法執行運行時間測試。（CVE-2026-64348）

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

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

  - HID： lg-g15：取消移除的擱置工作，以修正釋放後使用，lg_g15_data已與 devm 一起配置並保留工作專案。報告處理常式會直接從裝置輸入排程工作。lg_g15_event（） 和 lg_g15_v2_event（） 在背光循環鍵上執行此操作，lg_g510_leds_event（） 也執行此操作。背景工作者會透過container_of取消參照lg_g15_data。驅動程式沒有移除回呼，也從未取消工作。因此，如果報告排定了工作，然後拔掉了鍵盤，則 devres 會在工作仍在擱置或執行中時釋放lg_g15_data，而背景工作者會觸及釋放的記憶體。這是釋放後使用。它可以作為設備拔掉插頭上的爭用來訪問。新增移除回呼，在 devres 釋放狀態之前取消工作。g15->work 只會針對排程它的模型 （G15， G15 v2， G510） 初始化。和 G13 Z-10 將其歸零，因此請保護 g15->work.func 上的取消，以避免取消從未設定過的工作。g15 NULL 測試會反映 lg_g15_raw_event（） 中已有的測試。（CVE-2026-64362）

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

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

  - binder：修正 binder_thread_release（） 中的 UAF 當執行緒退出時，binder_thread_release（） 會遍歷其事務堆疊，以清除與退出執行緒對應的 t->from 和 t->to_proc。不過，平行結束的處理程序可能會嘗試釋放其中一些交易。如果其中一個沒有關聯的 t->to_proc，則不會獲得 t->to_proc->inner_lock。這表示在清除 t->to_proc 之後，binder_thread_release（） 中的交易存取可能會與 binder_free_transaction（） 爭用，並導致 KASAN 報告的釋放後使用錯誤：
    ================================================================== 錯誤： KASAN：binder_thread_release+0x5d0/0x798 中的 slab-use-after-free 透過任務 X/715 在 addr ffff000016627500 寫入大小 8 CPU：17 UID：0 PID：715 通訊：X 未受污染 7.1.0-rc5-00149-g8fde5d1d47f6 #30 搶佔 硬體名稱：linux，dummy-virt （DT） 呼叫追蹤：binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...]由 cpu 18 上的任務 717 在 67.267803 秒分配：__kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...]在 90.416221s 處被 CPU 18 上的任務 202 釋放：__kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== 為了避免這種情況，請確保 binder_free_transaction（） 讀取事務鎖下的 t->to_proc。這會序列化交易發行與 binder_thread_release（） 中的存取權。此外，它符合 @to_proc （CVE-2026-64469） 的記錄鎖定規則。

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

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

  - proc：使用 exec_update_lock 保護 ptrace_may_access（） （第 1 部分） 修正 procfs 目前在沒有 exec_update_lock 保護的情況下呼叫 ptrace_may_access（） 的簡單情況，其中修正方法是簡單地新增額外的鎖或使用 mm_access（）： - do_task_stat（）：抓取exec_update_lock - proc_pid_wchan（）：抓取exec_update_lock
    - proc_map_files_lookup（）：使用 mm_access（） 而不是 get_task_mm（） - proc_map_files_readdir（）：使用 mm_access（） 而不是 get_task_mm（） - proc_ns_get_link（）：抓取exec_update_lock - proc_ns_readlink（）：
    抓取exec_update_lock （CVE-2026-64371）

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

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

  - partitions： aix：將 pp_count 掃描連結至 PPE 陣列 aix_partition（） 將實體磁碟區描述元讀取至固定大小的結構 PVD，然後掃描其實體分割區範圍陣列：int numpps = be16_to_cpu（PVD->pp_count）;...for （i = 0; i < numpps; i += 1） { struct ppe *p = pvd->ppe + i; ...lp_ix = be16_to_cpu（p->lp_ix）;pvd 指向單一 kmalloc（）'d 結構 pvd，其 PPE[] 成員保存固定的 ARRAY_SIZE （PVD->PPE） （1016） 項目，但迴圈會一直運行到磁碟上的pp_count。pp_count 是直接從描述元讀取的未經驗證的__be16，因此pp_count大於 1016 的特製AIX映像會驅動迴圈讀取 PVD->PPE[i]，超過分配的末尾 （最多 65535 個項目，~2 MB 越界）。當透過 msdos_partition（） -> aix_partition（） 出現具有特製 AIX/IBM 分割區表的區塊裝置（攻擊者提供的影像附加有 losetup -P 或由 udev 自動掃描的裝置）時，分割區掃描會在不掛載任何內容的情況下執行。將掃描限制為 ppe[] 陣列可以容納的項目數。（CVE-2026-64318）

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

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

  - ksmbd：需要重複範圍的來源讀取存取權，FSCTL_DUPLICATE_EXTENTS_TO_FILE將來源檔案直接傳遞至 vfs_clone_file_range（） 或 vfs_copy_file_range（），而不檢查授與來源控點的 SMB 存取遮罩。因此，以屬性存取權開啟的控點可用來將檔案內容複製到攻擊者可讀取的目的地。在任一 VFS 作業之前，需要在來源控點上FILE_READ_DATA，以符合其他 ksmbd 資料複製路徑。（CVE-2026-64395）

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

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

  - ACPI： CPPC：禁止因欄位濫用而引起的 UBSAN 警告 reg->access_width 的定義會根據 reg->space_id 類型而變更。類型 ACPI_ADR_SPACE_PLATFORM_COMM 使用 access_width 來指出 PCC 區域，如果值大於 4，則可能會導致 UBSAN。例如： UBSAN：drivers/acpi/cppc_acpi.c：1090：9 中的 shift-out-of-bounds shift 指數 32 對於 32 位元類型「int」來說太大 CPU：61 UID：0 PID：1220 Comm：（udev-worker） 未受污染 7.0.10-201.fc44.aarch64 #1 PREEMPT（lazy） 硬體名稱：
    由 O.E.M. 呼叫追蹤填寫：...（修剪）ubsan_epilogue+0x10/0x48
    __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ...（修剪）讓我們透過驗證區域類型以及access_width是否有值來解決此問題。然後，由於我們直接返回bit_width以供ACPI_ADR_SPACE_PLATFORM_COMM，因此刪除更正大小的程式碼。（CVE-2026-64512）

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

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

  - proc：使用 exec_update_lock （FD 連結） proc_pid_get_link（） 和 proc_pid_readlink（） 保護 ptrace_may_access（） 目前從 PID 查詢任務一次，然後對該任務進行 ptrace 存取檢查，然後再次從 PID 查詢任務以執行實際存取。這在幾個方面都是活潑的。若要修正此問題，請將任務傳遞給 ->proc_get_link（） 處理常式，而不是 proc_fd_access_allowed（），而是引入一個新的協助程式 call_proc_get_link（），該協助程式會查詢並鎖定任務、執行存取檢查並呼叫 ->proc_get_link（）。（CVE-2026-64375）

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

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

  - 藍牙：修正 bt_accept_dequeue（） 中的 UAF bt_accept_get（） 在刪除接受佇列鎖定之前會進行臨時參照。bt_accept_dequeue（） 目前會在 bt_accept_unlink（） 之前刪除該參照，只留下佇列參照。bt_accept_unlink（） 會捨棄佇列參照。因此，如果後續的 sock_hold（） 是最終參照，則會存取釋放的記憶體，如 KASAN 在偵聽 L2CAP 通訊端清除期間觀察到的那樣。透過取消連結保留暫時佇列遍歷參照，並在成功時將其交給呼叫端。將其明確放在已關閉且尚未連接的路徑上。（CVE-2026-64406）

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

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

  - SMB： 用戶端：修正變更通知重播雙重釋放 回應產生嘗試可能會傳回可重播的錯誤，並釋放其回應緩衝區。如果 SMB2_notify_init（） 在下次傳送之前失敗，清理會保留先前的緩衝區類型，並再次釋放該回應。每次嘗試前重設回應簿記，以防止過時釋放。（CVE-2026-64384）

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

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

  - cpufreq： pcc：針對兩階段_OSC協商，修正_OSC評估 pcc_cpufreq_do_osc（） 呼叫 acpi_evaluate_object（） 兩次中的釋放後使用和雙重釋放。在兩者呼叫之間，它釋放了 output.pointer，但保持 output.length 不變。由於 acpi_evaluate_object（） 將具有非 NULL 指標的非零長度視為要寫入的現有緩衝區，因此第二次呼叫會寫入釋放的記憶體 （釋放後使用）。然後，out_free 處的後續 kfree（output.pointer） 第二次釋放相同的指標（雙重釋放）。釋放第一個結果後，將 output.pointer 重設為 NULL，並將 output.length 重設為 ACPI_ALLOCATE_BUFFER，因此 ACPICA 會為每個階段獨立配置一個新的緩衝區。（CVE-2026-64372）

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

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

  - USB： typec： tcpci_rt1711h：向 devres 取消註冊 TCPCI 連接埠 rt1711h_probe（） 會在要求中斷並啟用警示中斷之前註冊 TCPCI 連接埠。如果後面的任一步驟失敗，探查函式會傳回，而不會取消註冊 TCPCI 連接埠。明確的取消註冊目前只會從移除回呼發生。在 tcpci_register_port（） 成功後立即註冊 devres 動作，以便 tcpci_unregister_port（） 在稍後的探查失敗和驅動程式分離時執行。刪除 remove 回呼以避免兩次取消註冊相同的連接埠。此問題是在我們正在進行的靜態分析研究中發現的，同時檢閱核心程式碼。（CVE-2026-64463）

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

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

  - ntfs：當 ntfs_ib_write（） 傳回錯誤時，避免針對無效的 index_block ntfs_icx_ib_sync_write（） 呼叫呼叫 post_write_mst_fixup post_write_mst_fixup（） 而呼叫 （），目的是在寫入失敗後還原緩衝區。但是，如果 ntfs_ib_write（） 驗證失敗，pre_write_mst_fixup（） 會立即傳回錯誤。呼叫端 ntfs_icx_ib_sync_write（） 會將任何錯誤解譯為需要復原的寫入失敗。
    它不會區分 I/O 錯誤和驗證失敗，並且無論如何都會呼叫 post_write_mst_fixup（）。由於 post_write_mst_fixup（） 假設index_block內容正確，因此不會執行邊界檢查，這會導致越界記憶體存取。攻擊者可以使用以下方式製作惡意 NTFS 映像： - 較大的 index_block.usa_ofs 偏移，指向ntfs_record外部 - index_block.usa_count = 0，導致整數反向溢位 - 或 index_block.usa_count 大於ntfs_record中的實際扇區數，導致越界存取 KASAN 報告描述記憶體損毀：
    ================================================================== 錯誤：KASAN：post_write_mst_fixup+0x19c/0x1d0 中的 slab-out-of-bounds 透過任務 p/9428 在 addr ffff8881586c9018 讀取大小 2 呼叫追蹤： <TASK> dump_stack_lvl+0x100/0x190 print_report+0x139/0x4ad ？ post_write_mst_fixup+0x19c/0x1d0 ？
    __virt_addr_valid+0x262/0x500？post_write_mst_fixup+0x19c/0x1d0 kasan_report+0xe4/0x1d0 ？post_write_mst_fixup+0x19c/0x1d0 post_write_mst_fixup+0x19c/0x1d0 ntfs_icx_ib_sync_write+0x179/0x220 ntfs_inode_sync_filename+0x83d/0x1080 __ntfs_write_inode+0x1049/0x1480 ntfs_file_fsync+0x131/0x9b0 ================================================================== 錯誤： KASAN：post_write_mst_fixup+0x1aa/0x1d0 中的 slab-out-of-bounds 透過任務 p/9428 在 addr ffff8881586c91fe 寫入大小 2 呼叫追蹤：
    <TASK> dump_stack_lvl+0x100/0x190 print_report+0x139/0x4ad ？post_write_mst_fixup+0x1aa/0x1d0 ？
    __virt_addr_valid+0x262/0x500？post_write_mst_fixup+0x1aa/0x1d0 kasan_report+0xe4/0x1d0 ？post_write_mst_fixup+0x1aa/0x1d0 post_write_mst_fixup+0x1aa/0x1d0 ntfs_icx_ib_sync_write+0x179/0x220 ntfs_inode_sync_filename+0x83d/0x1080 __ntfs_write_inode+0x1049/0x1480 ntfs_file_fsync+0x131/0x9b0 ================================================================== 讓我們將 post_write_mst_fixup（） 呼叫移至 ntfs_ib_write（）。ntfs_ib_write（） 函數在開頭呼叫 pre_write_mst_fixup（）。如果index_block內容無效，則 pre_write_mst_fixup（） 會失敗，並且 ntfs_ib_write（） 會提前返回，而不會在錯誤index_block上呼叫 post_write_mst_fixup（）。（CVE-2026-64431）

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

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

  - crypto： ccp - 不要為 ioctl 初始化 SNP（SNP_COMMIT） Sashiko 指出：>如果 SEV 初始化失敗並且 KVM 正在主動執行正常 VM，>使用者空間進程是否可以透過 /dev/sev ioctl （例如 > SEV_PDH_GEN） 觸發此程式碼路徑並全域歸零MSR_VM_HSAVE_PA？作用中虛擬機器的下一個 VMRUN >執行是否會觸發一般保護錯誤，並使>主機當機？SNP_COMMIT 命令不需要韌體處於任何特定狀態。如果之前未初始化，請跳過初始化。SEV-SNP 韌體規格文件 56860 並未提及表 5 中的 SNP_COMMIT 作為 UNINIT 狀態下允許的命令，但實際上是允許的，未來的文件更新將反映這一點。（CVE-2026-64309）

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

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

  - crypto： drbg - 修正 CTR_DRBG drbg_ctr_generate（） 失敗時傳回成功有時會在失敗時傳回成功，導致輸出緩衝區未初始化。修復它。（CVE-2026-64306）

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

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

  - ksmbd：追蹤擁有位元組範圍鎖定的連線SMB2_LOCK將每一個已授與的位元組範圍鎖定新增至檔案鎖定清單及處理要求之連線的鎖定清單。不過，最終關閉且持久的控制碼路徑會在保留 fp->conn->llist_lock 時移除連線清單項目。使用 SMB3 多通道時，處理 LOCK 要求的連線可能與開啟檔案的連線不同。因此，可以在與保護其所屬清單的微調鎖定不同的微調鎖定下移除項目。然後，並行遊走可以存取釋放的結構ksmbd_lock和結構file_lock物件。記錄擁有每個鎖的 clist 項目的連線，並在鏈結項目時保留對它的引用。使用該連線及其llist_lock進行解鎖、復原、關閉和持久保存。
    再次發佈鎖定時，Durable reconnect 會將新連線指派為擁有者。
    (CVE-2026-64390)

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

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

  - ALSA： gus：檢查 snd_ctl_new1（） 傳回值 snd_ctl_new1（） 在記憶體配置失敗時可以傳回 NULL。
    snd_gf1_pcm_volume_control（） 不會在取消參照 kctl->id.index 之前檢查傳回值，這可能會導致 NULL 指標解除參照。在 snd_ctl_new1（） 之後新增 NULL 檢查，如果失敗則傳回 -ENOMEM。（CVE-2026-64482）

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

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

  - rust： block：修正 GenDisk 清理路徑 GenDiskBuilder：：build（） 在
    __blk_mq_alloc_disk（），但其錯誤路徑只會回復外部佇列資料。這會洩露臨時 gendisk 並request_queue直到稍後拆卸。如果呼叫端將最後一個 Arc<TagSet<T>> 移至 build（） 中，則在卸除標籤集之後，洩漏的佇列可以保留 blk-mq 狀態。在復原queue_data之前，使用 put_disk（） 刪除暫時 gendisk 參照，以修正預先註冊失敗路徑，以便 disk_release（） 可以卸除擁有的佇列。同時在 del_gendisk（） 之後將 GenDisk：:d rop（） 與 put_disk（） 配對。一旦使用 device_add_disk（） 新增了 Rust GenDisk，del_gendisk（） 只會取消註冊它;最終的 gendisk 參照仍必須捨棄，才能完成發行路徑。（CVE-2026-64509）

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

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

  - fuse-uring：修正將已取消的項目移至清單ent_in_userspace fuse_uring_cancel（） 會將可用項目 （這些項目沒有附加要求） 移動到ent_in_userspace清單。ent_list_request_expired（） 會檢查 ent_in_userspace 上的第一個項目，並無條件地取消參照 ent->fuse_req，這將在已移至此清單的已取消項目上當機。透過釋放項目並直接在 fuse_uring_cancel（） 中刪除queue_refs來解決此問題。這是安全的，因為 cancel 是 cancel 處理常式本身 - 在 io_uring_cmd_done（） 之後，將不再為此命令分派取消，並且透過 queue->lock 以 cancel 序列化 teardown。由於 cancel 現在會遞減 queue_refs，因此 fuse_uring_abort（） 不得再在 queue_refs > 0 上限制 fuse_uring_abort_end_requests（），因為當要求仍在佇列時，取消的項目可能已經丟棄queue_refs。移除閘道，讓中止一律排清要求並停止佇列。（CVE-2026-64263）

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

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

  - s390：還原對 DCACHE_WORD_ACCESS load_unaligned_zeropad（） 的支援會從未對齊的位址讀取 8 個位元組，並且可能會跨越頁面邊界。它會處理如果從第二頁讀取導致例外狀況時可能會發生的例外狀況。然而，對於出於安全執行目的捐贈給 Ultravisor 的頁面，do_secure_storage_access（） 例外處理常式無法正確處理此類異常。這樣的異常可能會導致一個永遠無法解決的無休止的異常循環。事實證明，嘗試解決這個問題 [1] 是不夠的。現在還原 load_unaligned_zeropad（），直到此問題以適當的方式解決為止。請注意，load_unaligned_zeropad（） 本身的實作是正確的。還原只是暫時的因應措施，直到安全儲存存取例外狀況完全修正為止。
    [1] 提交 b00be77302d7 （s390/mm：為捐贈的記憶體新增缺少的安全儲存存取修正） （CVE-2026-64369）

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

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

  - crypto：krb5 - 在 rfc3961_simplified.c 中的 alloc krb5_aead_encrypt（）、krb5_aead_decrypt（） 和 rfc8009_aes2.c 中的 rfc8009_encrypt、rfc8009_decrypt（） 時篩選出非同步 AEAD 實作，設定 NULL 完成回呼，並將來自 crypto_aead_{encrypt，decrypt}（） 的任何負傳回視為終端機，落入 kfree_sensitive（buffer）。當encrypt_name解析為非同步 AEAD 執行個體時，要求會傳回
    -EINPROGRESS，則緩衝區會在後端的背景工作程式仍保留指標時釋放，且背景工作程式會在完成時解除參照釋放的 slab。UML+SLUB 下的 KASAN 報告，其合成非同步 aead 後端繫結至 krb5->encrypt_name： 錯誤：KASAN：t5_stub_complete+0x7d/0xc7 中的 slab-use-after-free 協助程式是同步編寫的，因此請在配置時篩選出非同步執行個體，而不是透過每個呼叫站點管道 crypto_wait_req（）。在具有繫結至 krb5 enctype 名稱的非同步 AEAD 提供者的系統上，可透過 net/rxrpc/rxgk.c、fs/afs/cm_security.c 和 net/ceph/crypto.c 連線。（CVE-2026-64439）

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

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

  - cpufreq： qcom-cpufreq-hw： 修正可能的雙重釋放 qcom_cpufreq.data 會以 probe（） 中的 devm_kzalloc（） 作為每個網域資料的陣列配置。qcom_cpufreq_hw_cpu_init（） 在 policy->driver_data 中儲存指向此陣列其中一個元素的指標。qcom_cpufreq_hw_cpu_exit（） 目前在 policy->driver_data 上呼叫 kfree（）。
    這無效，因為記憶體是由 devm 管理。對於第一個網域，這可以在 devres 項目仍處於作用中狀態時釋放 devm 管理的配置，導致稍後分離平台裝置時可能會造成雙重釋放。對於其他網域，指標可能參照陣列內的元素，而不是分配基礎。移除 kfree（data） 調用，讓 devres 釋放 qcom_cpufreq.data。這個問題是由我正在開發的靜態分析工具發現的。（CVE-2026-64377）

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

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

  - iio： pressure： mpl115：修正讀取錯誤時的執行階段 PM 洩漏 mpl115_read_raw（） 在讀取已處理的壓力或原始溫度之前，使用 pm_runtime_get_sync（） 進行執行階段 PM 參照，但在讀取錯誤路徑上，它會傳回而不呼叫 pm_runtime_put_autosuspend（） 。因此，每個失敗的讀取都會洩漏執行階段 PM 參照，並防止裝置自動暫停。在檢查傳回值之前刪除參照，以便平衡成功和錯誤路徑。（CVE-2026-64493）

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

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

  - vfio/pci：每個裝置的閂鎖disable_idle_d3當 disable_idle_d3 引入 vfio-pci 時，它直接使用 pci_set_power_state（） 來操縱裝置電源狀態。沒有引用計數來維持或平衡操作，我們可以無條件地將設備帶到 D0 並有條件地將其移動到 D3hot。
    因此，模組參數是可寫入的。後來，在提交 c61302aa48f7 （vfio/pci： 將模組參數移至 vfio_pci.c） 中，作為 vfio-pci-core 分割的一部分，模組參數的可寫入部分已無效。參數值仍可透過 sysfs 變更，但 vfio-pci 驅動程式會在模組 init 時將值閂鎖到 vfio-pci-core 全域變數中。使用非預設值或不同的值載入 vfio-pci 模組，或卸載並重新載入，可能會變更相對於繫結至 vfio-pci 變體驅動程式的現有裝置的全域。執行階段 PM 是在提交 7ab5e10eda02 中引入的 （vfio/pci：使用執行階段 PM 將未使用的裝置移至低電源狀態），這標誌著電源狀態被引用的點。PM 獲取和放置操作需要平衡，但上述相同的模塊操作可以更改相對於已綁定到 vfio-pci 變體驅動程序的設備的全域變量。這引入了一個窗口，預防性維護作業現在可能會變得不平衡。為了以穩定反向移植的窄佔用空間來解決此問題，disable_idle_d3旗標會在初始化時閂鎖到vfio_pci_core_device中，讓裝置一律以一致的值運作。注意。
    vfio_pci_dev_set_try_reset（） 現在會無條件地提高匯流排重設前後的執行階段 PM 使用計數，以解決disable_idle_d3成為每個裝置而非全域旗標的原因。設定此旗標時，額外的 get/put 配對是無害的，並允許繼續使用共用 vfio_pci_dev_set_pm_runtime_get（） 協助程式。（CVE-2026-64476）

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

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

  - block：在 bdev_mark_dead（） 中意外移除時跳過 sync_blockdev（） bdev_mark_dead（） 的 @surprise == true 表示裝置已經消失。檔案系統回呼 fs_bdev_mark_dead（） 接受這一點並跳過 sync_filesystem（），但當持有者 ->mark_dead 回呼連線時，裸區塊裝置路徑（無 ->mark_dead 操作）失去了其 ！surprise 保護（請參閱修復），並且現在無條件調用 sync_blockdev（），這可能會永遠懸置，等待無法再完成的回寫。syzkaller 透過 nvme_reset_work（） 的 I/O 佇列遺失路徑來解決這個問題：nvme_mark_namespaces_dead（） -> blk_mark_disk_dead（） -> bdev_mark_dead（bdev， true） -> sync_blockdev（） 區塊在 folio_wait_writeback（） 中，楔入重置工作程式和等待它的每個任務。跳過意外移除時的同步，符合 fs_bdev_mark_dead（）;
    invalidate_bdev（） 仍會執行。有序移除 （surprise == false） 不變。由 FuzzNvme（Syzkaller with FEMU fuzzing framework） 找到。（CVE-2026-64326）

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

ID	名稱	嚴重性
330030	Linux Distros 未修補弱點：CVE-2026-9238	medium
330029	Linux Distros 未修補弱點：CVE-2026-12681	high
330028	Linux Distros 未修補弱點：CVE-2026-15578	medium
330027	Linux Distros 未修補弱點：CVE-2026-66011	medium
330026	Linux Distros 未修補弱點：CVE-2026-8348	medium
330025	Linux Distros 未修補弱點：CVE-2026-16043	medium
330024	Linux Distros 未修補弱點：CVE-2026-61475	medium
330022	Linux Distros 未修補弱點：CVE-2026-15705	medium
330021	Linux Distros 未修補弱點：CVE-2026-63319	medium
330019	Linux Distros 未修補弱點：CVE-2026-66373	high
330018	Linux Distros 未修補弱點：CVE-2024-14040	medium
330017	Linux Distros 未修補弱點：CVE-2026-64530	critical
330016	Linux Distros 未修補弱點：CVE-2026-14899	high
329997	Linux Distros 未修補弱點：CVE-2026-64412	critical
329996	Linux Distros 未修補弱點：CVE-2026-64323	critical
329995	Linux Distros 未修補弱點：CVE-2026-64470	critical
329994	Linux Distros 未修補弱點：CVE-2026-64510	critical
329993	Linux Distros 未修補弱點：CVE-2026-64471	critical
329992	Linux Distros 未修補弱點：CVE-2026-64460	critical
329991	Linux Distros 未修補弱點：CVE-2026-64416	critical
329990	Linux Distros 未修補弱點：CVE-2026-64480	critical
329989	Linux Distros 未修補弱點：CVE-2026-64287	critical
329988	Linux Distros 未修補弱點：CVE-2026-64410	critical
329987	Linux Distros 未修補弱點：CVE-2026-64418	critical
329986	Linux Distros 未修補弱點：CVE-2026-64338	critical
329985	Linux Distros 未修補弱點：CVE-2026-64348	critical
329984	Linux Distros 未修補弱點：CVE-2026-64362	critical
329983	Linux Distros 未修補弱點：CVE-2026-64469	critical
329982	Linux Distros 未修補弱點：CVE-2026-64371	critical
329981	Linux Distros 未修補弱點：CVE-2026-64318	critical
329980	Linux Distros 未修補弱點：CVE-2026-64395	critical
329979	Linux Distros 未修補弱點：CVE-2026-64512	critical
329978	Linux Distros 未修補弱點：CVE-2026-64375	critical
329977	Linux Distros 未修補弱點：CVE-2026-64406	critical
329976	Linux Distros 未修補弱點：CVE-2026-64384	critical
329975	Linux Distros 未修補弱點：CVE-2026-64372	critical
329974	Linux Distros 未修補弱點：CVE-2026-64463	critical
329973	Linux Distros 未修補弱點：CVE-2026-64431	critical
329972	Linux Distros 未修補弱點：CVE-2026-64309	critical
329971	Linux Distros 未修補弱點：CVE-2026-64306	critical
329970	Linux Distros 未修補弱點：CVE-2026-64390	critical
329969	Linux Distros 未修補弱點：CVE-2026-64482	critical
329968	Linux Distros 未修補弱點：CVE-2026-64509	critical
329967	Linux Distros 未修補弱點：CVE-2026-64263	critical
329966	Linux Distros 未修補弱點：CVE-2026-64369	critical
329965	Linux Distros 未修補弱點：CVE-2026-64439	critical
329964	Linux Distros 未修補弱點：CVE-2026-64377	critical
329963	Linux Distros 未修補弱點：CVE-2026-64493	critical
329962	Linux Distros 未修補弱點：CVE-2026-64476	critical
329961	Linux Distros 未修補弱點：CVE-2026-64326	critical

偵測

Nessus 的 Misc. 系列

medium

high

medium

medium

medium

medium

medium

medium

medium

high

medium

critical

high

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical