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

  - perf/x86/amd/lbr： 修正核心位址洩漏 僅限使用者的分支堆疊可以包含源自核心的分支。因此，即使要求PERF_SAMPLE_BRANCH_USER，核心位址也會公開給使用者空間。在支援 X86_FEATURE_AMD_LBR_V2 的 AMD 處理器上，perf 仍然可以報告分支來源位址位於核心中的 SYSRET/ERET 項目。例如 $ perf record -e cycles -o - -j any，save_type，u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ...0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/--/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... 這是因為硬體篩選器只會考量適用於分支目標的權限層級。延伸軟體篩選，以針對br_sel驗證分支來源位址，以便在要求PERF_SAMPLE_BRANCH_USER時捨棄分支來源位址位於核心中的任何分支記錄。（CVE-2026-80602）

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

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

  - vxlan：在 route_shortcircuit（） 之後重新擷取 ETH 標頭 在 route_shortcircuit（） 之前，ETH 標頭指標會從 eth_hdr（skb） 快取。在 route_shortcircuit（） 內部，可以呼叫 pskb_may_pull（），這可能會重新分配 skb->head。在這種情況下，返回 vxlan_xmit（） 會使快取的 eth 指標指向釋放的內存，從而導致在取消引用 eth->h_dest 時出現釋放後使用。透過在呼叫 route_shortcircuit（） 後更新 eth = eth_hdr（skb） 來解決此問題。（CVE-2026-80681）

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

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

  - soc：xilinx：關閉並釋放 rx 信箱通道 在探測中使用 mbox_request_channel_byname（） 要求 mbox rx 通道。在 remove 回呼中，當 rx_chan 因條件檢查不正確而為 NULL 時，會清除 rx 信箱通道。信箱通道不會關閉，即使在移除裝置之後也可以接收郵件。這導致釋放後使用。此外，通道資源也不會釋放。透過正確檢查rx_chan來解決此問題。（CVE-2026-80654）

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

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

  - i2c：imx：修正從屬註冊爭用和錯誤處理 在 i2c_imx_reg_slave（） 中，從屬指標是在 pm_runtime_resume_and_get（） 之前分配的。如果 pm_runtime_resume_and_get（） 失敗，則傳回錯誤路徑而不清除 i2c_imx->slave，使其保持為非 NULL，並導致所有後續註冊嘗試都以 -EBUSY 失敗。此外，由於此驅動程式使用共用 IRQ，因此中斷處理常式 i2c_imx_isr（） 可以同時執行，並在取得slave_lock後取消參照 i2c_imx->從。先前的修正嘗試在錯誤路徑上新增了無鎖定的 i2c_imx->slave = NULL，但這可能會與鎖定下的 ISR 爭用，並且仍然會導致 NULL 指標解除參照。若要在成功復原之後延遲指派 i2c_imx->從屬和 i2c_imx->last_slave_event，並在slave_lock關鍵區段內執行指派，以解決這兩個問題。這可確保從屬指標永遠不會在錯誤路徑上保持過時，並且在中斷處理常式觀察到時始終有效。（CVE-2026-80678）

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

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

  - Bluetooth： hci_sync：在 hci_connect_acl/le_sync（） 回呼中保留 conn 如果在 hci_sync 任務執行時釋放 conn，則理論上存在 UAF。保留 refcount 以避免這種情況。（CVE-2026-80692）

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

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

  - dmaengine： idxd：修正 wq、engine 和 group 結構的雙重釋放 wq、engine 和群組裝置 （idxd_conf_wq_release、idxd_conf_engine_release、idxd_conf_group_release） 的釋放回呼，每個都會呼叫封閉結構上的 kfree（）。設定錯誤路徑和清理函數也會在 put_device（） 之後明確呼叫 kfree（），每當 put_device（） 將參照計數降至零並觸發釋放時，就會產生雙重釋放。在設定函式中，device_initialize（） 是在 device_add（） 之前呼叫的，因此錯誤點的參照計數恰好是 1。put_device（） 無條件觸發釋放，從而釋放結構;然後，後續的明確 kfree（） 在釋放的記憶體上運作。對於 idxd_setup_wqs（），wq 釋放回呼也擁有 opcap_bmap 和 wqcfg。錯誤展開會在呼叫 put_device（） 之前明確釋放這些欄位，從而在兩者上造成進一步的雙重釋放。從 wq、engine 和群組結構的所有設定錯誤路徑和清理函式中移除冗餘的明確 kfree（） 呼叫，並將這些分配的唯一所有權委派給版本回呼。（CVE-2026-80698）

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

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

  - 韌體：arm_scmi：修正 scmi_power_name_get（） 中的 OOB scmi_power_name_get（） 不會驗證外部呼叫端傳遞的網域號碼，這可能會導致越界存取。透過傳回無效網域的未知來修正此問題，例如 scmi_reset_name_get（） 所做的那樣。（CVE-2026-80649）

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

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

  - drm/amd/display：使用適當的上下文進行記錄 與程式碼的其餘部分相同，get_ss_info_from_atombios（） 使用 calc_pll_cs->ctx->logger 進行記錄。但 calc_pll_cs->ctx 只會在稍後的 calc_pll_max_vco_construct（） 中初始化。因此，任何使用 DC_LOG_SYNC（） 的輸出都會導致 get_ss_info_from_atombios（） 中的 NULL 指標解除參照。根據 Sashiko 的說法，同樣的問題也存在於 dce112_get_pix_clk_dividers（） 和 dcn3_get_pix_clk_dividers（） 中。若要避免存取 NULL 內容，請在各處使用 clk_src->base.ctx->logger。base 中的該上下文在 dce110_clk_src_construct（） 和 dce112_clk_src_construct（） 中較早初始化。在get_ss_info_from_atombios（）或Sashiko的get_pix_clk_dividers之前，實際調用了上面的函數。這是透過將 DC_LOGGER 重新定義為 CTX->logger 來完成的。之前： dce110_clk_src_construct（） 做： -> 設定 clk_src->base.ctx = ctx;-> ss_info_from_atombios_create（） -> get_ss_info_from_atombios（） <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct（） <- sets calc_pll_cs->ctx 之後： dce110_clk_src_construct（） 執行： -> 設定 clk_src->base.ctx = ctx; -> ss_info_from_atombios_create（） -> get_ss_info_from_atombios（） <- uses clk_src->base.ctx （從提交 6f16fcbb0c46a87e3d9685407e906573d60104b0） （CVE-2026-80704）

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

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

  - EDAC/igen6：修正因缺少 release（） 而導致的呼叫追蹤 卸載 igen6_edac 驅動程式時，出現呼叫追蹤：裝置 '（null）' 沒有 release（） 函數，已損壞，必須修復。請參閱 Documentation/core-api/kobject.rst。警告：drivers/base/core.c：2567，device_release+0x84/0x90， CPU#5：
    rmmod/127209 ... RIP：0010：device_release+0x84/0x90 呼叫追蹤： <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ...
    透過為記憶體控制器裝置提供空的 release（） 函式來修正呼叫追蹤。
    (CVE-2026-80643)

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

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

  - 適用於 PHP 的 MongoDB 用戶端程式庫在使用應用程式提供的命名空間 ID 來建構資料庫作業的目標命名空間之前，未充分清理它們。將不受信任文字併入這些識別碼的應用程式可能會以無訊息方式將作業導向到與應用程式預期位置不同的儲存位置。（CVE-2026-81525）

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

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

  - ntfs3：修正 decompress_lznt decompress_lznt（） 中的越界讀取不會在存取解壓縮表格之前驗證陣列索引邊界。具有無效壓縮資料的損毀 NTFS3 映像可能會觸發越界讀取。新增索引邊界檢查以防止 OOB 存取。（CVE-2026-80598）

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

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

  - netfilter： flowtable：避免橋接器 VLAN 取消標記上的num_encaps下溢 DEV_PATH_BR_VLAN_UNTAG情況在 WARN_ON_ONCE（） 內遞減 info->num_encaps。num_encaps 是 u8，因此如果它已經是 0，則仍然會發生遞減並將其包裝為 255。中斷只留下內部開關 -- 後面的路徑條目可以將 info->indev 設定回真實設備，我們最終返回 num_encaps == 255。
    然後，nft_dev_forward_path（） 會遍歷 info.encap[] （大小 2） 至 num_encaps，這表示讀取 OOB 堆疊，並將虛假計數複製到路由描述元中。應該只發生在格式錯誤的橋接路徑堆疊上，因此是 WARN，但值得理智處理。將遞減移出 WARN。[ 此時，請移除WARN_ON_ONCE，因為這只會發生在有錯誤的橋接路徑堆疊 --pablo 上]。（CVE-2026-80634）

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

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

  - cpp-httplib 是一個僅 C++ 標頭的 HTTP/HTTPS 程式庫。在版本 0.49.0中，區塊回應預告片輸出路徑會將預告片標頭名稱和值直接寫入通訊端，而不進行驗證，因此可讓預告片欄位中的 CRLF 序列插入其他標頭或分割 HTTP 回應。與程式庫中的所有其他標頭寫入路徑不同，預告片編寫程式碼不會套用任何拒絕歸位和換行的欄位名稱和欄位值檢查，因此將受攻擊者影響的資料放入區塊回應預告片的應用程式會將攻擊者控制的 CRLF 發射到網路上。這會啟用 HTTP 回應分割，讓攻擊者偽造回應標頭或插入第二個回應。0.50.0 版已修正此問題。(CVE-2026-77341)

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

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

  - ipvs：不要將單封包旗標傳播至已同步的 conns 同步的連線可以在目的地存在之前建立。稍後新增目的地時，ip_vs_bind_dest（） 會將連線旗標從目的地複製到 cp->flags 中。IP_VS_CONN_F_ONE_PACKET連線未同步處理。如果同步處理的連線在已雜湊時繼承IP_VS_CONN_F_ONE_PACKET，則到期可以將其視為單封包連線，並跳過取消現有conn_tab節點的連結，留下過時的雜湊節點指向釋放的結構ip_vs_conn。繫結同步連線時，從目的地旗標刪除IP_VS_CONN_F_ONE_PACKET。
    (CVE-2026-80714)

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

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

  - bpf：停用 LSM 程式目前可以附加到 xfrm_decode_session（） 的xfrm_decode_session鉤附件 BPF。該鉤子可能會傳回錯誤，但 security_skb_classify_flow（） 會從 void 路徑呼叫它，並在傳回錯誤時觸發 BUG_ON（）。停用 BPF 連接到勾點，以防止 BPF LSM 程式將封包分類變成完全錯誤。（CVE-2026-80669）

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

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

  - hwmon：（sht3x） 修正未對齊的存取 Sashiko 報告： 在 sht3x_update_client（） 中，使用 be16_to_cpup（） 從堆疊配置的位元組陣列中擷取 16 位元溫度和濕度值。傳遞給此函數的指標計算為 buf 和 buf + 3。由於兩個指標之間的差異是奇數位元組，因此保證其中至少有一個位於未對齊的位移。這將觸發嚴格對齊架構（例如 ARMv5 或 SPARC）上的對齊錯誤，從而導致核心錯誤。使用 get_unaligned_be16（） 而非 be16_to_cpup（） 和 put_unaligned_be16（） 而非 cpu_to_be16（） 來修正此問題。（CVE-2026-80695）

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

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

  - s390/zcrypt：使用 CPRB 修正 EP11 錯誤的網域值驗證 處理 CPRB 以傳送至加密卡時 EP11 ，網域值的上限檢查錯誤。此檢查僅在自訂裝置節點上有效，但傳送管理 CPRB 時，可能會導致 perms->adm 後面的存取堆積記憶體。新增正確的限制 （AP_DOMAINS = 256） 檢查以修正此問題。（CVE-2026-80709）

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

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

  - i2c：amd-mp2：在配接器新增失敗上取消註冊回呼 amd_mp2_register_cb（） 會在註冊配接器之前，將平台 I2C 內容儲存在 MP2 PCI 驅動程式的回呼資料表中。如果 i2c_add_adapter（） 失敗，探查傳回並釋放上下文，但 PCI 驅動程式仍然可以從其 IRQ 和系統睡眠回呼取消參照過時指標。在傳回配接器註冊錯誤之前，先取消註冊回呼。（CVE-2026-80680）

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

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

  - 驅動程式：hv：vmbus：使用通用 driver_override 基礎架構 當驅動程式被探查時
    __driver_attach（） 時，會在未持有裝置鎖定的情況下呼叫匯流排的 match（） 回呼，因此在沒有鎖定的情況下存取 driver_override 欄位，這可能會導致 UAF。使用驅動程式核心driver_override基礎結構來修正此問題，並在內部進行適當的鎖定。請注意，從
    未保留裝置鎖定的 __driver_attach（） 是故意的。[1] （CVE-2026-80676）

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

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

  - wifi： mac80211：在驅動程式設定之前驗證個別 TWT 參數 ieee80211_process_rx_twt_action（） 只會在將收到的 S1G TWT 設定框架排入佇列之前部分驗證。因此，個別協議可以達到 ieee80211_s1g_rx_twt_setup（），而 twt->length 對於完整結構ieee80211_twt_params來說太短。個別路徑會將 twt 傳遞至 drv_add_twt_setup（）。追蹤點和驅動程式回呼都會取用完整的參數區塊，而不只是req_type。不要向司機傳遞簡短的個人協議。廣播協議保持不變，因為它們在僅存取req_type後在本地被拒絕。[編輯提交消息，不要誇大缺乏驗證或低估驅動程序的影響]（CVE-2026-80722）

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

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

  - scsi：hisi_sas：新增 v3 硬體的slave_destroy介面 同時執行遠端 PHY 和 rmmod SAS 驅動程式的連結重設時，會觸發警告。以下是警告記錄： 警告： CPU：61 PID：21818，位於 drivers/base/core.c：1347 __device_links_no_driver+0xb4/0xc0 呼叫追蹤：
    __device_links_no_driver+0xb4/0xc0 device_links_driver_cleanup+0xb0/0xfc
    __device_release_driver+0x198/0x23c device_release_driver+0x38/0x50 bus_remove_device+0x130/0x140 device_del+0x184/0x434 __scsi_remove_device+0x118/0x150 scsi_remove_target+0x1bc/0x240 sas_rphy_remove+0x90/0x94 sas_rphy_delete+0x24/0x3c sas_destruct_devices+0x64/0xa0 [libsas] sas_revalidate_domain+0xe4/0x150 [libsas] process_one_work+0x1e0/0x46c worker_thread+0x15c/0x464 kthread+0x160/0x170 ret_from_fork+0x10/0x20 ---[ 結束追蹤 71e059eb58f85d4a ]--- 在 SAS phy up 期間， link->status 在 device_links_driver_bound 中設定為 DL_STATE_AVAILABLE，則此設定會影響
    __device_links_no_driver（） 在驅動程式 rmmod 之前，並導致 WARNING。新增slave_destroy介面，以確保在排清工作執行後移除連結。（CVE-2026-80653）

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

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

  - CAN： softing： fw_parse（）：驗證韌體記錄跨度 fw_parse（） 讀取固定記錄標頭、韌體提供的承載和尾端總和檢查碼，而不知道韌體 blob 的結尾。因此，截斷的記錄可能會使這些讀取超出 Blob。相同的記錄也提供寫入 DPRAM 的位址和長度。泛型載入器會使用易換行的混合帶正負號算術來進行邊界檢查，而應用程式載入器則完全不會繫結暫存副本。將韌體端傳遞至剖析器，並驗證完整的來源記錄。對通用 DPRAM 記錄使用帶正負號的寬位移，並在複製之前針對對應的 DPRAM 驗證應用程式暫存範圍。（CVE-2026-80706）

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

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

  - mm/percpu-km：修正 pcpu_create_chunk（） 中的點陣圖溢位和記帳 在 pcpu_create_chunk（） 中，nr_pages 是連續後備分配總量，即 nr_units * pcpu_unit_pages，但 pcpu_chunk_populated（） 使用它來設定區塊>填充 （其大小為 pcpu_unit_pages） 的點陣圖。由於區塊>填充中的位元 N 表示每個單元內的頁面偏移量 N 都得到支援。當nr_units > 1 時，函式會寫入超出區塊>填入的文字。使用 chunk->nr_pages 來修正它。它還修復了全域pcpu_nr_empty_pop_pages帳戶，因為 pcpu_balance_free（） 最多只能迭代到區塊>nr_pages。提交 a63d4ac4ab609 （percpu：
    使 percpu-km 設定區塊>正確填充的點陣圖）引入了點陣圖溢位問題。後來，提交 b539b87fed37f （percpu：implmeent pcpu_nr_empty_pop_pages 和 chunk->nr_populated） 新增了pcpu_nr_empty_pop_pages並造成了帳戶問題。（CVE-2026-80718）

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

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

  - soc：xilinx：修正事件註冊中的爭用情形 zynqmp_power 驅動程式使用 register_event（） 註冊暫停和子系統重新啟動事件的處理常式。不過，這些處理常式所使用的工作結構 （zynqmp_pm_init_suspend_work 和 zynqmp_pm_init_restart_work） 會在登錄呼叫之後配置並起始設定。這會建立爭用視窗，如果韌體在註冊後立即觸發事件，但在配置之前觸發事件，回呼 （suspend_event_callback 或 subsystem_restart_event_callback） 會取消參照 work_pending（） 中的 NULL 指標，進而導致損毀。
    在登錄事件之前，先配置和初始化工作結構，以修正此問題。
    (CVE-2026-80655)

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

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

  - wifi： wcn36xx：修正來自短觸發 BA 韌體回應的 OOB 讀取 韌體回應長度只會根據 sizeof（*rsp） （20 位元組） 檢查韌體回應長度，但當 candidate_cnt >= 1 時，會在 buf + 20 處讀取 22 位元組的候選結構，而不驗證回應包含它。這會導致過時堆積資料的越界讀取，進而損毀 BA 工作階段狀態。新增回應包含候選資料的驗證。
    (CVE-2026-80635)

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

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

  - drm/amdkfd：修正 KFD_IOC_DBG_TRAP_DISABLE 中缺少的授權檢查 防止未經授權終止作用中 GPU 偵錯工作階段。以前，具有 /dev/kfd 存取權的使用者可以在沒有適當擁有權或 ptrace 授權的情況下終止另一個處理程序的除錯工作階段。（從提交 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5 中挑選）（CVE-2026-80703）

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

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

  - 在 jwcrypto 中發現缺陷。遠端攻擊者可傳送包含多個句點分隔符號的特製 JSON Web 加密 （JWE） 權杖。此格式錯誤的權杖可能會強制 JWE.deserialize（） 函式配置過多的記憶體，從而導致 MemoryError。此問題會導致處理不受信任 JWE 值的服務發生拒絕服務 （DoS）。（CVE-2026-80179）

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

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

  - KVM：s390：pci：修正 AIBV 配置失敗時的空取消參照 airq_iv_create（） 可以在失敗時傳回空值，但從未檢查傳回值。如果失敗，zdev->aibv 將為 NULL，並且在 kvm_zpci_set_airq（） 中取消參照時失敗。新增 NULL 檢查，並在失敗時釋放先前配置的 AISB 位元和 zdev->aisb。（CVE-2026-80684）

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

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

  - 跟蹤/探查：從 parse_btf_arg 中移除WARN_ON_ONCE Sashiko 發現，使用者可以透過根據具有 BTF 參數的原始位址新增 kprobe 事件，輕鬆導致此 WARN_ON_ONCE（）。由於這不是意外情況，因此請移除 WARN_ON_ONCE（）。（CVE-2026-80607）

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

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

  - tracing/mmiotrace：在記錄函式 mmio_trace_rw（） 和 mmio_trace_mapping（） 中新增 NULL 檢查以進行mmio_trace_array檢查，將mmio_trace_array擷取到 tr 中並將其傳遞給 __trace_mmiotrace_rw（） 和
    __trace_mmiotrace_map（）。如果在 mmio_trace_array 為 NULL 時呼叫這些函數（例如，在初始化之前或停用之後），則存取 tr->array_buffer.buffer 將導致 NULL 指標解除參照損毀。透過在 tr 的開頭新增明確的 NULL 檢查來修正此問題
    __trace_mmiotrace_rw（） 和 __trace_mmiotrace_map（）。（CVE-2026-80689）

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

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

  - btrfs： lzo：拒絕溢位壓縮輸入的壓縮區段 lzo_decompress_bio（） 僅針對工作區 CBUF 大小，而不是根據壓縮的輸入大小 （compressed_len，bio 的對開間位元組總數） 驗證每個磁碟上的區段長度seg_len。特製的範圍可以承載一個區段，其seg_len通過 cbuf 檢查，但會經過 bio 的結尾，因此 copy_compressed_segment（） 會離開最後一個對開本：get_current_folio（） 然後從 bio_next_folio（） 傳回 NULL 對開本，並且CONFIG_BTRFS_ASSERT停用 （預設） folio_size （NULL） 錯誤。錯誤：KASAN：lzo_decompress_bio 中的 null-ptr-deref （fs/btrfs/lzo.c：383） 由任務 kworker/u8：1/29 在 addr 0000000000000000000000 讀取大小 8 工作佇列：btrfs-endio simple_end_io_work kasan_report （mm/kasan/report.c：590） lzo_decompress_bio （fs/btrfs/lzo.c：383） end_bbio_compressed_read （fs/btrfs/compression.c：1065） btrfs_bio_end_io （fs/btrfs/bio.c：135） btrfs_check_read_bio （fs/btrfs/bio.c：180 fs/btrfs/bio.c：285） simple_end_io_work process_one_work worker_thread 在複製之前，拒絕任何承載會超出compressed_len的區段，將其視為損毀，就像此功能中的其他磁碟驗證失敗一樣。
    (CVE-2026-80631)

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

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

  - igc：移除 igc_down（） 中的 napi_synchronize（） 當AF_XDP零複製應用程式突然終止時，XSK 集區會被拆除，但 NAPI 會繼續輪詢。然後，igc_clean_rx_irq_zc（） 在每次輪詢時返回全部預算，因此 napi_complete_done（） 永遠不會清除 NAPI_STATE_SCHED。igc_down（） 在 napi_disable（） 之前呼叫 napi_synchronize（），因此它會永遠旋轉等待該位，並且介面永遠不會關閉。刪除 napi_synchronize（） 並讓 napi_disable（） 完成這項工作 -- 它會設定NAPI_STATE_DISABLE，從而強制完成卡住的輪詢。在 igc_set_queue_napi（） 之前重新排序，以便只有在輪詢停止後才清除 NAPI 映射，符合最近的 igb 修正 b1e067240379。（CVE-2026-80715）

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

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

  - can： j1939： transport： j1939_session_fresh_new（）：初始化接收緩衝區 將 j1939_session_fresh_new（） 中分配的緩衝區歸零，以確保它不包含任何殘留資料。雖然如果使用者配置最大大小的 ETP 緩衝區，可能會對效能產生影響，但大多數實際使用案例不會受到明顯影響，因為已知緩衝區大小上限通常約為 65K。 [mkl：新增訊息 ID] （CVE-2026-80707）

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

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

  - MongoDB C 驅動程式中的弱點允許在驅動程式撰寫作業的目標命名空間時，呼叫端提供的資料庫和集合名稱元件中的特殊元素在不清理的情況下傳遞。將不受信任的輸入併入這些名稱元件的應用程式可能會有針對預期資源以外的資源的作業。（CVE-2026-81524）

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

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

  - ieee802154：避免在 cfg802154_switch_netns（） 中的 -ENOMEM 上呼叫 WARN_ON（） 在 dev_change_net_namespace（） 和 device_rename（） 中出現分配失敗的情況下呼叫 WARN_ON（） 是沒有意義的，因為它只會導致故意的錯誤注入造成的無用的 splats，因此請避免它。由 Linux 驗證中心 （linuxtesting.org） 與 Syzkaller 一起找到。（CVE-2026-80616）

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

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

  - inet： frags：在重組之前從片段中剝離 GSO 狀態 virtio_net_hdr（tun/tap 或帶有 PACKET_VNET_HDR 的AF_PACKET）可以將 IPv4 或 IPv6 片段標記為 GSO;沒有什麼與gso_type與frag_off有關。
    inet_frag_reasm_prepare（）/inet_frag_reasm_finish（） 保留第一個片段的 skb 作為重組資料包的頭部，包括其 shinfo->gso_size/gso_type/gso_segs，並將剩餘片段鏈結在frag_list上，並使用它們到達的任何線性/分頁佈局。因此，在 ip_defrag（） （ip_local_deliver（）、nf_defrag_ipv4 等） 之後，重組的 skb 仍然聲稱是 GSO （SKB_GSO_DODGY），而下一個軟體分段點 - 本地交付的 udp_rcv_segment（）、validate_xmit_skb（） 或 ip_finish_output_gso（） 慢速路徑 - 將其交給 skb_segment（）。skb_segment（） 的 frag_list 遍歷假設 GRO 形狀的輸入並命中其其中一個 BUG_ON（）。無權限的使用者在其自己的 userns 中對 tap 進行兩次寫入就足夠了：net/core/skbuff.c：4899 的核心錯誤！哎呀：無效的操作碼：0000 [#1] SMP KASAN NOPTI CPU：0 UID：1000 PID：82 通信：poc 未受污染 7.2.0-pentest+ #2 RIP：0010：skb_segment+0x20ca/0x48b0 呼叫追蹤：
    <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0
    __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> 核心錯誤 - 未同步：中斷中的致命異常 此動作會在停用 BH 的情況下執行，因此這是錯誤而不是 oops。
    在 netns 中，重組點位於 GSO 點之前，以及從其 VMM 將 virtio_net_hdr 轉送至分流器的客體中，CAP_NET_RAW也可以達到相同的目的。提交 3dcbdb134f32 （net： gso： 修正分割具有線性頭 frag_list） gso_size 殘缺 skb 時的 skb_segment splat） 和提交 9e4b7a99a03a （net： gso：修正具有混合頭配置類型的frag_list的錯誤） 新增的 SKB_GSO_DODGY frag_list 檢查並未涵蓋它：當 gso_size == skb_headlen（head） 時，頁面備份的頭會跳過它們，而 kmalloc 頭會跳過它們， 由寄件者控制。根據定義，進入片段佇列的 skb 是 IP 片段，無法合法地攜帶 GSO 狀態：GRO 不會在片段化之前合併片段和堆疊區段，因此只有不受信任的來源會受到影響。自從提交 f43798c27684（tun：允許使用 virtio_net_hdr 的 GSO）以來，這已經可以實現，這是允許使用者空間將 GSO 中繼資料附加到 IP 片段的第一個路徑。在 IPv4、IPv6、nf_conntrack_reasm 和 6lowpan 重組共用的 inet_frag_queue_insert（） 中，在排入佇列時重設每個片段的 GSO 欄位;然後，重新組裝的 skb 的負責人和frag_list成員都沒有攜帶它們（成員也很重要：ip_do_fragment（）/ip6_fragment（） 快速路徑按原樣發送它們）。頭部可能保持CHECKSUM_PARTIAL;這在接收時已經被接受，並在轉發時由 ip_do_fragment（）/ip6_fragment（） 中的 skb_checksum_help（） 解析。在 net.git （dc4b95b8fee9） 之上進行測試，x86_64：上面的 tap 再現器，另外兩個到達 BUG_ON（i >= nfrags） 和 BUG_ON（！list_skb->head_frag） 的 IPv4 frag_list幾何圖形，以及一個 IPv6 片段標頭變體 （udp6_ufo_fragment（）），每個都使未修補的核心出現錯誤;使用此修補程式時，所有四個資料包都完好無損地交付，並且不會記錄任何內容。（CVE-2026-80590）

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

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

  - ALSA： pcm：在鏈結資料流上解除連結 snd_pcm_drain（） 時喚醒鏈結的排空等候程式，會在排空對等的 runtime->sleep 上停放堆疊上等候項目，並在 schedule_timeout（） 之後，只有在呼叫端群組中仍可找到該對等時，才會移除它。如果群組成員資格在等候期間變更，且睡眠因訊號或逾時而結束 （因此 autoremove_wake_function（） 不會執行） ，則會跳過 finish_wait（） ，而 snd_pcm_drain（） 會傳回項目，且項目仍在該資料流的睡眠清單上排入佇列;然後，稍後的 wake_up（） 遍歷釋放的堆疊框架。這可以透過取消排空或排幹流的連結來實現。
    與關閉路徑 （snd_pcm_drop（） -> snd_pcm_post_stop（）） 不同，snd_pcm_unlink（） 永遠不會喚醒睡眠佇列。在成員資格變更之前，喚醒群組鎖定下的每個群組成員，以便在資料流仍分組時釋放連結的排水器並刪除其項目。當snd_pcm_link_rwsem在等待期間停止保留時，視窗隨即開啟，且移除變成以群組成員資格為條件 （請參閱修正）。後來切換到 finish_wait（） 保留了該條件刪除，因此訊號/逾時情況仍然存在。（CVE-2026-80716）

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

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

  - drm/amd/display：檢查 dml21_add_phantom_plane（） 是否成功 驗證是否已配置虛擬平面以避免稍後出現 segfault。（從提交 5adb54abe5a8e82cbff7f8806db30a5f4924329f 中挑選）（CVE-2026-80705）

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

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

  - cxl：修正 CXL_HEADERLOG_SIZE 以符合 RAS 功能大小 CXL r4.0 8.2.4.17.7 RAS 功能結構的總長度為 0x58 位元組 （CXL_RAS_CAPABILITY_LENGTH）;標頭記錄在位移0x18佔用尾隨 64 位元組。CXL_HEADERLOG_SIZE定義為SZ_512，是實際裝置上大小的八倍。
    header_log_copy（） 會從 RAS 功能 iomap 讀取 CXL_HEADERLOG_SIZE_U32 （128） 個 dword，將 88 位元組對應溢出 448 個位元組。cxl_aer_uncorrectable_error追蹤事件 memcpy（） 從其來源CXL_HEADERLOG_SIZE （512） 個位元組。對於 CPER 調用者，來源是嵌入在堆疊本地cxl_cper_prot_err_work_data中的結構 cxl_ras_capability_regs：：header_log[16] （64 位元組），因此 memcpy 將 448 位元組的核心堆疊讀取到追蹤事件環緩衝區中，使用者空間可以透過 tracefs 讀取它。將 CXL_HEADERLOG_SIZE 設定為 64 並從中衍生CXL_HEADERLOG_SIZE_U32，讓所有 iomap 讀取器就 16 個 dword 達成一致。rasdaemon 等使用者空間工具在cxl_aer_uncorrectable_error追蹤事件中增加了對有錯誤的 512 位元組 （128 u32） header_log佈局的依賴。新增 CXL_HEADERLOG_TRACE_SIZE_U32 = 128，並將其用於追蹤事件__array及其 memcpy，以保留該 ABI。兩個呼叫端現在都會傳遞一個零填充的 u32[CXL_HEADERLOG_TRACE_SIZE_U32] 暫存緩衝區，其中只有前 CXL_HEADERLOG_SIZE_U32 （16） 個項目從硬體填入;其餘 112 個 U32 為零填充，保持 512 位元組追蹤環緩衝區配置不變。[ dj： 根據 RichardC 用 SZ_64 替換了 64 ]（CVE-2026-80662）

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

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

  - coresight： ete：一律在斷電時儲存狀態 CPU 斷電時，系統暫存器 ETM 和 ETE 不太可能保留。ETE DT 繫結也從未記錄過 arm，coresight-loses-context-with-cpu 因此沒有人能夠合法地使用該繫結來修復它，而 ACPI 根本沒有這樣的繫結。透過硬式編碼 sysreg ETM （ETE 一律為 sysreg） 或 ACPI 開機的設定來修正此問題。在設定save_state時使用本機變數，以便在裝置具有不同的設定時不受並行探查的影響，這是修改全域的問題。這修正了在支援 CPU PM 的 FVP 上將 Coresight 與 ACPI 搭配使用時的下列錯誤： coresight ete0： 外部代理程式已取得宣告標籤 警告：drivers/hwtracing/coresight/coresight-core.c：248 at coresight_disclaim_device_unlocked+0xe0/0xe8， CPU#0： perf/117 （CVE-2026-80623）

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

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

  - sctp：驗證「適應指示」參數長度 「適應層指示」參數的參數標頭後包含一個固定的 32 位元「適應程式碼點」。但是，sctp_verify_param（） 接受僅標頭參數，因為通用參數 walker 只需要標頭存在。
    然後sctp_process_param（） 讀取超出宣告參數的adaptation_ind。當格式錯誤的參數最後出現在 INIT 中時，讀取會從接收 skb 尾部開始，並將值複製到 INIT ACK 中傳回的狀態 Cookie 中。這可能會洩漏四個接收緩衝區尾部位元組。要求宣告的參數長度符合固定結構大小，否則會透過現有的無效參數長度路徑中止關聯。（CVE-2026-80717）

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

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

  - netfilter： conntrack：還原 ct 延伸模組 genid 基礎架構 在移動 ct 逾時和協助程式以使用資料路徑參照計數來追蹤物件使用情況後，不再使用此基礎架構。還原提交 c56716c69ce1 （netfilter： extensions：引入擴充功能 genid 計數） 此修補程式會針對未確認的 conntracks 停用所有 ct 延伸模組 （導致 NULL），而此擴充功能僅針對 ct 協助程式和 ct 逾時。還有一些代碼庫會取消參照 ct 擴展名而不檢查 NULL，這可能會導致損毀。（CVE-2026-80636）

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

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

  - ACPI：processor_idle：將 LPI 進入功能標記為 __cpuidle 啟用功能追蹤或 Kprobes 時，進入 ACPI 低電源閒置 （LPI） 狀態會觸發下列 RCU splat： RCU 未開啟：
    acpi_idle_lpi_enter+0x4/0xd8 警告： CPU：8 PID：0 在 include/linux/trace_recursion.h：162 function_trace_call+0x1e8/0x228 在目前本機 CPU 停用 RCU 之後，會在 cpuidle 路徑中叫用 acpi_idle_lpi_enter（） 函式。因此，ftrace 的 function_trace_call（） 期望 RCU 在記錄追蹤資料之前主動監視，如果沒有，則發出警告。透過使用 __cpuidle 註釋 acpi_idle_lpi_enter（）、通用__weak存根和 acpi_processor_ffh_lpi_enter（） 的 RISC-V 實作來解決此問題。這會將這些函式移至「.cpuidle.text」區段，隱含地停用此敏感路徑上的 ftrace 檢測 （notrace），並防止在閒置進入期間出現追蹤引起的 RCU 警告。（CVE-2026-80611）

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

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

  - s390/zcrypt：修正 cca_clr2cipherkey（） 中清除金鑰匯入時遺失的記憶體清理 協助程式函式
    _ip_cprb_helper（） 使用內部緩衝記憶體來建置和處理 CPRB。使用之後，此緩衝區永遠不會清除，這可能會導致記憶體中留下清除的金鑰資料，例如，這些資料可能會透過重複使用相同的記憶體而暴露。使用另一個參數「scrub」擴充 _ip_cprb_helper（） 函式，用來引導此緩衝區的清理。因此，現在呼叫者有機會決定是否需要擦洗。在函式 cca_clr2cipherkey（） 中擴充清除金鑰以保護金鑰權杖匯入處理程序，以通知上方的協助程式函式在清除金鑰值是要求資料的一部分時清除 cprb 緩衝區。在函數 cca_clr2cipherkey（） 返回時為隨機 EXOR 緩衝區和 cprb 緩衝區新增明確的清理。整體而言，這會在清除金鑰匯入的情況下清除內部使用的緩衝區，以防止敏感資料暴露。（CVE-2026-80708）

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

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

  - erofs：確保頁面快取共用的有效f_path 先前，頁面快取共用的備份檔案設定時f_path保留為 NULL （只有f_inode有效）。它有效，但最近的 mincore 修正依賴 f_path.mnt 並崩潰（由 erofs/028 在 7.2-rc4 上發現）： 錯誤：核心 NULL 指標解除參照，位址：
    0000000000000018 #PF：核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 PGD 0 P4D 0 哎呀：哎呀：0000 [#1] SMP PTI CPU：3 UID：0 PID：675528 通訊：fincore 未受污染 7.2.0-rc4-00002-g[]-dirty #1 PREEMPT（lazy） 硬體名稱：Red Hat KVM，BIOS 1.16.0-4.al8 04/01/2014 RIP：
    0010：__do_sys_mincore+0xc0/0x2c0 ... 使用有效的斷開連接的 dentry 和 erofs_ishare_mnt 來指定有效路徑，而不是將f_path留空，因此它們更像是虛擬檔案系統中的真實備份文件，並且可以直接使用標準 backing_file_open（）。（CVE-2026-80697）

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

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

  - ptp： vmclock：防止唯讀對應變成可寫入 vmclock_miscdev_mmap（） 會拒絕具有 -EROFS 的共用 vmclock ABI 頁面的可寫入對應，但保留設定VM_MAYWRITE。使用者空間可以將頁面對應為唯讀，然後使用 mprotect（） 將其升級為可寫入，之後客體可能會損毀 vmclock ABI 定義為唯讀的主機寫入計時資料 （序列計數器、UTC 時間、TSC 位移）。清除唯讀路徑上的VM_MAYWRITE，以便無法升級對應，就像 i915 對其唯讀物件所做的那樣，並在 drm/vc4 （CVE-2026-68445） 和 drm/panthor （CVE-2024-53071） 中修正。
    (CVE-2026-80724)

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

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

  - perf 工具：在檢查 al->>cpu >= 0 和 env->cpu ！= NULL 後，在 machine__resolve（） 中使用 perf_env__get_cpu_topology（） machine__resolve（） 會存取 env-cpu[al->cpu].socket_id，但不會根據 env->nr_cpus_avail 驗證 al->cpu。由於 al->cpu 來自不受信任的 perf.data 範例，因此具有大型 CPU 索引的特製檔案會導致越界堆積讀取。使用驗證 NULL 和邊界的 perf_env__get_cpu_topology（）。在轉換為結構 perf_cpu 之前，還要對 al->cpu 進行邊界檢查 （int16_t）：
    如果沒有這個，像 65536 這樣的值會默默地截斷為 0，繞過存取者的內部檢查並傳回 CPU 0 的拓撲。（CVE-2026-80670）

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

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

  - idpf：繫結的中斷向量暫存器填入已配置的陣列 idpf_get_reg_intr_vecs（） 會從配接器 >req_vec_chunks 中的 VIRTCHNL2_OP_ALLOC_VECTORS 回覆填入呼叫端配置 reg_vals[] 的陣列，僅以每個區塊num_vectors來限制其內部迴圈。陣列的大小會個別調整：
    idpf_intr_reg_init（） 從caps.num_allocated_vectors配置 kzalloc_objs（struct idpf_vec_regs， total_vecs），並且只檢查填充後傳回的計數。每個區塊num_vectors的總和永遠不會與total_vecs協調，因此具有小num_allocated_vectors但總和較高的區塊的回覆會寫入 的結尾 reg_vals[]。影響：控制平面 （PF 或 Hypervisor 裝置型號） 傳回VIRTCHNL2_OP_ALLOC_VECTORS回覆，其每個區塊num_vectors總和超過reg_vals kmalloc 配置結束時的num_allocated_vectors寫入結構idpf_vec_regs項目 （KASAN slab-out-of-bounds 寫入）。將填充迴圈綁定到調用方傳入的陣列容量，鏡像同級 idpf_vport_get_q_reg（）。然後，現有的num_regs < num_vecs檢查會拒絕大小過小的回覆，而不會先發生越界寫入。（CVE-2026-80693）

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

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

  - net： emac：修正 emac_probe 移動 devm_request_irq（） 之後的 devm_platform_ioremap_resource（） 中的 NULL 指標解除參照，以便在中斷處理常式觸發之前對應 dev->emacp。早期中斷命中 emac_irq（） 會取消參照 NULL dev->emacp 並當機。同時移除多餘的錯誤訊息。devm_platform_ioremap_resource（） 已傳回帶有 dev_err_probe（） 的錯誤訊息。
    (CVE-2026-80614)

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

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

  - Redis 的「tlsProcessPendingData（）」函式中包含釋放後使用弱點，如果 Redis 設定了 TLS 支援，則該函式會處理 TLS 擱置資料清單。未經身份驗證的遠端攻擊者可能能夠以 Redis 伺服器的權限執行任意命令。（CVE-2026-81934）

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

ID	名稱	嚴重性
341326	Linux Distros 未修補弱點：CVE-2026-80602	high
341325	Linux Distros 未修補弱點：CVE-2026-80681	critical
341324	Linux Distros 未修補弱點：CVE-2026-80654	medium
341323	Linux Distros 未修補弱點：CVE-2026-80678	high
341322	Linux Distros 未修補弱點：CVE-2026-80692	high
341321	Linux Distros 未修補弱點：CVE-2026-80698	medium
341320	Linux Distros 未修補弱點：CVE-2026-80649	high
341319	Linux Distros 未修補弱點：CVE-2026-80704	medium
341318	Linux Distros 未修補弱點：CVE-2026-80643	medium
341317	Linux Distros 未修補弱點：CVE-2026-81525	high
341316	Linux Distros 未修補弱點：CVE-2026-80598	high
341315	Linux Distros 未修補弱點：CVE-2026-80634	critical
341314	Linux Distros 未修補弱點：CVE-2026-77341	medium
341313	Linux Distros 未修補弱點：CVE-2026-80714	critical
341312	Linux Distros 未修補弱點：CVE-2026-80669	medium
341311	Linux Distros 未修補弱點：CVE-2026-80695	medium
341310	Linux Distros 未修補弱點：CVE-2026-80709	high
341309	Linux Distros 未修補弱點：CVE-2026-80680	high
341308	Linux Distros 未修補弱點：CVE-2026-80676	medium
341307	Linux Distros 未修補弱點：CVE-2026-80722	high
341306	Linux Distros 未修補弱點：CVE-2026-80653	high
341305	Linux Distros 未修補弱點：CVE-2026-80706	high
341304	Linux Distros 未修補弱點：CVE-2026-80718	high
341303	Linux Distros 未修補弱點：CVE-2026-80655	medium
341302	Linux Distros 未修補弱點：CVE-2026-80635	high
341301	Linux Distros 未修補弱點：CVE-2026-80703	medium
341300	Linux Distros 未修補弱點：CVE-2026-80179	medium
341299	Linux Distros 未修補弱點：CVE-2026-80684	critical
341298	Linux Distros 未修補弱點：CVE-2026-80607	medium
341297	Linux Distros 未修補弱點：CVE-2026-80689	medium
341296	Linux Distros 未修補弱點：CVE-2026-80631	high
341295	Linux Distros 未修補弱點：CVE-2026-80715	medium
341294	Linux Distros 未修補弱點：CVE-2026-80707	high
341293	Linux Distros 未修補弱點：CVE-2026-81524	medium
341291	Linux Distros 未修補弱點：CVE-2026-80616	medium
341290	Linux Distros 未修補弱點：CVE-2026-80590	high
341289	Linux Distros 未修補弱點：CVE-2026-80716	high
341288	Linux Distros 未修補弱點：CVE-2026-80705	medium
341287	Linux Distros 未修補弱點：CVE-2026-80662	high
341286	Linux Distros 未修補弱點：CVE-2026-80623	high
341285	Linux Distros 未修補弱點：CVE-2026-80717	high
341284	Linux Distros 未修補弱點：CVE-2026-80636	medium
341283	Linux Distros 未修補弱點：CVE-2026-80611	medium
341282	Linux Distros 未修補弱點：CVE-2026-80708	high
341281	Linux Distros 未修補弱點：CVE-2026-80697	medium
341280	Linux Distros 未修補弱點：CVE-2026-80724	high
341279	Linux Distros 未修補弱點：CVE-2026-80670	critical
341278	Linux Distros 未修補弱點：CVE-2026-80693	critical
341277	Linux Distros 未修補弱點：CVE-2026-80614	high
341276	Linux Distros 未修補弱點：CVE-2026-81934	high

偵測

Nessus 的 Misc. 系列

high

critical

medium

high

high

medium

high

medium

medium

high

high

critical

medium

critical

medium

medium

high

high

medium

high

high

high

high

medium

high

medium

medium

critical

medium

medium

high

medium

high

medium

medium

high

high

medium

high

high

high

medium

medium

high

medium

high

critical

critical

high

high