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

  - mt76mt7921不假設 SDIO 標頭有足夠的空間給 SDIO 標頭 mt7921_usb_sdio_tx_prepare_skb() 呼叫 mt7921_usb_sdio_write_txwi() 和 mt7921_skb_add_usb_sdio_hdr()兩者都盲目地假設傳遞的 skb 中有足夠的空間。當 skb 是在透過 mt7921 netdev 的傳輸之網路核心中配置的 skb 時通常符合此假設 (雖然這也只是一種最佳化且並非嚴格保證)但是當 skb 源自接收路徑時有時無法符合此假設另一個 netdev 和 的 值會透過例如橋接器層傳遞到 mt7921。盲目地在 skb 前面加上位元組一律是錯誤的。此認可會在 mt7921_usb_sdio_tx_prepare_skb() 中的 mt7921_usb_sdio_write_txwi() 呼叫之前引入 skb_cow_head() 呼叫以確保至少 MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE 位元組可推送到 skb。如果沒有此修正我可以在使用其內建 RTL8169 PCI 乙太網路介面卡的 Intel Atom x86 系統上以及在 ARM 型 Raspberry Pi 1 上橋接 MT7921AU 型 USB 802.11ax 介面和乙太網路介面進而簡單地造成核心錯誤使用其內建的 SMSC9512 USB 乙太網路介面卡。請注意並非每個系統組態都會發生錯誤因為只有當接收端 netdev 在其所接收的 skbs 中留下的空餘空間少於 mt7921 針對其 SDIO 標頭所需的空間時才會發生錯誤。以下是執行核心 6.1.24+ [1] 的 skb_panic 之 skb_push+0x44/0x48 的 skb_panic 來自 mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 的 skb_push [mt7921_common] 來自 [b_sdio_t21_comare_sk mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24 /0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34 After this修正橋接 mt7921 介面在我先前有問題的兩個系統上皆可正常運作。 [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a (CVE-2023-53785)

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

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

  - KVMVMX修正KVM 在 Hyper-V 上作為巢狀 hypervisor 執行時因未初始化的 current_vmcs 而導致的損毀情形。更新 MSR 點陣圖時evmcs_touch_msr_bitmap 函式會使用 current_vmcs per-cpu 變數來標記 msr 點陣圖已變更。 vmx_vcpu_create() 透過 vmx_disable_intercept_for_msr -> vmx_msr_bitmap_l01_changed 最後呼叫此函式來修改 msr 點陣圖。該函式會檢查 current_vmcs 是否為 null但由於 current_vmcs 未初始化因此檢查不充分。因此程式碼可能會錯誤寫入其他工作留下的 current_vmcs 值所指向的結構。
    未停用先佔目前的工作可先佔並移至另一個 CPU當多次從 evmcs_touch_msr_bitmap() 存取 current_vmcs進而導致損毀時。只有 vmcs01 才會發生呼叫者操控 MSR 點陣圖的情形因此解決方案是使用 vmx->vmcs01.vmcs 而非 current_vmcs。錯誤核心 NULL 指標解除參照、位址 0000000000000338 PGD 4e1775067 P4D 0 Oops
    0002 [#1] PREEMPT SMP NOPTI ... RIP0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... 呼叫追踪：
    vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53756)

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

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

  - gve使用 -EOPNOTSUPP 實作 gettimex64。gve 目前實作 ptp_clock 供 do_aux_work 單獨使用。 ptp_clock_gettime() 和 ptp_sys_offset() 假設每個 ptp_clock 已實作 gettimex64 或 gettime64。虛設常式 gettimex64 並傳回 -EOPNOTSUPP 以防止 NULL 解除參照。 (CVE-2025-40299)

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

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

  - futex在 exec 爭用時不洩漏 robust_list 指標 sys_get_robust_list() 和 compat_get_robust_list() 會使用 ptrace_may_access() 檢查是否允許呼叫的工作存取其他工作的 robust_list 指標。
    此檢查會影響目標處理程序中的並行 exec()。在 exec() 期間工作可能會從無權限的二進位轉換為有權限的二進位 (例如 setuid 二進位)且其認證/記憶體對應可能會變更。如果 get_robust_list() 在此轉換前執行 ptrace_may_access()它可能會在目標變得有權限後錯誤地允許存取敏感資訊。爭用存取權允許攻擊者惡意利用一個視窗在目標處理程序透過 exec() 轉換為有權限的狀態之前ptrace_may_access() 在該視窗中傳送。例如，假設有一個即將執行 setuid-root 二進位的無權限工作 T。攻擊者工作 A 在 T 仍無權限時呼叫了 get_robust_list(T)。由於 ptrace_may_access() 會根據目前的認證檢查權限因此可成功執行。不過如果 T 之後立即開始執行它會變成具權限並可變更其記憶體對應。由於 get_robust_list() 繼續存取 T->robust_list 而不與 exec() 同步因此可能會從現在具有權限的處理程序中讀取使用者空間指標。這違反了預定的 post-exec 存取限制且可能洩漏敏感記憶體位址或在較大型的惡意利用鏈結中被當做原語使用。因此爭用可導致跨權限邊界未經授權的資訊洩漏並造成潛在的安全性風險。在叫用 ptrace_may_access() 和存取 robust_list/compat_robust_list 之前在 signal->exec_update_lock 上取得讀取鎖定。如此可確保目標工作的 exec 狀態在檢查期間維持穩定進而可對認證進行一致且同步的驗證。 (CVE-2025-40341)

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

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

  - drm/msm修正系結錯誤的工作佇列洩漏。如果系結期間發生早期錯誤 (例如子元件系結失敗)，請務必破壞工作佇列。由於提交 c3b790ea07a1 (drm使用 drmm_ 管理 drm_mode_config_init)當釋放 drm 裝置時也會釋放模式組態 (使用舊版介面時)但會新增明確的清理以確保一致性 和便於反向移植。
    拼湊而成 https://patchwork.freedesktop.org/patch/525093/ (CVE-2023-53849)

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

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

  - smb用戶端修正 smb2_close_cached_fid() 中潛在的 UAFfind_or_create_cached_dir() 可在 kref_put() 發現 refcount 降為零之後但在 smb2_close_cached_fid() 中取得 cfid_list_lock 之前擷取新參照從而導致釋放後使用。切換至 kref_put_lock()以便在保留 cfid_list_lock 的情況下呼叫 cfid_release()進而縮小差距。 (CVE-2025-40328)

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

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

  - f2fs如果不可部分完成檔案中止則排清 inode 讓我們排清正在中止不可部分完成作業的 inode以避免在此呼叫堆疊收回期間過時的已變更 inode f2fs_mark_inode_dirty_sync+0x22/0x40 [f2fs] f2fs_abort_atomic_write+0xc4/0xf0 [f2fs] f2fs_evict_inode+0x3f/ 0x690 [f2fs] sugov_start+0x140/0x140 evict+0xc3/0x1c0 evict_inodes+0x17b/0x210 generic_shutdown_super+0x32/0x120 kill_block_super+0x21/0x50 deactivate_locked_super+0x31/0x90 cleanup_mnt+0x100/0x160 task_work_run+0x59/0x90 do_exit+0x33b/0xa50 do_group_exit+0x2d/0x80 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd 這會在 f2fs_evict_inode: f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) 中觸發 f2fs_bug_on()其可修正 syzbot 報告 loop0偵測到容量從 0 變更到 131072 F2FS-fs (loop0): crc 值無效 F2FS-fs (loop0)在檢查點找到 nat_bits F2FS-fs (loop0)使用檢查點版本 = 48b305e4 掛載 - -----------[在此處切入]------------ fs/f2fs/inode.c:869! 的核心錯誤無效 opcode0000 [#1] PREEMPT SMP KASAN CPU0 PID 5014 Commsyz-executor220 未受污染的 6.4.0-syzkaller-11479-g6cd06ab12d1a #0 硬體名稱 Google Google Compute Engine/Google Compute Engine、BIOS Google 05 /27/2023 RIP0010:f2fs_evict_inode+0x172d/0x1e00 fs/f2fs/inode.c:869 程式碼
    ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd <0f> 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc RSP
    0018:ffffc90003a6fa00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff8880273b8000 RSI: ffffffff83a2bd0d RDI: 0000000000000007 RBP: ffff888077db91b0 R08:
     R090000000000000007  : 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888029a3c000 R13: ffff888077db9660 R14: ffff888029a3c0b8 R15: ffff888077db9c50 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f1909bb9000 CR3: 00000000276a9000 CR4: 0000000000350ef0 Call Trace: <TASK> evict+0x2ed/0x6b0 fs/inode.c:665 dispose_list+0x117/0x1e0 fs/inode.c:698 evict_inodes+0x345/0x440 fs/inode.c:748 generic_shutdown_super+ 0xaf/0x480 fs/super.c:478 kill_block_super+0x64/0xb0 fs/super.c:1417 kill_f2fs_super+0x2af/0x3c0 fs/f2fs/super.c:4704 deactivate_locked_super+0x98/0x160 fs/super.c:330 deactivate_super+ 0xb1/0xd0 fs/super.c:361 cleanup_mnt+0x2ae/0x3d0 fs/namespace.c:1254 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [內嵌] do_exit+0xa9a /0x29a0 kernel/exit.c:874 do_group_exit+0xd4/0x2a0 kernel/exit.c:1024 __do_sys_exit_group kernel/exit.c:1035 [內嵌] __se_sys_exit_group kernel/exit.c:1033 [內嵌] __x64_sys_exit_group+0x3e/0x50 kernel/ exit.c:1033 do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP0033:0x7f309be71a09 程式碼無法執行存取 opcode 位元組位於 0x7f309be719df。RSP002b00007fff171df518 EFLAGS00000246 ORIG_RAX
    00000000000000e7 RAX: ffffffffffffffda RBX: 00007f309bef7330 RCX: 00007f309be71a09 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09:
     R1000007f309bef1e40  : 0000000000010600 R11: 0000000000000246 R12: 00007f309bef7330 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK> Modules linked in: ---[ end trace 0000000000000000]--- RIP: 0010:f2fs_evict_inode+0x172d/ 0x1e00 fs/f2fs/inode.c:869 程式碼ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd <0f> 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc RSP0018:ffffc90003a6fa00 EFLAGS00010293 RAX
    0000000000000000 RBX0000000000 ---truncated--- (CVE-2023-53829)

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

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

  - drm/amdgpu驗證 userq 緩衝區虛擬位址和大小它需要驗證 userq 物件虛擬位址來判斷其是否位於有效的 vm 對應中。 (CVE-2025-40334)

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

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

  - usb早期xhci-dbc修正潛在的超出邊界記憶體存取 如果 xdbc_bulk_write() 失敗「buf」中的值可以是任何值。因此不保證呼叫 xdbc_trace() 時字串會以 NULL 終止。
    保留一個額外的位元組此位元組會自動歸零因為 'buf' 是靜態變數以避免在此情況發生時發生的麻煩。 (CVE-2023-53840)

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

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

  - wifiath11k忽略來自 dp 中未初始化對等的片段。當所有具有 ACS 的頻段皆設定最大虛擬 ap 介面且 hostapd 會每 60 秒重新啟動一次時會隨機觀察到當機。在此特定狀況下系統會收到本身對等的片段封包但其 rx_tid 和 rx_frags 並未在 datapath 中初始化。處理此片段時可觀察到當機因為 rx_frag 清單未初始化而且當我們進入 ath11k_dp_rx_h_sort_frags, skb null 時會導致例外狀況。為解決此問題在處理收到的片段之前我們會先檢查 dp_setup_done 旗標是否已設定以確保對等節點已完成片段佇列的 dp 對等節點設定否則忽略片段的處理。呼叫追踪
    ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0 /0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 (CVE-2023-53822)

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

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

  - s390/idlemark arch_cpu_idle() noinstr linux-next 認可 (cpuidletracing: Warn about !rcu_is_watching()) 新增一個警告該問題會針對 s390 的 arch_cpu_idle() 函式 RCU 未啟用 下列情況
    arch_cpu_idle+0x0/0x28 警告CPU 2 PID在 include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258 中的模組連結在 CPU2 PID 0 Commswapper/2 未受污染的 6.2.0-rc6 中。 -next-20230202 #4 硬體名稱 IBM 8561 T01 703 (z/VM 7.3.0) Krnl PSW 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258) R:0 T:1 IO:0 EX:0 Key:0 M 1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000 0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000 0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0 0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8 Krnl Code: 00000000002b55b0: c02000840051 larl %r2 ,0000000001335652 00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58 #00000000002b55bc: af000000 mc 0,0 >00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e 00000000002b55c4: 0707 bcr 0,%r7 00000000002b55c6: 0707 bcr 0,%r7 00000000002b55c8:
    eb6ff0480024 stmg %r6,%r15,72(%r15) 00000000002b55ce: b90400ef lgr %r14,%r15 呼叫追踪
    [<00000000002b55c0>] arch_ftrace_ops_list_func+0x250/0x258 ([<00000000002b55bc>] arch_ftrace_ops_list_func+0x24c/0x258) [<0000000000f5f0fc>] ftrace_common+0x1c/0x20 [<00000000001044f6>] arch_cpu_idle+0x6/0x28 [<0000000000f4acf6>] default_idle_call+0x76/0x128 [<00000000001cc374>] do_idle+0xf4/0x1b0 [<00000000001cc6ce>] cpu_startup_entry+0x36/0x40 [<0000000000119d00>] smp_start_secondary+0x140/0x150 [<0000000000f5d2ae>] restart_int_handler+0x6e/0x90 像所有其他架構一樣使用 CONFIG_ARCH_WANTS_NO_INSTR 標記 arch_cpu_idle() noinstr (應該)修正此問題。
    (CVE-2023-53859)

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

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

  - drm/gpusvm修正 hmm_pfn_to_map_order() 使用方式 處理 hmm 範圍部分涵蓋大型頁面 (例如 2M) 的情況否則我們可能最終會做出令人困擾的事情例如對應範圍外的記憶體甚至可能不對應以 mm 為單位。修正以 xe userptr 程式碼為基礎此程式碼在未來的修補程式中會直接使用 gpusvm因此需要在此處對齊。 v2- 新增 kernel-doc (Matt B) - s/fls/ilog2/ (Thomas) (CVE-2025-40336)

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

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

  - ASoCIntel: avs關閉 PCM 時停用經時工作。前者會釋放 DAI 的私密內容因此這兩個作業應同步以避免 slab-use-after-free 或更嚴重的錯誤。 (CVE-2025-40344)

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

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

  - drm/amdgpu驗證 userq 輸入引數這將有助於驗證 userq 輸入引數並拒絕 IOCTL 首先的無效 userq 要求。 (CVE-2025-40335)

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

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

  - iavf使用內部狀態釋放流量 IRQ 如果系統在 iavf_reset_task() 執行時嘗試關閉 netdev __LINK_STATE_START 會被清除而 netif_running() 會在 iavf_reinit_interrupt_scheme() 中傳回 false。這將導致無法呼叫 iavf_free_traffic_irqs()並發生如下泄漏[7632.489326] remove_proc_entry移除非空白目錄「irq/999」至少洩漏「iavf-enp24s0f0v0-TxRx-0」[7632.490214] 警告CPU: 0 PID: 稍後呼叫 pci_disable_msix() 時會顯示 fs/proc/generic.c:718 的 remove_proc_entry+0x19b/0x1b0 ()。使用內部介面卡狀態修正。若 state == __IAVF_RUNNING 則流量 IRQ 將永遠存在。 (CVE-2023-53850)

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

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

  - drm/sched修正 drm_sched_entity_kill_jobs_cb 中的鎖死。下方提及的 Mesa 問題指出了可能的鎖死[ 1231.611031] ] 可能的中斷鎖定鎖定情況 [ 1231.611033] CPU0 CPU1 [1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable() [1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** 在此範例中CPU0 可以是透過 xa_* 函式存取 job->dependencies 的任何函式且不會停用中斷 (例如
    drm_sched_job_add_dependency()、drm_sched_entity_kill_jobs_cb())。因此在中斷內容中CPU1 會執行 drm_sched_entity_kill_jobs_cb() 做為隔離訊號回呼。嘗試擷取已由 CPU0 保留的 xa_lock 時會發生鎖死。以 xa_*_irq 對應取代所有 xa_* 的使用可修正此問題但 Christian 指出另一個問題dma_fence_signal 佔用 fence.lockdma_fence_add_callback 也一樣。 dma_fence_signal() // 鎖定 f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependent -> dma_fence_add_callback() // 鎖定 f2.lock如果 f1 和 f2 共用相同的執行緒同步鎖定則會鎖死。為修正這兩個問題將對相依性進行反覆運算並重新啟用相依性的程式碼移出至 drm_sched_entity_kill_jobs_work()。 [phasta認可訊息 nits] (CVE-2025-40329)

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

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

  - drm/xe執行 core_hotunplug 測試時修正 xe_gem_fault 中的 oops。在未啟用除錯選項的情況下針對即時核心執行 xe-fast-feedback 測試清單時我在 xe_gem_fault 中看到 oops。core_hotunplug unbind-rebind 完成後會發生不穩定情形。據推測會發生的情況是處理程序 mmaps、因為 FAULT_FLAG_RETRY_NOWAIT 邏輯而解除鎖定、沒有剩餘處理程序記憶體造成 ttm_bo_vm_dummy_page() 傳回 VM_FAULT_NOPAGE (因為沒有任何剩餘項目可填入)然後在 mem_type_is_vram(tbo->resource-> mem_type)因為 tbo->resource 為 NULL。這很複雜但符合資料並在測試結束後說明 oops。 (CVE-2025-40340)

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

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

  - netstmmac正確處理 Rx 總和檢查碼卸載錯誤如果硬體總和檢查碼卸載 (CoE) 已啟用且封包屬於已知的 IP ethertype stmmac_rx 函式之前會將 skb->ip_summed 設定為 CHECKSUM_UNNECESSARY。但是此邏輯無法檢查硬體是否確實報告了總和檢查碼錯誤。在此階段會忽略表示標頭或承載總和檢查碼失敗的硬體狀態。這可造成損毀的封包被視為有效向上傳遞至網路堆疊。此修補程式會檢查硬體報告總和檢查碼錯誤時設定的 `csum_none` 狀態旗標藉此更正邏輯。如果設定此旗標skb->ip_summed 現在會正確設定為 CHECKSUM_NONE確保核心的網路堆疊會執行其本身的驗證並正確處理損毀的封包。
    (CVE-2025-40337)

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

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

  - drm/amdkfd修正未釋放的 mmap 寫入鎖定。如果在排出重試錯誤時取得 mmap 寫入鎖定則不會釋放 mmap 寫入鎖定因為 svm_range_restore_pages 呼叫 mmap_read_unlock 然後傳回。因為無法取得 mmap 讀取或寫入鎖定這會造成鎖死及系統稍後當機。如果排出重試錯誤可修正此錯誤則將 mmap 寫入鎖定降級為讀取鎖定。 (CVE-2025-40332)

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

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

  - block/rq_qos使用新的鎖定認可 50e34d78815e 保護 rq_qos api (block停用提升裝置 int del_gendisk)將 rq_qos_exit() 從 disk_release() 移至 del_gendisk()此會引入一些問題
    1) 如果透過 cgroupfs 啟用 iocost/iolatency 來觸發 rq_qos_add()則其可與 del_gendisk() 並行執行同時寫入「q->rq_qos」並不安全。 2) 啟用 cgroup 原則時仰賴 rq_qos 將呼叫 rq_qos_add() 和 blkcg_activate_policy()且如果在中間呼叫 rq_qos_exit()則會在 blkcg_activate_policy() 中觸發 null-ptr-dereference()。 3) blkg_conf_open_bdev() 可先呼叫 blkdev_get_no_open() 以尋找磁碟然後如果 del_gendisk() 的 rq_qos_exit() 先於 rq_qos_add() 執行則記憶體將會洩漏。此修補程式新增了磁碟層級 mutex「rq_qos_mutex」1) 鎖定將直接保護 rq_qos_exit()。 2) 針對不依賴 blk-cgroup 的 wbt目前只能從磁碟初始化呼叫 rq_qos_add()因為直到 rq_qos_exit() 才能解構 wbt因此暫時不保護 wbt 是安全的。然而若未來支援 rq_qos 動態解構此修補程式也可直接保護 rq_qos_add() 不受 wbt_init() 影響這已足夠因為 blk-sysfs 已同步寫入器和磁碟移除。 3) 針對 iocost 和 iolatency為了同步磁碟移除和 cgroup 組態設定會在執行 blkg_conf_open_bdev() 的 blkdev_get_no_open() 之後保留鎖定並在 blkg_conf_exit() 中釋放。為修正上述記憶體洩漏問題會在保留新鎖定後檢查 disk_live()。 (CVE-2023-53823)

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

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

  - RDMA/siw修正 QP 損毀以等待所有參照卸除。延遲 QP 破壞完成直到中斷 QP 的所有 siw 參照為止。呼叫 RDMA 核心會在成功從 siw_qp_destroy() 呼叫傳回後釋放 QP 結構因此 siw 不得在傳回時保留任何 QP 的剩餘參照。測試 NFSoRDMA 時在 xfstest generic/460 中遇到一個釋放後使用問題。在此情況下對等節點的 TCP 連線中斷後觸發的 siw_cm_work_handler 會延遲直到參照已釋放的 QP 的 QP 破壞呼叫之後。 (CVE-2022-50666)

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

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

  - nvme-fc使用鎖定存取 port_state 和 rport 狀態。當沒有使用中的關聯時nvme_fc_unregister_remote 會在任何時間點移除 lport 物件上的遠端連接埠。這會與重新連線邏輯爭用因為 nvme_fc_create_association 並未鎖定以檢查 port_state而是以不可分割的方式增加 rport 上的作用中計數。 (CVE-2025-40342)

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

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

  - drm/amdgpu修正 vm_handle_moved 的 nullptr 錯誤 如果 amdgpu_bo_va 為 fpriv->prt_va此項目的 bo 一律為 NULL。因此這類 amdgpu_bo_va 應在 amdgpu_vm_handle_moved 之前個別更新。
    (CVE-2025-40339)

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

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

  - f2fs修正以在 truncate_dnode() 的直接節點上執行功能健全檢查 syzbot 報告下列錯誤
    在 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 讀取位址 ffff88802a25c000 的大小 4 (由工作 syz-executor148/5000 CPU: 1 PID: 5000 Comm: syz-executor148 未受污染 6.4 .0-rc7-syzkaller-00041-ge660abd551f1 #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 05/27/2023 呼叫追踪 <TASK> __dump_stack lib/dump_stack.c:88 [內嵌] dump_stack_lvl+0xd9 /0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [內嵌] kasan_report+0x11c/0x130 mm/kasan/report 。 0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h :825 [內嵌] f2fs_setattr+0x1738 /0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [內嵌] do_open fs/namei .c:3640 [內嵌] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c 1372 [內嵌] __do_sys_creat fs/open.c:1448 [內嵌] __se_sys_creat fs/open.c:1442 [內嵌] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 根本原因是inodeA 透過 inodeB 的 ino 參照 inodeB一旦 inodeA 被截斷它就會呼叫 truncate_dnode() 來截斷資料區塊在 inodeB 的節點頁面中它會遍歷從 node->i.i_addr[0] 到 node->i.i_addr[ADDRS_PER_BLOCK() - 1] 的對應資料進而導致超出邊界存取。此修補程式可修正在 truncate_dnode() 中的 dnode 頁面上新增功能健全檢查如此有助於避免觸發此類問題一旦遇到此類問題便會將新引入的 ERROR_INVALID_NODE_REFERENCE 錯誤記錄到超級區塊中稍後 fsck 即可偵測到此類問題並嘗試修復。
    此外它也會移除 f2fs_truncate_data_blocks() 以進行清理 (因為該函式只有一個呼叫端)並改用 f2fs_truncate_data_blocks_range()。 (CVE-2023-53846)

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

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

  - f2fs修正 __insert_extent_tree() 中的無限迴圈。我們取得錯誤的範圍資訊資料並在 rb 樹狀結構中查閱 extent_node 時會造成無限迴圈 (CONFIG_F2FS_CHECK_FS=n)。透過在該情況下傳回 NULL 並列印某些核心訊息來避免此問題。 (CVE-2025-40333)

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

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

  - of: overlay儘早呼叫 of_changeset_init() 當 of_overlay_fdt_apply() 失敗時可能會套用部分變更集但呼叫者仍應呼叫 of_overlay_remove() 以清理此部分狀態。不過of_overlay_apply() 會先於 init_overlay_changeset() 呼叫 of_resolve_phandles()。因此如果重疊因為未解析的符號而無法套用，overlay_changeset.cset.entries 清單仍會未初始化而且清理將會在 overlay_removal_is_ok() 中發生 NULL 指標解除參照而損毀。將 of_changeset_init() 的呼叫從 init_overlay_changeset() 移至 of_overlay_fdt_apply()以修正此問題所有其他早期初始化均在此完成。 (CVE-2023-53856)

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

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

  - nvmet-fc避免兩次排程關聯刪除透過 configfs 介面強制關閉連接埠時nvmet_port_subsys_drop_link() 會先呼叫 nvmet_port_del_ctrls()然後再呼叫 nvmet_disable_port()。這兩個函式最終都會排程所有剩餘的關聯進行刪除。目前的實作會檢查關聯是否將要移除但僅在排程工作項目之後才會檢查。因此第一個排程的工作項目可能會釋放所有資源然後再排程相同的工作項目進行刪除。由於關聯清單是 RCU 清單因此無法直接取得鎖定並移除清單項目因此無法再次查詢。而是必須使用旗標 (終止) 來判斷關聯是否已處於刪除程序中。 (CVE-2025-40343)

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

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

  - sctp防止 TOCTOU 超出邊界寫入針對下列未保留通訊端鎖定的路徑sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() 確保在位址清單在兩次分配之間增加的情況下不超過邊界(time-of-check) 和 write (time-of-use)。 (CVE-2025-40331)

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

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

  - drm/msm/dp將輔助裝置與 DP 控制器一起中斷。使用 devres 取消填充輔助匯流排可確保在探查延遲時損毀 EDP 面板裝置並在下次嘗試時重新建立。但 devres 連結的結構裝置是 DPU (drm_dev->dev)這可能會在 DP 控制器關閉後發生。可在記錄中常見的滿是零的 EDID-hexdump 或偶發/罕見的 KASAN 錯誤 (面板嘗試讀取 EDID 資訊) 中看到此問題的徵兆會造成 DP 資源釋放後使用。很想將 devres 移至 DP 控制器的 struct 裝置但 aux 匯流排上裝置所使用的資源已在錯誤路徑中明確移除。
    KASAN 報告的釋放後使用問題也仍然存在因為 DP aux 模組會明確釋放此程式碼路徑中其 devres 配置的記憶體。因此請明確刪除錯誤路徑中以及元件解除系結路徑中的 aux 匯流排以避免這些問題。修補程式
    https://patchwork.freedesktop.org/patch/542163/ (CVE-2023-53851)

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

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

  - iioadcina2xx避免符合 OF 裝置時發生 NULL 指標解除參照。受影響的行會導致我們的平台發生 NULL 指標解除參照因為裝置樹狀結構中包含下列相容字串的清單power-sensor@40 {compatible = ti ina232、ti、ina231 ... };由於驅動程式未宣告相容的字串 ti,ina232因此 OF 比對在 ti,ina231 上成功。但是 I2C 裝置 ID 資訊是透過第一個相容字串填入 cf。 of_i2c_get_board_info() 中的模態別名填充。由於舊版 I2C 裝置 ID 表格中也沒有 ina232 項目因此探查函式中的 struct i2c_device_id *id 指標為 NULL。改用已填入的類型變數來修正此變數其可指向正確的驅動程式資料。由於也需要該名稱因此新增一個泛型名稱至 ina2xx_config 表格。 (CVE-2023-53834)

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

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

  - ASoCIntelavs不在元件之間共用名稱指標若直接共用 'name'卸除元件可能會導致釋放後使用錯誤。複製名稱以避免發生此情況。同時更新作業順序 - 自從認可 cee28113db17 (ASoCdmaengine_pcm允許透過組態傳送元件名稱)以來架構不會覆寫 component->name (若在叫用初始化程式之前設定)。
    (CVE-2025-40338)

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

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

  - bpfbpf_sk_storage修正無效的等待內容 lockdep report './test_progs -t test_local_storage' 報告快速[ 27.137569] ======================= ====== [ 27.138122] [錯誤無效等待內容] [27.138650] 6.5.0-03980-gd11ae1b16b0a #247 污染 GO [ 27.139542] ------------- ---------------- [27.140106] test_progs/1729 嘗試鎖定 [ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}位於
    local_lock_acquire+0x9/0x130 [ 27.141834] 其他可協助我們除錯的其他資訊 [ 27.142437] context-{5:5} [ 27.142856] test_progs/1729 保留的 2 個鎖定 [ 27.143352] #0ffffffff84bcd9c0 (rcu_read_lock ){..}-{1:3}、@rcu_lock_acquire+0x4/0x40 [ 27.144492] #1ffff888107deb2c0 (&storage->lock){..-.}-{2:2}、@bpf_local_storage_update+ 0x39e/0x8e0 [ 27.145855] 堆疊反向追踪 [27.146274] CPU: 0 PID: 1729 Comm: test_progs 污染GO 6.5.0-03980-gd11ae1b16b0a #247 [ 27.147550] 硬體名稱QEMU Standard PC (i440FX + PIIX、 1996)、BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org04/01/2014 [ 27.149127] 呼叫追踪 [ 27.149490] <TASK> [ 27.149867] dump_stack_lvl+0x130/0x1d0 [27.152609] dump_stack +0x14/0x20 [ 27.153131] __lock_acquire+0x1657/0x2220 [ 27.153677] lock_acquire+0x1b8/0x510 [ 27.157908] local_lock_acquire+0x29/0x130 [ 27.159048] obj_cgroup_charge+0xf4/0x3c0 [ 27.160794] slab_pre_alloc_hook [0+0x28e/0x2bb] 27.161931]
    __kmem_cache_alloc_node+0x51/0x210 [ 27.163557] __kmalloc+0xaa/0x210 [ 27.164593] bpf_map_kzalloc+0xbc/0x170 [ 27.165147] bpf_selem_alloc+0x130/0x510 [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0 [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0 [ 27.169199] bpf_map_update_value+0x415/0x4f0 [ 27.169871] map_update_elem+0x413/0x550 [ 27.170330]
    __sys_bpf+0x5e9/0x640 [ 27.174065] __x64_sys_bpf+0x80/0x90 [ 27.174568] do_syscall_64+0x48/0xa0 [27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 27.175932] RIP 0033:0x7effb40e41ad [ 27.176357] 程式碼2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 c0 ff 8 4 3 8b 0d8 [ 27.179028] RSP002b:00007ffe64c21fc8 EFLAGS00000202 ORIG_RAX: 0000000000000141 [ 27.180088] RAXffffffffffffffda RBX00007ffe64c22768 RCX
    00007effb40e41ad [ 27.181082] RDX 0000000000000020 RSI 00007ffe64c22008 RDI 0000000000000002 [27.182030] RBP 00007ffe64c21ff0 R08000000000000 [076] R09[4] 2 :780 [076] []2:780 [ 27.183038076 ] R10[4]
    0000000000000064 R110000000000000202 R120000000000000000 [ 27.184006R13]  00007ffe64c22788 R14
    00007effb42a1000 R150000000000000000 [ 27.184958] </TASK> 它抱怨在保留 raw_spin_lock 的同時取得 local_lock。這表示其不應在保留 raw_spin_lock 時配置記憶體因為這對 RT 不安全。需要 raw_spin_lock因為 bpf_local_storage 支援追踪內容。特別是對於工作本機儲存在追踪 bpf prog 中很容易取得目前工作 PTR_TO_BTF_ID。
    不過工作 (和 cgroup) 本機儲存已移至可在 raw_spin_lock 之後使用的 bpf 記憶體配置器。展開用於 sk 儲存。針對 sk (和 inode) 儲存其尚未移至 bpf 記憶體配置器。無論是否使用 raw_spin_lockkzalloc(GFP_ATOMIC) 在追踪內容中理論上可能是不安全的。但是本機儲存協助程式需要驗證器接受的 sk 指標 (PTR_TO_BTF_ID)假設會發生這種情況 (是指在 kzalloc 不安全的內容中執行 bpf prog同時也能容納驗證器接受的 sk 指標)。此修補程式可避免 kzalloc 在 raw_spin_lock 之後使 splat 無訊息。在 raw_spin_lock 之前有一個現有的 kzalloc。此時很可能需要 kzalloc因為之前剛剛完成查閱。因此此修補程式一律先執行 kzalloc再執行 acq ---truncated--- (CVE-2023-53857)

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

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

  - ASoCsoc-compress重新定位並新增 pcm_mutex如果已設定 panic_on_warn 且已啟動壓縮資料流 (DPCM)則會因為 card->pcm_mutex 未正確保留而發生核心錯誤。在下列函式中已在此行 snd_soc_dpcm_mutex_assert_held 發出警告。 static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ...
    snd_soc_dpcm_mutex_assert_held(fe); ... } void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { ... snd_soc_dpcm_mutex_assert_held(rtd); ... } int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, int event) { ...
    snd_soc_dpcm_mutex_assert_held(fe); ... } 這些函式會由沒有 pcm_mutex 鎖定的 soc_compr_set_params_fe、soc_compr_open_fe 和 soc_compr_free_fe 呼叫。這是呼叫堆疊。 [ 414.527841][T2179] pc dpcm_process_paths+0x5a4/0x750 [ 414.527848][ T2179] lr dpcm_process_paths+0x37c/0x750 [414.527945][ T2179] 呼叫追踪 [ 414.527949][ T2179] dpcm_process_paths +0x5a4/0x750 [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc [ 414.527972][ T2179] snd_compr_open+0x180/0x248 [ 414.527981][ T2179] snd_open+0x15c/0x194 [ 414.528003][ T2179] chrdev_open+0x1b0/0x220 [ 414.528023][ T2179] do_dentry_open+0x30c/0x594 [ 414.528045][ T2179] vfs_open+0x34/0x44 [ 414.528053][ T2179] path_openat+0x914/0xb08 [ 414.528062][ T2179] do_filp_open+0xc0/0x170 [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4 [ 414.528084][ T2179] invoke_syscall+0x48/0x10c [ 414.528094][ T2179] el0_svc_common+0xbc/0x104 [ 414.528099][ T2179] do_el0_svc+0x34/0xd8 [ 414.528103][ T2179] el0_svc+0x34/0xc4 [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4 [ 414.528142][ T2179] 核心錯誤 - 未同步: panic_on_warn set ... 因此我重新定位並新增了 pcm_mutex 來解決 lockdep 錯誤。
    (CVE-2023-53866)

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

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

  - vc_screen在 vcs_write() 中重新載入結構 vc_data 指標以避免 UAF。呼叫 vcs_write() 中的 console_unlock() 後vc_data 結構可由 vc_port_destruct() 釋放。因此必須在 vcs_write() 的 while 迴圈中在 console_lock() 之後重新載入 vc_data 指標以避免在呼叫 vcs_size() 時發生 UAF。Syzkaller 報告 vcs_size() 有一個 UAF。BUG: KASANvcs_size 中發生 slab釋放後使用 (drivers/tty/vt/vc_screen.c:215) 工作 repro_vcs_size/4119 呼叫追踪於 addr ffff8880beab89a8 讀取大小 4 <TASK> __asan_report_load4_noabort (mm/kasan/report_generic .c:380) vcs_size (drivers/tty/vt/vc_screen.c:215) vcs_write (drivers/tty/vt/vc_screen.c:664) vfs_write (fs/read_write.c:582 fs/read_write.c:564) ...<TASK> 由工作 1213 分配kmalloc_trace (mm/slab_common.c:1064) vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680 drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058) con_install (drivers/tty/vt/vt.c:3334) tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415 drivers/tty/ tty_io.c:1392) tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128) chrdev_open (fs/char_dev.c:415) do_dentry_open (fs/open.c:921) vfs_open (fs /open.c:1052) ... 已由工作 4116 釋放 kfree (mm/slab_common.c:1016) vc_port_destruct (drivers/tty/vt/vt.c:1044) tty_port_destructor (drivers/tty/tty_port.c:296) tty_port_put (drivers/tty/tty_port.c) :312) vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (辨別器 2)) vt_ioctl (drivers/tty/vt/vt_ioctl.c:903) tty_ioctl (drivers/tty/tty_io.c:2778) ... 錯誤位址屬於 ffff8880beab8800 處的物件該物件屬於大小為 1024 的快取 kmalloc-1k。錯誤位址位於已釋放的 1024 位元組區域內 424 位元組 [ffff8880beab8800、ffff8880beab8c00) 錯誤位址屬於實體 page 00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbeab8 head:00000000afc77580 order:3 whole_mapcount:0 nr_pages_mapped:0 pincount:0 旗標
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880beab8a00fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8a80fb fb fb fb fb fb fb fb fb fb fb fb fb ======== ================================================== ======== 因核心污染而停用鎖定除錯 (CVE-2023-53747)

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

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

  - HIDhidraw修正裝置 refcount 上的資料爭用 hidraw_open() 函式可增加 hidraw 裝置參照計數器。計數器沒有專用的同步機制導致在並行開啟裝置時可能會發生資料爭用。爭用是認可 8590222e4b02 引入的回歸 (HID
    hidraw以 rwsem 取代 hidraw 裝置表格 mutex。雖然 minors_rwsem 預定用於保護 hidraw_table 本身但藉由取得寫入鎖定的方式也可保護參照計數器。
    這與 hidraw_release() 對稱。 (CVE-2023-53759)

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

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

  - net處理 kmalloc_reserve() 中的整數溢位。責備變更ptr = kmalloc(size) if (ptr) size = ksize(ptr); size = kmalloc_size_roundup(size); ptr = kmalloc(size);這會造成如 syzbot [1] 和 Kyle Zeng 所報告的多種損毀情形。問題是如果 @size 大於 0x80000001則 kmalloc_size_roundup(size) 會傳回 2^32。 kmalloc_reserve() 使用 32 位元變數 (obj_size)因此 2^32 會截斷為 0。kmalloc(0) 會傳回 skb 配置未處理的 ZERO_SIZE_PTR。如果 netdev->mtu 設定為接近 0x7fffffff則可觸發下列追踪我們日後可能會將 netdev->mtu 限制在更合理的限制 (如 KMALLOC_MAX_SIZE)。此修補程式以 syzbot 報告以及 Kyle Zeng 提供的報告和暫定修正為基礎。 [1] 錯誤 KASAN__build_skb_around net/core/skbuff.c:294 中的使用者記憶體存取權 [內嵌] 錯誤 KASAN__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 中的使用者記憶體存取權工作 syz-executor.4/22554 在 addr 00000000fffffd10 寫入大小為 32 的情況 CPU1 PID
    22554 Commsyz-executor.4 未受污染的 6.1.39-syzkaller #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 7 月 3 日呼叫追踪dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/ stacktrace.c:279 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106 print_report+0xe4/0x4b4 mm /kasan/report.c:398 kasan_report+0x150/0x1ac mm/kasan/report.c:495 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 memset+0x40/0x70 mm/kasan/shadow.c:44 __build_skb_around net/core/skbuff.c:294 [內嵌] __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 alloc_skb include/linux/skbuff.h:1316 [內嵌] igmpv3_newpack+0x104/0x1088 net/ipv4/igmp .c:359 add_grec+0x81c/0x1124 net/ipv4/igmp.c:534 igmpv3_send_cr net/ipv4/igmp.c:667 [內嵌] igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810 call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [內嵌]
    __run_timers+0x54c/0x710 kernel/time/timer.c:1790 run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
    _stext+0x380/0xfbc__do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79 call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891 do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq。 c:84 invoke_softirq kernel/softirq.c:437 [內嵌] __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683 irq_exit_rcu+0x14/0x78 kernel/softirq.c:695 el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry -common.c:717
    __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724 el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729 el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S :584 (CVE-2023-53752)

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

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

  - drm/amdgpu/powerplay/psm修正電源狀態 init 提交中的記憶體洩漏 902bc65de0b3 (drm/amdgpu/powerplay/psm在電源狀態 init 中傳回一個錯誤) 使電源狀態 init 函式在無法取得powerplay 表格中的項目但未在傳回之前清理針對目前電源狀態配置的記憶體。 (CVE-2022-50617)

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

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

  - 在 libcoap release-4.3.5-patches 之前的 libcoap 的 OSCORE 組態剖析器中存在一個記憶體洩漏弱點。剖析特定組態值時可能發生超出邊界讀取情形進而允許攻擊者推斷或讀取 .rodata 區段中字串邊界以外的記憶體。這可能導致資訊洩漏或拒絕服務。 (CVE-2025-59391)

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

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

  - PCI釋放 coalescing release_resource() 後已釋放的資源但實際上並不會釋放資源或資源清單項目因此請釋放資源清單項目以避免洩漏。 (CVE-2023-53743)

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

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

  - mmcmeson-gx修正 mmc_add_host() 的傳回值檢查 mmc_add_host() 可能傳回錯誤若忽略其傳回值則會導致兩個問題 1. 在 mmc_alloc_host() 中配置的記憶體洩漏。 2. 在 remove() 路徑中將呼叫 mmc_remove_host() 以刪除裝置 (但尚未新增)這將導致核心因 device_del() 中的 null-ptr-deref 而損毀。檢查將呼叫 mmc_free_host() 的傳回值和 goto 錯誤路徑藉此修正此問題。 (CVE-2022-50618)

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

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

  - dmverity-loadpin只信任具有強制執行力的 verity 目標。Verity 目標可以設定為忽略損毀的資料區塊。LoadPin 必須只信任設定為在偵測到資料損毀時執行某種強制執行 (例如傳回錯誤、重新啟動系統或觸發不穩定) 的 verity 目標。 (CVE-2022-50621)

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

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

  - scsiufscoremcq修正 &hwq->cq_lock 鎖死問題執行 ufshcd_err_handler() 時CQ 事件中斷可進入等候相同的鎖定。ufshcd_handle_mcq_cq_events() 和 ufs_mtk_mcq_intr() 可能會發生此問題。在已啟用 IRQ 的情況下於 IRQ 內容中使用 &hwq->cq_lock 時會產生下列警告訊息。將 ufshcd_mcq_poll_cqe_lock() 與 spin_lock_irqsave 搭配使用 (而非 spin_lock) 可解決鎖死問題。 [name:lockdep&]警告不一致的鎖定狀態 [name:lockdep&]-------------------------------- [名稱: lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} 使用量。 [name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] Takesffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at: ufshcd_mcq_poll_cqe_lock+0x30/0xe0 [name:lockdep&]{IN-HARDIRQ-W} state was registered at: lock_acquire+0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod] __handle_irq_event_percpu+0x140/0x3ec handle_irq_event+0x50/0xd8 handle_fasteoi_irq+0x148/0x2b0 generic_handle_domain_irq+0x4c/0x6c gic_handle_irq+0x58/0x134 call_on_irq_stack+0x40/0x74 do_interrupt_handler+0x84/0xe4 el1_interrupt+0x3c/0x78 <snip> 可能的不安全鎖定情況CPU0 ---- lock(&hwq->cq_lock);
    <Interrupt> lock(&hwq->cq_lock); *** DEADLOCK *** kworker/u16:4/260 保留的 2 個鎖定[name:lockdep&] 堆疊反向追踪CPU: 7 PID: 260 通訊: kworker/u16:4 受污染的 GSW OE 6.1.17-mainline-android14-2-g277223301adb#1 Workqueue: ufs_eh_wq_0 ufshcd_err_handler Call trace: dump_backtrace+0x10c/0x160 show_stack+0x20/0x30 dump_stack_lvl+0x98/0xd8 dump_stack+0x20/0x60 print_usage_bug+0x584/0x76c mark_lock_irq+0x488/0x510 mark_lock+0x1ec/0x25c __lock_acquire+0x4d8/0xffc lock_acquire +0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufshcd_poll+0x68/0x1b0 ufshcd_transfer_req_compl+0x9c/0xc8 ufshcd_err_handler+0x3bc/0xea0 process_one_work+0x2f4/0x7e8 worker_thread+0x234/0x450 kthread+0x110/0x134 ret_from_fork+0x10/0x20 (CVE-2023-53760)

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

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

  - USB: usbtmc修正 0 長度 ioctl 控制訊息的方向 syzbot fuzzer 在 usbtmc 驅動程式中發現一個問題 使用者提交 0 長度控制傳輸的 ioctl 時驅動程式不會檢查方向是否設定為OUT: ------------[cut here ]------------ usb 3-1BOGUS 控制目錄管道 80000b80 不符合 bRequestType fd 警告 CPU在 drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 的 5100 模組連結在 CPU: 0 PID: 5100 Comm: syz-executor428 未受污染6.3.0-syzkaller-12049-g58390c8ce1bd #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 4 月 14 日 RIP 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411程式碼7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41 RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282 RAX: 0000000000000000 RBXff ff8880789e9058 RCX0000000000000000 RDXffff888029593b80 RSI ffffffff814c1447 RDI 0000000000000001 RBP
     R08ffff88801ea742f8  : 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528 R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100 FS:
    0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0
    0000000080050033 CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 呼叫追踪 <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [內嵌] usb_control_msg+0x320/0x4a0 drivers/usb/core/message。 c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [內嵌] usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc:2097 若要修正此問題我們必須覆寫控制項的 bRequestType 欄位中的方向長度為 0 時的要求結構。(CVE-2023-53761)

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

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

  - io_uring/rw確認針對提早失敗清除已配置的 iovec。先前提交重複使用回收基礎結構以提早清理但是這對於我們的內部快取溢位的情況來說還是不夠的。如果發生這種情況如果要求也提早中止則可能洩漏已配置的 iovec。
    還原先前在該情況下強制釋放 iovec。 (CVE-2025-40267)

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

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

  - mediadvb-usb修正 dvb_usb_adapter_init() 中的記憶體洩漏。Syzbot 報告 dvb_usb_adapter_init() 中的記憶體洩漏。洩漏的原因是發生錯誤時未考量和釋出目前反覆運算的 Adapter->priv。目前若發生錯誤其會在增加 num_adapters_initalized 前結束以作為參照計數器釋放 dvb_usb_adapter_exit() 中的所有 adap->priv。有多個錯誤路徑可在計數器增加前結束。在 dvb_usb_adapter_init() 內包含 dvb_usb_adapter_stream_init()、dvb_usb_adapter_dvb_init() 和 dvb_usb_adapter_frontend_init() 的錯誤處理路徑。這表示若這些函式中的任何一個發生錯誤目前的反覆運算不會受到影響且目前反覆運算的 adap->priv 也不會釋放。透過釋放錯誤路徑中的 stream_init_err: 標籤中目前反覆運算的 adap->priv 來修正此問題。(適用的)adap->priv 物件如預期在 dvb_usb_adapter_exit() 中使用 num_adapters_initalized 變數釋放。Syzbot 報告
    BUG記憶體洩漏未參照物件 0xffff8881172f1a00 (大小 512)comm kworker/0:2, pid 139, jiffies 4294994873 (10.960s) 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... backtrace
    [<ffffffff844af012>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [內嵌] [<ffffffff844af012>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c 184 [內嵌] [<ffffffff844af012>] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308 [<ffffffff830db21d>] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb -usb/dib0700_core.c:883 [<ffffffff82d3fdc7>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [內嵌] [<ffffffff8274ab37>] real_probe .part.0+0xe7/0x310 drivers/base/dd.c:621 [<ffffffff8274ae6c>] real_probe drivers/base/dd.c:583 [內嵌] [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c :752 [<ffffffff8274af6a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782 [<ffffffff8274b786>]
    __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899 [<ffffffff82747c87>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [<ffffffff8274b352>] __device_attach+0x122/0x260 drivers/base/dd.c:970 [<ffffffff827498f6>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [<ffffffff82745cdb>] device_add+0x5fb/0xdf0 drivers/base/core.c:3405 [<ffffffff82d3d202>] usb_set_configuration+0x8f2/0xb80 drivers/usb/core /message.c:2170 [<ffffffff82d4dbfc>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<ffffffff82d3f49c>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [內嵌] [<ffffffff8274ab37>] real_probe.part.0+0xe7/0x310 drivers/base/dd.c:621 [<ffffffff8274ae6c>] real_probe drivers/base/dd.c:583 [內嵌] [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752 (CVE-2022-50626)

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

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

  - virt/coco/sev-guest雙重緩衝區訊息加密演算法直接讀取和寫入共用的未加密記憶體其可能會洩漏資訊並允許主機竄改訊息完整性。而是視需要將整個訊息複製入或複制出然後再對其執行任何計算。
    (CVE-2023-53769)

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

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

  - 序列amba-pl011ARM Server Base System Architecture [1] 文件中描述通用 UART 介面的避免 SBSA UART 存取 DMACR 暫存器第 B 章通用 UART。這種泛型 UART 不支援 DMA。在目前的程式碼中sbsa_uart_pops 和 amba_pl011_pops 共用相同的 stop_rx 作業這會叫用 pl011_dma_rx_stop進而導致存取 DMACR 暫存器。此認可會在 pl011_dma_rx_stop 中新增一個使用using_rx_dma 檢查以避免存取不支援 DMA 的 SBSA UART 的 DMACR 暫存器。當核心以 CONFIG_DMA_ENGINE=y 啟用 DMA 引擎時Linux SBSA PL011 驅動程式將會存取某些函式中的 PL011 DMACR 暫存器。針對大多數真正的 SBSA Pl011 硬體實作DMACR 寫入行為將會遭到忽略。因此這些 DMACR 作業不會造成明顯的問題。但就某些虛擬 SBSA PL011 硬體而言例如 Xen 虛擬 SBSA PL011 (vpl011) 裝置行為可能不同。來賓存取未實作的 UART 暫存器時Xen vpl011 模擬會對來賓插入資料中止。由於 Xen VPL011 與 SBSA 相容因此不會實作 DMACR 暫存器。因此當 Linux SBSA PL011 驅動程式存取 DMACR 暫存器時將會發生未處理的資料中止錯誤而應用程式將會發生分割錯誤未處理 0xffffffc00944d048 的錯誤記憶體中止資訊ESR = 0x96000000 EC = 0x25DABT (目前 EL)、IL = 32 位元 SET = 0、FnV = 0 EA = 0、S1PTW = 0 FSC = 0x00ttbr 位址大小錯誤 資料中止資訊ISV = 0、ISS = 0x00000000 CM = 0、WnR = 0 swapper pgtable4k 頁面、39 -位元 VA、 pgdp=0000000020e2e000 [ffffffc00944d048] pgd=100000003ffff803、p4d=100000003ffff803、 pud=100000003ffff803、 pmd=100000003fffa803、 pte=006800009c090f13 內部錯誤ttbr 位址大小錯誤96000000 [#1] PREEMPT SMP ... Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+ 0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 程式碼b9000083 b901f001 794038a0 8b000042 (b9000041) ---[ end trace 83dd93df15c3216f ]--- 注意
    bootlogd[132] 以 preempt_count 1 結束 /etc/rcS.d/S07bootlogd: line 47: 132 分割錯誤 start-stop-daemon 此問題已在 Xen 社群中討論過我們認為它應能修正 Linux 中的此問題。如需詳細資訊請參閱 [2]。 [1] https://developer.arm.com/documentation/den0094/c/?lang=en [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html (CVE-2022-50625)

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

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

  - drm/gud修正 UBSAN 警告 UBSAN 抱怨 bool 的無效值[ 101.165172] [drm] 已初始化 2-3 的 gud 1.0.0 20200422。2:1次要版本 1 上的 .0 [ 101.213360] gud 2-3.2:1.0[drm] fb1guddrmfb 框架緩衝區裝置 [ 101.213426] usbcore已註冊新介面驅動程式 gud [ 101.989431] ===================== ================================================== ========= [ 101.989441] UBSAN
    linux/include/linux/iosys-map.h:253:9 中的無效載入 [ 101.989447] 值 121 的載入不是 '_Bool' 類型的有效值 [ 101.989451] CPU1 PID455 通訊kworker /1:6 未受污染的 5.18.0-rc5-gud-5.18-rc5 #3 [101.989456] 硬體名稱Hewlett-Packard HP EliteBook 820 G1/1991BIOS L71 版本 01.44 2018 年 4 月 12 日 [101.989459] 工作佇列events_long gud_flush_work [gud] [ 101.989471] 呼叫追踪 [ 101.989474] <TASK> [101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ [] ] drm_gem_vmap+0x26/0x60 [drm] [[vmapx] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594[vmapx ] drm_gem_shmem_object_vmap+0x9/0xb [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [101.989708] ========================== ================================================== ==== 此警告的來源是在 dma_buf_vmap() 呼叫的 iosys_map_clear() 中。它會根據 map->is_iomem 有條件地設定值。iosys_map 變數在堆疊上配置未初始化導致 ->is_iomem 具有所有類型的值而不僅是 0/1。透過歸零 iosys_map 變數來修正此問題。 (CVE-2022-50628)

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

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

  - c-ares 是一個非同步解析器程式庫。 1.32.3 至 1.34.5 版在使用 read_answer() 和 process_answer() 的嘗試次數達到上限後終止查詢進而造成拒絕服務。1.34.6 版已修正此問題。(CVE-2025-62408)

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

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

  - scsilpfc修正 lpfc_sli4_pci_mem_setup() 中的 ioremap 問題 if_type 等於零且 pci_resource_start(pdev, PCI_64BIT_BAR4) 傳回 falsedrbl_regs_memmap_p 不會重新對應。此可將 NULL 指標傳遞至 iounmap()其可在特定架構上觸發 WARN()。當 if_type 等於 6 且 pci_resource_start(pdev, PCI_64BIT_BAR4) 傳回 true 時drbl_regs_memmap_p 可能已重新對應且不會重新對應 ctrl_regs_memmap_p。這是資源洩漏並將 NULL 指標傳送至 iounmap()。若要修正這些問題我們需要在 iounmap() 前新增 null 檢查並變更部分 goto 標籤。 (CVE-2023-53754)

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

ID	名稱	嚴重性
277888	Linux Distros 未修補的弱點：CVE-2023-53785	medium
277887	Linux Distros 未修補的弱點：CVE-2023-53756	medium
277886	Linux Distros 未修補的弱點：CVE-2025-40299	medium
277880	Linux Distros 未修補的弱點：CVE-2025-40341	medium
277879	Linux Distros 未修補的弱點：CVE-2023-53849	medium
277878	Linux Distros 未修補的弱點：CVE-2025-40328	high
277877	Linux Distros 未修補的弱點：CVE-2023-53829	high
277876	Linux Distros 未修補的弱點：CVE-2025-40334	high
277875	Linux Distros 未修補的弱點：CVE-2023-53840	medium
277874	Linux Distros 未修補的弱點：CVE-2023-53822	medium
277873	Linux Distros 未修補的弱點：CVE-2023-53859	medium
277853	Linux Distros 未修補的弱點：CVE-2025-40336	high
277852	Linux Distros 未修補的弱點：CVE-2025-40344	medium
277851	Linux Distros 未修補的弱點：CVE-2025-40335	medium
277850	Linux Distros 未修補的弱點：CVE-2023-53850	medium
277849	Linux Distros 未修補的弱點：CVE-2025-40329	medium
277848	Linux Distros 未修補的弱點：CVE-2025-40340	medium
277847	Linux Distros 未修補的弱點：CVE-2025-40337	medium
277846	Linux Distros 未修補的弱點：CVE-2025-40332	high
277845	Linux Distros 未修補的弱點：CVE-2023-53823	medium
277844	Linux Distros 未修補的弱點：CVE-2022-50666	high
277843	Linux Distros 未修補的弱點：CVE-2025-40342	high
277840	Linux Distros 未修補的弱點：CVE-2025-40339	medium
277839	Linux Distros 未修補的弱點：CVE-2023-53846	medium
277838	Linux Distros 未修補的弱點：CVE-2025-40333	medium
277837	Linux Distros 未修補的弱點：CVE-2023-53856	medium
277836	Linux Distros 未修補的弱點：CVE-2025-40343	high
277835	Linux Distros 未修補的弱點：CVE-2025-40331	high
277834	Linux Distros 未修補的弱點：CVE-2023-53851	high
277833	Linux Distros 未修補的弱點：CVE-2023-53834	medium
277832	Linux Distros 未修補的弱點：CVE-2025-40338	high
277831	Linux Distros 未修補的弱點：CVE-2023-53857	medium
277830	Linux Distros 未修補的弱點：CVE-2023-53866	medium
277787	Linux Distros 未修補的弱點：CVE-2023-53747	high
277786	Linux Distros 未修補的弱點：CVE-2023-53759	medium
277785	Linux Distros 未修補的弱點：CVE-2023-53752	high
277784	Linux Distros 未修補弱點：CVE-2022-50617	medium
277783	Linux Distros 未修補的弱點：CVE-2025-59391	medium
277782	Linux Distros 未修補的弱點：CVE-2023-53743	medium
277781	Linux Distros 未修補的弱點：CVE-2022-50618	medium
277780	Linux Distros 未修補的弱點：CVE-2022-50621	medium
277779	Linux Distros 未修補的弱點：CVE-2023-53760	medium
277778	Linux Distros 未修補的弱點：CVE-2023-53761	medium
277777	Linux Distros 未修補的弱點：CVE-2025-40267	medium
277776	Linux Distros 未修補的弱點：CVE-2022-50626	medium
277775	Linux Distros 未修補的弱點：CVE-2023-53769	high
277774	Linux Distros 未修補的弱點：CVE-2022-50625	medium
277773	Linux Distros 未修補的弱點：CVE-2022-50628	high
277772	Linux Distros 未修補的弱點：CVE-2025-62408	medium
277771	Linux Distros 未修補的弱點：CVE-2023-53754	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

medium