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

  - iio： sca3000：修正 sca3000_probe（） spi->irq 中的資源洩漏問題，此問題來自 iio_device_register（） 失敗時未釋放的 request_threaded_irq（）。新增傳回值檢查，並在 iio_device_register（） 失敗時跳至常見錯誤處理常式。（CVE-2026-45883）

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

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

  - KVM：nSVM：如果還原主機 CR3 在巢狀 #VMEXIT 上失敗，則發生三重錯誤 如果在巢狀 #VMEXIT 上載入 L1 的 CR3 失敗，則 nested_svm_vmexit（） 會傳回大多數呼叫端忽略的錯誤碼，並繼續以損毀狀態執行 L1。在此情況下，無法進行合理的復原，而硬體行為會導致關機。改為注入三重錯誤，並且不要提前從 nested_svm_vmexit（） 返回。繼續清理 vCPU 狀態 （例如清除擱置中的例外狀況），以盡可能正常地處理失敗。來自 APM：#VMEXIT 時，處理器會執行下列動作，以返回主機執行內容：...if （載入非法主機狀態，或載入主機狀態時出現異常） shutdown else 執行 VMRUN 之後的第一條主機指令 移除 nested_svm_vmexit（） 的傳回值，無論如何，該傳回值大多未選中。（CVE-2026-46032）

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

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

  - FastNetMon Community Edition through 在 1.2.9 NetFlow v9 資料流程集處理器中包含越界讀取弱點。在 src/netflow_plugin/netflow_v9_collector.cpp 中，資料範本分支 （行 1695-1702） 會反覆運算流程記錄，而不針對封包端點執行每次反覆運算的邊界檢查。相反地，選項範本分支 （行 1709-1719） 會在每次反覆運算之前正確檢查「if （pkt + offset + field_template->total_length > packet_end）」。「資料」分支會完全省略此檢查。由於範本定義是由網路對等體傳送 （並且是未經驗證的 UDP），因此攻擊者可以製作範本，使剖析器讀取通過封包緩衝區的任意記憶體。這可能會洩漏敏感記憶體內容或導致當機。（CVE-2026-48683）

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

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

  - zram：不要忘記對部分捨棄要求進行 endio 正如 Qu Wenruo 和 Avinesh Kumar 所報告的那樣，以下 getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 實際上需要很長時間才能完成。zram 不支援部分捨棄，只是立即返回，在這種情況下不執行任何捨棄工作。
    問題是我們在離開時忘記了 endio，所以 blkdiscard 永遠沉睡在 submit_bio_wait（） 中。
    透過跳轉到標籤來解決此問題end_bio標籤，該標籤會執行 bio_endio（）。（CVE-2026-46089）

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

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

  - ASoC： nau8821： 取消元件移除的延遲工作 在千斤頂偵測工作擱置時嘗試卸載驅動程式，可能會在最終排定執行核心時當機： [1984.896308] 錯誤：無法處理位址的頁面錯誤： ffffffffc10c2a20 [...][ 1984.896388] 硬體名稱：Valve Jupiter/Jupiter，BIOS F7A0131 01/30/2024 [ 1984.896396] 工作佇列：事件nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP：0010：__mutex_lock+0x9f/0x11d0 [...][ 1984.896504] 呼叫追蹤： [1984.896511] <TASK> [ 1984.896524] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ？ srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 取消排程外的jdet_work，或等待其執行完成後再移除元件驅動程式。CVE-2026-45963）

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

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

  - media：amphion：修正 m2m job_abort 和 device_run 之間的爭用 修正由爭用情形引起的核心錯誤，其中 v4l2_m2m_ctx_release（） 釋放m2m_ctx而 v4l2_m2m_try_run（） 即將呼叫具有相同上下文的 device_run。爭用序列：v4l2_m2m_try_run（）：v4l2_m2m_ctx_release（）：鎖定/解鎖 v4l2_m2m_cancel_job（） job_abort（） v4l2_m2m_job_finish（） kfree（m2m_ctx） <- 釋放 ctx device_run（） <- 0x538 時釋放後使用當機 當機追蹤：無法處理從虛擬位址 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 的不可讀記憶體讀取核心 amphion vpu 驅動程式不依賴 m2m 架構的device_run回呼來執行編碼/解碼作業。透過完全阻止 m2m 架構工作排程來修正爭用：- 新增傳回 0 的job_ready回呼 （沒有為 m2m 架構準備的工作）
    - 移除job_abort回呼以避免爭用情形 （CVE-2026-46058）

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

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

  - ALSA： control：在 snd_ctl_elem_init_enum_names（） 中 strnlen（） 之前驗證 buf_len snd_ctl_elem_init_enum_names（） 將指標 p 推進 names 緩衝區，同時遞減 buf_len。如果buf_len達到零，但項目仍然存在，則下一次反覆運算會呼叫 strnlen（p， 0）。雖然 strnlen（p， 0） 傳回 0 並會命中現有的 name_len == 0 錯誤路徑，但 CONFIG_FORTIFY_SOURCE 的強化 strnlen（） 會先針對 __builtin_dynamic_object_size（） 檢查 maxlen。當 Clang 在迴圈內遺失 p 的物件大小時，這會在檢查傳回值之前觸發 BRK 例外狀況錯誤。在迴圈項目新增 buf_len == 0 防護，以防止在耗盡的緩衝區上呼叫強化的 strnlen（）。透過小米智慧型手機進行核心模糊測試發現。（CVE-2026-46088）

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

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

  - netfilter： nf_conncount：將連接清理限制增加到 64 在優化為每次僅執行一次 GC 之後，引入了一個新問題。如果快速追蹤超過 8 個新連線，則清單的清理速度不夠快，可能會錯誤地達到限制。為了防止此問題，只有在GC已在同一瞬間觸發，且增量低於清理限制時，才跳過GC。此外，將清理限制增加到 64 個連線，以避免過於頻繁地觸發 GC，並執行更有效的 GC。這已使用 HTTP 伺服器和數個效能工具進行測試，同時設定了 nft_connlimit/xt_connlimit 或 OVS 限制。52000 個連線時的 slowhttptest + OVS 限制的輸出：第 340 秒的慢速 HTTP 測試狀態：初始化中：0 擱置中：432 已連接：51998 錯誤：0 關閉：0 可用服務：是 （CVE-2026-45860）

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本在 BGP AS_PATH 屬性編碼器中包含整數溢位。在 src/bgp_protocol.hpp 中，IPv4UnicastAnnounce::get_attributes() 函式會按照 sizeof(bgp_as_path_segment_element_t) + this->as_path_asns.size() * sizeof(uint32_t) 計算 attribute_length，並將其存入一個 uint8_t 欄位 (第 600-605 行)。由於 uint8_t 只能保存 0-255 的值，因此包含超過 63 個 ASN 的 AS_PATH (2 + 64*4 = 258 > 255) 會導致無訊息截斷。截斷的長度用於緩衝區大小調整，而實際寫入的資料是完整的未截斷量，因此會導致堆積緩衝區溢位。類似地，第 621 行的 path_segment_length 欄位也是 uint8_t 類型，當 ASN 超過 255 個時會被截斷。(CVE-2026-48691)

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

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

  - drm/display/dp_mst：新增針對 0 vcpi 的保護：釋放時隙時，如果 delayed_destroy_work 在 DP 2.1 監視器中斷連線後最終發揮作用，導致 vcpi 變為 0，則我們可能會因溢位而產生錯誤的有效負載遮罩，然後我們嘗試使有效負載 = ~BIT（vcpi - 1），這是一個負偏移。VCPI ID 永遠不應該真正為 0，因此如果 VCPI 為 0，則跳過變更負載遮罩。否則會導致 <7> [515.287237] xe 0000：03：00.0：
    [drm：drm_dp_mst_get_port_malloc [drm_display_helper]] 連接埠 ffff888126ce9000 （3） <4> [515.287267]
    -----------[ 從此處剪下 ]----------- <3> [515.287268] UBSAN：../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 處發生移位越界 <3> [515.287271] 移位指數 -1 為負數 <4> [515.287275] CPU：7 UID：0 PID：3108 通訊：kworker/u64:33 已污染：G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT（自願）<4> [515.287279] 已污染：[S]=CPU_OUT_OF_SPEC，[U]=使用者 <4> [515.287279] 硬體名稱：ASUS 系統產品名稱/PRIME Z790-P WIFI，BIOS 1645 2024/03/15 <4> [515.287281] 工作佇列：drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] 呼叫追蹤：<4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 (CVE-2025-71305)

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

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

  - mm/vmalloc：可以從兩個路徑同時叫用 Shrinker decay_va_pool_node（） 中的 take vmap_purge_lock：清除集區時的 __purge_vmap_area_lazy（），以及透過 vmap_node_shrink_scan（） 的 Shrinker。
    然而，decay_va_pool_node（） 並發運行並不安全，而且縮減器路徑目前缺乏序列化，導致爭用和可能的洩露。透過在壓縮器路徑中進行vmap_purge_lock來保護 decay_va_pool_node（），以確保與清除使用者一起序列化。（CVE-2026-46093）

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

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

  - ata： libata-scsi：避免非 NCQ 指令匱乏 當執行 NCQ 指令時發出非 NCQ 指令時，ata_scsi_qc_issue（） 會向 SCSI 層指示應傳回 SCSI_MLQUEUE_XXX_BUSY 來延遲發出指令。此命令延遲是正確的，並且符合ACS規範的規定，因為NCQ和非NCQ命令不能混合使用。但是，在使用多個提交佇列的主機配接卡的情況下，當目標裝置處於 NCQ 命令的持續負載下時，無法保證稍後會執行將非 NCQ 命令重新排入佇列，並且可能會重複延遲，因為其他提交佇列可能會不斷地在非 NCQ 命令之前從不同的 CPU 發出 NCQ 命令。這可能會導致非 NCQ 命令的執行延遲很長，甚至在最壞的情況下完全耗盡這些命令。由於區塊層和 SCSI 層不區分可排入佇列 （NCQ） 和不可排入佇列 （non-NCQ） 命令，因此 libata-scsi SAT 實作必須確保在存在 NCQ 指令流量的情況下，非 NCQ 指令的前送進度。
    這類似於具有硬體/韌體型 SAT 實作的 SAS HBA 所做的事情。透過限制來自 ata_scsi_qc_issue（） 的非 NCQ 命令重新排隊來實作此類前向進度保證：當收到非 NCQ 命令且 NCQ 命令正在進行中時，不要透過傳回 SCSI_MLQUEUE_XXX_BUSY 來強制非 NCQ 命令重新排隊，而是傳回 0 以表示命令已被接受，但使用 struct ata_port 的新 deferred_qc 欄位保留 qc。一旦所有進行中的命令完成，就會使用工作項目deferred_qc_work執行函式 ata_scsi_deferred_qc_work （） 發出此延遲的 qc，並使用埠 qc_defer（） 回呼傳回值進行檢查，指出不需要進一步延遲。此檢查是使用從 ata_scsi_qc_complete（） 呼叫的協助函式 ata_scsi_schedule_deferred_qc（） 來完成的。因此，這會從 ATA EH 發出的所有內部非 NCQ 命令中排除此機制。當埠deferred_qc為非空時，亦即埠具有等待裝置佇列清空的命令，則會使用一般忙碌機制延遲發出所有傳入命令 （NCQ 及非 NCQ）。這簡化了程式碼，還可以避免在使用者發出過多非 NCQ 命令時潛在的拒絕服務問題。最後，每當排程 ata EH 時，無論原因為何，延遲的 qc 一律會重新排入佇列，以便在 EH 完成後重試。這是透過從 ata_eh_set_pending（） 呼叫函數 ata_scsi_requeue_deferred_qc（） 來完成的。這避免了在 NCQ 錯誤、鏈路或設備重置或設備逾時的情況下對延遲的 qc 進行任何特殊處理。
    (CVE-2026-45855)

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

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

  - apparmor：修正未設定export_binary時對 rawdata 的無效解除參照 如果在執行階段停用 export_binary 參數，則在此之前載入的設定檔仍會將其原始資料儲存在 apparmorfs 中，並在原則目錄上提供指向原始資料的符號連結。替換其中一個設定檔時，rawdata 會設定為 NULL，但當嘗試解析該設定檔的 rawdata 的符號連結時，當 profile->rawdata 現在為 NULL 時，它會嘗試取消參照 profile->rawdata->name ，從而導致 oops。透過檢查是否設定了 rawdata 來修復它。[ 168.653080] 錯誤：核心 NULL 指標解除參照，位址：
    0000000000000088 [ 168.657420] #PF：核心模式下的主管讀取存取權 [ 168.660619] #PF：
    error_code（0x0000） - 不存在頁面 [ 168.663613] PGD 0 P4D 0 [ 168.665450] 哎呀：哎呀：0000 [#1] SMP NOPTI [ 168.667836] CPU：1 UID：0 PID：1729 通訊：ls 未受污染 6.19.0-rc7+ #3 PREEMPT（自願） [168.672308] 硬體名稱：QEMU Ubuntu 24.04 PC （i440FX + PIIX， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP： 0010：rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] 代碼： 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 4883 EC 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP：
    0018：ffffcdcb8200fb80 EFLAGS： 00010282 [ 168.690871] RAX： ffffffffaee74ec0 RBX： 0000000000000000000 RCX：
    ffffffffb0120158 [ 168.692251] RDX：ffffcdcb8200fbe0 RSI：ffff88c187c9fa80 RDI：ffff88c186c98a80 [168.693593] RBP：ffffcdcb8200fbc0 R08： 0000000000000000 R09： 000000000000000000 [ 168.694941] R10：
    0000000000000000000 R11： 000000000000000000 R12： ffff88c186c98a80 [ 168.696289] R13： 00007fff005aaa20 R14：
    0000000000000080 R15： ffff88c188f4fce0 [ 168.697637] FS： 0000790e81c58280（0000） GS：ffff88c20a957000（0000） knlGS：00000000000000000 [ 168.699227] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [ 168.700349] CR2：
    0000000000000088 CR3： 000000012fd3e000 CR4： 0000000000350ef0 [ 168.701696] 呼叫追蹤： [ 168.702325] <TASK> [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] ] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ？ do_statx+0x72/0xb0 [168.711109] ？ putname+0x3e/0x80 [ 168.711845] ？ __x64_sys_statx+0xb7/0x100 [ 168.712711] ？ x64_sys_call+0x10fc/0x26b0 [ 168.713577] ？ do_syscall_64+0xbf/0x500 [ 168.714412] ?do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ？ irqentry_exit+0xb2/0x740 [ 168.716359] ？ exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-45965）

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

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

  - net： caif：拆卸時清除用戶端服務指標 'caif_connect（）' 可以在遠端關機後呼叫 'caif_disconnect_client（）' 後接 'caif_free_client（）' 來卸除現有用戶端。
    'caif_free_client（）' 會釋放 'adap_layer->dn' 所引用的服務層，但會讓該指標保持過時狀態。當通訊端稍後遭到破壞時，'caif_sock_destructor（）' 會再次呼叫 'caif_free_client（）' 並解除參照釋放的服務指標。釋放服務物件之前，請先清除用戶端/服務連結，讓重複的拆卸變得無害。（CVE-2026-46098）

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

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

  - ALSA： usb-audio：停止剖析 MAX_NR_RATES parse_uac2_sample_rate_range（） 處的 UAC2 速率會將列舉速率的數量限制為 MAX_NR_RATES，但它只會跳出目前的速率迴圈。具有額外三元組的格式錯誤的 UAC2 RANGE 響應繼續解析剩餘的三元組，並在探針仍保持register_mutex時重複打印無效的 uac2 速率。一旦達到上限，就停止整個剖析，並傳回目前收集的費率數目。（CVE-2026-46018）

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

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

  - net： strparser：修正 strp_abort_strp（） 中的skb_head洩漏 當資料流剖析器中止時 （例如在訊息組合逾時之後），它仍然可以在 strp->skb_head 中保留對部分組合訊息的參照。該 skb 不會在 strp_abort_strp（） 中釋放，這會洩漏部分組合的訊息，並且可以重複觸發以耗盡記憶體。透過釋放 strp->skb_head 並在中止路徑中重設剖析器狀態來修正此問題。保持 strp_stop（） 不變，以便在工作和計時器同步後仍會在 strp_done（） 中進行最終清理。（CVE-2026-46102）

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

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

  - ext4：修正 ext4_xattr_inode_dec_ref_all（） 中缺少的 brelse（） 提交 c8e008b60492 （ext4：忽略過去的 xattrs） 在 block_csum 為 false 時引入了參照計數洩漏。ext4_xattr_inode_dec_ref_all（） 呼叫 ext4_get_inode_loc（） 來取得 iloc.bh，但從不使用 brelse（） 釋放它。（CVE-2026-46046）

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本的 BGP NLRI (網路層可達性資訊) 解碼器中包含一個堆疊型緩衝區溢位弱點。src/bgp_protocol.cpp 中的函式 decode_bgp_subnet_encoding_ipv4_raw() 直接從 BGP 封包 (第 99 行) 讀取prefix_bit_length，而不驗證 IPv4 前置詞是否 <= 32。此值會被傳遞至 how_much_bytes_we_need_for_storing_certain_subnet_mask()，該函式會計算 ceil(prefix_bit_length / 8)，導致對於 prefix_bit_length 為 255 的情況最多返回 32 個位元組。這個返回值會被用作 memcpy() 的長度引數 (第 106 行)，而 memcpy() 會將數據複製到大小為 4 位元組的 uint32_t 堆疊變數 (prefix_ipv4) 中。這會導致最多 28 位元組發生堆疊緩衝區溢位，而攻擊者則可藉此來執行任意程式碼。此外，未經驗證的 prefix_bit_length 會被傳遞至 convert_cidr_to_binary_netmask_local_function_copy() (第 111 行)，其中當 cidr > 32 時，(32 - cidr) 的移位會導致未定義的行為。(CVE-2026-48686)

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

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

  - rxrpc： 修正 conn 層級封包處理以取消共用 RESPONSE 封包 驗證 RESPONSE 封包的安全作業會就地解密其中的位元 - 但是，sk_buff可能會與封包嗅探器共用，這會導致嗅探器看到明顯損毀的封包 （實際上已解密）。如果封包已複製，請將封包副本交給特定安全性處理常式，以修正此問題。
    (CVE-2026-46000)

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

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

  - ext4：分割範圍失敗時捨棄範圍快取 當分割範圍失敗時，我們可能會讓某些範圍仍在處理中，並直接傳回錯誤，這會導致過時的範圍項目保留在範圍狀態樹狀結構中。因此，如果分割失敗，請捨棄所有剩餘的潛在過時範圍。（CVE-2026-45899）

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

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

  - Ceph：修正加密配置失敗時的 num_ops 差一錯誤 move_dirty_folio_in_page_array（） 如果檔案已加密、已變更的對開本不是批次中的第一個，且無法配置退回緩衝區來保存密文，則可能會失敗。發生這種情況時，ceph_process_folio_batch（） 只會重新弄髒對開本並排清目前批次 -- 它可以在未來的批次中重試該對開本。但是，如果這個失敗的對開本與最後一個進入批次的對開本不相鄰，則 ceph_process_folio_batch（） 已經遞增了「ceph_wbc->num_ops」;因為它沒有跟進並將不連續的作品集添加到陣列中，所以 ceph_submit_write（） -- 它期望 'ceph_wbc->num_ops' 準確地反映回寫中連續範圍的數量 （因此所需的寫入範圍操作數量） -- 會使核心恐慌：BUG_ON（ceph_wbc->op_idx + 1 ！= req->r_num_ops）;此問題可在受影響的核心上重現，方法是以 4KiB 寫入/4KiB 跳過/重複模式寫入已啟用 fscrypt 的 CephFS 檔案 （檔案大小總大小無關緊要），並逐漸增加系統的記憶體壓力，直到反彈緩衝區配置失敗為止。當 move_dirty_folio_in_page_array（） 失敗時，將 'ceph_wbc->num_ops' 遞減回正確值，但對開本已開始計算新的 （亦即仍為空白） 範圍，藉此修正此損毀。此修補程式更正的缺陷自 2022 年以來一直存在（請參閱第一個「修正：」），但另一個錯誤直到最近才阻止多對開加密回寫（請參閱第二個「修正：」）。第二次提交進入 6.18.16了 、 6.19.6和 7.0-rc1，揭開了這些版本中的錯誤。因此，此修補程式修正了由 cac190c7674f 引入的迴歸 （錯誤）。（CVE-2026-46066）

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

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

  - drm/exynos： vidi：修正以避免直接解除參照使用者指標 在 vidi_connection_ioctl（） 中，vidi->edid（使用者指標） 在核心中直接解除參照。這允許從使用者空間存取任意核心記憶體，因此我們應該修改它，而不是直接存取核心中的使用者指標，而是使用 copy_from_user（） 將 edid 複製到核心記憶體並使用它。（CVE-2026-45958）

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

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

  - mfd：亞利桑那州：修正 wm5102_clear_write_sequencer（） 失敗時的調節器資源洩漏 wm5102_clear_write_sequencer（） 協助程式可能會傳回錯誤並返回，繞過清理序列並導致調節器保持啟用狀態，從而導致資源洩漏。將直接返回變更為跳至err_reset標籤，以適當釋放資源。（CVE-2026-45875）

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

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

  - ipv4： icmp：使用 icmp_pointers 之前先驗證回覆類型 延伸回應回覆會使用 ICMP_EXT_ECHOREPLY 作為出埠回覆類型。該值超出了 所涵蓋 icmp_pointers[]的範圍，它僅描述了最多 NR_ICMP_TYPES 的傳統 ICMP 類型。避免諮詢 icmp_pointers[] 超出該範圍的回覆類型，並使用 array_index_nospec（） 進行其餘的範圍內查詢。一般 ICMP 回覆會維持其現有行為不變。（CVE-2026-46037）

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

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

  - hwrng： core - 使用 RCU 和 work_struct 來修正爭用情形 目前，直到 hwrng_fillfn（） 執行緒結束，才會清除hwrng_fill。由於 hwrng_unregister（） 讀取rng_mutex鎖定之外的hwrng_fill，因此並行 hwrng_unregister（） 可能會在同一任務上再次呼叫 kthread_stop（）。此外，如果在 hwrng_register（） 之後立即呼叫 hwrng_unregister（），則停止的執行緒可能從未被執行過。因此，即使在 hwrng_unregister（） 傳回之後，hwrng_fill 仍會保持髒狀態。在這種情況下，後續對 hwrng_register（） 的呼叫將無法啟動新的執行緒，並且 hwrng_unregister（） 將在同一個釋放的任務上呼叫 kthread_stop（）。在這兩種情況下，都會發生釋放後使用：refcount_t：在 0 上加法;釋放後使用。
    警告：...lib/refcount.c：25 refcount_warn_saturate+0xec/0x1c0 呼叫追蹤：kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 此修補程式透過保護 rng_mutex 鎖定內的全域 hwrng_fill 指標來修正爭用，因此 hwrng_fillfn（） 執行緒只會停止一次，並且對 kthread_run（） 和 kthread_stop（） 的呼叫會在持有的鎖定的情況下序列化。為了避免 hwrng_fillfn（） 在保持鎖定的情況下停止時出現鎖死，我們將 current_rng 轉換為 RCU，以便 get_current_rng（） 可以在不保持鎖定的情況下讀取current_rng。為了從 put_rng（） 中刪除鎖定，我們還將實際清理延遲到work_struct中。由於 get_current_rng（） 不再傳回ERR_PTR值，因此會從呼叫端移除 IS_ERR（） 檢查。當 hwrng_fill 受到 rng_mutex 鎖定保護時，hwrng_fillfn（） 無法再清除 hwrng_fill 本身。因此，如果 hwrng_fillfn（） 在丟棄current_rng後直接傳回，則稍後會在釋放的task_struct上呼叫 kthread_stop（）。為了解決此問題，hwrng_fillfn（） 現在呼叫 schedule（） 以使任務保持活動狀態，直到停止為止。kthread_stop（） 呼叫也從 hwrng_unregister（） 移至 drop_current_rng（），確保在 current_rng 變為 NULL 的所有可能路徑上呼叫 kthread_stop（），這樣執行緒就不會永遠等待。（CVE-2026-45949）

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本在 dynamic_binary_buffer_t 類別 (src/dynamic_binary_buffer.hpp) 中存在基於堆疊的緩衝區溢位漏洞。五種方法 (append_dynamic_buffer、append_data_as_pointer、append_data_as_object_ptr、memcpy_from_ptr、memcpy_from_object_ptr) 在進行錯誤的邊界檢查：使用了形式為「if (offset + length > maximum_internal_storage_size + 1)」的檢查，而不是正確的「if (offset + length > maximum_internal_storage_size)」。這允許在堆積配置緩衝區結尾之後寫入正好一個位元組。類別廣泛應用於 BGP 訊息編碼/解碼、NetFlow 範本處理和流程規範 NLRI 建置。攻擊者如果能夠向 FastNetMon 執行個體傳送網路流量 (NetFlow、sFlow、IPFIX 或 BGP)，就可以觸發此溢出，並透過破壞堆積中繼資料實現任意程式碼執行。值得注意的是，append_byte() 方法使用了正確的邊界檢查，證實了這種不一致。(CVE-2026-48689)

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

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

  - FastNetMon Community Edition 1.2.9 及之前版本的 Juniper 路由器整合 plugin 中包含一個作業系統命令插入弱點。src/juniper_plugin/fastnetmon_juniper.php (第 117-118 行) 中的 _log() 函式透過將 $msg 參數直接串連到 exec() 呼叫，來建構 shell 命令：
    exec(echo `date` \- {FASTNETMON] - . $msg . \ >> . $FILE_LOG_TMP). 此 $msg 變數包含從命令列引數 argv[1] 到 argv[3] 派生的未清理資料，代表攻擊的 IP 位址、方向及功率。雖然 FastNetMon 的 C++ 核心目前透過 inet_ntoa() 傳遞 IP 位址 (僅產生安全的點分十進制表示法)，但 PHP 腳本不會執行輸入驗證或 shell 逸出。如果該指令碼是由另一個協調流程系統直接調用，或未來的程式碼變更傳遞字串來源的 IP，則可以插入任意命令。正確的修復方法是將 exec() 替換為 file_put_contents()，或在所有參數上使用 escapeshellarg()。(CVE-2026-48687)

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

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

  - ipmi：ssif：在錯誤時清理 kthread 如果在建立 ssif kthread 之後，但在主 IPMI 程式碼啟動 ssif 介面之前發生錯誤，則 ssif kthread 將不會停止。因此，如果 kthread 正在運行，請確保它在錯誤情況下停止。（CVE-2026-46044）

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

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

  - LoongArch：為 syscall 分派表新增 spectre 邊界 LoongArch 系統調用號碼由使用者空間直接控制，但沒有 array_index_nospec（） 邊界來防止存取 systemcall 函數指標表。（CVE-2026-45993）

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

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

  - ext4：修正 e4b 點陣圖不一致報告 在混合大頁面工作負載下的壓力測試期間觀察到點陣圖不一致問題。Ext4 報告了多個 e4b 點陣圖檢查失敗，例如：
    ext4_mb_complex_scan_group：2508：根據群組資訊，群組 350、8179 個免費叢集。但得到了 8192 個區塊的分析和實驗證實，該問題是由頁面遷移和點陣圖修改之間的爭用情形引起的。雖然這個計時窗口極窄，但在實踐中還是被擊中的：
    folio_lock ext4_mb_load_buddy __migrate_folio檢查參照計數 folio_mc_copy __filemap_get_folio folio_try_get（對開本） ......mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock 此問題的根本原因是load_buddy的快速路徑只會增加作品集的參照計數，不足以防止並行作品集移轉。我們觀察到，對開移轉程序會取得對開鎖定。因此，我們可以透過檢查鎖定狀態來判斷是否在load_buddy中走快速路徑。如果作品集已鎖定，我們會選擇慢速路徑 （取得鎖定） 來關閉此並行視窗。此外，此變更還解決了以下問題： 啟用DOUBLE_CHECK巨集以檢查點陣圖相關問題時，可能會觸發下列錯誤：
    位元組 784 （6272） 處的群組 324 中的損毀：f in copy ！= ff on disk/prealloc 分析顯示這是誤報。有一個特定的爭用視窗，其中點陣圖和群組描述元會暫時變得不一致，從而導致此錯誤報告：ext4_mb_load_buddy ext4_mb_load_buddy
    __filemap_get_folio（create|lock） folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio（no lock） ......mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits（e4b->bd_bitmap） folio_unlock 原始邏輯假設由於從磁碟新載入點陣圖時呼叫 mb_cmp_bitmaps，因此對開鎖定足以防止並行存取。不過，這會忽略特定的爭用情形：如果另一個處理程序嘗試載入 buddy 並發現作品集已處於最新狀態，則會立即開始使用它，而不保留作品集鎖定。（CVE-2026-45942）

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

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

  - tpm2-sessions：修正 tpm2_read_public（） tpm2_read_public（） 呼叫 tpm_buf_init（） 中缺少的 tpm_buf_destroy（），但在兩個退出路徑上無法呼叫 tpm_buf_destroy（），導致頁面分配洩露：1. 當 name_size（） 傳回錯誤（無法識別的雜湊演算法）時，函數直接返回，不破壞緩衝區。2. 在成功路徑上，緩衝區在返回之前永遠不會被破壞。函式中的所有其他錯誤路徑都會在傳回之前正確呼叫 tpm_buf_destroy（）。透過新增缺少的 tpm_buf_destroy（） 呼叫來修正這兩個問題。（CVE-2026-46096）

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

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

  - drm/exynos： vidi：在 vidi_connection_ioctl（） 中使用 priv->vidi_dev 進行 ctx 查詢 vidi_connection_ioctl（） 會從 drm_dev->dev 擷取driver_data以取得結構vidi_context指標。然而，drm_dev->dev 是 exynos-drm 主設備，其中包含的driver_data不是 vidi 組件設備，而是完全不同的設備。這可能會導致各種錯誤，從空指標解除參照和垃圾值訪問，到不幸的情況下的越界錯誤、釋放後使用錯誤等等。為了解決這個問題，我們需要在綁定/解除綁定期間將 vidi 裝置指標儲存/刪除 exynos_drm_private->vidi_dev，然後在 ioctl（） 中讀取此 exynos_drm_private->vidi_dev，以取得正確的結構vidi_context指標。（CVE-2026-45956）

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

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

  - KVM： nSVM：避免清除 vmcb12 中的VMCB_LBR svm_copy_lbrs（） 一律在目的地 VMCB 中標示為已變更VMCB_LBR。但是，nested_svm_vmexit（） 使用它將 LBR 複製到 vmcb12，並且清除 vmcb12 中的乾淨位元並未在架構上定義。將 vmcb_mark_dirty（） 移至呼叫端，並針對 vmcb12 刪除它。這也有助於將未將整個 VMCB 傳遞至 svm_copy_lbrs（） 的傳入重構。（CVE-2026-46071）

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

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

  - netfilter： nft_set_rbtree：檢查匿名集中的部分重疊 使用者空間在間隔相鄰的情況下提供最佳化的表示，其中結束元素被省略。基於這個原因，現有的部分重疊偵測邏輯會跳過起始元素的匿名集檢查。但是，可以添加與此匿名重疊的間隔，其中兩個以相同的開始元素，例如。A-B、A-C 其中 C < B. 開始結束 A B 開始結束 A C 還原對重疊起始元素的檢查以報告重疊。（CVE-2026-45873）

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

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

  - gfs2：修正錯誤路徑中的記憶體洩漏gfs2_fill_super修正將檔案系統轉換為讀寫模式失敗時，gfs2_fill_super（） 錯誤處理路徑中的兩個記憶體洩漏。第一次洩漏：kthread 物件（thread_struct、task_struct 等）當 init_threads（） 成功後 gfs2_freeze_lock_shared（） 失敗時，建立的核心執行緒 （logd 和 quotad） 永遠不會被破壞。發生這種情況的原因是 fail_per_node 標籤未呼叫 gfs2_destroy_threads（）。第二次洩漏：配額點陣圖緩衝區 （8192 位元組） 當 gfs2_make_fs_rw（） 在 gfs2_quota_init（） 成功但其他作業完成之前失敗時，永遠不會釋放分配的配額點陣圖。此修正程式會將執行緒清除移至fail_per_node標籤，以統一處理所有錯誤路徑。
    無條件調用 gfs2_destroy_threads（） 是安全的，因為它會檢查 NULL 指標。gfs2_make_fs_rw（） 中新增了配額清理，以正確處理配額初始化成功但隨後撤回檔案系統的撤回情況。執行緒洩漏回溯（gfs2_freeze_lock_shared失敗）：未參照的物件0xffff88801d7bca80（大小 4480）：copy_process+0x3a1/0x4670 kernel/fork.c：2422 kernel_clone+0xf3/0x6e0 kernel/fork.c：2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c：478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c：611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c：1265 配額洩漏回溯（gfs2_make_fs_rw失敗）： 未參照的物件0xffff88812de7c000 （大小 8192）：
    gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c：1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c：149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c：1275 （CVE-2026-45961）

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

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

  - net：qrtr：ns：修正驅動程式 remove（） 中的釋放後使用在 remove 回呼中，如果封包在呼叫 destroy_workqueue（） 之後，但在 sock_release（） 之前到達，則 qrtr_ns_data_ready（） 回呼將嘗試將工作排入佇列，從而造成釋放後使用問題。透過在 qrtr_ns_init（） 期間儲存預設的「sk_data_ready」回呼並使用它來取代 remove（） 開頭的 qrtr_ns_data_ready（） 回呼來解決此問題。這樣可以確保即使封包在 destroy_workqueue（） 之後到達，工作結構也不會被取消參照。請注意，在銷毀工作佇列之前，也必須確保 RX 執行緒已完成，因為執行緒可能會使用 qrtr_ns_data_ready（） 回呼。
    (CVE-2026-46047)

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

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

  - thermal： core：修正熱區域調速器清除問題 如果在將熱調速器新增至要註冊的熱區域後，thermal_zone_device_register_with_trips（） 失敗，則不會適當地從中移除調速器，這可能會導致記憶體洩漏。反過來，thermal_zone_device_unregister（） 在未事先取得熱區域鎖定的情況下呼叫 thermal_set_governor（），這可能會與透過 sysfs 的調速器更新爭用，並可能導致在這種情況下釋放後使用。透過新增兩個 thermal_set_governor（） 呼叫來解決這些問題，一個呼叫到 thermal_release（） 以從指定的熱區域移除調速器，另一個呼叫到熱區域註冊錯誤路徑，以涵蓋熱區域裝置註冊之前的故障。（CVE-2026-46021）

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

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

  - media：rc：igorplugusb：注意一致性規則 在控制要求中，USB 要求結構可能會受到某些 HC 上的 DMA 約束。因此，它必須遵守 DMA 一致性規則。單獨分配。
    (CVE-2026-46091)

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

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

  - net：ks8851：還原停用 IRQ 處理常式周圍的 BH 如果驅動程式執行 ks8851_irq（） 且已傳送 TX 封包，則驅動程式會透過 netif_wake_queue（） 啟用 TX 佇列，以排程 TX softirq 將此裝置的封包排入佇列。如果設定了 CONFIG_PREEMPT_RT=y，並且 MAC 也收到了封包，則 ks8851_rx_pkts（） 會呼叫 netdev_alloc_skb_ip_align（） 為收到的封包配置 SKB。如果在啟用 BH 的情況下呼叫 netdev_alloc_skb_ip_align（），則 netdev_alloc_skb_ip_align（） 結尾的 local_bh_enable（） 將觸發擱置的 softirq 處理，這最終可能會呼叫 .xmit 回呼 ks8851_start_xmit_par（）。ks8851_start_xmit_par（） 會嘗試鎖定結構ks8851_net_par .lock 微調鎖，該結構已由呼叫 ks8851_start_xmit_par（） 的 ks8851_irq（） 鎖定。
    這會導致鎖死，核心會報告此鎖死，包括下面列出的追蹤記錄。如果未設定CONFIG_PREEMPT_RT，則自提交 0913ec336a6c0 （net： ks8851： 修正 SPI 晶片變體的鎖死） 之後，也可以在沒有 RX FIFO 中接收封包的情況下觸發鎖死。擱置中的 softirq 將在 ks8851_irq（） 中的 spin_unlock_bh（&ks->statelock） 傳回時進行處理，這也會觸發鎖死。透過停用關鍵區段（包括 IRQ 處理常式）周圍的 BH 來解決問題，從而防止 net_tx_action（） softirq 在這些關鍵區段期間觸發。一旦重新啟用 BH，並且在 IRQ 處理常式結束時，一旦所有其他 IRQ 處理常式動作都完成，就會觸發 net_tx_action（） softirq。__schedule從 schedule_rtlock+0x1c/0x34 schedule_rtlock 從 rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked 從 rt_spin_lock+0x60/0x9c rt_spin_lock 從 ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par 從 netdev_start_xmit+0x20/0x44 netdev_start_xmit 從 dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit 從 sch_direct_xmit+0xb8/0x25c sch_direct_xmit 從 __qdisc_run+0x1f8/0x4ec __qdisc_run 從 qdisc_run+0x1c/0x28 qdisc_run 從 net_tx_action+0x1f0/0x268 net_tx_action 從 handle_softirqs+0x1a4/0x270 handle_softirqs
    __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip從 __alloc_skb+0xd8/0x128 __alloc_skb
    __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb 從 ks8851_irq+0x388/0x4d4 ks8851_irq 從 irq_thread_fn+0x24/0x64 irq_thread_fn 從 irq_thread+0x178/0x28c irq_thread 從 kthread+0x12c/0x138 kthread 從 ret_from_fork+0x14/0x28 （CVE-2026-46031）

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

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

  - fbdev： defio：中斷延遲的 I/O 與結構fb_info 保留結構 fb_deferred_io_state 中延遲 I/O 的狀態。在初始化延遲 I/O 的過程中配置執行個體，並僅在關閉最終對應之後將其移除。如果fb_info和包含的延遲 I/O 同時消失，請清除 struct fb_deferred_io_state.info 以使對應無效。任何存取都會產生 SIGBUS 訊號。修正了一個長期存在的問題，即當使用者空間仍有圖形記憶體的作用中對應時，就會發生裝置熱拔拔問題。hot- unplug 釋放 struct fb_info 的實例。存取記憶體將在未定義狀態下運作。（CVE-2026-46065）

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

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

  - 暫存：greybus：lights：在配置 channels 陣列之前避免 NULL 解除參照 gb_lights_light_config（） 儲存channel_count。如果 kcalloc（） 失敗，gb_lights_release（） 會反覆運算非零計數，並解除參照 light->channels，這是 NULL。先配置通道，然後才發佈channels_count，讓清除路徑無法遍歷 NULL 指標。（CVE-2026-45978）

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

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

  - ext2：拒絕 ext2_iget（） 中具有零i_nlink和有效模式的 inode ext2_iget（） 已經在 i_mode 為零或設定了 i_dtime 時拒絕具有 i_nlink == 0 的 inode，將它們視為已刪除。然而，具有非零模式和零 dtime 的 i_nlink == 0 的情況會溜走。由於 ext2 沒有孤立清單，因此這種組合只能由檔案系統損毀引起 - 合法的 inode 刪除總是在釋放 inode 之前設定i_dtime或清除i_mode。特製的映像可以利用此間隙向 VFS 呈現這樣的 inode，然後 VFS 透過 ext2_unlink（）、ext2_rename（） 和 ext2_rmdir（） 觸發 drop_nlink（） （fs/inode.c） 內部的WARN_ON： 警告： CPU：3 PID：609 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：3 UID：0 PID：609 通訊： syz-executor 未受 6.12.77污染 + #1 呼叫追蹤： <TASK> inode_dec_link_count include/linux/fs.h：2518 [內嵌] ext2_unlink+0x26c/0x300 fs/ext2/namei.c：295 vfs_unlink+0x2fc/0x9b0 fs/namei.c：4477 do_unlinkat+0x53e/0x730 fs/namei.c：4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c：4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 警告： CPU：0 PID：646 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：0 UID：0 PID：646 通訊：syz.0.17 未受污染 6.12.77+ #1 呼叫追蹤： <TASK> inode_dec_link_count include/linux/fs.h：2518 [內聯] ext2_rename+0x35e/0x850 fs/ext2/namei.c：374 vfs_rename+0xf2f/0x2060 fs/namei.c：5021 do_renameat2+0xbe2/0xd50 fs/namei.c：5178
    __x64_sys_rename+0x7e/0xa0 fs/namei.c：5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 警告： CPU：0 PID：634 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：0 UID：0 PID：634 Comm：syz-executor 未受 6.12.77污染 + #1 呼叫追蹤： <TASK> inode_dec_link_count include/linux/fs.h：2518 [內嵌] ext2_rmdir+0xca/0x110 fs/ext2/namei.c：311 vfs_rmdir+0x204/0x690 fs/namei.c：4348 do_rmdir+0x372/0x3e0 fs/namei.c：4407
    __x64_sys_unlinkat+0xf0/0x130 fs/namei.c：4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 擴展現有的 i_nlink == 0 檢查以同時捕獲此案例，透過 ext2_error（） 報告損毀並傳回 -EFSCORRUPTED。這會在載入時拒絕 inode，並防止其到達任何 namei.c 路徑。由 Linux 驗證中心 （linuxtesting.org） 與 Syzkaller 一起找到。（CVE-2026-46002）

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

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

  - md/raid5：修正 retry_aligned_read（） 中的軟鎖定 當 retry_aligned_read（） 遇到重疊的等量時，它會透過 raid5_release_stripe（） 釋放等量，將其放在無鎖定的 released_stripes llist 上。在下一個 raid5d 迴圈迭代中，release_stripe_list（） 將條帶排空到handle_list上（因為STRIPE_HANDLE是由原始 IO 設定的），但 retry_aligned_read（） 在 handle_active_stripes（） 之前運行，並透過 find_get_stripe（） -> list_del_init（） 從handle_list中刪除條帶。這可以防止 handle_stripe（） 處理等量以解決重疊，從而導致無限迴圈和軟鎖定。在失敗路徑中使用 __release_stripe（） 搭配 temp_inactive_list 而不是 raid5_release_stripe（） 來修正此問題，讓等量不會通過 released_stripes llist。這使得 raid5d 能夠跳脫其迴圈，並且當條帶最終被 handle_stripe（） 處理時，重疊將得到解決。（CVE-2026-46051）

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

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

  - iommu/vt-d：在使用 PASID 表之前排清快取 將新配置的零初始化 PASID 表的位址寫入 PASID 目錄項目時，請在此 PASID 表的 CPU 快取排清之後執行此操作，而不是在它之前，以避免此 PASID 表可能已經被非一致 IOMMU 硬體使用的時間範圍，而其在 RAM 中的內容仍然是一些隨機的舊資料， 未初始化為零。
    (CVE-2026-45862)

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

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

  - mm：修正移轉期間延遲的分割佇列爭用 migrate_folio_move（） 會記錄來自 src 的延遲分割佇列狀態，並在 DST 上重播。在 remove_migration_ptes（src， dst， 0） 之後重播它會使 dst 在重新排隊之前可見，因此並行的 rmap 移除路徑可以將 dst 標記為部分映射並觸發 deferred_split_folio（） 中的 WARN。在 remove_migration_ptes（） 之前移動重新佇列，以便在 dst 再次可見之前回到延遲的分割佇列上。由於移轉此時仍會鎖定 dst，因此當 folio_trylock（） 失敗時，教導 deferred_split_scan（） 將對開本重新排入佇列。否則，完整對應的未充分利用對開本可能會被縮小器出列，並從split_queue中無訊息地遺失。[ziy@nvidia.com：移動評論]（CVE-2026-46017）

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

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

  - power： supply： wm97xx： 修正 power_supply_changed（） 中的 NULL 指標解除參照 在 'probe（）' 中，在配置/註冊 'power_supply' 控制碼之前呼叫 'request_irq（）'。如果在呼叫 'request_irq（）' 和 'power_supply_register（）' 之間觸發中斷，則 'power_supply' 句柄將在 'wm97xx_bat_update（）' 的 'power_supply_changed（）' 中以未初始化的方式使用 （從中斷處理常式觸發）。
    這將導致 'NULL' 指標解除參照，因為 透過確保在註冊 'power_supply' 控制碼之後 _ 請求 IRQ 來修正此 racy 'NULL' 指標解除參照。由於 IRQ 現在是 'probe（）' 中的最後一個請求，因此請刪除釋放它的錯誤路徑。相反，新增一個用於在 IRQ 請求失敗時取消註冊「power_supply」句柄。（CVE-2026-45869）

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

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

  - ext4：修正 fs 關機時 dirtyclusters 雙重遞減 fstests 測試 generic/388 偶爾會在 ext4_put_super（） 中重現與髒叢集計數相關的警告： 警告： fs/ext4/super.c：1324 處的 CPU：7 PID：76064 ext4_put_super+0x48c/0x590 [ext4] 追蹤失敗會顯示，由於s_dirtyclusters_counter值為 -1，因此觸發警告。IOW，這似乎是一種虛假的遞減，而不是某種洩漏。進一步追蹤已變更叢集計數差異，並對產生的輸出進行 LLM 掃描，將原因識別為 ext4_mb_mark_diskspace_used（） 與呼叫端 ext4_mb_new_blocks（） 之間的錯誤路徑雙重遞減。首先，請注意 generic/388 是關機與 fsstress 測試，因此會產生一組隨機操作和關機注入。在有問題的情況下，關機會觸發從 ext4_mb_mark_context（） 進行的 ext4_handle_dirty_metadata（） 呼叫的錯誤傳回。
    此時更改的值為非零，因此 ext4_mb_mark_diskspace_used（） 在錯誤從 ext4_mb_mark_context（） 冒泡後不會退出。相反地，前者會遞減兩個叢集計數器，並將錯誤傳回至 ext4_mb_new_blocks（） 。後者會落入 ！ar->len out 路徑，這會第二次遞減髒叢集計數器，造成不一致。若要避免此問題，並簡化此程式碼路徑中叢集保留的擁有權，請將計數器縮減提升至呼叫端中的單一位置。這更清楚說明 ext4_mb_new_blocks（） 負責在 ！delalloc 案例中取得叢集保留 （透過 ext4_claim_free_clusters（）） 以及釋放叢集保留，無論它最終是否因失敗而耗用或傳回。（CVE-2026-45920）

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

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

  - HID： intel-ish-hid：修正 ishtp_bus_remove_all_clients 中的 NULL-ptr-deref 在暖重設流程期間，如果在用戶端仍在列舉時發生重設，則 cl->device 指標可能是 NULL。在沒有 NULL 檢查的情況下存取 cl->device->reference_count 會導致核心錯誤。此問題是在多單元熱重啟壓力克萊克爾期間發現的。對 cl->device 新增防禦性 NULL 檢查，以確保在此類密集測試條件下的穩定性。KASAN：範圍 [0000000000000000-0000000000000007] 工作佇列中的 null-ptr-deref：ish_fw_update_wq fw_reset_work_fn 呼叫追蹤：ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp] ishtp_reset_handler+0x85/0x1a0 [intel_ishtp] fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc] （CVE-2026-45877）

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

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

  - xfs：修正 xfs_alloc_buftarg（） 中的資源洩漏 在錯誤路徑中，呼叫 fs_put_dax（） 以刪除 DAX 裝置參照。（CVE-2026-46005）

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

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

  - RDMA/uverbs：在 ib_uverbs_post_send ib_uverbs_post_send（） 中使用wqe_size之前先對其進行驗證，在將cmd.wqe_size傳遞給 kmalloc（） 並使用分配的緩衝區作為結構ib_uverbs_send_wr之前，無需任何驗證即可使用來自使用者空間的。如果使用者提供較小的wqe_size值 （例如 1），則 kmalloc（） 會成功，但後續存取 user_wr->opcode、user_wr->num_sge 和其他欄位的讀取範圍超出配置的緩衝區，導致從核心堆記憶體進行越界讀取。這可能會將敏感的核心資訊洩露給使用者空間。此外，提供過大的wqe_size可能會在記憶體配置路徑中觸發警告，如 syzkaller 所報告的那樣。這與 ib_uverbs_unmarshall_recv（） 不一致，後者在繼續之前正確驗證 wqe_size >= sizeof（struct ib_uverbs_recv_wr）。對 ib_uverbs_post_send（） 新增相同的驗證，以確保wqe_size至少為 sizeof（struct ib_uverbs_send_wr）。（CVE-2026-45856）

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

ID	名稱	嚴重性
317207	Linux Distros 未修補弱點：CVE-2026-45883	medium
317206	Linux Distros 未修補弱點：CVE-2026-46032	medium
317205	Linux Distros 未修補的弱點：CVE-2026-48683	medium
317204	Linux Distros 未修補弱點：CVE-2026-46089	medium
317203	Linux Distros 未修補的弱點：CVE-2026-45963	medium
317202	Linux Distros 未修補弱點：CVE-2026-46058	high
317201	Linux Distros 未修補的弱點：CVE-2026-46088	medium
317200	Linux Distros 未修補弱點：CVE-2026-45860	high
317199	Linux Distros 未修補弱點：CVE-2026-48691	critical
317198	Linux Distros 未修補弱點：CVE-2025-71305	medium
317197	Linux Distros 未修補的弱點：CVE-2026-46093	high
317196	Linux Distros 未修補的弱點：CVE-2026-45855	medium
317195	Linux Distros 未修補弱點：CVE-2026-45965	medium
317194	Linux Distros 未修補弱點：CVE-2026-46098	medium
317193	Linux Distros 未修補的弱點：CVE-2026-46018	medium
317192	Linux Distros 未修補弱點：CVE-2026-46102	high
317191	Linux Distros 未修補的弱點：CVE-2026-46046	medium
317190	Linux Distros 未修補弱點：CVE-2026-48686	critical
317189	Linux Distros 未修補弱點：CVE-2026-46000	medium
317188	Linux Distros 未修補的弱點：CVE-2026-45899	medium
317187	Linux Distros 未修補的弱點：CVE-2026-46066	medium
317186	Linux Distros 未修補弱點：CVE-2026-45958	high
317185	Linux Distros 未修補弱點：CVE-2026-45875	medium
317184	Linux Distros 未修補弱點：CVE-2026-46037	high
317183	Linux Distros 未修補弱點：CVE-2026-45949	medium
317182	Linux Distros 未修補弱點：CVE-2026-48689	critical
317181	Linux Distros 未修補弱點：CVE-2026-48687	critical
317180	Linux Distros 未修補弱點：CVE-2026-46044	medium
317179	Linux Distros 未修補的弱點：CVE-2026-45993	medium
317178	Linux Distros 未修補的弱點：CVE-2026-45942	high
317177	Linux Distros 未修補的弱點：CVE-2026-46096	medium
317176	Linux Distros 未修補弱點：CVE-2026-45956	high
317175	Linux Distros 未修補弱點：CVE-2026-46071	medium
317174	Linux Distros 未修補弱點：CVE-2026-45873	medium
317173	Linux Distros 未修補弱點：CVE-2026-45961	medium
317172	Linux Distros 未修補弱點：CVE-2026-46047	high
317171	Linux Distros 未修補弱點：CVE-2026-46021	medium
317170	Linux Distros 未修補弱點：CVE-2026-46091	medium
317169	Linux Distros 未修補弱點：CVE-2026-46031	high
317168	Linux Distros 未修補的弱點：CVE-2026-46065	high
317167	Linux Distros 未修補的弱點：CVE-2026-45978	medium
317166	Linux Distros 未修補弱點：CVE-2026-46002	medium
317165	Linux Distros 未修補的弱點：CVE-2026-46051	medium
317164	Linux Distros 未修補弱點：CVE-2026-45862	high
317163	Linux Distros 未修補弱點：CVE-2026-46017	medium
317162	Linux Distros 未修補弱點：CVE-2026-45869	medium
317161	Linux Distros 未修補弱點：CVE-2026-45920	high
317160	Linux Distros 未修補的弱點：CVE-2026-45877	medium
317159	Linux Distros 未修補弱點：CVE-2026-46005	medium
317158	Linux Distros 未修補弱點：CVE-2026-45856	high

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

high

medium

high

critical

medium

high

medium

medium

medium

medium

high

medium

critical

medium

medium

medium

high

medium

high

medium

critical

critical

medium

medium

high

medium

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

medium

medium

high

medium

medium

high