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

  - platform/x86： hp-bioscfg：修正 sk_store（） 和 kek_store（） 中的堆積 OOB 讀取 sk_store（） 和 kek_store（） 在配置金鑰緩衝區之前，從 sysfs 寫入中剝離尾端換行符：長度 = 計數;if （buf[length - 1] == '\n'） length--; bioscfg_drv.spm_data.signing_key = kmemdup（buf， length， GFP_KERNEL）; 但隨後將原始計數 （不是長度） 作為副本大小傳遞給 hp_wmi_perform_query（），這會從長度大小的分配中讀取那麼多位元組，每當寫入以換行符結束時，就會讀取一個位元組，這是 shell echo 到 sysfs 的正常情況。KASAN 直接確認了這一點： 錯誤：KASAN：hp_wmi_perform_query+0x1e9/0x460 中的 slab-out-of-bounds [hp_bioscfg] 任務 python3/16022 在 addr ffff88813c8e2b80 讀取大小 28 ...sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... 有錯誤的位址位於分配的 27 位元組區域內的 0 位元組 [ffff88813c8e2b80， ffff88813c8e2b9b） 以相同的方式重現 kek_store，並且以多種寫入大小（28、57、201 位元組），每次讀取的 kmemdup（） 分配恰好是一個位元組，比寫入小一個位元組。透過在這兩個函式中向 hp_wmi_perform_query（） 傳遞長度而不是計數來修復。（CVE-2026-81014）

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

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

  - svcrdma：ADDR_CHANGE替換失敗時清除sc_cm_id 當 svc_rdma_listen_handler（） 處理RDMA_CM_EVENT_ADDR_CHANGE時，它會建立一個替換接聽程式cm_id並傳回 1，告訴 CM 核心銷毀舊的接聽程式。如果取代配置失敗，sc_cm_id仍會指向 CM 核心即將銷毀的舊cm_id。任何後續的 sc_cm_id 解除參照 （例如 svc_rdma_detach（） 的 rdma_disconnect（） 呼叫 — 都是釋放後使用。NULL sc_cm_id故障路徑上，並保護 svc_rdma_detach（） 的 rdma_disconnect（） 呼叫免受 NULL 的影響，以便在伺服器關閉時可以安全地拆除接聽程式。（CVE-2026-89534）

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

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

  - ceph：在 NFS 匯出 get_name ceph_get_name（） 中綁定複製的 dentry 名稱長度會使用 memcpy（name， rinfo->dname， rinfo->dname_len） 將 MDS 提供的名稱複製到呼叫端的 NAME_MAX 大小緩衝區中，然後寫入 name[rinfo->dname_len] = 0，而不檢查dname_len NAME_MAX。傳回帶有 dname_len > NAME_MAX 的 LOOKUPNAME 回覆的惡意或有錯誤的 MDS 會使緩衝區溢位。__get_snap_name（） 以相同的未檢查方式複製 rde->name / rde->name_len。影響：惡意或已入侵的 Ceph MDS 使用戶端 NFS 匯出get_name路徑中的 NAME_MAX 名稱緩衝區溢位，這是 KASAN 報告的 Slab 越界寫入。透過 NFS 重新匯出 CephFS 掛載時可連線。新增 ceph_export_copy_name（），在複製之前使用 -ENAMETOOLONG 拒絕超過 NAME_MAX 的長度，並在 ceph_get_name（） 和
    __get_snap_name（）。（CVE-2026-89652）

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

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

  - net/smc：在佇列項目 smc_llc_rmt_delete_rkey（） 和 smc_llc_save_add_link_rkeys（） 中攜帶過大的 SMC-Rv2 LLC 訊息，讀取 v2 訊息中不適合 44 位元組聯合smc_llc_msg的部分，並且兩者都受其著陸的緩衝區大小的約束，而不是由到達的內容約束。在具有共用 v2 接收緩衝區的連結上，宣告 255 個 rkey 的 44 位元組DELETE_RKEY_V2在 lgr->wr_rx_buf_v2 中留下的任何先前訊息中都會到達 rkey[9..254]，並將每個 rkey 傳遞給 smc_rtoken_delete（）。這 255 個中的一個與已註冊的 rtoken 匹配並將其刪除。這類連結上的ADD_LINK會從相同的位元組安裝最多 255 個 rtoken。將尾部複製到佇列項目中，使其長度是到達訊息的長度，並將內嵌的 rkey 宣告為聯集的成員，而不是透過轉換到達它們。現在，同一DELETE_RKEY_V2處理它攜帶的 9 個 rkey。副本僅限於兩個函式可以讀取的最長尾部，因此對等不會挑選項目的大小。不再需要先前修補程式放置在沒有共用 v2 接收緩衝區的連結上的繫結。
    (CVE-2026-80985)

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

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

  - nfsd：在釋放複合 arg 時清除 opcnt 以防止 OOB 讀取 nfsd4_release_compoundargs（） 在釋放動態配置的 ops 緩衝區時，將 args->ops 重設為內嵌 iops[8] 陣列，但將 args->opcnt 保留為原始值 （NFSv4.1+ 化合物最多可為 200）。如果 rq_status_counter 停留在奇數值（當 nfsd_dispatch（） 在將其設定為奇數後到達錯誤路徑時，可能會發生這種情況），則RPC狀態轉儲處理常式會從 args->ops[] 讀取 min（opcnt， 16） 條目。由於 iops 只有 8 個元素，並且是結構 nfsd4_compoundargs 中的最後一個字段，因此讀取索引 8-15 會存取相鄰的 slab 記憶體，並透過網路連結將其洩漏到使用者空間。在 nfsd4_release_compoundargs（） 中無條件地零 opcnt，因此永遠不會透過狀態介面公開過時的複合中繼資料。[ cel：從曝光視窗中移除 kvfree_rcu_mightsleep（） 睡眠 ]（CVE-2026-89691）

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

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

  - 當 tarfile 在不支援連結的系統上擷取連結時，它會回復為從封存中擷取成員。在此情況下，篩選函式會執行兩次：一次針對擷取的成員，另一次將名稱設定為連結的位置。針對其中一個呼叫，傳回值會被忽略。相反地，如果任一呼叫傳回 None，則應該略過成員。（CVE-2026-87910）

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

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

  - nfsd：拒絕 NFSv3 SETATTR 中超出範圍的 nseconds 並建立操作 用戶端可以傳送 NFSv3 SETATTR、CREATE、MKDIR、SYMLINK 或 MKNOD，其中包含 nseconds 欄位超出範圍的 atime 或 mtime。該值在網路上格式正確，並且可以乾淨地解碼為有效的 uint32，但它不是有效的 timespec64：
    tv_nsec必須小於NSEC_PER_SEC。setattr 路徑中沒有任何內容限制它。notify_change（） 通過 timestamp_truncate（） 運行時間，當文件系統支持納秒粒度 （s_time_gran == 1） 時，它不會將tv_nsec減少到 NSEC_PER_SEC 以下，並且 inode atime/mtime setter 逐字存儲它（只有 ctime 通過 inode_set_ctime_to_ts（））進行標準化）。然後，未正規化的值會損毀磁碟上的中繼資料：ext4 的 ext4_encode_extra_time（） tv_nsec EXT4_EPOCH_BITS左移位，這會溢出 32 位元額外欄位並破壞秒元位元，因此儲存的秒數（以及年份）在回讀時是錯誤的。出於同樣的原因，帶有 bigtime 的 XFS 錯誤儲存了時間戳記。在 proc 處理常式中驗證用戶端提供的 atime/mtime，並在變更任何內容之前傳回 NFS3ERR_INVAL。RFC 1813 列出了 SETATTR 的NFS3ERR_INVAL，並將其描述為伺服器「無法儲存...在它自己的代表中“;用戶端會將其對應至 EINVAL。簽入 proc 處理常式，而不是在 nfsd_setattr（） 中簽入，會將拒絕保留在物件建立之前。建立作業會在 nfsd_create_setattr（） 執行之前建立物件，因此延遲失敗會留下新物件，並將非冪等要求變成報告失敗的命名空間變更。因此，在建立物件之前，會針對建立作業預先完成檢查。tv_nsec 是一個長，因此比較將其轉換為無符號長（相同寬度）而不是 u32，與 timespec64_valid（） 匹配。u32 轉換會在 64 位元上截斷;未帶正負號的長轉換也會拒絕當超出範圍的 u32 線 n秒 被指派給 32 位長時變成負數的值。僅檢查用戶端提供的時間：SET_TO_SERVER_TIME要求不帶有用戶端值。sattrguard3 ctime 被故意保留：超出範圍的保護根本永遠不會匹配對象的 ctime，並通過現有的 guardtime 比較產生NFS3ERR_NOT_SYNC，這是協議正確的結果，而不是拒絕請求。（CVE-2026-89666）

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

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

  - bpf：在 __bpf_get_stack get_perf_callchain（） 中停用搶佔會傳回每個 CPU 的 perf_callchain_entry 緩衝區，並在返回之前透過 put_callchain_entry（） 釋放其遞迴插槽，因此當 __bpf_get_stack（） 在下方耗用該條目時，沒有任何內容會保留該條目。可以在取得項目和副本之間安排搶佔式 BPF 程式（例如，PREEMPT 核心上的不可休眠原始追蹤點程式，該程式在 migrate_disable（） 下運行，而不是在 preempt_disable（）） 下運行）。然後，在相同 CPU 上排程的另一個工作會重複使用相同的每個 CPU 緩衝區，並以較大的值覆寫 trace->nr。然後從膨脹的 trace->nr 計算copy_len，並且可能會超過調用方的緩衝區，從而導致 memcpy（） 和 build_id 路徑中越界寫入。僅此處採用的 rcu_read_lock（） 並不能阻止這一點。它僅在may_fault路徑上進行，在CONFIG_PREEMPT_RCU下不會停用搶佔;它只是使 perf 的呼叫鏈緩衝區陣列保持活動狀態（透過 call_rcu（））釋放），並且不會阻止另一個任務重複使用該條目。停用取得呼叫鏈專案並將它複製到呼叫端緩衝區的先佔，因此無法在我們下方重複使用專案，且 trace->nr 仍受 max_depth 限制。
    組建識別碼解析可能會出錯，因此會延遲到重新啟用搶佔之後;此時指令指標已複製到 BUF 中，因此它只會在該私有副本上運作。請注意，preempt_disable（） 也包含 rcu_read_lock（） 提供的緩衝區存留期保證，因為搶佔停用區段是呼叫鏈緩衝區 call_rcu（） 回收的 RCU 讀取端關鍵區段。[ 已變更 修正：提交 ]（CVE-2026-89580）

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

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

  - PCI/sysfs：修正 pci_write_legacy_io（） 中的越界讀取 pci_write_legacy_io（） 會從 kernfs 寫入緩衝區載入 4 個位元組，無論使用者空間寫入多少位元組： if （count ！= 1 &&; count ！= 2 &&; count ！= 4） return -EINVAL;return pci_legacy_write（bus， off， *（u32 *）buf， count）;kernfs_fop_write_iter（） 會使用 kmalloc（len + 1） 配置緩衝區，因此對 legacy_io sysfs 檔案的 1 位元組寫入會配置 2 個位元組，而無條件的 u32 載入會在配置結束後讀取最多 2 個位元組，KASAN 會將其報告為 slab-out-of-bounds 讀取。同樣地，2 位元組的寫入會過度讀取 1 個位元組。因此，針對 2 和 4 位元組情況，僅讀取使用 get_unaligned_le16（） 和 get_unaligned_le32（） 請求的位元組數，將緩衝區解釋為小端，以符合 PCI I/O 連接埠空間的位元組順序。PowerPC 實作先前會針對 1 和 2 位元組案例將值移至適當的位置，以補償泛型程式碼的原生端 32 位元負載。這些移位僅在大端核心上是正確的。在 little-endian PowerPC （POWER8 及更新版本） 上，他們擷取了錯誤的位元組，因此 1 位元組寫入會寫入越界位元組，而不是要求的值。在 big-endian 上，本機負載也會導致 out_le16（） 和 out_le32（） 反轉使用者在網路上的位元組，以進行 2 和 4 位元組寫入。little-endian 協助程式解決了這兩個問題，因此移除了班次。Alpha 平台不需要任何變更。legacy_io 檔案是僅限 root 檔案，且僅存在於 Alpha 和 PowerPC 上，這是定義 HAVE_PCI_LEGACY 的兩種架構。（CVE-2026-89722）

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

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

  - power： supply： MAX17040： 暫停時同步工作取消 max17040_work（） 會在每次輪詢之後重新排入佇列。cancel_delayed_work（） 只會取消擱置中的執行個體，不會等待已執行的回呼。如果系統暫停與輪詢回呼爭用，回呼可以繼續存取電量計，並在暫停回呼傳回後重新排隊。使用 cancel_delayed_work_sync（） 確保輪詢在暫停完成之前靜止。（CVE-2026-89461）

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

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

  - 調節器： as3722_get_regulator_dt_data：修正過早of_node_put留下懸空of_node指標 在 as3722_get_regulator_dt_data（） 中，of_get_child_by_name（） 取得 np 上的參照，然後將其指派給 pdev->dev.of_node。函式會立即呼叫 of_node_put（np），釋放參照，並將 pdev->dev.of_node 保留為懸空指標。移除 of_node_put（np） 呼叫，讓裝置保留參照。（CVE-2026-89504）

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

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

  - nfsd：在失敗的委派撤回佇列上清除CALLBACK_RUNNING nfsd_break_one_deleg（） 透過 test_and_set_bit at entry 設定NFSD4_CALLBACK_RUNNING序列化撤回工作，然後呼叫 nfsd4_run_cb（） 將撤回排入佇列。當佇列嘗試失敗時，參照計數凸起會復原，但 RUNNING 位仍會保留設定。唯一清除位元的站點是 nfsd41_destroy_cb（） （fs/nfsd/nfs4callback.c），它從工作佇列執行，因此當沒有任何內容排入佇列時，無法連線。該位成為 dp->dl_recall.cb_flags 上的永久鎖存：同一委派上的每個後續 break_lease（） 都會命中 nfsd_break_one_deleg（） 中的提前返回防護並默默地跳過召回，因此委派永遠不會中斷，並且衝突的開啟或鎖定停止。透過清除 ！queued 分支上的 NFSD4_CALLBACK_RUNNING 與refcount_dec一起修正。CVE-2026-89692

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

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

  - jackson-databind 透過將原始字串逐字傳遞給 CoreXMLDeserializers.Std._deserialize 中的 DatatypeFactory.newDuration（value） 或 newXMLGregorianCalendar（value），將 JSON 字串綁定到 javax.xml.datatype.Duration 或 javax.xml.datatype.XMLGregorianCalendar 欄位。這些還原序列化程式預設為註冊，無需選擇加入，因此沒有多態類型且沒有特殊設定的普通 ObjectMapper 或 JsonMapper 會到達此路徑。XML 結構描述詞彙文法允許任意長度的數值元件，JDK 會透過原生 BigInteger（String） 和 BigDecimal（String） 建構函式實現這些元件，這兩個建構函式的位數計數都是二次的。由於數字位於 JSON 字串權杖內，而不是 JSON 數字權杖中，因此 jackson-core 的 StreamReadConstraints.maxNumberLength 防護永遠不會套用;jackson 自己的 NumberDeserializers 會在剖析字串化數字之前呼叫 validateIntegerLength 或 validateFPLength，但 XML 資料類型還原序列化程式會省略該預先檢查。因此，未經身份驗證的攻擊者可以提交幾兆位元組的單一請求，例如由字母 P 後面接著數百萬位數字和字母 Y 組成的 Duration 值，並強制數十秒到幾分鐘的單執行緒 CPU 工作;少數並行要求可能會使伺服器的工作執行緒飽和。這會影響 com.fasterxml.jackson.core：jackson-databind from 2.0.0 before ， from 2.19.0 before 2.21.6和 2.22.22.22.0 from before ，以及 tools.jackson.core：jackson-databind 3.1.63.0.0 from before 和 3.2.0 from before3.2.2。2.18.10 使用者應升級至 2.18.10、 2.21.6、 2.22.23.1.6、 或 3.2.2。（CVE-2026-68497）

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

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

  - cifs：在 cifs_do_truncate（） 中使用 cifs_invalidate_cache（），因為 O_TRUNC cifs_do_truncate（） 是從 cifs_open（） 叫用而沒有i_rwsem，因此它無法使用 cifs_resize_file_locked（） 來執行適當的 fscache cookie 大小調整。相反，請在 cifs_setsize（） 之後新增 cifs_invalidate_cache（）。cifs_invalidate_cache（） 會呼叫 fscache_invalidate（），該 （） 無需保留 i_rwsem即可運作：它無條件地遞增 inval_counter 並設定 FSCACHE_COOKIE_NO_DATA_TO_READ，確保一旦 cookie 稍後被 fscache_use_cookie（） 啟動，就不會提供過時的快取資料。截斷為零不會留下任何有效的快取資料，因此無效是此處的正確語義。（CVE-2026-89639）

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

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

  - scsi： core：在 scsi_alloc_sgtables（） 中填寫 DMA 填充位元組在模糊測試期間，發現以下問題： 錯誤：KMSAN：__dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 中的 uninit-value
    __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340
    __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420
    __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit 是在以下位置建立的：__alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70
    __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 16 個位元組中的 14-15 個位元組未初始化 大小 16 的記憶體存取從 ffff88800cbdb000 開始 當處理散佈清單的最後一個未對齊元素時，會補充 pad_len 的遺漏位元組。這些位元組保持未初始化狀態，這會導致問題。先將 last_sg->length 擴充 pad_len，然後使用 sg_zero_buffer（） 將這些 pad_len 位元組歸零。
    sg_zero_buffer（） 在內部使用 sg_miter，它可以正確處理跨越多個頁面的 sg 項目和跨越頁面邊界的填充。由 Linux 驗證中心 （linuxtesting.org） 與 Syzkaller 一起找到。（CVE-2026-89515）

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

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

  - power： supply： qcom_battmgr：終止韌體的字串 當韌體傳送字串時，qcom_battmgr_sc8280xp_strcpy（） 會採用 Pascal 式字串。否則，它會複製所有BATTMGR_STRING_LEN位元組，並在沒有終止符的情況下離開目的地。這些目的地是 model_number、serial_number 和 oem_info，每個目的地都彼此相鄰BATTMGR_STRING_LEN和宣告。它們以 val->strval 的形式傳入使用者空間，power_supply_format_property（） 以 %s 列印，因此填充整個欄位的韌體字串會使讀取進入以下成員。使用 strscpy（），使副本始終終止，就像路徑已經針對同一欄位所做的那樣 SM8350 。（CVE-2026-89466）

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

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

  - i3c： master：修正裝置取消註冊路徑中的資訊洩露和 UAF i3c_master_unregister_i3c_devs（） 會在呼叫 device_unregister（） 之前清除 i3cdev->dev->desc。在 device_unregister（） 期間，device_del（） 會發出KOBJ_REMOVE uevent，並在裝置描述元仍預期有效時解除綁定驅動程式。因此，i3c_device_uevent（） 和爭用 modalias_show（） 可以觀察到 NULL desc 並回歸到未初始化的堆疊結構i3c_device_info，從而洩露生成的模態中的核心堆疊內容。
    驅動程式 .remove（） 回呼在解除綁定期間也可能遇到非預期的 NULL desc。在 device_unregister（） 完成之前，保持 desc 有效。由於 device_unregister（） 會刪除裝置參照並可能釋放裝置，因此在取消註冊之前，請使用 get_device（） 進行額外的參照。之後清除 desc 並使用 put_device（） 釋放額外的參照。這會保留 desc 必須為 NULL 的發行時間不變量，同時避免資訊洩漏，以及在裝置發行之後寫入 desc 的潛在釋放後使用。（CVE-2026-80952）

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

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

  - ALSA： portman2x4：在探測時檢查卡片索引有效性 雖然 portman2x4 驅動程式會檢查指定的 devptr->id 值，但它不會檢查負 ID，當透過 sysfs 繫結時，負 ID 通常會指定為 none 或此類值。這可能會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80966）

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

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

  - ceph：拒絕 mdsmap 解碼 MDSMap 中export_targets排名 >= CEPH_MAX_MDS export_targets項目由監控控制。check_new_map（） 使用每個項目作為固定堆疊點陣圖中的位數，因此協定命名空間之外的排名可以使 set_bit（） 寫入陣列結尾。在解碼地圖時拒絕CEPH_MAX_MDS之外的排名。不要針對此處的possible_max_rank進行驗證，因為地圖可能會合法地引用暫時減少的max_mds之外的排名。（CVE-2026-89653）

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

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

  - ata： libata-scsi：修正磁區大小大於 2048 位元組的 DSM TRIM ata_scsi_write_same_xlat（） 會將設定 UNMAP 位元的 SCSI WRITE SAME 命令轉換為 ATA DATA SET MANAGEMENT TRIM 命令。
    TRIM 描述項由 ata_format_dsm_trim_descr（） 建置到 2048 位元組的 ata_scsi_rbuf 暫存緩衝區中，並由調用方將複製的位元組數與邏輯磁區大小進行比較：size = ata_format_dsm_trim_descr（scmd， trmax， block， n_block）;if （size ！= len） /* len == sdp->sector_size */ 轉至 invalid_param_len;ata_format_dsm_trim_descr（） 將副本長度限制為 ATA_SCSI_RBUF_SIZE （2048）。
    在邏輯磁區大小超過該磁區大小的裝置 （例如 4Kn 裝置，其中 sector_size == 4096） 上，函式永遠不會傳回超過 2048，而呼叫端預期它會傳回 sector_size。因此，比較總是失敗，因此每次嘗試時，每個 TRIM 都會被拒絕，並出現參數清單長度錯誤和 WARN_ON（） splat。因此，TRIM/丟棄在此類設備上完全被破壞。根據邏輯磁區大小，描述元的大小不正確。DSM 修剪承載是 512 位元組頁面的清單，每個頁面最多可容納 ATA_MAX_TRIM_RNUM （64） 個 LBA 範圍項目，且與邏輯磁區大小無關。「區塊限制」VPD 頁面已將單一此類頁面通告為最大 WRITE SAME 長度 （65535 * ATA_MAX_TRIM_RNUM 邏輯區塊），因此區塊層永遠不會傳送需要多個頁面的要求。
    只發出一個 512 位元組的頁面，與邏輯磁區大小無關，並且只傳輸該頁面 （COUNT == 1）。對於 512 位元組磁區裝置，這不會改變;具有較大邏輯磁區的裝置現在可以工作，而不是每次 TRIM 都失敗。（CVE-2026-89586）

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

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

  - ocfs2：根據 refcount 區塊驗證器中的 rl_count 驗證 rl_used 驗證器 ocfs2_find_refcount_rec_in_rl（） 使用下列命令遍歷磁碟上的 refcount 記錄陣列： for （; i < le16_to_cpu（rb->rf_records.rl_used）; i++） { rec = &rb->rf_records.rl_recs[i]; ... rl_recs[] 位於單一中繼資料區塊 （通用配置為 4096 位元組） 中，因此其實際容量由 ocfs2_refcount_recs_per_rb（SB） 固定（具有 16 位元組ocfs2_refcount_rec的 4K 區塊為 247 筆記錄）。rl_used 和 rl_count 都由 ocfs2_validate_refcount_block（） 直接從磁碟中讀取，並且在任何 refcount/reflink/CoW 操作遍歷陣列之前，絕不會根據該容量或彼此進行檢查。具有 rl_used == 0xffff 的特製（或損毀）參照計數區塊會使上面的迴圈遠遠超過區塊的末尾，將 i 的 rl_recs[i] 取消引用，最高可達 65534。然後將產生的索引傳遞給同級 ocfs2_insert_refcount_rec（），其插入移位執行：if （index < le16_to_cpu（rf_list->rl_used）） memmove（&rf_list->rl_recs[index + 1]， &rf_list->rl_recs[index]， （le16_to_cpu（rf_list->rl_used） - index） * sizeof（struct ocfs2_refcount_rec））;
    即，最多 （0xffff - index） * 16 位元組 （~1 MiB） 的 memmove（） 距離已經超過區塊的偏移量。這可從針對特製/損毀的 ocfs2 影像的普通參照連結 （FICLONE） 來存取：附加範圍，其 cpos 排序經過葉中的每個實際記錄，會強制查詢從結尾執行，而不是在匹配時儘早返回。攻擊者模型是本地的：CAP_SYS_ADMIN掛載特製或損毀的 ocfs2 映像，或原始寫入支援已掛載的 ocfs2 檔案系統的區塊裝置。
    ocfs2_validate_refcount_block（） 已經驗證了區塊的 ECC、簽名、rf_blkno和rf_fs_generation，但從未根據區塊的實際磁碟容量進行rl_count/rl_used。這與 ocfs2_validate_extent_block（） （fs/ocfs2/alloc.c） 已經為同級範圍清單標頭縮小的間隙類別相同，該標頭在任何程式碼遍歷之前都會檢查記錄容量和已h_list界。：l_recs[] if （le16_to_cpu（eb->h_list.l_count） ！= ocfs2_extent_recs_per_eb（sb）） { rc = ocfs2_error（...）; goto bail; } if （le16_to_cpu（eb->h_list.l_next_free_rec） > le16_to_cpu（eb->h_list.l_count）） { rc =ocfs2_error（...）;戈托保釋;} 將對等效的檢查新增至 ocfs2_validate_refcount_block（）：拒絕rl_count與 ocfs2_refcount_recs_per_rb（） 傳回的固定每個區塊容量不符的 refcount 區塊，並拒絕rl_used > rl_count。設定 OCFS2_REFCOUNT_TREE_FL 時，會略過這兩項檢查，因為在這種情況下，相同的聯集位元組會保留 ocfs2_extent_list （rf_list），而不是參照計數記錄清單 （rf_records） -- 當讀取參考範圍區塊時，該配置已由 ocfs2_validate_extent_block（） 單獨驗證。這反映了現有的 ！（rb->rf_flags &; OCFS2_REFCOUNT_TREE_FL） 此檔案中其他地方使用的防護 （例如
    ocfs2_get_refcount_rec（）） 來決定 rf_records 或 rf_list 是聯盟的即時成員。有了這個，就會在區塊驗證時 （ocfs2_error（）） 捕獲偽造的 rl_used/rl_count，這與此函式中的所有其他損毀檢查一致，而不是驅動 ocfs2_find_refcount_rec_in_rl（） 中的越界讀取和 ocfs2_insert_refcount_rec（） 中的後續越界 memmove（）。
    根據 v6.19 KASAN （KASAN_GENERIC） 版本上的特製映像進行驗證：在此修補程式之前，重播相同的參照連結 （FICLONE） 可靠地命中了 __ocfs2_increase_refcount（）/ocfs2_insert_refcount_rec（） 中的 KASAN 報告，並且一旦 ocfs2_validate_refcount_block（） 拒絕偽造的 rl_used/rl_count，則不會觸發任何報告。（CVE-2026-89493）

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

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

  - lockd：將下一個檔案固定在 lock-drop nlm_inspect_file lock-drop nlm_traverse_files（） 會以 f_count++ 固定目前檔案，用於 nlm_inspect_file（） 的mutex_unlock，但沒有任何內容會固定已儲存的下一個指標。並行 nlm_release_file（） 可以在解鎖窗口期間釋放下一個文件，迭代器在下一個循環步驟中解除參照釋放的記憶體。在鎖定丟棄之前將當前和下一個都固定住。透過在每次迭代結束時交換固定的游標來前進，以便下一個游標在解鎖過程中始終保持活動狀態。一律在卸除反覆專案針腳之後呼叫 nlm_file_release（），不論檔案是否符合述詞。使用 nlm_file_inuse（），它會即時遍歷 inode 鎖定清單，而不是快取的 f_locks 欄位，以便正確評估從未執行 nlm_inspect_file（） 的跳過檔案。
    由於雜湊儲存桶中的每個檔案現在都已釘選並釋放，因此在遊走期間會刪除is_failover_file述詞跳過且沒有鎖定、區塊、共用或外部參照的檔案。舊程式碼從未評估跳過的檔案進行清理。新行為是有意為之：這類檔案已過時，不應保留在表格中。（CVE-2026-89485）

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

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

  - cxl/features：繫結至輸入緩衝區的 fwctl 命令承載 fwctl_cmd_rpc（） 會將 cmd->in_len 位元組複製到 inbuf = kvzalloc（cmd->in_len） 中，並將 inbuf 和 in_len 傳遞至 ->fw_rpc（）。CXL 回呼 cxlctl_fw_rpc（） 會忽略in_len，而且絕不會針對它檢查使用者控制的op_size。
    cxlctl_set_feature（） 僅從下方op_size邊界 （op_size <= sizeof（feat_in->hdr）），然後透過 cxl_set_feature（） 從 feat_in->feat_data 讀取 op_size - sizeof（hdr） 位元組。對於小in_len和大op_size，第一個 memcpy（） 已經讀取過 kvzalloc（in_len） 緩衝區;越界位元組被放置在郵箱承載中並發送到設備，足夠大的op_size可以進入未映射的內存並導致內核 oops。取得路徑op_size固定大小，但同樣地讀取輸入結構而不檢查in_len。在單一分派點，拒絕其固定標頭加上 op_size 不符合複製緩衝區的任何要求。下限測試保護減法並確保op_size在讀取之前被複製。（CVE-2026-89571）

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

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

  - NFSD：在使用 list_for_each_entry_safe（ni， tmp， ...） 捨棄 nfsd_ssc_lock nfsd4_ssc_expire_umount（） 遍歷 nn->nfsd_ssc_mount_list 之後，重新啟動ssc_expire_umount遍歷。對於每個過期的項目，它設定為 nsui_busy = true，刪除nfsd_ssc_lock以在來源 vfsmount 上執行 mntput（），然後重新取得鎖定以 list_del + kfree 項目，並透過巨集儲存的 tmp 指標繼續反覆運算。nsui_busy 標誌保護當前 ni 在鎖定放置窗口期間免受並發 nfsd4_ssc_setup_dul（） 查找器的影響，但它不會固定 tmp。另一個 nfsd RPC執行緒如果無法掛載來源伺服器並達到 nfsd4_ssc_cancel_dul（），將在同一視窗內接受 nfsd_ssc_lock，list_del + kfree 自己的ssc_umount項，然後釋放鎖定。如果該項目是到期遍歷的已儲存 tmp，則下一次反覆運算會解除參照已釋放的nfsd4_ssc_umount_item。在 mntput（） 解鎖視窗之後從頭部重新啟動遍歷，因此不會有已儲存的下一個指標在鎖定刪除後倖存下來。此清單以作用中伺服器間來源掛載的數目 （通常較小） 為界，且到期的延遲工作會定期執行，而不是每個 IO 執行，因此重新啟動的成本很低。（CVE-2026-89712）

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

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

  - nfsd：在nfsd4_drop_revoked_stid中為委派設定SC_STATUS_FREED nfsd4_drop_revoked_stid（） 會處理管理員撤銷委派的FREE_STATEID，但不會在發行委派之前設定SC_STATUS_FREED cl_lock。
    revoke_delegation（） 使用此標誌來檢測FREE_STATEID是否已經處理了委派 -- 如果沒有它，釋放的委派將通過 list_add（） 添加到cl_revoked中，當稍後在 __destroy_client（） 中遍歷 cl_revoked 時，會產生釋放後使用。nfsd4_free_stateid（） 中的SC_STATUS_REVOKED路徑（第 7983 行）已正確設定SC_STATUS_FREED。將相同的模式套用至 nfsd4_drop_revoked_stid（） 中的SC_STATUS_ADMIN_REVOKED路徑。（CVE-2026-89703）

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

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

  - nfsd：驗證 NFSv4 中的符號連結目標長度 CREATE nfsd4_decode_create（） 接受來自網路的 NF4LNK 符號連結目標的無限cr_datalen，允許用戶端強制每個 COMPOUND 操作的 kmalloc 最多達到最大 RPC 負載大小 （數 MiB），該容量會持續到複合拆卸為止。VFS 會拒絕具有 ENAMETOOLONG 的過大目標，但已進行分配。使用 nfserr_inval 提前拒絕 cr_datalen == 0，並cr_datalen大於 NFS4_MAXPATHLEN （PATH_MAX），並有 nfserr_nametoolong 來限制分配。（CVE-2026-89699）

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

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

  - clocksource/drivers/nxp-pit：修正錯誤路徑cpuhp_setup_state IRQ 洩漏 當 pit_clockevent_per_cpu_init 成功呼叫 request_irq 後 cpuhp_setup_state 失敗時，錯誤處理會直接跳轉至 out_pit_clocksource_unregister，而不會釋放已註冊的 IRQ。這會洩露 IRQ 行，並且由於 kfree（pit） 緊隨其後，會留下一個懸空指標註冊為中斷處理常式的dev_id，如果 IRQ 隨後觸發，可能會導致釋放後使用。透過呼叫 pit_clockevent_per_cpu_exit 來修正它，以便在落入現有清理鏈之前正確釋放 IRQ。（CVE-2026-89769）

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

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

  - fanotify：修正檔案範圍資訊的釋放後使用 fsnotify_pre_content（） 在觸發任務的堆疊上建立其file_range。fanotify_alloc_perm_event（） 會在堆積分配的權限事件中儲存指向 range.pos 的指標，以便 copy_range_info_to_user（） 稍後可以報告偏移。事件讀取器可以將事件狀態設定為FAN_EVENT_REPORTED，然後在準備檔案描述元時休眠。如果訊號在該點中斷觸發任務，fanotify_get_response（） 會將狀態變更為 FAN_EVENT_CANCELED 並返回。這會在讀者仍擁有事件時展開file_range堆疊框架。然後，閱讀器取消參照 pevent->ppos，並將過時的堆疊值複製到使用者空間。KASAN 報告： 錯誤：KASAN：fanotify_read+0x293e/0x2970 中的釋放後使用 任務 fanotify_inotif/95 在 addr ffff88811434fc50 讀取大小 8 呼叫追蹤：fanotify_read+0x293e/0x2970 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f 將範圍位置直接儲存在權限事件中，並在範圍資訊不可用時使用FANOTIFY_NO_RANGE。
    在閱讀器完成之前，事件會保持作用中，因此報告的偏移不再取決於觸發任務的堆疊。（CVE-2026-89600）

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

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

  - nouveau/gem：在 vma 查詢周圍的資訊 ioctl 中保留 bo 在非 uvmm 路徑中，資訊查詢找到 vma 與關閉 vma 的 gem 關閉路徑之間可能會發生爭用，導致釋放後使用。在 Opus 4.6的幫助下發現。（CVE-2026-89553）

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

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

  - nfsd：驗證TIME_DELEG解碼路徑中的 n秒 以 xdrgen 為基礎的 TIME_DELEG_ACCESS 和 TIME_DELEG_MODIFY 解碼臂會將原始uint32_t n秒直接儲存到 tv_nsec 中，而不會強制執行 n秒< NSEC_PER_SEC。舊版nfsd4_decode_nfstime4有此檢查，但TIME_DELEG路徑沒有。
    格式錯誤的時間規格可以透過 notify_change（） 傳播到磁碟。在 nfs4xdr.c （SETATTR 路徑） 和 nfs4callback.c （CB_GETATTR路徑） 中新增範圍檢查。（CVE-2026-89701）

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

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

  - SUNRPC：檢查 svc 集區 percpu 計數器配置 __svc_create（） 會初始化三個每個集區percpu_counter統計資料，並忽略每個傳回值。在 SMP 上，當 __alloc_percpu_gfp（） 無法滿足分配時，percpu_counter_init（） 就會失敗，導致失敗的計數器 fbc->counters == NULL，並且其內嵌的 raw_spinlock_t、list_head 和 count 從未初始化。無論如何，__svc_create（） 都會將半建構的svc_serv傳回給 nfsd、lockd 或 NFS 回呼服務。一旦該服務上線，svc_xprt_enqueue（）、svc_handle_xprt（） 和 svc_pool_wake_idle_thread（） 中的熱路徑就會到達支援指標為 NULL 的計數器。指標是每個 CPU 的偏移量，因此存取不會出錯：它解析為偏移當前 CPU 的每個 CPU 區域的零，並靜默地損壞存在於其中的任何變數。/proc/fs/nfsd/pool_stats 讀取會遍歷相同的 NULL 每個 CPU 儲存並傳回垃圾，並且在 CONFIG_DEBUG_SPINLOCK 或 lockdep 上，它會在從未初始化的鎖定上進行 splats。建立損毀的服務需要在 RPC 伺服器啟動期間發生 percpu 配置失敗，因此只有本機管理員在記憶體壓力或錯誤插入下才能存取;遠端對等體無法自行誘發不良狀態。檢查 __svc_create（） 中的每個 percpu_counter_init（） 傳回值，並在配置失敗時失敗，展開目前集區和之前初始化的每個集區中已設定的計數器。拆卸時每個計數器的離散 percpu_counter_destroy（） 只會釋放每個 CPU 分配一次。
    (CVE-2026-89547)

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

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

  - nfsd：確保 nfsd_file_do_acquire（） 不使用未開啟的檔案 ->atomic_open 允許在不實際開啟檔案的情況下傳回 SUCCESS。它透過呼叫 finish_no_open（） 來指示這一點。這意味著 dentry_create（） 可以傳回尚未開啟的檔案。這極不可能，因為 ->atomic_open 處理常式通常僅對現有檔案使用 finish_no_open（），在這種情況下不會呼叫 dentry_create（），並且被鎖定的父項應該防止爭用。然而，出於謹慎考慮，如果設定了 FMODE_OPENED，則教導 nfsd 僅使用 dentry_create（） 傳回的檔案，表示它實際上已被開啟，這似乎是明智之舉。（CVE-2026-89687）

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

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

  - mm/kmemleak：掃描任務堆疊時避免軟鎖定 修補程式系列 mm/kmemleak：掃描任務 v3 時避免軟鎖定。kmemleak_scan（） 會掃描一個 rcu_read_lock（） 下的每個任務堆疊，沒有重新排程點，這可能會使具有非常多執行緒的主機上的軟鎖定看門程式觸發。這會列印以下訊息，具體取決於工作負載 + 主機配置： 監控程式： 錯誤：軟鎖定 - CPU#35 卡住 22 秒！[kmemleak：537] scan_block kmemleak_scan kmemleak_scan_thread kthread 修補程式 1 使用 find_ge_pid（） 遍歷任務，因此掃描會在任務之間重新排程 修補程式 2-3 讓掃描迴圈在掃描中斷後提前停止。此修補程式（共 3 個）：kmemleak_scan（） 遍歷每個執行緒，並在單一 rcu_read_lock（） 下掃描其核心堆疊，沒有重新排程點。在具有大量執行緒的主機上 （在除錯版本中被 KASAN/lockdep 放大） 上，此迴圈可能會佔用 CPU 足夠長的時間，以致軟鎖定看門程式跳閘：
    看門狗：錯誤：軟鎖定 - CPU#35 卡住 22 秒！[kmemleak：537] scan_block kmemleak_scan kmemleak_scan_thread kthread 無法直接新增 cond_resched（）：迴圈在 RCU 讀取端關鍵區段內運行。使用 find_ge_pid（） 一次遍歷一個 PID 的任務，採用 RCU 讀取鎖只是為了查找和固定每個任務。然後在沒有鎖定的情況下掃描堆疊，因此 cond_resched（） 會在任務之間執行，掃描會在 scan_should_stop（） 上提前停止。這遵循 next_tgid（）/task_seq_get_next（） 迭代模式，並使每個 RCU 關鍵區段保持簡短。（CVE-2026-89759）

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

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

  - ipip：當 metadata_dst 分配失敗時，修正 collect_md 模式下的 skb 洩漏 在collect_md模式下，當 ip_tun_rx_dst（） 無法配置 metadata_dst 時，ipip_tunnel_rcv（） 傳回 0，而不釋放 skb。ipip_rcv（） 和 mplsip_rcv（） 註冊為xfrm_tunnel處理常式，因此 tunnel4_rcv（） 和 tunnelmpls4_rcv（） 會在封包已消耗時讀取零返回，並且也不釋放它。skb 洩露了。其他通道驅動程式此時都會處理封包：ip6_tunnel.c 跳到其放置標籤，ip_gre.c 和 ip6_gre.c 傳回 PACKET_REJECT，這使得 gre_rcv（） 釋放 skb。只有 ipip 傳回 0。請改為跳至現有的下拉標籤。它釋放了 skb 並且仍然返回 0，因此封包不斷被報告為已消耗，這就是我們在這裡想要的：外部標頭已經被拉取，其餘的處理常式和 ICMP 無法存取都沒有任何用處。觸發此觸發需要處於collect_md模式的 ipip 或 mplsip 通道以及不可部分完成分配失敗，這就是它被忽視的原因。（CVE-2026-89565）

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

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

  - SUNRPC： 拒絕重複的CREDS_VALUE選項 gssx_dec_option_array（） 遍歷有線提供的選項陣列，並針對名稱符合 CREDS_VALUE 的每個項目，呼叫同一結構svc_cred上的 gssx_dec_linux_creds（）。該協助程式無條件地將新的 groups_alloc（） 結果安裝到 creds->cr_group_info 中，而不釋放任何已經存在的指標：for （i = 0; i < count; i++） { ...解碼名稱 ...if （length == sizeof（CREDS_VALUE） &; memcmp（p， CREDS_VALUE， sizeof（CREDS_VALUE）） == 0） { err = gssx_dec_linux_creds（XDR， creds）; ... } }因此，包含兩個CREDS_VALUE項目的回覆會覆寫第二次反覆運算的cr_group_info，並孤立第一次呼叫所配置的group_info。
    較早的free_creds路徑僅透過 free_svc_cred（） 釋放最後一個cr_group_info，因此第一個分配的參照計數保持在 1，並且其 kvmalloc 支援的儲存會洩漏。gssp_accept_sec_context_upcall（） 的樹狀結構內呼叫端都不需要每個回覆有多個CREDS_VALUE。透過追蹤CREDS_VALUE選項是否已解碼並在任何後續相符時傳回 -EINVAL 來修正，因此free_creds路徑會釋放已安裝的單一group_info。（CVE-2026-89539）

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

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

  - NFSD：防止 unlock_filesystem 中的關機後釋放後使用 將檔案系統路徑寫入 /proc/fs/nfsd/unlock_filesystem 會在保留 nfsd_mutex 之前以及處理常式確認已設定 nn->nfsd_serv 之前執行 nfsd4_cancel_copy_by_sb（）。一旦 nfsd 關閉，nfs4_state_destroy_net（） 已釋放 nn->conf_id_hashtbl，但保持指標不變，因此取消協助程式會反覆運算釋放的 slab 記憶體作為結構list_head陣列，然後在採用 clp->async_lock 時取消參照虛假nfs4_client。持有CAP_SYS_ADMIN的本機管理員可以透過停止伺服器，然後寫入unlock_filesystem來達到此釋放後使用;KASAN 會在 nfsd4_cancel_copy_by_sb（） 中報告 slab-use-after-free 讀取。
    nfsd4_revoke_states（） 遍歷相同的狀態表，因此已僅在確認存在 nn->nfsd_serv 的 nfsd_mutex 下運行。將非同步 COPY 取消移至該受保護區段，以便此路徑上的每個 NFSv4 狀態表遍歷器都會觀察執行中的伺服器。非同步副本僅在伺服器運行時存在，因此在 nn->nfsd_serv 上控制取消不會丟失任何內容。（CVE-2026-89661）

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

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

  - iommu/vt-d：啟用 tboot 時強制請求 ACS 目前在 detect_intel_iommu（） 中請求 ACS 的條件不包括 tboot，這可能導致在停用 ACS 的情況下出現錯誤設定 （例如
    由於使用者選擇），而 IOMMU 稍後會被 tboot_force_iommu（） 強制開啟。透過檢查 detect_intel_iommu（） 中的 tboot 來修復它。（CVE-2026-89448）

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

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

  - WiFi：MT76：MT7615：避免等待 Mac 在 MT76 互斥下工作 mt7615_suspend（） 取得 MT76 互斥，然後在 mac_work 上呼叫 cancel_delayed_work_sync（）。mt7615_mac_work（） 透過工作程式頂端的 mt7615_mutex_acquire（） 取得相同的互斥，因此，如果 mac_work 已經在互斥體上執行且遭到封鎖，則暫停路徑會鎖死，等待它持有互斥體的工作。在使用互斥之前，請排清scan_work和mac_work，以符合 mt7921 和 mt7925 中的暫停路徑。scan_work 只採用 mt76 微調鎖，但移動它可以保持序列一致。這也可防止mac_work在已暫停的 HIF 上執行，而先前的分割 （鎖定下的非同步取消、釋放後同步取消） 會允許這樣做。（CVE-2026-80938）

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

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

  - ring-buffer：將 cpu_buffer：：free_page 設為buffer_data_read_page 在並行環形緩衝區調整大小時捨棄快取的讀取器頁面，會使用 free_pages（） 呼叫的新全域subbuf_order。這種不相符的順序可能會導致核心當機或記憶體洩漏，因為快取的頁面是在舊大小下配置的。
    將實際free_page順序與頁面位址一起儲存，以確保我們始終參考正確的值，並且不依賴可能停滯的cpu_buffer>subbuf_order值。最簡單的方法是free_page製作一個已經完全涵蓋我們需要的內容的buffer_data_read_page：頁面地址和頁面順序。（CVE-2026-89500）

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

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

  - ubifs：修正簽章長度檢查中的越界讀取 ubifs_sb_verify_signature（） 在將簽章承載交給 verify_pkcs7_signature（） 之前，會限制磁碟上的 ubifs_sig_node->len 欄位，但檢查的符號錯誤：if （le32_to_cpu（signode->len） > snod->len + sizeof（struct ubifs_sig_node）） 簽章位元組開始 sizeof（struct ubifs_sig_node） （UBIFS_SIG_NODE_SZ， 64 位元組），因此負載最多是 snod->len - sizeof（struct ubifs_sig_node） 位元組長。新增標頭大小而不是減去標頭大小，會接受宣告的長度，最多比節點實際容納的長度大 2 * UBIFS_SIG_NODE_SZ
    -- 經過 c->sbuf 的結尾，即 vmalloc（c->leb_size）。然後，verify_pkcs7_signature（） -> pkcs7_parse_message（） -> asn1_ber_decoder（） 會傳遞膨脹的長度，並在遍歷 DER 標頭時讀取超出分配範圍。節點長度直接來自掛載的映像，因此在加密檢查簽名之前，特製的簽名 UBIFS 映像會通過 ubifs_read_superblock（） 到達此長度。snod->len 被節點掃描器保證為 >= UBIFS_SIG_NODE_SZ （c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ），因此修正後的減法不能下溢。
    合法簽名的圖像不受影響：正確的超級區塊聲明的簽名時間永遠不會超過它嵌入的節點。（CVE-2026-89720）

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

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

  - s390/dasd：跨 ERP 復原傳播部分完成長度 dasd_default_erp_postaction（） 會將已完成 ERP 要求的時間和裝置狀態複製回原始要求，但會捨棄proc_bytes。部分完成的要求、尚未配置軌道的 ESE 讀取傳回的位元組少於要求的位元組，然後透過 ERP 鏈結復原會遺失其部分完成長度。
    然後，__dasd_cleanup_cqr（） 看到 proc_bytes == 0 並完成整個請求，而不是將其餘部分重新排隊，靜默地傳回從未讀取的部分的歸零資料。將proc_bytes轉移到原始要求，就像其他每個要求的狀態一樣。（CVE-2026-89456）

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

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

  - debugfs：修正 mmap_prepare 提交 651fdda8406d 的鎖定檢查 （轉送：更新轉送以使用 mmap_prepare） 將 relayfs 的 'mmap' 檔案作業變更為 'mmap_prepare'，但 debugfs 中的鎖定檢查並未相應更新。如果檔案使用「mmap_prepare」而不是「mmap」，則這可以防止核心處於完整性模式時鎖定 debugfs。由於整個核心向「mmap_prepare」的轉換尚未完成，因此請更新鎖定檢查以同時尋找「mmap」和「mmap_prepare」，以確保全面涵蓋。（CVE-2026-89745）

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

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

  - openvswitch：修正 CT 限制拆解釋放後使用封包處理在 RCU 下使用 CT 限制狀態，而 netns 拆解在 ovs_mutex 下釋放該狀態。CT 限制指標既沒有從讀取器中移除，也沒有受到寬限期的保護，因此封包處理可以取消參照釋放的狀態。無權限的使用者可從使用者和網路命名空間觸發此錯誤，導致 netns 被拆除時，ovs_ct_execute（） 中出現 slab-use-after-free。透過RCU發布CT極限指標，在拆解前將其刪除，等待讀者後再釋放其內容。保持ovs_mutex個別 CT 限制更新，並在 GET 周遊 RCU 保護限制清單時使用 RCU 讀取端鎖定。Netns teardown 會在保留 ovs_mutex 時，分離 pernet .pre_exit回呼中受 RCU 保護的 CT 限制狀態。pernet 核心保證 .pre_exit 和 .exit 回呼之間有 RCU 寬限期，因此 .exit 回呼會在不新增任何額外同步的情況下完成拆卸。netlink 命令處理常式不需要 NULL 檢查，因為使用者空間 netlink 通訊端會在處理要求時保留其網路命名空間的作用中參照。因此，per-netns 結束路徑無法與該通訊端命名空間的 SET、DEL 或 GET 同時執行。（CVE-2026-89488）

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

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

  - libceph：在游標前進之前驗證 OSD 範圍對應 net/ceph/osd_client.c：osd_sparse_read（） 會驗證疏鬆讀取資料長度是否符合總和範圍長度，但不會驗證每個 OSD 提供的範圍是否單調且位於原始要求範圍內。格式錯誤的已驗證 OSD 回覆可以通告具有相符資料長度的遠向非零範圍位移，並使用戶端將訊息資料游標推進到要求緩衝區之外。這會從用戶端接收路徑達到 ceph_msg_data_next（） 中的 BUG_ON（！*length） 判斷提示。影響：惡意或已入侵的已驗證 Ceph OSD 對等可能會透過格式錯誤的疏鬆讀取回覆使核心 Ceph 用戶端當機。在前進游標之前，拒絕溢位、向後移動、重疊或延伸至原始疏鬆讀取要求之外的疏鬆範圍對映。[ idryomov：在 CEPH_SPARSE_READ_DATA_LEN 而不是CEPH_SPARSE_READ_DATA_PRE狀態下，早一點執行 sparse_extent_map_valid（） 檢查 ]（CVE-2026-89657）

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

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

  - wifi： mt76： mt7996：驗證預設 EEPROM 韌體大小 預設 EEPROM 韌體會剖析並複製為完整的 EEPROM，而不檢查其長度。截斷的檔案可讓驅動程式在變體驗證或後援複本期間讀取超出韌體緩衝區。在剖析或複製韌體之前，請拒絕短於 MT7996_EEPROM_SIZE 的檔案。（CVE-2026-80933）

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

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

  - nfsd：在seqid_op重播重試時刪除 stateid，而不是 stateowner 在 nfs4_preprocess_seqid_op（） 中，stateid 是從 nfsd4_lookup_stateid（） 取得的，（） 持有對 nfs4_stid （sc_count） 的參照，但不對 stateowner 進行參照。OpenLockStateId（） 僅轉換該 STID，同樣不進行任何引用。當 nfsd4_cstate_assign_replay（） 傳回 -EAGAIN 時（RP_UNHASHED，重播所有者正在被拆除），它尚未在該路徑上獲取狀態所有者引用。儘管如此，錯誤處理仍稱為 nfs4_put_stateowner（stp->st_stateowner），刪除函數從未獲取的so_count參照 - 存在 stateowner refcount 下溢和釋放後使用的風險 - 同時洩露 stid 上持有的sc_count參照。洩漏的 stid 參照也可以停止並行的 nfsd4_close_open_stateid（），等待 sc_count 刪除。在重試之前，刪除實際持有的參照 -- stid。國家所有者通過 stid 持有的參考資料保持活力。這反映了 nfsd4_process_open1（） 中的開放路徑，其中 put 平衡了路徑明確保留在狀態所有者上的引用。（CVE-2026-89688）

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

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

  - ALSA：mpu401：在探測時檢查卡片索引有效性 mpu401 驅動程式盲目地信任指定的 devptr->id 值在探測時的適當卡片索引範圍內。驅動程式本身在模組探查時建立的裝置沒問題，但如果裝置是透過 sysfs 介面手動繫結，則可能是 -1 為無，這會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80969）

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

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

  - HID： picolcd：clamp eeprom debugfs read 到實際收到的位元組 picolcd_debug_eeprom_read（） 信任 resp->raw_data[2] -- 裝置在其 REPORT_EE_DATA 回覆中提供的長度位元組 -- 僅限制為呼叫者的 read（） 計數：ret = resp->raw_data[2];如果 （ret > s） ret = s;if （copy_to_user（u， resp->raw_data+3， ret）） 它從不檢查 resp->raw_size，即實際複製到 kmalloc'd 結構picolcd_pending的 64 位元組 raw_data[] 中的位元組數 picolcd_raw_event（）。裝置 （或詐騙的 picoLCD） 傳回長度位元組 0xff，以計數 >= 255 讀取，使 copy_to_user（） 讀取到 raw_data[] 相鄰的 slab 記憶體中，並透過 debugfs eeprom 檔案將其返回給使用者空間： 錯誤：
    KASAN：大小為 255 的 _copy_to_user 讀取中的 slab-out-of-bounds ...picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] 相同檔案中的偵錯轉儲路徑在信任裝置長度位元組之前，已經根據接收到的大小驗證了裝置長度位元組;這本讀物沒有。該檔案是S_IRUSR建立的 （僅限 root），並且需要特製的裝置，因此它既不是無權限的，也不是遠端觸發的。將複製長度限制為 resp->raw_size - 3 （實際收到的負載，減去 3 位元組標頭），對於簡短的回覆，底線為 0。（CVE-2026-89628）

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

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

  - zram：修正 writeback_store（） 修補程式系列中的越界存取 zram：修正重新初始化後過時的掃描邊界。writeback_store（） 和 read_block_state（） 在取得 dev_lock 之前，都會從 zram->disksize 派生其表格掃描邊界。如果在讀取和鎖定取得之間以較小的磁碟大小重設裝置並重新初始化，則在掃描在新資料表上運作時，界限可以描述舊資料表。這可能會導致越界插槽存取。將兩個繫結計算移至「dev_lock」下方，讓每個邊界在整個掃描過程中與表格保持一致。將修正程式分開，因為受影響的介面源自不同的認可，而且可以獨立地反向移植。此修補程式 （共 2 個）：writeback_store（） 在進行 dev_lock 之前計算表格掃描邊界。因此，重設後使用較小磁碟大小重新配置可以在 writeback_store（） 等待鎖定時取代 zram->table。取得鎖定之後，它會看到初始化的裝置，但會使用舊的上限掃描新資料表，導致越界存取。按住dev_lock時計算頁數，以便掃描綁定與受鎖定保護的表格相符。（CVE-2026-89718）

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

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

  - dm-pcache：驗證磁碟上的幾何圖形欄位 cache_info cache_segs_init（） 會反覆運算 cache_info >n_segs 次，索引 cache->segments[] （大小取決於快取裝置幾何圖形），而 get_seg_id（） 會從媒體cache_info和每個區段的next_seg連結中取得每個區段 ID。兩者都來自快取裝置中繼資料，該中繼資料僅使用固定的公共種子受 CRC 保護，因此無論誰在表負載 （CAP_SYS_ADMIN） 上提供快取裝置，都可以控制它們：過大的 n_segs 或超出範圍的 ID 會驅動 cache->segments[] 的越界存取，以及進入裝置映射的野生 CACHE_DEV_SEGMENT（） 指標 -- 從磁碟上資料進行越界讀取和寫入。拒絕超過裝置區段計數的n_segs，以及超出範圍的區段識別碼，再使用其中任何一個。有效的中繼資料不受影響。（CVE-2026-80962）

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

ID	名稱	嚴重性
345128	Linux Distros 未修補弱點：CVE-2026-81014	high
345127	Linux Distros 未修補弱點：CVE-2026-89534	high
345126	Linux Distros 未修補弱點：CVE-2026-89652	critical
345125	Linux Distros 未修補弱點：CVE-2026-80985	high
345124	Linux Distros 未修補弱點：CVE-2026-89691	high
345123	Linux Distros 未修補弱點：CVE-2026-87910	medium
345122	Linux Distros 未修補弱點：CVE-2026-89666	medium
345121	Linux Distros 未修補弱點：CVE-2026-89580	high
345120	Linux Distros 未修補弱點：CVE-2026-89722	high
345119	Linux Distros 未修補弱點：CVE-2026-89461	high
345118	Linux Distros 未修補弱點：CVE-2026-89504	high
345117	Linux Distros 未修補弱點：CVE-2026-89692	high
345116	Linux Distros 未修補弱點：CVE-2026-68497	high
345115	Linux Distros 未修補弱點：CVE-2026-89639	high
345114	Linux Distros 未修補弱點：CVE-2026-89515	high
345113	Linux Distros 未修補弱點：CVE-2026-89466	high
345112	Linux Distros 未修補弱點：CVE-2026-80952	high
345111	Linux Distros 未修補弱點：CVE-2026-80966	medium
345110	Linux Distros 未修補弱點：CVE-2026-89653	critical
345109	Linux Distros 未修補弱點：CVE-2026-89586	high
345108	Linux Distros 未修補弱點：CVE-2026-89493	high
345107	Linux Distros 未修補弱點：CVE-2026-89485	critical
345106	Linux Distros 未修補弱點：CVE-2026-89571	high
345105	Linux Distros 未修補弱點：CVE-2026-89712	critical
345104	Linux Distros 未修補弱點：CVE-2026-89703	critical
345103	Linux Distros 未修補弱點：CVE-2026-89699	high
345102	Linux Distros 未修補弱點：CVE-2026-89769	high
345101	Linux Distros 未修補弱點：CVE-2026-89600	high
345100	Linux Distros 未修補弱點：CVE-2026-89553	high
345099	Linux Distros 未修補弱點：CVE-2026-89701	medium
345098	Linux Distros 未修補弱點：CVE-2026-89547	high
345097	Linux Distros 未修補弱點：CVE-2026-89687	high
345096	Linux Distros 未修補弱點：CVE-2026-89759	medium
345095	Linux Distros 未修補弱點：CVE-2026-89565	medium
345094	Linux Distros 未修補弱點：CVE-2026-89539	medium
345093	Linux Distros 未修補弱點：CVE-2026-89661	high
345092	Linux Distros 未修補弱點：CVE-2026-89448	critical
345091	Linux Distros 未修補弱點：CVE-2026-80938	medium
345090	Linux Distros 未修補弱點：CVE-2026-89500	high
345089	Linux Distros 未修補弱點：CVE-2026-89720	high
345088	Linux Distros 未修補弱點：CVE-2026-89456	high
345087	Linux Distros 未修補弱點：CVE-2026-89745	high
345086	Linux Distros 未修補弱點：CVE-2026-89488	high
345085	Linux Distros 未修補弱點：CVE-2026-89657	high
345084	Linux Distros 未修補弱點：CVE-2026-80933	high
345083	Linux Distros 未修補弱點：CVE-2026-89688	critical
345082	Linux Distros 未修補弱點：CVE-2026-80969	high
345081	Linux Distros 未修補弱點：CVE-2026-89628	medium
345080	Linux Distros 未修補弱點：CVE-2026-89718	high
345079	Linux Distros 未修補弱點：CVE-2026-80962	high

偵測

Nessus 的 Misc. 系列

high

high

critical

high

high

medium

medium

high

high

high

high

high

high

high

high

high

high

medium

critical

high

high

critical

high

critical

critical

high

high

high

high

medium

high

high

medium

medium

medium

high

critical

medium

high

high

high

high

high

high

high

critical

high

medium

high

high