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

  - KVM： SVM：新增 LBR MSR 的遺漏儲存/還原處理 MSR_IA32_DEBUGCTLMSR 和 LBR MSR 目前未由 KVM_GET_MSR_INDEX_LIST列舉，且無法使用 KVM_SET_MSRS 設定 LBR MSR。所以保存/恢復完全損壞了。透過將 MSR 新增至 msrs_to_save_base 來修正此問題，並在啟用 LBR 虛擬化的情況下，僅允許從使用者空間寫入 LBR MSR （因為它們是唯讀 MSR）。此外，若要在 L2 執行時正確還原 L1 的 LBR，請確定 LBR 是從 svm_copy_vmrun_state（） 中擷取的 VMCB01 儲存區域複製的。請注意，針對 VMX，這也會修正MSR_IA32_DEBUGCTLMSR未回報為要儲存/還原的 MSR 的缺陷。請注意 #2，在 Intel 上過度報告MSR_IA32_LASTxxx是可以的，因為 KVM 已經處理了不支援的讀取和寫入，這要歸功於提交 b5e2fec0ebc3 （KVM：忽略沒有效果的 DEBUGCTL MSR）（kvm_do_msr_access（） 會將不支援的使用者空間寫入轉換為 nop）。[肖恩：LBRV 檢查守衛，按摩變更日誌]（CVE-2026-46014）

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

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

  - cpuidle：當只有一個閒置狀態可用時，跳過調速器 在某些平台 （沒有 power-mgt DT 節點的 PowerNV 系統） 上，cpuidle 可能只註冊一個閒置狀態。如果該單一狀態是輪詢狀態 （狀態 0），階梯調控者可能會錯誤地將狀態 1 視為第一個可用狀態，並傳遞越界索引。這可能會導致叫用 NULL 輸入回呼，最終導致系統損毀。[ 13.342636] cpuidle-powernv：只有貪睡可用 [ 13.351854] 錯誤指令位址：0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 透過在 cpuidle_select（） 中新增一個救助機制來解決這個問題，該救助機制在 state_count <= 1 時直接傳回狀態 0，繞過調速器並保持滴答程式運行。（CVE-2026-45968）

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

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

  - FastNetMon Community Edition through 在 1.2.9 封包擷取緩衝區配置中包含整數溢位弱點。在 src/packet_storage.hpp 中，allocate_buffer（） 函數使用無符號 int （32 位元） 算術將memory_size_in_bytes計算為「buffer_size_in_packets * （max_captured_packet_size + sizeof（fastnetmon_pcap_pkthdr_t）） + sizeof（fastnetmon_pcap_file_header_t）」。在 max_captured_packet_size=1500 和 sizeof（fastnetmon_pcap_pkthdr_t）=16 的情況下，每個封包大約需要 1516 個位元組。如果buffer_size_in_packets超過大約 2,832,542，則乘法會溢位，導致分配比預期小得多。隨後的 write_packet（） 呼叫會寫入已分配的緩衝區，從而導致堆積損毀。buffer_size_in_packets 值衍生自 ban_details_records_count 組態參數，該參數使用 atoi（） 剖析，沒有溢位檢查。（CVE-2026-48690）

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

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

  - 還原 hwmon： （ibmpex） 修正高/低存放區中的釋放後使用 這會還原提交 6946c726c3f4c36f0f049e6f97e88c510b15f65d。Jean Delvare 指出，該修補程式並沒有完全解決報告的問題，它實際上引入了（新的）爭用條件，而且實際上可能一開始就不需要它。各種人工智慧評論都同意這一點。特定且相關的 AI 意見反應：此重新排序會將驅動程式資料設定為 Null，然後移除下列迴圈中的感應器屬性。ibmpex_show_sensor（） 會透過 dev_get_drvdata（） 擷取此驅動程式資料，但在取消參照以存取 data->sensors[] 之前，不會檢查它是否為 NULL。如果使用者空間進程在此刪除函式執行時讀取感測器檔案（如 temp1_input），它是否會與此處的 dev_set_drvdata（...， NULL） 呼叫爭用並在 ibmpex_show_sensor（） 中崩潰？在清除驅動程式資料之前保留呼叫 device_remove_file（） 的原始順序會更安全嗎？device_remove_file（） 應等待任何作用中的 sysfs 回呼完成，這可能已經阻止了此修補程式打算修正的釋放後使用問題。還原有問題的修補程式。如果可以證明最初報告的所謂爭用條件確實存在，則始終可以通過完全修復重新引入它。（CVE-2026-45914）

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

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

  - erofs：修正 ztailpacking pcluster 的內嵌資料讀取失敗 ztailpacking pcluster 的壓縮對開本必須有效，才能將這些 pcluster 新增至 I/O 鏈。否則，z_erofs_decompress_pcluster（） 可能會假設它們已經有效，然後觸發 NULL 指標解除參照。它有點難以重現，因為內聯資料與壓縮索引的尾部位於同一區塊中，壓縮索引通常在之前讀取。但是，如果在 read_mapping_folio（） 執行時出現致命訊號，仍可能發生這種情況，如下所示： erofs：（裝置 dm-1）：
    z_erofs_pcluster_begin：無法取得內嵌資料 -4 無法處理虛擬位址0000000000000008的核心 NULL 指標解除參照 ...PC ： z_erofs_decompress_queue+0x4c8/0xa14 LR ：
    z_erofs_decompress_queue+0x160/0xa14 sp：ffffffc08b3eb3a0 x29：ffffffc08b3eb570 x28：ffffffc08b3eb418 x27：0000000000001000 x26：ffffff8086ebdbb8 x25：ffffff8086ebdbb8 x24：0000000000000001 x23：
    0000000000000008 x22： 00000000fffffffb x21： dead000000000700 x20： 0000000000015e7 x19： ffffff808babb400 x18： ffffffc089edc098 x17： 00000000c006287d x16： 00000000c006287d x15： 0000000000000004 x14：
    ffffff80ba8f8000 x13： 0000000000000004 x12： 00000006589a77c9 x11： 0000000000000015 x10： 0000000000000000 x9 ： 00000000000000000 x8 ： 0000000000000000 x7 ： 0000000000000000 x6 ： 000000000000003f x5 ：
    0000000000000040 x4 ： ffffffffffffffe0 x3 ： 0000000000000020 x2 ： 0000000000000008 x1 ： 00000000000000000 x0 ： 000000000000000000000000 呼叫追蹤：z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_讀取+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0 在配置 pcluster 並將其新增至 I/O 鏈之前，先讀取內嵌資料來修正此問題。（CVE-2026-45943）

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

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

  - RDMA/rxe：在 rxe_rcv rxe_rcv（） 中的 payload_size（） 之前驗證 pad 和 ICRC 目前僅檢查傳入封包是否在使用 payload_size（） 之前至少為 header_size（pkt） 位元組。但是，payload_size（） 會從 pkt->paylen 中減去攻擊者控制的 BTH 填充欄位和RXE_ICRC_SIZE：
    payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad（pkt） - RXE_ICRC_SIZE 這意味著即使短封包包含足夠的位元組用於固定標頭，它仍然可以使 payload_size（） 反向溢位。僅僅要求 header_size（pkt） + RXE_ICRC_SIZE 也是不夠的，因為具有偽造的非零 BTH pad 的封包仍然可以保留 payload_size（） 負值，並將下溢值傳遞給稍後的接收路徑使用者。透過根據 payload_size（） 要求的完整最小長度驗證 pkt->paylen 來解決此問題：
    header_size（pkt） + bth_pad（pkt） + RXE_ICRC_SIZE。（CVE-2026-46043）

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

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

  - net： stmmac：修正啟用分割標頭時的 oops 對於 GMAC4，啟用分割標頭時，在極少數情況下，硬體不會以承載填滿第一個描述元的 buf2。因此，如果 buf2 不是最後一個描述元，我們就不能假設它總是完全填充。否則，第二個描述項的 buf2 長度將計算錯誤並導致 oops：無法處理虛擬位址 ffff00019246bfc0 上的核心分頁要求 ...x2 ： 0000000000000040 x1 ： ffff00019246bfc0 x0 ： ffff00009246c000 呼叫追蹤：
    dcache_inval_poc+0x28/0x58 （P） dma_direct_sync_single_for_cpu+0x38/0x6c
    __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc ... 為了解決此問題，RDES3 暫存器中的 PL 位元欄位會用於所有描述元，無論它是否是最後一個描述元。CVE-2026-45940

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

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

  - net/smc：避免在 smc_clc_wait_msg 中提前存取 在交握仍處於早期階段時，在連線與連結群組相關聯之前，可能會收到 CLC 拒絕。smc_clc_wait_msg（） 中的拒絕處理會更新首次聯絡拒絕的連結群組層級同步狀態，但該狀態僅在連結群組設定完成後存在。相應地保護連結群組更新，並保持每個通訊端對等診斷處理不變。這會保留已建立連結群組內容的現有sync_err處理，並避免在連結群組狀態可用之前接觸連結群組狀態。（CVE-2026-46027）

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

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

  - sched/rt：跳過目前在 rto_next_cpu（） 中執行的 CPU 當託管 CPU 綁定的 RT 任務、非 CPU 綁定的 RT 任務和卡在核心空間的 CFS 任務時，CPU0 會變得過載。當其他 CPU 從 RT 切換到非 RT 任務時，會觸發 RT 負載平衡 （LB）;啟用 HAVE_RT_PUSH_IPI 後，它們會將 IPI 傳送至 CPU0 以驅動 rto_push_irq_work_func 的執行。在 CPU0 上push_rt_task期間，如果 next_task->prio < rq->donor->prio，則 resched_curr（） 會設定NEED_RESCHED，推送作業完成後，CPU0 會呼叫 rto_next_cpu（）。由於在此案例中只有 CPU0 過載，因此 rto_next_cpu（） 理想情況下應傳回 -1 （不需要進一步的 IPI）。不過，多個 CPU 在 LB 期間叫用 tell_cpu_to_push（） 會遞增 rd->rto_loop_next。即使 rd->rto_cpu 設定為 -1，rd->rto_loop 和 rd->rto_loop_next 之間的不相符也會迫使 rto_next_cpu（） 從 -1 重新啟動搜尋。當 CPU0 保持過載狀態 （滿足 rt_nr_migratory & rt_nr_total > 1） 時，系統會重新選取它，導致 CPU0 將 irq_work 排入佇列，並重複傳送自我 IPI。只要 CPU0 保持過載狀態，而其他 CPU 執行 pull_rt_tasks（），它就會陷入無限的自 IPI 迴圈，從而因持續的自中斷而觸發 CPU 硬鎖定。觸發場景如下： cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr（rq） pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc（rto_loop_next） rd->rto_loop ！= next rto_next_cpu irq_work_queue_on rto_push_irq_work_func 透過篩選 rto_next_cpu（） 中的啟動 CPU 來修正冗餘的自我 IPI。此解決方案已通過驗證，可有效消除虛假的 self-IPI 並防止 CPU 硬鎖定情況。（CVE-2026-45919）

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

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

  - SUNRPC：修正錯誤路徑中的 gss_auth kref 洩漏gss_alloc_msg 提交 5940d1cf9f42 （SUNRPC：重新平衡 auth_gss.c 中的 kref） 已新增 kref_get（&gss_auth->kref） 呼叫以平衡 gss_release_msg（） 中完成的 gss_put_auth（），但當 kstrdup_const（） 失敗時，忘記在錯誤路徑上新增對應的 kref_put（）。如果 service_name 為非 NULL 且 kstrdup_const（） 失敗，則函式會跳至呼叫 put_pipe_version（） 和 kfree（gss_msg） 的 err_put_pipe_version，但絕不會釋放 gss_auth 參照。這會導致 kref 洩漏，其中 gss_auth 結構永遠不會被釋放。新增 gss_free_callback（） 的前置宣告，並在err_put_pipe_version錯誤路徑中呼叫 kref_put（），以正確釋放先前取得的參照。（CVE-2026-45964）

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

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

  - xfrm：修正反向路徑中的ip_rt_bug爭用icmp_route_lookup icmp_route_lookup（） 會執行多個路由查詢，以尋找傳送 ICMP 錯誤訊息的適當路由，並對 XFRM （IPsec） 原則進行特殊處理。查詢順序為： 1. 首先，查找 ICMP 回覆的輸出路由 （dst = 原始 src） 2.
    傳遞 xfrm_lookup（） 進行原則檢查 3.如果封鎖 （-EPERM） 或 dst 不是本機，請輸入反向路徑 4。在反向路徑中，呼叫 xfrm_decode_session_reverse（） 以取得反轉原始封包流的fl4_dec （saddr<->daddr swapped） 5.如果 fl4_dec.saddr 是本機的 （我們是原始目的地），請使用
    __ip_route_output_key（） 用於輸出路由查詢 6.如果 fl4_dec.saddr 不是本地的（我們是轉送節點），請使用 ip_route_input（） 模擬反向封包的輸入路徑 7。最後，使用 XFRM_LOOKUP_ICMP 標誌通過 xfrm_lookup（） 傳遞 rt2 錯誤發生在步驟 6 中：以 fl4_dec.daddr （原始封包的來源） 作為目的地呼叫 ip_route_input（）。如果此位址在初始檢查和 ip_route_input（） 呼叫之間成為本地位址（例如，由於並發 ip addr add），則 ip_route_input（） 會傳回 dst.output 設定為 ip_rt_bug 的 LOCAL 路由。然後，此路由用於 ICMP 輸出，導致 dst_output（） 調用 ip_rt_bug（），觸發 WARN_ON：------------[ 切到這裡 ]------------ 警告：
    net/ipv4/route.c：1275 在 ip_rt_bug+0x21/0x30， CPU#1 呼叫追蹤： <TASK> ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... 透過在 ip_route_input（） 之後檢查 rt2->rt_type 來解決此問題。如果RTN_LOCAL，則路由無法用於輸出，因此請將其視為錯誤。重現者需要修改核心以擴大爭用視窗，因此不適合作為自檢。可於以下網址取得：
    https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81 (CVE-2026-45905)

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

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

  - pinctrl： single：修正 pcs_add_gpio_func（） 中的 refcount 洩漏 of_parse_phandle_with_args（） 傳回一個 device_node 指標，其中 refcount 以 gpiospec.np 遞增。迴圈會反覆運算所有 phandle，但絕不會釋放參照，因此每次反覆運算都會造成參照計數洩漏。新增 of_node_put（） 呼叫，以在擷取所需的引數後釋放參照，並在 devm_kzalloc（） 失敗時釋放錯誤路徑。這個錯誤是由我們的靜態分析工具檢測到的，並通過我的代碼審查進行了驗證。（CVE-2026-45868）

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

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

  - ALSA： aloop：修正格式變更停止期間的對等執行階段 UAF，當播放開始時，loopback_check_format（） 可能會停止擷取端，而參數不再符合執行中的擷取串流。提交 826af7fa62e3 （ALSA：aloop：修正 PCM 觸發時的 racy 存取） 將對等查詢移至 cable->lock 下，但實際的 snd_pcm_stop（） 在丟棄該鎖定後仍會執行。並行關閉可以清除 cable->streams[] 中的擷取項目，並在播放觸發路徑仍保留過時的對等子資料流指標時中斷連結或釋放其執行階段。在丟棄 cable->lock 之前，保留每條纜線的進行中對等停止計數，並讓 free_cable（） 等待這些停止，然後再分離執行階段。這會保留現有的行為，同時讓對等執行階段存留期明確。（CVE-2026-46090）

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

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

  - ext4：執行PARTIAL_VALID1歸零後丟棄範圍快取 在中間分割未寫入的範圍並將其轉換為在 ext4_split_extent（） 中設定了 EXT4_EXT_MAY_ZEROOUT 和 EXT4_EXT_DATA_VALID2 旗標的初始化範圍時，可能會留下過時的未寫入範圍。假設我們有一個未寫入的檔案，中間有緩衝寫入，而未啟用dioread_nolock，它會將區塊配置為寫入範圍。0 A B N [UUUUUUUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUUUUUUU] 範圍狀態樹狀結構 [--DDDDDDDD--] D：有效資料 |<- ->|---->需要初始化這個範圍ext4_split_extent（）先嘗試在B處拆分這個範圍，並設定EXT4_EXT_DATA_PARTIAL_VALID1和EXT4_EXT_MAY_ZEROOUT旗標，但ext4_split_extent_at（）由於暫時空間不足，無法拆分這個範圍。它將 B 歸零到 N，並將整個範圍保留為未寫入的範圍。0 A B N [UUUUUUUUUUUUU] 磁碟範圍 [UUUUUUUUUUUU] 範圍狀態樹狀結構 [--DDDDDDDDZZ] Z：歸零的資料 ext4_split_extent（），然後嘗試在 A 處分割此範圍，並設定EXT4_EXT_DATA_VALID2旗標。這次，它成功分割，並留下從 A 到 N 的寫入範圍 0 A B N [UUWWWWWWWWWW] 磁碟範圍 W：寫入範圍 [UUUUUUUUUUUU] 範圍狀態樹狀結構 [--DDDDDDDDZZ] 最後 ext4_map_create_blocks（） 只將範圍 A 到 B 插入範圍狀態樹狀結構，並在狀態樹狀結構中留下過時的未寫入範圍。0 A B N [UUWWWWWWWWWW] 磁碟範圍 W：寫入範圍 [UUWWWWWWWWUU] 範圍狀態樹狀結構 [--DDDDDDDDDDZZ] 在將第二部分歸零後，一律快取範圍狀態項目來修正此問題。CVE-2026-45892

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

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

  - crypto：ccree - 修正 cc_mac_digest（） 中的記憶體洩漏 如果 cc_map_hash_request_final（） 無法防止潛在的記憶體洩漏，則新增 cc_unmap_result（）。（CVE-2026-45986）

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

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

  - FastNetMon 社區版通過 1.2.9 有一個緩衝區溢位，一個與 CVE-2026-48686 和 CVE-2026-48689不同的漏洞。（CVE-2026-48696）

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

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

  - md/raid10：修正檢查操作和 nowait 要求的鎖死 當陣列檢查正在執行時，它會提高障礙，此時正常請求將被阻止，並遞增 nr_pending 值以指示 wait_barrier（） 內部有待處理的工作。NOWAIT 請求不會阻塞，因此會立即返回錯誤，並且不會在 wait_barrier（） 中遞增 nr_pending。上游變更提交 43806c3d5b9b （raid10：清理 raid10_make_request 處的 memleak） 新增了對 raid_end_bio_io（） 的呼叫，以在 NOWAIT 要求遇到此條件時修正記憶體洩漏。raid_end_bio_io（） 最終會呼叫 allow_barrier（），並且它會無條件地執行 atomic_dec_and_test（&conf->nr_pending），即使 nr_pending 的相應增量在 NOWAIT 案例中沒有發生。當應用程式在相同陣列上執行 nowait IO 時，啟動檢查作業即可輕鬆看到這一點。這會導致 nr_pending 值下溢而導致鎖死狀態，因此 md 重新同步處理執行緒會停滯在等待 nr_pending == 0 時。當我們遇到這種情況時，陣列的 r10conf 狀態輸出：crash> struct r10conf barrier = 1， nr_pending = { counter = -41 }， nr_waiting = 15， nr_queued = 0， md_sync等待 raise_barrier（） 和其他請求卡在 wait_barrier（） 中的執行緒等待的範例： md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040：2+flush-253：4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>]
    __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>]
    __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 （CVE-2026-46050）

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

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

  - s390/cio：在設定 DMA 遮罩之前，修正 css_alloc_subchannel（） 'css_alloc_subchannel（）' 呼叫 'device_initialize（）' 中的裝置生命週期處理。如果「dma_set_coherent_mask（）」或「dma_set_mask（）」失敗，錯誤路徑會直接釋放子通道結構，繞過裝置模型參照計數。呼叫「device_initialize（）」之後，必須透過「put_device（）」釋放內嵌結構裝置，讓釋放回呼釋放容器結構。使用「put_device（）」刪除初始裝置參照，而不是直接呼叫「kfree（）」來修正錯誤路徑。這可確保正確的裝置生命週期處理，並避免潛在的釋放後使用或雙重釋放問題。
    (CVE-2026-45981)

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

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

  - ALSA： ctxfi：新增 S/PDIF 的預設 RSR 後援 spdif_passthru_playback_get_resources（） 使用 atc->pll_rate 作為 MSR 計算迴圈的 RSR。但是，pll_rate僅在 atc_pll_init（） 中更新，而不在 hw_pll_init（） 中更新，因此在卡片初始化後仍為 0。當 spdif_passthru_playback_setup（） 跳過 32000 Hz 的 atc_pll_init（） 時，（rsr * desc.msr） 一律變成 0，導致迴圈無限旋轉。當 atc->pll_rate 為 0 時，新增後援以使用 atc->rsr。這反映了硬體狀態，因為 hw_card_init（） 已將 PLL 配置為預設 RSR。（CVE-2026-46049）

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

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

  - crypto：atmel-sha204a - 修正移除路徑中潛在的 UAF 和記憶體洩漏 取消註冊 hwrng 以防止新的 ->read（） 呼叫，並在拆卸前排清 Atmel I2C 工作佇列，以防止在移除裝置時執行佇列的回呼時可能發生 UAF。刪除提前返回，以確保移除 sysfs 項目並釋放 ->hwrng.priv，防止記憶體洩漏。（CVE-2026-46075）

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

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

  - ext4：修正 ext4_ext_shift_extents（） 中的記憶體洩漏 在 ext4_ext_shift_extents（） 中，如果 while 迴圈中的範圍為 NULL，則函數會立即返回而不釋放透過 ext4_find_extent（） 獲得的路徑，從而導致記憶體洩漏。透過跳到輸出標籤來修正此問題，以確保路徑已正確釋放。（CVE-2026-45948）

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

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

  - RDMA/rxe：修正 rxe_srq_from_init 中的雙重釋放 在 rxe_srq_from_init（） 中，佇列指標 'q' 在將 SRQ 編號複製到使用者空間之前，會指派給 'srq->rq.queue'。如果 copy_to_user（） 失敗，則函式會呼叫 rxe_queue_cleanup（） 以釋放佇列，但會將現在無效的指標保留在 'srq->rq.queue' 中。rxe_srq_from_init（） （rxe_create_srq） 的呼叫者最終在收到錯誤後呼叫 rxe_srq_cleanup（），這會觸發同一記憶體上的第二個 rxe_queue_cleanup（），從而導致雙重釋放。呼叫追蹤如下所示：kmem_cache_free+0x.../0x...rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] 透過在copy_to_user之後移動「srq->rq.queue = q」來修正此問題。（CVE-2026-45852）

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

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

  - 藍牙：hci_event：修正 SSP 通行金鑰處理常式中潛在的 UAF，hci_conn hci_user_passkey_notify_evt（） 和 hci_keypress_notify_evt（） 中的 hdev 鎖定必須涵蓋查詢和欄位存取，否則可能會同時釋放連線。擴充 hci_dev_lock 關鍵區段，以涵蓋兩個處理常式中的所有 conn 使用方式。透過一般解除鎖定路徑遞送提前結束，讓現有按鍵通知行為不變。（CVE-2026-46056）

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

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

  - ext4：不要在分割範圍期間快取範圍 在分割處理程序期間快取範圍有風險，因為這可能會導致狀態樹狀結構中保留過時的範圍。此外，在大多數情況下，對應的範圍區塊項目可能在分割發生之前就已經快取，因此此處快取並不是特別有用。假設我們有一個不成文的範圍，然後 DIO 寫入前半部分。
    [UUUUUUUUUUUUUUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUUUUUUUUUUUU] 範圍狀態樹狀結構 |<- ->|----> dio 寫入此範圍首先，當 ext4_split_extent_at（） 分割此範圍時，它會截斷現有範圍，然後插入一個新的範圍。在此過程中，此範圍狀態項目可能會縮小，並且可能會呼叫 ext4_find_extent（） 和 ext4_cache_extents（），這可能會將截斷的範圍作為漏洞插入範圍狀態樹狀結構中。分割完成後，此孔不會替換為正確的狀態。[嗚嗚嗚嗚嗚|UUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUU|HHHHHHH] 範圍狀態樹狀結構 H：孔 然後，外部呼叫函式也不會更正這個剩餘的孔範圍。
    最後，如果我們對後一部分執行延遲緩衝區寫入，它會重新插入延遲範圍並導致空間計費錯誤。此外，如果在分割期間未縮減未寫入的範圍快取，則在快取範圍時，ext4_cache_extents（） 也會與現有範圍衝突。將來，我們將在快取範圍時新增檢查，這會觸發警告。因此，請勿快取正在分割的範圍。（CVE-2026-45912）

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

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

  - ntfs3：修正 run_unpack（） 磁碟區邊界檢查中的整數溢位 磁碟區邊界檢查「lcn + len > sbi->used.bitmap.nbits」使用原始加法，可以針對較大的 lcn 和 len 值進行換行，繞過驗證。使用 check_add_overflow（），就像對相鄰prev_lcn所做的那樣 + dlcn 和 vcn64 + 提交 3ac37e100385 新增的 len 檢查 （ntfs3： 修正 run_unpack（）） 中的整數溢位。透過使用原始碼修補的工具 （LibAFL + QEMU） 進行模糊測試找到。（CVE-2026-46062）

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

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

  - SPI：修正裝置設定失敗時的資源洩漏 如果 spi_setup（） 在註冊裝置時失敗，請務必呼叫控制器 cleanup（），以避免洩漏 setup（） 配置的任何資源。（CVE-2026-46083）

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

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

  - bonding： alb：在綁定上/下綁定期間修復rlb_arp_recv中的 UAF ALB RX 路徑可以在綁定拆解的同時存取rx_hashtbl。在快速綁定上/下週期期間，rlb_deinitialize（） 會在 RX 處理常式仍在執行時釋放rx_hashtbl，導致 KASAN 偵測到空指標解除參照。然而，根本原因是將 recv_probe 設定為 NULL 後仍然可以存取 rlb_arp_recv（），這實際上是一個釋放後使用（UAF）問題。這就是在 Fixes 標籤中使用參照提交的原因。[ 214.174138] 哎呀：一般保護錯誤，可能是非規範位址0xdffffc000000001d：
    0000 [#1] SMP KASAN PTI [ 214.186478] KASAN：範圍 [0x00000000000000e8-0x00000000000000ef] 內的 null-ptr-deref [ 214.194933] CPU：30 UID：0 PID：2375 通訊：ping kdump：已載入 未受污染 6.19.0-rc8+ #2 PREEMPT（自願） [ 214.205907] 硬體名稱：Dell Inc. PowerEdge R730/0WCJNT， BIOS 2.14.0 01/14/2022 [ 214.214357] RIP：0010：rlb_arp_recv+0x505/0xab0 [bonding] [214.220320] 代碼：0f 85 2b 05 00 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP： 0018：ffffc900073d8870 EFLAGS： 00010206 [ 214.247116] RAX： dffffc00000000000 RBX：
    ffff888168556822 RCX：ffff88816855681e [ 214.255082] RDX：000000000000001d RSI：dffffc00000000000 RDI：
    0000000000000000e8 [ 214.263048] RBP： 000000000000000000000000000000000 ： R080000000000000002 R09： ffffed11192021c8 [214.271013] R10： ffff8888c9010e43 R11： 0000000000000001 R12： 1ffff92000e7b119 [ 214.278978] ： R13
    ffff8888c9010e00 R14： ffff888168556822 R15： ffff888168556810 [ 214.286943] FS： 00007f85d2d9cb80（0000） GS：ffff88886ccb3000（0000） knlGS：000000000000000000 [ 214.295966] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [ 214.302380] CR2： 00007f0d047b5e34 CR3： 00000008a1c2e002 CR4： 00000000001726f0 [214.310347] 呼叫追蹤： [ 214.313070] <IRQ> [ 214.315318] ？ __pfx_rlb_arp_recv+0x10/0x10 [bonding] [214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ？ __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ？
    __pfx_arp_process+0x10/0x10 [ 214.343775] ？ sched_balance_find_src_group+0x98/0x630 [ 214.349513] ？
    __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ？ arp_rcv+0x307/0x690 [ 214.360311] ？
    __pfx_arp_rcv+0x10/0x10 [ 214.364499] ？ __lock_acquire+0x58c/0xbd0 [ 214.368975]
    __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ？ __pfx___netif_receive_skb_one_core+0x10/0x10 [214.380743] ？ lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ？ process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ？ __pfx_net_rx_action+0x10/0x10 [ 214.408193] ？ lock_acquire.part.0+0xbd/0x260 [ 214.413058] ？ sched_clock_cpu+0x6c/0x540 [ 214.417540] ？ mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ？
    __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ？ __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> 此問題可透過在接收 ARP 訊息時重複執行 ip link set bond0 up/down 來重現，其中 rlb_arp_recv（） 可能會與 rlb_deinitialize（） 爭用並取消參照釋放的 rx_hashtbl 項目。透過將 recv_probe 設定為 NULL，然後呼叫 synchronize_net（） 以等待任何並行的 RX 處理完成來修正此問題。這可確保在 bond_alb_deinitialize（） 中釋放後，任何 RX 處理常式都無法存取 rx_hashtbl。（CVE-2026-45970）

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

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

  - ALSA： caiaq：正確處理探查錯誤 caiaq 驅動程式中 setup_card（） 的探查程序不會正常地處理錯誤情況，例如來自 snd_card_register（） 呼叫 snd_card_free（） 的錯誤，但會繼續發生。這將導致 UAF 用於像 snd_usb_caiaq_control_init（） 這樣的進一步調用，正如 Berk 在下面連結中的另一個補丁中建議的那樣。然而，問題不僅如此;一般來說，此函數會刪除所有錯誤處理（因為它是 void 函數），儘管其調用方可以將錯誤傳播到 snd_probe（），最終調用 snd_card_free（） 作為適當的錯誤路徑。也就是說，我們應該處理 setup_card（） 中的每個錯誤情況，並立即傳回錯誤代碼，然後將其作為 snd_probe（） 中的致命錯誤進行處理。此修補程式透過變更 setup_card（） 以傳回錯誤代碼來實現這一點。此外，多餘的 snd_card_free（） 調用也被刪除。請注意，在傳回錯誤時仍可安全地設定 card->private_free。card_free（） 中所有被呼叫的函式都會檢查未指派的資源或 NULL 檢查。（CVE-2026-46004）

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

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

  - fbdev：au1200fb：修正 au1200fb_drv_probe（） 中的記憶體洩漏 在 au1200fb_drv_probe（） 中，當 platform_get_irq fails（） 時，它直接從函數返回錯誤代碼，從而導致記憶體洩漏。將其替換為 goto 標籤以確保正確清理。（CVE-2026-45954）

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

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

  - ibmasm：修正 command_file_write 中由於缺少大小檢查而導致的 OOB 讀取 command_file_write（） 處理常式會配置一個精確計數位元組的核心緩衝區，並將使用者資料複製到其中，但在將緩衝區傳遞給 get_dot_command_size（） 和 get_dot_command_timeout（） 之前，不會根據 dot 命令通訊協定驗證緩衝區。由於配置大小 （計數） 和標頭欄位 （command_size、data_size） 都是獨立的使用者控制，因此攻擊者可導致 get_dot_command_size（） 傳回超出配置的值，從而觸發 get_dot_command_timeout（） 中的 OOB 讀取，以及將核心堆積記憶體洩漏給服務處理器的越界 memcpy_toio（）。使用兩個防護措施進行修正：在分配之前拒絕小於 sizeof（struct dot_command_header） 的寫入，然後在複製使用者資料後拒絕緩衝區小於標頭 （sizeof（header） + command_size + data_size） 所宣告的總大小的命令。這可確保所有後續標頭和承載欄位存取都保留在緩衝區內。（CVE-2026-45994）

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

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

  - selinux：修正 overlayfs、mmap（） 和 mprotect（） 存取檢查 overlayfs 的現有 SELinux 安全性模型是，如果目前任務能夠存取頂層檔案 （使用者檔案），且裝載程式的憑證足以存取較低層級檔案 （備份檔案），則允許存取。
    遺憾的是，目前的程式碼並未針對 overlayfs 檔案系統上的 mmap（） 和 mprotect（） 作業正確執行這些存取控制。此修補程式會利用新建立的 security_mmap_backing_file（） LSM 勾點，為 mmap（） 作業提供缺少的備份檔強制執行，並利用備份檔 API 和新的 LSM blob 提供必要的資訊，以正確強制執行 mprotect（） 存取控制。（CVE-2026-46054）

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

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

  - power： supply： cpcap-battery： 修正 power_supply_changed（） 中的釋放後使用 'devm_' 變體來請求 IRQ _before_ 用於配置/註冊 'power_supply' 句柄的 'devm_' 變體，意味著 'power_supply' 句柄將在中斷處理常式之前 _ 解除配置/取消註冊 （因為 'devm_' 自然地以相反的分配順序解除配置）。這表示在移除期間，會發生爭用情形，即中斷可能會在 'power_supply' 控制碼被釋放之後觸發，*但是* 就在 IRQ 處理常式的對應取消註冊執行之前。這將導致 IRQ 處理常式呼叫具有釋放的 'power_supply' 句柄的 'power_supply_changed（）'。這通常會使系統崩潰或以其他方式無聲地損壞記憶體... 請注意，在「probe（）」期間也可能發生類似的情況;在註冊 'power_supply' 控制碼之前_中斷觸發的可能性。這將導致在「power_supply_changed（）」中使用「power_supply」句柄*未初始化*的惡劣情況。透過確保在註冊 'power_supply' 控制碼之後 _ 請求 IRQ，來修正此 racy 釋放後使用。（CVE-2026-45885）

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

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

  - FastNetMon Community Edition through 具有 1.2.9 越界記憶體存取，因為它錯誤地剖析了已設定擴充長度旗標的 BGP 路徑屬性。在 src/bgp_protocol.hpp 中，parse_raw_bgp_attribute（） 函式會正確識別何時設定 extended_length_bit 並將 length_of_length_field 設為 2，但隨後僅讀取屬性值長度的單一位元組 （第 173 行的 attribute_value_length = value[2]）。根據 RFC 4271 區段 4.3，設定擴充長度位元時，屬性長度欄位為兩個八位元組，且值應從 value[2] 和 value[3] 讀取為 16 位元大端整數。因此，任何長度超過 255 位元組的屬性都會以無訊息方式截斷為低位元組 （例如，300 位元組 = 0x012C 會讀取為 0x2C = 44 位元組）。然後，剩餘的 256 個位元組被誤解為後續屬性，導致級聯剖析失敗和潛在的越界記憶體存取。（CVE-2026-48685）

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

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

  - SUNRPC： auth_gss：修正 XDR 解碼錯誤路徑中的記憶體洩漏 gssx_dec_ctx（）、gssx_dec_status（） 和 gssx_dec_name（） 函式透過呼叫 kmemdup（） 的 gssx_dec_buffer（） 配置記憶體。當後續解碼作業失敗時，這些函式會立即傳回，而不會釋放先前配置的緩衝區，進而造成記憶體洩漏。gssx_dec_ctx（） 中的洩漏特別相關，因為調用方 （gssp_accept_sec_context_upcall） 將多個緩衝區長度欄位初始化為非零值，從而導致記憶體分配：struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz， .mech.len = GSS_OID_MAX_LEN， .src_name.display_name.len = GSSX_max_princ_sz， .targ_name.display_name.len = GSSX_max_princ_sz };例如，如果 gssx_dec_name（） 對 src_name 成功，但對 targ_name 失敗，則配置給 exported_context_token、mech 和 src_name.display_name 的記憶體將保持未參照且無法回收。使用以 goto 為基礎的清除新增錯誤處理，以在傳回錯誤之前釋放任何先前配置的緩衝區。（CVE-2026-45870）

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

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

  - FastNetMon Community Edition 透過 1.2.9 /tmp 中可預測的檔案路徑，容易受到本機符號連結攻擊。統計資料檔案路徑預設為「/tmp/fastnetmon.dat」（src/fastnetmon.cpp第 159 行）。
    print_screen_contents_into_file（） 函式 （src/fastnetmon_logic.cpp 第 2186 行） 使用 std：：ios：：trunc 開啟此路徑，而不檢查符號連結或使用 O_NOFOLLOW。此外，無論傳遞了哪個 file_path 參數，第 2190 行的 chmod（） 呼叫始終在cli_stats_file_path上運行（一個套用錯誤權限的錯誤），並且在精靈化期間 umask 設定為 0（src/fastnetmon.cpp 第 1821 行），使所有建立的檔案都可以寫入世界。本機攻擊者可利用此弱點，以 FastNetMon 處理程序使用者 （通常是 root） 的身分覆寫任意檔案。（CVE-2026-48693）

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

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

  - hfsplus：當節點已存在於 hfs_bnode_create 時傳回錯誤 當 hfs_bnode_create（） 發現節點已經雜湊 （在正常操作中不應發生） 時，它目前會傳回現有節點，而不會增加其參照計數。這會導致參照計數不一致，導致節點稍後在 hfs_bnode_put（） 中釋放時出現核心錯誤：fs/hfsplus/bnode.c：676！BUG_ON（！atomic_read（&node->refcnt）） 當 hfs_bmap_alloc（） 嘗試配置已在使用的節點時（例如，當節點 0 的點陣圖位元被錯誤地取消設定時）或由於檔案系統損毀時，可能會發生這種情況。從建立路徑傳回現有節點不是正常作業。透過傳回 ERR_PTR（-EEXIST） 而不是已經雜湊的節點來修正此問題。這會正確地向呼叫端發出錯誤狀況訊號，呼叫端已檢查 IS_ERR（） 傳回值。（CVE-2026-45960）

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

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

  - ibmasm：修正 ibmasm_send_i2o_message（） 中的堆積過度讀取 ibmasm_send_i2o_message（） 函數使用 get_dot_command_size（） 來計算 memcpy_toio（） 的位元組計數，但此值衍生自dot_command_header中的使用者控制欄位 （command_size： u8， data_size： u16） ，而且永遠不會根據實際配置大小進行驗證。root 使用者可以寫入具有膨脹標頭欄位的小緩衝區，導致 memcpy_toio（） 在分配結束後讀取最多 ~65 KB 的內容到相鄰的核心堆積中，然後透過 MMIO 將其轉送至服務處理器。以無訊息方式限制副本大小是不夠的：
    如果標頭欄位宣告的大小大於緩衝區，則 SP 會收到一個 dot 命令，其自己的標頭與 I2O 訊息長度不一致，這可能會導致 SP 不同步。傳回失敗，直接拒絕這類命令。在呼叫 get_mfa_inbound（） 之前驗證command_size，以避免洩漏 I2O 訊息框架：讀取INBOUND_QUEUE_PORT會從控制器的可用集區中出列硬體框架，而在沒有對應 set_mfa_inbound（） 呼叫的情況下返回將永久耗盡它。此外，將command_size限制在 memcpy_toio（） 之前的 I2O_COMMAND_SIZE，以便 MMIO 寫入保留在 I2O 訊息框架內，這與 outgoing_message_size（） 已針對標頭欄位執行的限制一致。（CVE-2026-46064）

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

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

  - drm/nouveau：修正 pushbuf 重新定位邊界檢查中的 u32 溢位 nouveau_gem_pushbuf_reloc_apply（） 使用 if （r->reloc_bo_offset + 4 > nvbo->bo.base.size） 驗證每次重新定位，但reloc_bo_offset是__u32 （uapi/drm/nouveau_drm.h），整數常值 4 升級為無符號 int，因此加法以 32 位執行，並在與 size_t bo 大小進行比較之前換行。轉換為 u64，以便以 64 位算術進行加法。[ 新增修正： 標籤。- 達尼洛 ] （）CVE-2026-46006

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

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

  - spi： imx：修正解除綁定時的釋放後使用 SPI 子系統會在取消註冊過程中釋放控制器和任何子系統配置的驅動程式資料 （除非配置是裝置管理） 。在取消註冊控制器之前，先進行另一個參考，以便在驅動程式完成驅動程式資料之前不會釋放驅動程式資料。
    (CVE-2026-45996)

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

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

  - smack： /smack/doi：接受先前使用的值 寫入 /smack/doi 過去曾經寫入過的值會停用非環境標籤的網路。例如 # cat /smack/doi 3 # netlabelctl -p cipso list 已配置的 CIPSO 映射 （1） DOI 值：3 映射類型：PASS_THROUGH # netlabelctl -p 映射列表 已配置的 NetLabel 域映射 （3） 域：_ （IPv4） 協議：未標記域：默認 （IPv4） 協議：CIPSO，DOI = 3 域：默認 （IPv6） 協議：未標記 # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 位元組來自 10.1.95.12：icmp_seq=1 ttl=64 時間=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 來自 10.1.95.12 64 位元組： icmp_seq=1 ttl=64 time=0.956 ms 未知選項 86 # echo 4 >/smack/doi # echo 3 >/smack/doi ！> [ 214.050395] smk_cipso_doi：691 cipso add rc = -17 # echo 3 >/smack/doi ！> [ 249.402261] smk_cipso_doi：678 移除 rc =
    -2 ！> [ 249.402261] smk_cipso_doi：691 cipso 新增 rc = -17 # ping -c1 10.1.95.12 ！！> ping： 10.1.95.12
    不支援主機名稱的位址系列 # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 10.1.95.12位元組來自：icmp_seq=1 ttl=64 time=0.617 ms 發生這種情況是因為 Smack 保留已停用的 DOI，未能重新新增它們，因此拒絕新增預設網域映射： # netlabelctl -p cipso list 已配置的 CIPSO 映射 （2） DOI 值：3 映射類型：PASS_THROUGH DOI 值： 4 映射類型：PASS_THROUGH # netlabelctl -p 映射列表 已配置的 NetLabel 域映射 （2） domain：_ （IPv4） protocol： UNLABELED ！> （此處沒有預設域的 ipv4 映射） domain： DEFAULT （IPv6） protocol： UNLABELED 通過清除已停用的 DOI 定義並使用新鎖序列化並行 DOI 更新來修復。
    另外： - 允許 /smack/doi 處於未配置狀態，因為新增映射 （netlbl_cfg_cipsov4_map_add） 可能會失敗。
    CIPSO_V4_DOI_UNKNOWN（0） 表示未配置的 DOI - 在移除舊的預設映射之前添加新的 DOI，因此如果添加失敗，舊映射仍會保留 （2008-02-04， Casey Schaufler） （CVE-2025-71304）

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

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

  - ceph：只有 d_add（） 負 dentry 未雜湊時 Ceph 可以在主要 dcache 雜湊中已存在的負 dentry 上呼叫 d_add（dentry， NULL）。在當前的 VFS 中，這是不安全的。
    d_add（） 經過 __d_add（） 到 __d_rehash（），這會無條件地將 dentry->d_hash 重新插入 hlist_bl 儲存桶。如果 dentry 已雜湊，則重新插入相同的節點可能會損毀儲存區，包括建立自我迴圈。一旦發生這種情況，__d_lookup（） 可以在hlist_bl遍歷中永遠旋轉，通常僅在 d_name.hash 不匹配檢查時循環，並最終觸發 RCU 停止報告，如下所示： rcu： INFO：rcu_sched CPU 上自我偵測到的停止 rcu：87-....：（此 GP 為 2100 個 tick） idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu：（t=2101 jiffies g=79058445 q=698988 ncpus=192） CPU： 87 UID：2952868916 PID：3933303 通訊：php-cgi8.3 未受污染 6.18.17-i1-amd #950 無 硬體名稱：Dell Inc. PowerEdge R7615/0G9DHV， BIOS 1.6.6 09/22/2023 RIP：0010：__d_lookup+0x46/0xb0 代碼：c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f348 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP：
    0018：ff745a70c8253898 EFLAGS：00000282 RAX：ff26e470054cb208 RBX：ff26e470054cb208 RCX：000000006e958966 RDX：ff26e48267340000 RSI：ff745a70c82539b0 RDI：ff26e458f74655c0 RBP：000000006e958966 R08：
    0000000000000180 R09： 9cd08d909b919a89 R10： ff26e458f74655c0 R11： 000000000000000000 R12： ff26e458f74655c0 R13： ff745a70c82539b0 R14： d0d0d0d0d0d0d0 R15： 2f2f2f2f2f2f2f2f FS： 00007f5770896980（0000） GS：ff26e482c5d88000（0000） knlGS：00000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：
    00007f5764de50c0 CR3： 000000a72abb5001 CR4： 0000000000771ef0 PKRU： 55555554 呼叫追蹤： <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e 重複使用的快取負齒列可實現此目的。Ceph 查詢或atomic_open可以傳遞一個已經雜湊的負 dentry，然後 fs/ceph/dir.c 命中兩個路徑之一，這些路徑錯誤地假設負也意味著未雜湊： - ceph_finish_lookup（）：MDS 回覆為 -ENOENT，沒有追蹤 -> d_add（dentry， NULL） - ceph_lookup（）：具有共用上限的完整目錄的本機 ENOENT 快速路徑 -> d_add（dentry， NULL） 因此，兩條路徑都可以重新新增已雜湊的負 dentry。Ceph 已在其他地方使用正確的模式：
    ceph_fill_trace（） 僅在 d_unhashed（dn） 為 true 時呼叫 d_add（dn， NULL） 以取得負 null-dentry 回覆。
    以相同的方式修正兩個 fs/ceph/dir.c 網站：僅在負 dentry 實際未雜湊時呼叫 d_add（）。如果負 dentry 已雜湊，請將其保留在原處並按原樣重複使用。這會保留未雜湊 dentry 的現有行為d_hash同時避免重複使用的雜湊負值的清單損毀。（CVE-2026-46052）

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

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

  - rbd：當 device_add_disk（） 失敗時，修正 null-ptr-deref do_rbd_add（） 會在呼叫 device_add_disk（） 之前使用 device_add（） 發佈裝置。如果 device_add_disk（） 在 device_add（） 成功後失敗，則錯誤路徑會直接呼叫 rbd_free_disk（），然後失敗至 rbd_dev_device_release（），後者會再次呼叫 rbd_free_disk（）。這種雙重拆卸可能會使 blk-mq 清理在無效狀態下運行，並在 __blk_mq_free_map_and_rqs（） 中觸發 null-ptr-deref，從 blk_mq_free_tag_set（） 到達。請遵循正常的移除順序來修正此問題：當 device_add_disk（） 在 device_add（） 之後失敗時，在 rbd_dev_device_release（） 之前呼叫 device_del（）。如此可保持拆卸順序一致，並避免透過錯誤路徑重新進入磁碟清理。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。我們在 v7.0 上重現了這個錯誤，使用真正的 Ceph 後端和啟用 KASAN 和 CONFIG_FAILSLAB 啟動的 QEMU x86_64客體。再現器將 failslab 注入限制在 __add_disk（） 範圍內，並在透過 /sys/bus/rbd/add_single_major 映射 RBD 映像時注入 fail-nth。在未修補的核心上，fail-nth=4 可靠地觸發了錯誤：哎呀：
    一般保護錯誤，可能用於非規範位址 0xdffffc0000000000： 0000 [#1] SMP KASAN NOPTI KASAN： null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU： 0 UID： 0 PID： 273 Comm： bash 未受污染 7.0.0-01247-gd60bc1401583 #6 搶佔（延遲） 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009）， BIOS 1.15.0-1 04/01/2014 RIP： 0010：__blk_mq_free_map_and_rqs+0x8c/0x240 代碼： 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 0000 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP：0018：ff1100000ab0fac8 EFLAGS：00000246 RAX：dffffc00000000000 RBX：ff1100000c4806a0 RCX：000000000000000000 RDX：0000000000000002 RSI：
    000000000000000000 RDI：ff11000000c4806f4 RBP：00000000000000000000 R08：0000000000000001 R09：ffe21c000189001b R10：ff1100000c4800df R11：ff1100006cf37be0 R12：00000000000000000 R13：0000000000000000：000000000000000：000000000000000 R14：000000000000000：000000000000000：0000000000000000：000000000000：0000000000000：000000000000：000000000000：000000000000：0000000000000：000000000000：00000000000000：000000000000000：00000000000000：0000000000000：000000000000：0000000000000：0000000000000：00000000000：000000000
    ff1100000c480700 R15： ff1100000c480004 FS： 00007f0fbe8fe740（0000） GS：ff110000e5851000（0000） knlGS：00000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00007fe53473b2e0 CR3：
    0000000012eef000 CR4： 00000000007516f0 PKRU： 55555554 呼叫追蹤： <TASK> blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ？ __pfx_do_rbd_add+0x10/0x10 ？ lock_acquire+0x18c/0x300 ？ find_held_lock+0x2b/0x80 ？ sysfs_file_kobj+0xb6/0x1b0 ？ __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ？ expand_files+0x51f/0x850 ？
    __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ？__pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：0033：0x7f0fbea15907 代碼：10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 4889 54 24 18 48 89 74 24 RSP：002b：00007ffe22346ea8 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：ffffffffffffffda RBX：0000000000000058 RCX：00007f0fbea15907 RDX：
    0000000000000058 RSI：0000563ace6c0ef0 RDI：0000000000000001 RBP：0000563ace6c0ef0：0000563ace6c0ef0R09：6b6435726d694141R10：5250337279762f78R11：0000000000000246R12：0000000000000058R13：R08
    00007f0fbeb1c780 R14： ff1100000c480700 R15： ff1100000c480004 </TASK> 套用此修正後，在 fail-nth=1..256 上重新執行轉發器不會產生任何 KASAN 報告。[ idryomov：重新命名 err_out_device_del -> err_out_device ]（CVE-2026-46079）

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

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

  - KVM： nSVM：在 L2 的 VMRUN 之後，將中斷影子同步到快取的 vmcb12 在客體模式下進行 VMRUN 之後，nested_sync_control_from_vmcb02（） 會將 CPU 寫入的欄位從 vmcb02 同步到快取的 vmcb12。這是因為快取的 vmcb12 會用作某些控制項的授權複本，並且是儲存/還原巢狀狀態時的承載。int_state也由 CPU 寫入，特別是位元 0 （即
    SVM_INTERRUPT_SHADOW_MASK） 中，但不會同步至快取的 vmcb12。如果還原路徑中KVM_SET_NESTED_STATE先於KVM_SET_VCPU_EVENTS，這不會造成問題，因為中斷陰影會正確還原至 vmcb02 （KVM_SET_VCPU_EVENTS會覆寫KVM_SET_NESTED_STATE在 int_state 中還原的內容）。但是，如果 KVM_SET_VCPU_EVENTS 先於KVM_SET_NESTED_STATE，則中斷陰影將還原至 vmcb01 而非 vmcb02。這對於 L1 （延遲中斷） 來說大多是良性的，但對於 L2 則不然。對於 L2，vCPU 可能會停擺 （例如，如果喚醒中斷在 HLT 之前傳遞，而 HLT 本應處於中斷陰影中）。將int_state同步至 nested_sync_control_from_vmcb02（） 中快取的 vmcb12 以避免此問題。這樣，KVM_SET_NESTED_STATE還原正確的中斷影子狀態，如果KVM_SET_VCPU_EVENTS隨後，它會用相同的值覆蓋它。（CVE-2026-45987）

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

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

  - net： bridge：在 RCU 讀取器中使用穩定的 FDB dst 快照 「fdb_delete_local（）」可以就地重寫本機 FDB 項目，「（）」會將「f->dst」更新到另一個連接埠或「NULL」，同時保持項目處於活動狀態。
    數個橋接器 RCU 讀取器會透過 'brforward_read（）' sysfs 路徑檢查 'f->dst'，包括 'br_fdb_fillbuf（）'。這些讀取器目前會多次載入「f->dst」，因此可以在檢查和稍後的解除參照中觀察到不一致的值。在 'br_fdb_fillbuf（）' 中，這表示並行的 local-FDB 更新可以在 NULL 檢查之後和 'port_no' 解除參照之前變更 'f->dst'，從而導致 NULL-ptr-deref。透過在每個受影響的 RCU 讀取器中拍攝「f->dst」的單一「READ_ONCE（）」快照，並將該快照用於其餘的存取序列來解決此問題。此外，在 'fdb_delete_local（）' 中使用 'WRITE_ONCE（）' 發佈就地 'f->dst' 更新，讓讀取器和寫入器使用相符的存取模式。
    (CVE-2026-46086)

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

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

  - crypto： authencesn - 在執行個體建立期間拒絕短 ahash 摘要 authencesn 需要零驗證大小或至少 4 個位元組的驗證大小，因為 ESN 加密/解密路徑一律會在已驗證資料的結尾移動 4 個位元組的高階序號資料。雖然 crypto_authenc_esn_setauthsize（） 已經拒絕 1..3 範圍內的明確非零 authsizes，但 crypto_authenc_esn_create（） 仍然將 auth->digestsize 複製到 inst->alg.maxauthsize 中，而不進行驗證。然後，AEAD 核心會從該值初始化 tfm 的預設驗證大小。因此，選取摘要大小為 1..3 的 ahash （例如 cbcmac（cipher_null） 會暴露預設驗證大小無效的 authencesn 執行個體，即使 setauthsize（） 會拒絕相同的值。然後，AF_ALG可能會使用太短的標籤觸發 ESN 尾部處理並擊中越界存取。拒絕 ahash 摘要大小在無效非零範圍 1..3 中的 authencesn 執行個體，以便任何 tfm 都無法繼承不支援的預設驗證大小。（CVE-2026-46033）

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

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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
317252	Linux Distros 未修補弱點：CVE-2026-46014	medium
317251	Linux Distros 未修補弱點：CVE-2026-45968	medium
317250	Linux Distros 未修補弱點：CVE-2026-48690	high
317249	Linux Distros 未修補的弱點：CVE-2026-45914	high
317248	Linux Distros 未修補弱點：CVE-2026-45943	high
317247	Linux Distros 未修補的弱點：CVE-2026-46043	critical
317246	Linux Distros 未修補弱點：CVE-2026-45940	medium
317245	Linux Distros 未修補弱點：CVE-2026-46027	high
317244	Linux Distros 未修補弱點：CVE-2026-45919	medium
317243	Linux Distros 未修補弱點：CVE-2026-45964	medium
317242	Linux Distros 未修補的弱點：CVE-2026-45905	medium
317241	Linux Distros 未修補弱點：CVE-2026-45868	medium
317240	Linux Distros 未修補弱點：CVE-2026-46090	high
317239	Linux Distros 未修補弱點：CVE-2026-45892	medium
317238	Linux Distros 未修補弱點：CVE-2026-45986	medium
317237	Linux Distros 未修補弱點：CVE-2026-48696	medium
317236	Linux Distros 未修補的弱點：CVE-2026-46050	medium
317235	Linux Distros 未修補弱點：CVE-2026-45981	medium
317234	Linux Distros 未修補的弱點：CVE-2026-46049	medium
317233	Linux Distros 未修補的弱點：CVE-2026-46075	high
317232	Linux Distros 未修補弱點：CVE-2026-45948	medium
317231	Linux Distros 未修補弱點：CVE-2026-45852	high
317230	Linux Distros 未修補弱點：CVE-2026-46056	high
317229	Linux Distros 未修補弱點：CVE-2026-45912	medium
317228	Linux Distros 未修補弱點：CVE-2026-46062	high
317227	Linux Distros 未修補的弱點：CVE-2026-46083	medium
317226	Linux Distros 未修補弱點：CVE-2026-45970	high
317225	Linux Distros 未修補的弱點：CVE-2026-46004	high
317224	Linux Distros 未修補的弱點：CVE-2026-45954	medium
317223	Linux Distros 未修補弱點：CVE-2026-45994	high
317222	Linux Distros 未修補弱點：CVE-2026-46054	high
317221	Linux Distros 未修補的弱點：CVE-2026-45885	high
317220	Linux Distros 未修補的弱點：CVE-2026-48685	medium
317219	Linux Distros 未修補弱點：CVE-2026-45870	medium
317218	Linux Distros 未修補的弱點：CVE-2026-48693	medium
317217	Linux Distros 未修補的弱點：CVE-2026-45960	medium
317216	Linux Distros 未修補弱點：CVE-2026-46064	high
317215	Linux Distros 未修補弱點：CVE-2026-46006	high
317214	Linux Distros 未修補弱點：CVE-2026-45996	high
317213	Linux Distros 未修補弱點：CVE-2025-71304	medium
317212	Linux Distros 未修補的弱點：CVE-2026-46052	high
317211	Linux Distros 未修補的弱點：CVE-2026-46079	medium
317210	Linux Distros 未修補的弱點：CVE-2026-45987	medium
317209	Linux Distros 未修補弱點：CVE-2026-46086	medium
317208	Linux Distros 未修補的弱點：CVE-2026-46033	high
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

偵測

Nessus 的 Misc. 系列

medium

medium

high

high

high

critical

medium

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

high

medium

high

medium

high

high

medium

high

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

medium

medium