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

  - 輸入lkkbd - 透過 schedule_work() 釋放裝置 lkkbd_interrupt() 排程 lk->tq 前停用擱置的工作且工作處置程式 lkkbd_reinit() 解除參照 lkkbd 結構及其 serio/input_dev 欄位。 lkkbd_disconnect() 和 lkkbd_connect() 中的錯誤路徑釋放 lkkbd 結構時沒有阻止 reinit 工作再次排入佇列直到 serio_close() 傳回為止。這可允許工作處置程式在釋放結構後執行進而導致可能的釋放後使用。使用 disable_work_sync() 而非 cancel_work_sync()確保 reinit 工作無法重新排入佇列並在 lkkbd_disconnect() 和 lkkbd_connect() 錯誤路徑中 (serio_open() 之後) 呼叫它。 (CVE-2025-71073)

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

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

  - drm/amdgpu修正 gpu 復原中的 job->pasid 存取爭用避免 GPU 復原中因 sched 逾時回呼和 tdr 工作佇列間的爭用而發生可能的 UAF。gpu 復原函式呼叫 drm_sched_stop() 並隨後呼叫 drm_sched_start()。 drm_sched_start() 會重新啟動 tdr 佇列其最終會釋放工作。如果 tdr 佇列在逾時回呼完成前釋放工作該工作將會被釋放且我們會在存取 pasid 時獲得 UAF。提早快取以避免 UAF。KASAN 追踪範例 [ 493.058141] 錯誤KASANamdgpu_device_gpu_recover+0x968/0x990 中發生平台釋放後使用 [amdgpu] [493.067530] kworker/u128:1/323 工作於 addr ffff88b0ce3f794c 讀取大小為 4 的內容 [ 493.074892] [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 受污染GE 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(vulnerable) [ 493.076493] 受污染
    [E]=UNSIGNED_MODULE [ 493.076495] 硬體名稱TYAN B8021G88V2HR-2T/S8021GM2NR-2TBIOS V1.03。B10 2019 年 4 月 1 日 [ 493.076500] 工作佇列amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] [ 493.076512] 呼叫追踪 [ 493.076515<TASK> ]  [ 493.076518] dump_stack_lvl+0x64/0x80 [ 493.076529] print_report+ 0xce/0x630 [493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0 [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077253] kasan_report+0xb8/0xf0 [493.077258] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.078672] __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu] [ 493.079378] amdgpu_coredump+0x1fd/0x4c0 [amdgpu] [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu] [ 493.080903] pick_task_fair+0x24e/0x330 [ 493.080910] ?
    __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu] [ 493.081702] _raw_spin_lock+0x75/0xc0 [ 493.081708] ?
    __pfx__raw_spin_lock+0x10/0x10 [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched] [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081725] process_one_work+0x679/0xff0 [ 493.081732] worker_thread+0x6ce/0xfd0 [ 493.081736] __pfx_worker_thread+0x10/0x10 [ 493.081739] kthread+0x376/0x730 [ 493.081744] __pfx_kthread+0x10/0x10 [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081751] ?
    __pfx_kthread+0x10/0x10 [ 493.081755] ret_from_fork+0x247/0x330 [ 493.081761] ? __pfx_kthread+0x10/0x10 [493.081764] ret_from_fork_asm+0x1a/0x30 [ 493.081771] </TASK> (從認可 20880a3fd5dd7bca1a079534cf6596bda92e107d 中精選出) (CVE-2025-68793)

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

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

  - ext4xattr修正 ext4_raw_inode() 如果 ext4_get_inode_loc() 失敗 (例如如果它傳回
    -EFSCORRUPTED)則 iloc.bh 將保持設定為 NULL。由於 ext4_xattr_inode_dec_ref_all() 缺少錯誤檢查因此這將導致在 ext4_get_inode_loc() 之後立即呼叫的 ext4_raw_inode() 中發生 null 指標解除參照。由 Linux Verification Center (linuxtesting.org) 和 SVACE 發現。(CVE-2025-68820)

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

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

  - charapplicom修正 ac_ioctl 中的 NULL 指標解除參照由 Atuin - Automated Vulnerability Discovery Engine 發現。在 ac_ioctl 中cmd 為 6 時系統會略過 IndexCard 的驗證和有效的 RamIO 指標檢查。不過該函式會在結尾無條件執行 readb(apbs[IndexCard].RamIO + VERS)。如果 cmd 為 6IndexCard 可能會參照不存在的面板 (其中 RamIO 為 NULL)導致 NULL 指標解除參照。透過在 cmd 為 6 時略過 readb 存取來修正此命令是全域資訊查詢且不以特定的 board 內容為目標。 (CVE-2025-68797)

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

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

  - mptcp在同步連線上較早地遞補Syzkaller 報告同步連線爭用導致遞補狀態不一致 警告 net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow 的 CPU: 3 PID: 33。 c:1515 模組連結於 CPU3 UID0 PID33 Comm
    ksoftirqd/3 未受污染的 syzkaller #0 PREEMPT(full) 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.16.3-debian-1.16.3-2~bpo12+1 2014 年 4 月 1 日 RIP 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 程式碼89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX:
    ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12:
    ffff88802ba69900 R131ffff920000d9e67 R14ffff888046f81800 R150000000000000004 FS
    0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0
    0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 tcp_v6_do_rcv+0x492/0x1740 net/ ipv6/tcp_ipv6.c:1672 tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1e4/0x4b0 net/ipvNF6_HOOKinput_c44 include/linux/netfilter.h:318 [內嵌] NF_HOOK include/linux/netfilter.h:312 [內嵌] ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 dst_input include/net/dst.h:471 [內嵌] ip6_rcv_finish net/ipv6/ip6_input.c:79 [內嵌] NF_HOOK include/linux/netfilter.h:318 [內嵌] NF_HOOK include/linux/netfilter.h:312 [內嵌] ipv6_rcv+0x264/0x650 net/ipv6/ ip6_input.c:311 __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979
    __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 process_backlog+0x442/0x15e0 net/core/dev.c:6444
    __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 napi_poll net/core/dev.c:7557 [內嵌] net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 run_ksoftirqd kernel/softirq.c:968 [內嵌] run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread .c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> TCP 子流程可以處理 simult-connect syn-ack轉換至 TCP_FIN1 狀態後的封包繞過 MPTCP 遞補檢查因為不會針對 * -> FIN_WAIT1 轉換叫用 sk_state_change() 回呼。這會將 msk 通訊端移至不一致的狀態且下一個傳入資料將會命中報告的展開。儘早解決移動 simult-fallback 檢查的爭用階段 - 即產生 syn-ack 時。關於修正標籤 [2] 應該也修正了這個由 [3] 引入的問題。需要 [1] 做為相依性其並未明確標記為修正但確實是一個修正而且在 [3] 之前就已反向移植。換言之此認可應最多反向移植至 [3]包括 [2] 和 [1] (若該處尚不存在)。 (CVE-2025-71088)

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

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

  - iommu設定 CONFIG_X86 時停用 SVA 修補程式系列 修正核心位址空間的過時 IOTLB 項目v7。這會針對與 IOMMU 共用虛擬定址 (SVA) 相關的一個安全性弱點提出修正。在 SVA 內容中IOMMU 可以快取核心頁面表格項目。當釋放核心頁面表格頁面並重新配置用於其他目的時IOMMU 可能仍保留過時、不正確的項目。攻擊者可惡意利用此問題造成釋放後使用或釋放後寫入情形進而可能導致權限提升或資料損毀。此解決方案引入了適用於核心頁面表格頁面的延遲釋放機制其提供安全視窗來通知 IOMMU使其快取無效然後再重複使用頁面。此修補程式 (共 8 個)在 IOMMU 共用虛擬定址 (SVA) 內容中IOMMU 硬體會共用並遍歷 CPU 的頁面表格。x86 架構會將核心的虛擬位址空間對應至每個處理程序頁面表格的上方部分。因此在 SVA 內容中IOMMU 硬體可以遍歷和快取核心頁面表格項目。Linux 核心目前缺少核心頁面表格變更的通知機制特別是在釋放和重複使用頁面表格頁面時。IOMMU 驅動程式只會收到使用者虛擬位址對應變更的通知。這可造成 IOMMU 的內部快取為核心 VA 保留過時項目。釋放核心頁面表格頁面但之後又重新配置時會出現釋放後使用 (UAF) 和釋放後寫入 (WAF) 情形。IOMMU 可將新資料錯誤解譯為有效的頁面表格項目。然後 IOMMU 可能會深入受攻擊者控制的記憶體進而導致任意實體記憶體 DMA 存取或權限提升。這也是一個釋放後寫入問題因為 IOMMU 在嘗試遍歷過時頁面表格時可能會繼續將已存取和已變更位元寫入釋放的記憶體。目前SVA 內容無權限無法存取核心對應。不過IOMMU 仍會一直遍歷僅限核心的分頁表直到分頁項目在該分頁項目中它會意識到對應是針對核心而輸出錯誤。這表示 IOMMU 仍會快取這些中繼頁面表格項目造成上述弱點成為真正的問題。停用 x86 架構上的 SVA直到 IOMMU 可收到通知以排清分頁快取然後再釋放 CPU 核心頁面表格頁面。 (CVE-2025-71089)

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

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

  - Fulcio 是一種憑證授權單位針對 OpenID Connect (OIDC) 身分發出程式碼簽署憑證。在 1.8.5之前的版本中Fulcio 的 metaRegex() 函式使用未錨定的 regex進而允許攻擊者繞過 MetaIssuer URL 驗證並觸發 SSRF 進入任意內部服務。由於 SSRF 只能觸發 GET 要求因此要求無法變動狀態。GET 要求的回應並未傳回給呼叫者因此不可能發生資料洩漏。惡意執行者可嘗試透過 Blind SSRF 探查內部網路。此弱點已在 1.8.5 中修復。(CVE-2026-22772)

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

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

  - functionfs修正 ffs_epfile_open() 可與移除發生的 open/removal 爭用進而導致 file->private_data 指向已釋放的物件。functionfs 上有已開啟檔案的總計數 (ep0 和動態檔案)且當其達到零時會移除動態檔案。遺憾的是當其他執行緒位於 ffs_epfile_open() 中但尚未增加計數時可能會發生移除作業。在此情況下open 會成功在後續的 read() 或 write() 中留下 UAF。根本原因是誤用 ffs->opened。當物件始終保持可見時atomic_dec_and_test() 與 atomic_add_return() 不是一個好主意。若要解開該問題 * 序列化 ffs->mutex 上的 opener (ep0 和動態檔案適用) * 讓動態項目使用 atomic_inc_not_zero()如果零 ->opened 則失敗如此一來我們開啟的檔案就會遭到破壞。 * 在移除時標記動態檔案的 inode (來自 simple_recursive_removal() 的回呼) - 清除 ->i_private 。 * 已開啟動態項目驗證其尚未移除以及檢查狀態是否為 FFS_ACTIVE。 (CVE-2025-71074)

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

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

  - iavf修正 iavf_config_rss_reg() 中的差一問題。設定 RSS 雜湊金鑰和查閱表格時有差一錯誤可造成記憶體 [1] 的超出邊界讀取和超出邊界寫入複製到裝置暫存器。在認可 43a3d9ba34c9 之前 (i40evf允許 PF 驅動程式設定 RSS)迴圈上限為 i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX 由於值為最後一個有效索引因此較為安全。該認可將邊界變更為 i <= Adapter->rss_{key,lut}_size / 4其中「rss_{key,lut}_size / 4」是 dword 的數量因此最後一個有效索引是「(rss_{ key,lut}_size / 4) - 1`. 因此使用 `<=` 會存取超出結尾的一個元素。修正使用 `<` 而非 `<=` 的問題確保我們不會超出邊界。 [1] KASAN 展開關於 rss_key_size 差一錯誤KASAN作業 kworker/u8:6/63 在 iavf_config_rss+0x619/0x800 中於位址 ffff888102c50134 讀取大小為 4 的 4 錯誤 CPU: 0 UID 0 PID63 通訊kworker/u8:6 未受污染 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(自發) 硬體名稱：QEMU Standard PC (Q35 + ICH9, 2009)、BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作佇列iavf iavf_watchdog_task 呼叫追踪 <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf iavf_watchdog_task 呼叫process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK> 由工作 63 配置
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90
    __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc -64 (大小為 64) 錯誤位址位於已配置之 52 位元組區域右側 0 位元組處 [ffff888102c50100, ffff888102c50134) 錯誤位址屬於下列實體頁面page: refcount:0 mapcount:0 mapping:0000000000000000 索引:0x0 pfn 0x102c50 flags 0x200000000000000(node=0|zone=2) page_type
    f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc ffff888102c50200fc fc fc fc fc fc fc fc fc fc fc fc fc (CVE-2025-71087)

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

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

  - 團隊修正 team_queue_override_port_prio_changed() 中啟用的連接埠檢查。最近報告了一個具有下列追踪的 syzkaller 錯誤list_del 損毀、ffff888058bea080->prev 為 LIST_POISON2 (dead000000000122) ------------[在此處截斷]------------ lib/list_debug.c:59! 的核心錯誤Oops無效 opcode0000 [#1] SMP KASAN NOPTI CPU3 UID0 PID21246 Commsyz.0.2928 未受污染的 syzkaller #0 PREEMPT(完整) 硬體名稱 QEMU Standard PC (Q35 + ICH9, 2009) 、BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 程式碼48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09:
     R100000000000000000  : 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR2000000110c3afcb0 CR3
    00000000382c7000 CR40000000000352ef0 呼叫追踪 <TASK> __list_del_entry_valid include/linux/list.h:132 [內嵌] __list_del_entry include/linux/list.h:223 [內嵌] list_del_rcu include/linux/rculist.h:178 [內嵌] __team_queue_override_port_del drivers /net/team/team_core.c:826 [內嵌]
    __team_queue_override_port_del drivers/net/team/team_core.c:821 [內嵌] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [內嵌] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net /team/team_core.c:376 [內嵌] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c 1195 [內嵌] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink /af_netlink.c:1320 [內嵌] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [內嵌] __sock_sendmsg 網路/socket.c:742 [內嵌]____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684
    __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 的問題處於此流程中1) 連接埠已啟用 queue_id != 0在 qom_list 中2) 連接埠已停用 -> team_port_disable() -> team_queue_override_port_del() -> del (已從清單中移除) 3) 連接埠已停用 queue_id != 0而非任何清單 4) 優先順序變更 -> team_queue_override_port_prio_changed() -> 檢查
    已停用連接埠 && queue_id != 0 -> 呼叫 del - 遇到錯誤因為該錯誤已移除。若要修正此問題請變更 team_queue_override_port_prio_changed() 中的檢查以便在未啟用連接埠的情況下提早傳回。
    (CVE-2025-71091)

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

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

  - powerpc/64s/slb修正 SLB 預先載入期間的 SLB 多次點擊問題。在使用雜湊 MMU 的系統上軟體 SLB 預先載入快取會鏡像載入至硬體 SLB 緩衝區的項目。此預先載入快取通常會在每執行 256 次內容切換以移除舊項目之後遭到定期收回。
    為了最佳化效能核心會在上一個和下一個 mm_struct 相同時略過 switch_mm_irqs_off() 中的 switch_mmu_context()。不過在雜湊 MMU 系統上這可導致硬體 SLB 和軟體預先載入快取之間的不一致。如果從某個 CPU 的軟體快取中收回某個處理程序的 SLB 項目而之後在另一個 CPU 上執行相同的處理程序卻未執行 switch_mmu_context()則硬體 SLB 可能會保留過時的項目。如果之後核心嘗試重新載入該項目可能會觸發 SLB 多次點擊錯誤。以下時間軸顯示過時 SLB 項目的建立方式以及當處理程序在沒有 MMU 內容切換的 CPU 之間移動時可造成多次點擊錯誤的方式。CPU 0 CPU 1 -----
    ----- Process P exec swapper/1 load_elf_binarybegin_new_exc active_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * 這會讓 HW * 中的所有項目失效* 並根據預先載入快取設定新的 HW * SLB 項目。 */ context_switch sched_migrate_task 將處理程序 P 移轉至 cpu-1 處理程序 swapper/0 內容切換 (至處理程序 P) (使用處理程序 P 的 mm_struct) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb 在這裡變成 0 *而且我們從以下項目收回項目 *以 * preload_age() 預先載入快取。我們仍 * 保持硬體 SLB 和預先載入 * 快取同步這是因為 * 因為在 SLBIA 期間所有硬體 SLB 項目 * 在 switch_slb 中都會被收回。 * 然後我們只會在 HW SLB 中重新新增那些 * 目前 * 存在於 preload_cache 中的項目 * (收回後)。 */ load_elf_binary 繼續...
    setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task 將處理程序 P 移轉至 cpu-0 context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * 由於上一個和下一個 mm 結構相同我們不呼叫 * switch_mmu_context()。這會造成硬體 SLB 和軟體預先載入 * 快取在 preload_new_slb_context 中不同步。因為有 * 有一個 SLB 項目從硬體和 cpu-1 上的預先載入快取中收回 *。現在稍後在 preload_new_slb_context() 中當我們* 再次嘗試新增相同的預先載入項目時我們會將其新增至 SW * 預先載入快取然後再將其新增至 HW SLB。由於在 cpu-0 * 此項目從未失效因此新增此項目至 HW * SLB 會造成 SLB 多次點擊錯誤。 */ load_elf_binary 續 ---truncated--- (CVE-2025-71078)

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

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

  - RDMA/核心正確檢查 LS_NLA_TYPE_DGID 是否存在。RDMA_NL_LS_OP_IP_RESOLVE 的 netlink 回應應該一律有 LS_NLA_TYPE_DGID 屬性否則無效。
    正確使用 nl 剖析邏輯並呼叫 nla_parse_deprecated() 以填入 nlattrs 陣列然後直接索引該陣列以取得 DGID 的資料。若為 NULL則失敗。移除 nla 的搜尋迴圈並將驗證和剖析壓縮為一個函式。修正未將 DGID 提供給核心啟動的 RDMA_NL_LS_OP_IP_RESOLVE 查詢時由使用者空間觸發的未初始化堆疊讀取。錯誤 KMSANhex_byte_pack include/linux/hex.h:13 中的 uninit-value [內嵌] 錯誤 KMSANip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h 中的 uninit-value 13 [內嵌] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 指標+0xc09/0x1bd0 lib/vsprintf.c 2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk /printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [內嵌] ib_nl_handle_ip_res_resp +0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [內嵌] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [內嵌] rdma_nl_rcv+0xefa/ 0x11c0 drivers/infiniband/core/netlink.c :259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [內嵌] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c 714 [內嵌]
    __sock_sendmsg+0x333/0x3d0 net/socket.c:729____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
    ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703
    __compat_sys_sendmsg net/compat.c:346 [內嵌] __do_compat_sys_sendmsg net/compat.c:353 [內嵌]
    __se_compat_sys_sendmsg net/compat.c:350 [內嵌] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86 syscall_32.c:83 [內嵌] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry /syscall_32.c:3 (CVE-2025-71096)

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

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

  - iommu/mediatek修正探查延遲的釋放後使用。驅動程式會在成功查閱之後以及發生錯誤時中斷探查期間對 larb 裝置採取的參照。如果 larb 裝置尚未系結至其驅動程式導致 iommu 驅動程式探查延遲這可能會導致釋放後使用錯誤。在系結 iommu 驅動程式時將參照維持在預期狀態以修正此問題。 (CVE-2025-71071)

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

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

  - ksmbd略過相等大小時的鎖定範圍檢查以避免 size==0 反向溢位當大小等於目前 i_size (包括 0)時程式碼會用來呼叫 check_lock_range(filp, i_size, size - 1, WRITE)其會計算 `大小
    - 1` 且 size==0 會發生反向溢位。略過大小寫相等的情況。 (CVE-2025-68786)

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

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

  - ip6_gre使 ip6gre_header() 變得更健全。這些年syzbot 發現許多在 ip6gre_header() 中造成核心當機的方法 [1]。這涉及團隊或連結驅動程式動態變更其 dev->needed_headroom 和/或 dev->hard_header_len 的能力。在此特定損毀中mld_newpack() 以太小的保留/空餘空間配置 skb而且在呼叫 mld_sendpack() 時syzbot 設法附加 ip6gre 裝置。 [1] skbuffskb_under_panictext:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[截到此處 ]--- --------- net/core/skbuff.c:213 的核心錯誤 <TASK> skb_under_panic net/core/skbuff.c:223 [內嵌] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice。 h:3436 [內嵌] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [內嵌] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ ipv6/ip6_output.c:-1 [內嵌] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [內嵌] ip6_output+0x340/0x550 net/ipv6/ip6_output.c :247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [內嵌] mld_ifc_work+0x83e/0xd60 net/ ipv6/mcast.c:2693 (CVE-2025-71098)

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

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

  - svcrdma針對 memcpy 位元組位移使用 rc_pageoff svc_rdma_copy_inline_range 已將 rc_curpage (頁面索引) 新增至頁面基底而非位元組位移 rc_pageoff。使用 rc_pageoff讓複本落在目前頁面內。由 ZeroPath 發現 (https://zeropath.com) (CVE-2025-68811)

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

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

  - btrfs如果是在目前交易中移動的目錄則不記錄衝突的 inode。如果是目錄並且在目前的交易中從一個父目錄移動到另一個父目錄則無法記錄衝突的 inode因為這可能會導致在記錄重播期間嘗試使用具有兩個硬連結的目錄一個用於舊的父目錄另一個用於新的父目錄。下列狀況會觸發該問題1) 我們在過去的交易中建立了目錄 dir1 和 dir2。目錄 dir1 將 inode A 做為其父目錄2) 將 dir1 移至其他目錄3) 我們在目錄 inode A 中建立名稱為 dir1 的檔案4) fsync 新檔案。這會導致記錄新檔案的 inode 以及先前在目前交易中移動的目錄 dir1 的 inode。因此記錄樹狀結構具有 dir1 新位置的 INODE_REF 項目
    5) 我們將新檔案移至其他某個目錄。這會導致將記錄樹狀結構更新為包含檔案新位置的新 INODE_REF並移除舊位置的 INODE_REF。這會在我們呼叫 btrfs_log_new_name() 時發生6) 我們 fsync 檔案這會保留在之前步驟中完成的記錄樹狀結構變更 (btrfs_log_new_name() 只會更新記憶體中的記錄樹狀結構) 7) 發生電源故障8) 下次掛載 fs 時會發生記錄重播且在處理目錄 dir1 的 inode 時我們會找到新的 INODE_REF 並新增該連結但由於尚未記錄舊的父項因此不會移除 inode 的舊連結目錄 inode dir1。因此在我們觸發子磁碟區樹狀結構範圍緩衝區的回寫時記錄重播結束後樹狀結構檢查會偵測到我們有一個硬連結計數為 2 的目錄且會發生掛載失敗。dmesg/syslog 中報告的錯誤和堆疊追踪如下[ 3845.729764] BTRFS 資訊 (裝置 dm-0)啟動樹狀結構記錄重播 [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags
    0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] 原始
    017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino =257無效的 nlink具有 2 個但不超過 1 個用於 dir [ 3845.737786] BTRFS 資訊 (裝置 dm-0)分葉 30408704 產生 10 個總計 ptrs 17 可用空間 14881 擁有者 5 [ 3845.737789] BTRFS 資訊 (裝置 dm- 0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [3845.737803] 項目 1 金鑰 (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [3845.737807] item 2 的金鑰 (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] 位置金鑰 (257 1 0) 類型 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 k ey (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [3845.737816] 位置金鑰 (257 1 0) 類型 2 [ ---truncated--- (CVE-2025-68778)

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

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

  - scsi目標在錯誤情況下重設 t_task_cdb 指標如果配置 cmd->t_task_cdb 失敗它會保持為 NULL但之後會在「err」路徑中解除參照。若發生錯誤請將 NULL t_task_cdb 值重設為指向預設固定大小緩衝區。由 Linux Verification Center (linuxtesting.org) 和 SVACE 發現。
    (CVE-2025-68782)

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

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

  - tpm2-sessions修正 name_size「name_size」中的超出範圍索引編制沒有任何範圍檢查而直接以 TPM_ALG_ID 編制索引最嚴重的情況是會導致記憶體損毀。透過僅處理已知值並針對無法識別的值傳回 -EINVAL 來解決此問題。也使「tpm_buf_append_name」和「tpm_buf_fill_hmac_session」容易發生錯誤以便在造成任何假性 TPM 流量之前偵測到錯誤。同時在兩個函式中發生失敗時結束授權工作階段因為根據定義工作階段狀態將會損毀。 (CVE-2025-68792)

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

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

  - NFSDNFSv4 檔案建立作業忽略設定 ACL。在檔案建立期間以具名主體設定 ACL 的 NFSv4 用戶端之後可擷取 ACL然後發現這只是預設 ACL (根據模式位元)而非原本檔案建立期間已要求。這違反了 RFC 8881 區段 6.4.1.3ACL 屬性設定為指定狀態。此問題發生在 nfsd_create_setattr() 中進而呼叫 nfsd_attrs_valid() 來判斷是否要呼叫 nfsd_setattr()。不過nfsd_attrs_valid() 只會檢查 iattr 變更和安全性標籤而不會檢查 POSIX ACL。只有 ACL 存在時函式會傳回 false並略過 nfsd_setattr()且 POSIX ACL 從不套用至 inode。隨後當用戶端擷取 ACL 時伺服器在 inode 上找不到 POSIX ACL並傳回從檔案的模式位元產生的一個 POSIX ACL而非傳回原本指定的 ACL。 (CVE-2025-68803)

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

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

  - xfs修正 xattr repair 中的 UAF 問題。xchk_setup_xattr_buf 函式可以配置新的值緩衝區這表示在呼叫之前對 ab->value 的任何參照都可能變成懸置指標。在緩衝區設定之後將指派移至 以修正此問題。 (CVE-2025-68784)

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

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

  - ocfs2修正 ocfs2_find_victim_chain 中的核心錯誤 syzbot 報告 ocfs2_find_victim_chain() 中的一個核心錯誤這是因為配置鏈結清單 (鏈結清單中的下一個可用插槽) 的 `cl_next_free_rec` 欄位為 0進而觸發 BUG_ON(!cl->cl_next_free_rec) ocfs2_find_victim_chain() 中的情形並造成核心錯誤。為修正此問題在 ocfs2_claim_suballoc_bits() 中引入了一個 if 條件就在呼叫 ocfs2_find_victim_chain() (其中的程式碼區塊在下列任一條件為真時執行) 2. `cl_next_free_rec` 大於 `cl_count` (配置鏈清單中的鏈結總數)其中任一為真表示沒有剩餘鏈可供使用。
    此問題已使用 ocfs2_error() 解決其會列印錯誤記錄以供除錯之用而不會造成核心錯誤。 (CVE-2025-68771)

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

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

  - spi: fsl-cpm切換至 16 位元模式前檢查長度同位。 認可 fc96ec826bce (spi: fsl-cpm對偶數大小的大型傳輸使用 16 位元模式) 無法確保大小在切換至 16 前確實是偶數位元模式。直到最近此問題才被人們所忽略因為 kernfs 使用 PAGE_SIZE 大小的預先配置彈回緩衝區讀取 EEPROM。但是認可 8ad6249c51d0 (eepromat25轉換為 spi-mem API) 引入了一個額外的動態配置彈回緩衝區其大小正好是傳輸的大小導致當 fsl-cpm 驅動程式的大小為奇數時會造成緩衝區滿溢。當長度不是偶數時新增遺漏的長度同位驗證並保持在 8 位元模式。 (CVE-2025-68773)

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

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

  - ethtool避免統計資料查詢時發生使用者空間緩衝區溢位 ethtool -S 命令跨三個 ioctl 呼叫執行：ETHTOOL_GSSET_INFO 針對大小、ETHTOOL_GSTRINGS 針對名稱以及 ETHTOOL_GSTATS 針對值。如果在這些呼叫之間變更統計資料的數量 (例如因為裝置重新組態)使用者空間的緩衝區配置將會不正確進而可能導致緩衝區溢位。驅動程式通常應維持穩定的統計資料計數但某些驅動程式 (例如 mlx5、bnx2x、bna、ksz884x) 使用動態計數器導致發生此狀況。部分驅動程式會嘗試在內部處理此問題- 如果 stats.n_stats 不等於驅動程式的統計資料計數bnad_get_ethtool_stats() 會提早傳回。 - micrel/ksz884x 也會確保除了 stats.n_stats 不寫入任何內容並確保緩衝區溢位。
    不過兩者皆使用已指派 get_sset_count() 傳回之值的 stats.n_stats因此無法解決此處所述的問題。將 ethtool_get_strings()、ethtool_get_stats()、ethtool_get_phy_stats() 變更為在使用者空間大小和 get_sset_size() 不相符時不傳回任何項目以防止緩衝區溢位。傳回的 n_stats 值將等於零以反映尚未傳回任何內容。當使用上游 ethtool 時這可能會導致以下兩種情況其中之一取決於偵測到大小變更的時間1. 在 ethtool_get_strings() 中偵測到時報告為零。這兩種情況可能都是暫時性的後續 ethtool 呼叫應該會成功。除了避免溢位這兩種情況都非常明顯 (無輸出/已清除的統計資料)這可以說比顯示不正確/移位的統計資料要好。我也考慮過傳回錯誤而非無訊息回應但這似乎會對使用者空間應用程式造成更大的破壞。注意- 此修補程式並未聲稱可修正固有爭用它只確保我們不會溢位使用者空間緩衝區並提供更可預測的行為。- 每次 ioctl 期間都會保留 RTNL 鎖定因此釋放鎖定時個別 ioctl 呼叫之間存在爭用視窗。- 使用者空間 ethtool 一律填入 stats.n_stats但這些統計資料 ioctl 很可能是在可能不填入它的其他使用者空間應用程式中實作。新增的程式碼會檢查該值是否非零以防止任何回歸。 (CVE-2025-68795)

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

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

  - wifirtlwifi8192cu修正 rtl92cu_tx_fill_desc() 超出範圍的 tid 從 ieee80211_get_tid() 取得的 TID 可能超出 sta_entry->tids[] 的陣列大小範圍因此請檢查 TID 是否小於 MAX_TID_COUNT。
    其他方面UBSAN 警告drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 索引 10 中的 UBSAN array-index-out-of-bounds 超出「rtl_tid_data [9]」類型的範圍 (CVE-2025-71100)

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

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

  - drm/xe/oa限制 num_syncs 以防止配置過大。OA open 參數未驗證 num_syncs進而允許使用者空間傳遞任意大的值進而可能導致配置過多。新增檢查以確保 num_syncs 不超過 DRM_XE_MAX_SYNCS而在違反限制時傳回 -EINVAL。 v2使用 XE_IOCTL_DBG() 併中斷重複檢查。(Ashutosh) (從認可 e057b2d2b8d815df3858a87dffafa2af37e5945b) (CVE-2025-71076)

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

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

  - platform/chromecros_ec_ishtp解除系結驅動程式後修正 UAF 在解除系結驅動程式後另一個 kthread `cros_ec_console_log_work` 仍在存取裝置進而導致 UAF 和損毀。驅動程式未取消註冊 .remove() 中的 EC 裝置其應同步關閉子裝置。修正它。
    (CVE-2025-68804)

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

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

  - scsiaic94xx修正裝置移除路徑中的釋放後使用。asd_pci_remove() 函式在釋放 asd_ha 結構之前無法與擱置的 tasklet 同步導致潛在的釋放後使用弱點。當觸發裝置移除 (透過熱插拔或模組卸載) 時可能會發生爭用情形。此修正會在釋放 asd_ha 結構前新增 tasklet_kill()確保所有已排程的 tasklet 在清理繼續前完成。 (CVE-2025-71075)

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

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

  - fuse修正已終止且未認可的要求的 io-uring 清單損毀。如果在認可之前將要求終止則該要求不會從佇列的清單中移除。這會留下懸置清單項目進而導致清單損毀和釋放後使用問題。從已終止之未認可要求的佇列清單中移除要求。 (CVE-2025-68805)

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

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

  - nethns3在 vf 驅動程式中使用 num_tqps 申請資源目前hdev->htqp 是以 hdev->num_tqps 配置而 kinfo->tqp 是以 kinfo->num_tqps 配置。但是kinfo->num_tqps 設為 min(new_tqps, hdev->num_tqps);因此kinfo->num_tqps 可能小於 hdev->num_tqps導致部分 hdev->htqp[i] 在 hclgevf_knic_setup() 中維持未初始化狀態。因此此修補程式會使用 hdev->num_tqps 配置 hdev->htqp 和 kinfo->tqp確保 hdev->htqp 和 kinfo->tqp 的長度一致且所有元素都經過正確初始化。 (CVE-2025-71064)

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

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

  - drm/xe/oa修正 xe_oa_add_config_ioctl() 中可能發生的 UAF。在 xe_oa_add_config_ioctl() 中我們在放置metrics_lock 後存取 oa_config->id。由於此鎖定可保護 oa_config 的存留期因此攻擊者可猜測 id 並以完美的時機呼叫 xe_oa_remove_config_ioctl()在我們解除參照之前將 oa_config 釋放進而導致可能的釋放後使用。透過在保留鎖定的同時快取本機變數中的 ID 來修正此問題。 v2 (Matt A) - 中斷來自 xe_oa_remove_config_ioctl() 的 mutex_unlock(&oa->metrics_lock) 排序變更 (從認可 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31 精選) (CVE-2025-71099)

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

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

  - svcrdma邊界檢查內嵌路徑 svc_rdma_copy_inline_range 中的 rq_pages 索引。在沒有驗證 rc_curpage 的情況下編制了索引的 rqstp->rq_pages[rc_curpage] 是否停留在配置的頁面陣列內。在第一次使用前和進入新頁面後新增防護。 (CVE-2025-71068)

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

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

  - net/mlx5: fw_tracer驗證格式字串參數在韌體追踪器中新增格式字串參數驗證以防止潛在的安全性弱點和因從韌體收到的格式錯誤的格式字串造成的損毀。韌體追踪器會接收來自裝置韌體的格式字串並使用這些字串來格式化追踪訊息。若未正確驗證錯誤的韌體會提供具有無效格式指定名稱的格式字串 (例如 %s、%p、%n)進而導致當機或其他未定義的行為。新增 mlx5_tracer_validate_params()以驗證追踪字串中的所有格式指定元是否限制為安全的整數/十六進位格式 (%x、%d、%i、%u、%llx、%lx 等等)。拒絕含有其他格式類型可用來存取任意記憶體或造成當機的字串。為以 BAD_FORMAT: 為前置詞的可見度新增了無效的格式字串至追踪輸出。 (CVE-2025-68816)

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

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

  - sched/deadline只針對線上 runqueues 提交 16b269436b72 設定 free_cpus (sched/deadline修改 cpudl::free_cpus 以反映 rd->online)引入了 cpu_set/clear_freecpu 函式以允許在期限之前操控 cpu_dl::free_cpus 遮罩排程器類別 rq_on/offline 回呼因此遮罩也會反映此狀態。認可 9659e1eeee28 (sched/deadline從 cpudl_find() 移除 cpu_active_mask) 已移除 cpu_active_mask 檢查以在 cpudl::free_cpus 遮罩已反映 runqueue 線上狀態的前提下節省部分處理程序。遺憾的是在期限內執行佇列離線時cpudl_clear 函式可在某些情況下設定 CPU 的 free_cpus 位元。如果在 CPU 連線至預設 root 網域時發生此情況則拔除 CPU 後旗標可能會保留錯誤狀態。稍後當 cpudl_find 發現其 free_cpus 位元已設定時透過預設 root 網域轉換的其他 CPU 可能會將期限工作推送至電源關閉的 CPU。如果發生此情況工作將沒有機會執行。此處列出一個範例
    https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com 最後一個期限工作是從具有離線執行佇列的 CPU 移轉時會發生另一個情形。最後期限排程器類別的 dequeue_task 成員最終會呼叫 cpudl_clear 並設定 CPU 的 free_cpus 位元。此認可會修改 cpudl_clear 函式使其感知期限運行佇列的線上狀態以便可適當更新 free_cpus 遮罩。由於不再需要管理 cpudl_set/clear 函式之外的遮罩因此已移除 cpudl_set/clear_freecpu 函式。此外由於 free_cpus 遮罩現在只會在 cpudl 鎖定下更新因此程式碼已變更為使用非原子
    __cpumask 函式。 (CVE-2025-68780)

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

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

  - fuse在 fuse-over-io-uring 引數複製中遺失 copy_finish。修正 fuse 引數複製期間可能發生的承載頁面參照計數洩漏。[Joanne簡化錯誤清理] (CVE-2025-68791)

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

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

  - f2fs修正以避免更新範圍快取中大小為零的範圍如 syzbot 報告F2FS-fs (loop0)
    __update_extent_tree_range範圍 len 為零、類型0、範圍 [0, 0, 0]、有效期 [0, 0] ------------[切至此處 ]-------- ---- fs/f2fs/extent_cache.c:678! 的核心錯誤Oops無效 opcode0000 [#1] SMP KASAN NOPTI CPU0 UID0 PID5336 Commsyz.0.0 未受污染的 syzkaller #0 PREEMPT(完整) 硬體名稱 QEMU Standard PC (Q35 + ICH9, 2009) 、 BIOS 1.16.3-debian-1.16.3-2~bpo12+1 2014 年 4 月 1 日 RIP
    0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678 呼叫追踪 <TASK> f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085 f2fs_do_zero_range fs/f2fs/file.c:1657+linef2fs_zero_range 0x10c1/0x1580 fs/f2fs/file.c:1737 f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030 vfs_fallocate+0x669/0x7e0 fs/open.c:342 ioctl_preallocate fs/ioctl.c:289 [內嵌] file_ioctl +0x611/0x780 fs/ioctl.c:-1 do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576 __do_sys_ioctl fs/ioctl.c:595 [內嵌] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/ x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f07bc58eec9 在 f2fs_zero_range() 的錯誤路徑中可能會新增將大小為零的範圍拖入範圍快取時應避免此情況。 (CVE-2025-68796)

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

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

  - ublk在 ublk 伺服器結束時清理使用者復本參照。如果 ublk 伺服器處理程序釋放 ublk 字元裝置檔案則任何已分派至 ublk 伺服器但尚未完成的要求都會保留 UBLK_REFCOUNT_INIT 的參照值。在認可 e63d2228ef83 之前 (ublk簡化中止 ublk 要求)__ublk_fail_req() 會在完成失敗的要求之前遞減參照計數。不過該認可已最佳化
    __ublk_fail_req() 直接呼叫 __ublk_complete_rq()而不遞減要求參照計數。
    洩漏的參照計數錯誤地允許使用者對完成的 ublk 要求進行複制和零複製作業。它也會在 ublk_queue_reinit() 和 ublk_deinit_queue() 中觸發 WARN_ON_ONCE(refcount_read(&io->ref)) 警告。認可 c5c5eb24ed61 (ublk避免在關閉 ublk char dev 後呼叫 ublk_io_release()) 已修正使用 UBLK_F_SUPPORT_ZERO_COPY 或 UBLK_F_AUTO_BUF_REG 的 ublk 裝置的問題。
    不過參照計數洩漏也會影響 UBLK_F_USER_COPY亦即其他參照計數資料複製模式。修正 ublk_check_and_reset_active_ref() 中的條件以包含所有參照計數資料複製模式。這可確保任何在 ublk 結束時仍由 ublk 伺服器擁有的 ublk 要求都會將其參照計數重設為 0。(CVE-2025-71070)

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

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

  - scsi還原 scsiqla2xxx在中止路徑中執行無鎖定命令完成這會還原提交 0367076b0817d5c75dfb83001ce7ce5c64d803a9。還原的認可已新增至 的程式碼
    __qla2x00_abort_all_cmds() 呼叫 sp->done() 而不保留執行緒同步鎖定。但與下面的舊程式碼不同的是此新程式碼無法檢查 sp->cmd_type 且只假設 TYPE_SRB導致在目標模式中使用 TYPE_TGT_CMD qla2xxx [0000:65:00.0]-d034跳轉至無效指標qla2xxx [0000:65:00.0]-d034: 8qla24xx_do_nack_work create sess success 0000000009f7a79b qla2xxx [0000:65:00.0]-5003:8: ISP 系統錯誤 - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h。 qla2xxx [0000:65:00.0]-d01e:8: -> fwdump 無緩衝區 qla2xxx [0000:65:00.0]-f03a:8: qla_target(0)系統錯誤 async 事件 0x8002 發生 qla2xxx [0000:65:00.0] -00af:8執行 ISP 錯誤復原 - ha=0000000058183fda。錯誤核心 NULL 指標解除參照位址0000000000000000 PF核心模式中的監督指令擷取 PF
    error_code(0x0010) - 不存在頁面 PGD 0 P4D 0 Oops0010 [#1] SMP CPU2 PID 9446 Commqla2xxx_8_dpc 受污染的 GO 6.1.133 #1 硬體名稱 Supermicro Super Server/X11SPL-F、BIOS 4.2 12 /15/2023 RIP0010:0x0 程式碼無法存取 0xffffffffffffffd6 的 opcode 位元組。RSP0018:ffffc90001f93dc8 EFLAGS00010206 RAX0000000000000282 RBX0000000000000355 RCXffff88810d16a000 RDXffff88810dbadaa8 RSI
    0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14:
     R15ffff888100136610  : ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3:
    000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 </TASK> 然後提交 4475afa2646d (scsiqla2xxx在鎖定內提早完成命令) 重新新增了執行緒同步鎖定因為沒有鎖定造成爭用和當機。但是下方交換器中的 qla2x00_abort_srb() 已經檢查 qla2x00_chip_is_down()並以相同方式處理因此交換器上方的程式碼現在在目標模式中是多餘的且仍然有錯誤。將其移除。 (CVE-2025-68818)

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

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

  - e1000修正 e1000_tbi_should_accept() 中的 OOB。在 e1000_tbi_should_accept() 中我們透過「data[length - 1]」讀取框架的最後一個位元組以評估 TBI 因應措施。如果描述符號報告的長度為零或大於實際的 RX 緩衝區大小則此讀取超出邊界可能會命中不相關的平台物件。
    在 NAPI 接收路徑中發現此問題 (e1000_clean_rx_irq)
    ================================================== ================ 錯誤KASANe1000_tbi_should_accept+0x610/0x790 讀取 addr ffff888014114e54 的大小 1 中 sshd/363 CPU: 0 PID
    363 Commsshd 未受污染的 5.18.0-rc1 #1 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)、BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 呼叫追踪 <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110_clean_rx_irq+0xa8c/0x1110_description_report+0x1012/0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110_x_irq+0xa8c/0x1110_description_report+0x1110.
    __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x10
    __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP
    0033:0x7f511b476b10 程式碼73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 00 5 75 10 b8 01 0 5 75 10 b8 01 0 5 <48> 30 0 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP002b00007ffc9211d4e8 EFLAGS00000246 ORIG_RAX0000000000000001 RAXxffffRBffffffda
    0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11:
     R120000000000000246  : 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init +0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 錯誤位址屬於 ffff 處物件 (屬於快取)1 kmlocloc-0001大小為 2048 的 2k錯誤位址位於 2048 位元組區域右側 1620 個位元組 [ffff888014114000, ffff888014114800] 錯誤位址屬於實體頁面page:ffffea0000504400 refcount:1 mapcount:0 mapping0000000000000000 索引0x0 pfn: 0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags
    0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected =============== ================================================== = 之所以會發生這種情況是因為 TBI 檢查無條件解除參照最後一個位元組而未先驗證報告的長度u8 last_byte = *(data +length - 1);若長度為零或超過adapter->rx_buffer_len則提早拒絕框架藉此修正。這可保留有效框架的 TBI 因應措施語意並防止接觸 RX 緩衝區之外的記憶體。 (CVE-2025-71093)

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

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

  - ALSAusb-mixerus16x08驗證計量表封包索引 get_meter_levels_from_urb() 會剖析裝置傳送的 64 位元組計量表封包並在結構 snd_us16x08_meter_store 中填入各通道陣列 meter_level[]、 comp_level[] 和 master_level[] 。目前該函式可直接從計量器封包 (MUB2(meter_urb, s) - 1) 衍生通道索引並使用它來為這些陣列編制索引而不需要驗證範圍。如果封包包含負值或超出範圍的通道編號驅動程式可能會在超出這些陣列的結尾處寫入。引入一個本機通道變數並在更新陣列前進行驗證。我們拒絕負索引將 meter_level[] 和 comp_level[] 限制為 SND_US16X08_MAX_CHANNELS並保護 master_level[] 具有 ARRAY_SIZE(master_level) 的更新。 (CVE-2025-68783)

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

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

  - net/hsr修正 prp_get_untagg_frame() prp_get_untagg_frame() 呼叫中的 NULL 指標解除參照
    __pskb_copy() 建立 frame->skb_std但不檢查配置是否失敗。如果 __pskb_copy() 傳回 NULL則會以 NULL 指標呼叫 skb_clone()並造成當機Oops一般保護錯誤可能針對非正式位址 0xdffffc000000000f0000 [#1] SMP KASAN NOPTI KASANnull-ptr-deref在範圍 [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 未受污染的 syzkaller #0 PREEMPT(完整) 硬體名稱：QEMU Standard PC (Q35 + ICH9, 2009)、BIOS 1.16.3- debian-1.16.3-2~bpo12+1 04/01/2014 RIP0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041 程式碼03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 1 0f b6 7d 00 83 e 0c RSP0018:ffffc9000d00f200 EFLAGS00010207 RAX
    ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000 RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee R10:
     R11dffffc0000000000  : fffffbfff1efa1ef R12: dffffc0000000000 R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00 FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0 Call Trace: <TASK> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave .c:84
    __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [內嵌] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c: 6278 [內嵌] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/ 0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [內嵌] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/ entry/syscall_64.c:63 [內嵌] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP0033:0x7f0449f8e1ff 碼89 54 24 18 48 89 74 24 10 9c 724 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 9 24 0c 84 02 00 48 RSP002b:00007ffd7ad94c90 EFLAGS00000293 ORIG_RAX00000000000000 01 RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff RDX
    000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8 RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001 R13:
    00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 </TASK> 在 之後立即新增 NULL 檢查
    __pskb_copy()妥善處理配置失敗。 (CVE-2025-68776)

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

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

  - caif修正 cffrml_receive() 中的整數反向溢位。cffrml_receive() 函式會從封包標頭擷取長度欄位並且在停用 FCS 時從此長度減去 2而不驗證該 len >= 2。如果攻擊者傳送惡意封包將長度欄位 0 或 1 傳送至已停用 FCS 的介面時減法運算會造成整數反向溢位。這可導致記憶體耗盡和核心不穩定如果 padding 包含未初始化的核心記憶體可能會造成資訊洩漏。透過在執行減法前驗證 len >= 2 來修正此問題。 (CVE-2025-68799)

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

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

  - ksmbd在 EA 長度中加入 null 結束字元大小修正緩衝區驗證。處理延伸屬性 (EA) 的 smb2_set_ea 函式執行的緩衝區驗證檢查不正確地省略了 EA 名稱的 null 結束字元 (+1 位元組) 大小。此修補程式透過明確新增「+ 1」至預期 null 結束字元存在於緩衝區的 EaNameLength 來修正此問題確保驗證正確地反映所需的總緩衝區大小。 (CVE-2025-68806)

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

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

  - ksmbd修正「並行」下的 ksmbd_tree_connect_put 中的釋放後使用在高並行度下樹狀結構連線物件 (tcon) 在斷線路徑上遭到釋放而另一個路徑仍保留參照且之後在其上執行 *_put()/write。 (CVE-2025-68817)

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

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

  - netstmmac修正零複製 XDP_TX 動作的損毀問題 執行零複製 XDP_TX 動作時有一個損毀問題其損毀記錄如下所示。 [ 216.122464] 無法處理虛擬位址 fffeffff80000000 的核心分頁要求 [ 216.187524] 內部錯誤Oops 0000000096000144 [#1] SMP [216.301694] 呼叫追踪 [ 216.304130] dcache_clean_poc+0x20/0x38 (P) [ 216.308308]
    __dma_sync_single_for_device+0x1bc/0x1e0 [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400 [ 216.317701]
    __stmmac_xdp_run_prog+0x164/0x368 [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00 [ 216.326576]
    __napi_poll+0x40/0x218 [ 216.408054] 核心錯誤 - 未同步Oops中斷中發生嚴重例外狀況針對 XDP_TX 動作xdp_convert_buff_to_frame() 會將 xdp_buff 轉換為 xdp_frame()。產生的 xdp_frame 的記憶體類型取決於 xdp_buff 的記憶體類型。針對頁面集區型 xdp_buff它會產生具有記憶體類型 MEM_TYPE_PAGE_POOL 的 xdp_frame。針對零複製 XSK 集區型 xdp_buff它會產生記憶體類型為 MEM_TYPE_PAGE_ORDER0 的 xdp_frame。不過stmmac_xdp_xmit_back() 不會檢查記憶體類型而一律使用頁面集區類型這會導致無效的對應並造成當機。因此請檢查 stmmac_xdp_xmit_back() 中的 xdp_buff 記憶體類型以修正此問題。 (CVE-2025-71095)

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

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

  - tpm設定 PCR 庫數量上限 tpm2_get_pcr_allocation() 並未設定任何庫數量上限。上限為 8 個庫因此來自外部 I/O 的超出邊界值只會造成有限的損害。 (CVE-2025-71077)

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

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

  - 藍牙btusb還原 btusb 中的 devm_kzalloc 使用。這會還原認可 98921dbd00c4e (藍牙使用 btusb.c 檔案中的 devm_kzalloc)。在 btusb_probe() 中我們使用 devm_kzalloc() 來配置 btusb 資料。此可將所有 btusb 資料的存留期與驅動程式系結至單一介面 INTF 系結在一起。在系結至其他介面 ISOC 和 DIAG 的驅動程式中這是等待發生的意外。此問題暴露在 btusb_disconnect() 中呼叫 usb_driver_release_interface(&btusb_driver, data->intf) 將使 devm 釋放也由可能尚未釋放的驅動程式的其他介面使用的資料。若要修正此問題請還原使用 devm 並返回明確地釋放記憶體。
    (CVE-2025-71082)

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

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

  - drm/ttm避免收回的 BO 發生 NULL 指標解除參照。目前可能存在一個未與資源相關聯的 BO例如因為已收回。當 devcoredump 嘗試讀取所有 BO 的內容以進行轉儲存時我們也必須預期會發生此情況 -- 在此情況下記錄的是 ENODATA 而非緩衝區內容。 (CVE-2025-71083)

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

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

  - net/schedets如果 drr 類別變更為 strict則將其移除將 drr 類別轉換為使用中的清單 ets 程式碼不會檢查該類別是否符合使用中的清單並將其移除。這表示若使用者將 strict 類別 (位於使用中清單中) 變更回 drr 類別該類別會新增兩次至使用中清單 [1]。
    若使用下列命令tc qdisc add dev lo root handle 1: ets Bands 2 strict 1 tc qdisc add dev lo parent 1:2 handle 20:\ tbf rate 8bit Burst 100b 延遲 1s tc filter add dev lo parent 1basic classid 1:2 ping -c1 -W0.01 -s 56 127.0.0.1 tc qdisc 變更裝置 lo root 處置程式 1etsband 2 strict 2 tc qdisc 變更裝置 lo root 處置程式 1etsband 2 strict 1 ping -c1 -W0.01 - s 56 127.0.0.1 在開啟清單除錯的情況下會觸發下列splat[ 59.279014][ T365] ------------[cut here ]----------- - [59.279452][ T365] list_add double add new=ffff88801d60e350、 prev=ffff88801d60e350、 next=ffff88801d60e2c0。
    [ 59.280153][ T365] 警告CPU3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220 [ 59.280860][ T365] 連結的模組[ 59.281165][ T365] CPU 3 UID: 0 PID: 365 Comm: tc 未受污染 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(vulnerable) [ 59.281977][ T365] 硬體名稱Bochs BochsBIOS Bochs 01/01/ 2011 [ 59.282391][ T365] RIP 0010:__list_add_valid_or_report+0x17f/0x220 [59.282842][ T365] 程式碼89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44 ... [ 59.288812] [ T365] 呼叫追踪[ 59.289056][ T365] <TASK> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80 [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0 [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10 [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240 [ 59.291228][T365] ? __pfx___mutex_trylock_common+0x10/0x10 [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110 [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293022][T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0 將 ets 類別變更為 strict 時一律檢查並從使用中清單移除 ets 類別以修正此問題。 [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663 (CVE-2025-68815)

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

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

  - block修正 wbt_enable_default 和 IO 提交之間的爭用。當 wbt_enable_default() 被移出 elevator_change() 的佇列凍結時可造成 wbt 傳送計數器變成負值 (-1)進而導致工作在回寫路徑中懸置。工作在 wbt_wait() 中停滯因為計數器的狀態不一致。發生此問題的原因是 wbt_enable_default() 可與 IO 提交發生爭用進而允許計數器在正確初始化之前遞減。這表示為 rq_wait[0]: inflight: -1 has_waiters: True rwb_enabled() 會檢查可在 wbt_wait() (rq_qos_throttle()) 和 wbt_track()(rq_qos_track()) 之間精確更新的狀態然後是 inflight計數器會變成負值。並且會產生類似懸置工作警告task:kworker/u24:39 state:D stack:0 pid:14767 呼叫追踪
    rq_qos_wait+0xb4/0x150 wbt_wait+0xa9/0x100 __rq_qos_throttle+0x24/0x40 blk_mq_submit_bio+0x672/0x7b0 ...
    修正此問題的方式為 1. 將 wbt_enable_default() 分割為 - __wbt_enable_default()如果應呼叫 wbt_init()則傳回 true - wbt_enable_default()現有呼叫者的包裝函式 (無 init) - wbt_init_enable_default()檢查 和 init 的新函式WBT 2. 在 blk_register_queue() 中使用 wbt_init_enable_default()確保佇列註冊時正確初始化 3. 將 wbt_init() 移出 wbt_enable_default()其僅用於從 bfq 和 iocost 啟用已停用的 wbt且不需要 wbt_init()。則可避免原來的鎖定警告。 4. 移除 ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT 旗標及其處理程式碼因為不再需要這可確保在提交任何 IO 前正確初始化 WBT防止計數器變成負值。 (CVE-2025-68807)

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

ID	名稱	嚴重性
283629	Linux Distros 未修補的弱點：CVE-2025-71073	high
283628	Linux Distros 未修補的弱點：CVE-2025-68793	medium
283627	Linux Distros 未修補的弱點：CVE-2025-68820	medium
283626	Linux Distros 未修補的弱點：CVE-2025-68797	medium
283625	Linux Distros 未修補的弱點：CVE-2025-71088	medium
283624	Linux Distros 未修補的弱點：CVE-2025-71089	high
283623	Linux Distros 未修補的弱點：CVE-2026-22772	medium
283622	Linux Distros 未修補的弱點：CVE-2025-71074	medium
283621	Linux Distros 未修補的弱點：CVE-2025-71087	medium
283620	Linux Distros 未修補的弱點：CVE-2025-71091	high
283619	Linux Distros 未修補的弱點：CVE-2025-71078	high
283618	Linux Distros 未修補的弱點：CVE-2025-71096	medium
283617	Linux Distros 未修補的弱點：CVE-2025-71071	high
283616	Linux Distros 未修補的弱點：CVE-2025-68786	high
283615	Linux Distros 未修補的弱點：CVE-2025-71098	medium
283614	Linux Distros 未修補的弱點：CVE-2025-68811	high
283613	Linux Distros 未修補的弱點：CVE-2025-68778	low
283612	Linux Distros 未修補的弱點：CVE-2025-68782	medium
283611	Linux Distros 未修補的弱點：CVE-2025-68792	high
283610	Linux Distros 未修補的弱點：CVE-2025-68803	medium
283609	Linux Distros 未修補的弱點：CVE-2025-68784	high
283608	Linux Distros 未修補的弱點：CVE-2025-68771	high
283607	Linux Distros 未修補的弱點：CVE-2025-68773	medium
283606	Linux Distros 未修補的弱點：CVE-2025-68795	high
283605	Linux Distros 未修補的弱點：CVE-2025-71100	high
283604	Linux Distros 未修補的弱點：CVE-2025-71076	medium
283603	Linux Distros 未修補的弱點：CVE-2025-68804	medium
283602	Linux Distros 未修補的弱點：CVE-2025-71075	high
283601	Linux Distros 未修補的弱點：CVE-2025-68805	high
283599	Linux Distros 未修補的弱點：CVE-2025-71064	medium
283598	Linux Distros 未修補的弱點：CVE-2025-71099	high
283597	Linux Distros 未修補的弱點：CVE-2025-71068	high
283596	Linux Distros 未修補的弱點：CVE-2025-68816	medium
283595	Linux Distros 未修補的弱點：CVE-2025-68780	high
283594	Linux Distros 未修補的弱點：CVE-2025-68791	high
283593	Linux Distros 未修補的弱點：CVE-2025-68796	medium
283592	Linux Distros 未修補的弱點：CVE-2025-71070	high
283591	Linux Distros 未修補的弱點：CVE-2025-68818	high
283590	Linux Distros 未修補的弱點：CVE-2025-71093	high
283589	Linux Distros 未修補的弱點：CVE-2025-68783	medium
283588	Linux Distros 未修補的弱點：CVE-2025-68776	medium
283587	Linux Distros 未修補的弱點：CVE-2025-68799	high
283586	Linux Distros 未修補的弱點：CVE-2025-68806	medium
283585	Linux Distros 未修補的弱點：CVE-2025-68817	high
283584	Linux Distros 未修補的弱點：CVE-2025-71095	medium
283583	Linux Distros 未修補的弱點：CVE-2025-71077	medium
283582	Linux Distros 未修補的弱點：CVE-2025-71082	high
283581	Linux Distros 未修補的弱點：CVE-2025-71083	medium
283580	Linux Distros 未修補的弱點：CVE-2025-68815	high
283579	Linux Distros 未修補的弱點：CVE-2025-68807	medium

偵測

Nessus 的 Misc. 系列

high

medium

medium

medium

medium

high

medium

medium

medium

high

high

medium

high

high

medium

high

low

medium

high

medium

high

high

medium

high

high

medium

medium

high

high

medium

high

high

medium

high

high

medium

high

high

high

medium

medium

high

medium

high

medium

medium

high

medium

high

medium