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

  - VMCI使用執行緒 irq而非 tasklet vmci_dispatch_dgs() tasklet 函式呼叫使用 wait_event() 的 vmci_read_data()導致不可部分完成內容中發生無效的睡眠 (因而可能造成鎖死)。使用執行緒 irq 來修正此問題並完全移除 tasklet 的使用。 [20.264639] 錯誤從 drivers/misc/vmw_vmci/vmci_guest.c:145 的無效內容呼叫休眠函式 [20.264643] in_atomic()1、irqs_disabled()0、non_block0、pid762、名稱vmtoolsd [ 20.264645] preempt_count 101、 預期 0 [ 20.264646] RCU 巢狀深度0、 預期 0 [ 20.264647] vmtoolsd/762 保留的 1 次鎖定 [ 20.264648] #0ffff0000874ae440 (sk_lock-AF_VSOCK) {+.+.}-{0:0}, at:
    vsock_connect+0x60/0x330 [vsock] [ 20.264658] 已在以下位置停用先佔 [ 20.264659] [<ffff80000151d7d8>] vmci_send_datagram+0x44/0xa0 [vmw_vmci] [ 20.264665] ] CPU0 PID762 Commtoolsd 未受污染的 5.19.0 -0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1 [ 20.264667] 硬體名稱VMware, Inc.
    VBSA/VBSA、BIOS VEFI 12/31/2020 [ 20.264668] 呼叫追踪 [ 20.264669] dump_backtrace+0xc4/0x130 [20.264672] show_stack+0x24/0x80 [ 20.264673] dump_stack_lvl+0x88/0xb4 [ 20.264676] dump_stack +0x18/0x34 [20.264677] __might_resched+0x1a0/0x280 [ 20.264679] __might_sleep+0x58/0x90 [ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci] [ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci] [ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150 [ 20.264688] tasklet_action+0x40/0x50 [ 20.264689]
    __do_softirq+0x23c/0x6b4 [ 20.264690] __irq_exit_rcu+0x104/0x214 [ 20.264691] irq_exit_rcu+0x1c/0x50 [20.264693] el1_interrupt+0x38/0x6c [ [] ] el1h_64_irq_handler+0x18/0x24 [ 20.264695[]0] 64_irq_handler+0x18/0x24 [  0] 68/4h8/qirq_handler+0x18/0x24 [ 20.2646960] 68/4h8/qirq_handler+0x18/0x24 [ 20.264697] preempt_count_sub+0xa4/0xe0 [ 20.264698]
    _raw_spin_unlock_irqrestore+0x64/0xb0 [ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci] [ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci] [ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci] [20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport] [ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport] [ 20.264713] vsock_connect+0x278/0x330 [vsock] [ 20.264715] __sys_connect_file+0x8c/0xc0 [ 20.264718] __sys_connect+0x84/0xb4 [ 20.264720]
    __arm64_sys_connect+0x2c/0x3c [ 20.264721] invoke_syscall+0x78/0x100 [ 20.264723] el0_svc_common.constprop.0+0x68/0x124 [ 20.264724] do_el0_svc+0x38/0x4c [ 20.264725] el0_svc+0x60/0x180 [20.264726] el0t_64_sync_handler +0x11c/0x150 [ 20.264728] el0t_64_sync+0x190/0x194 (CVE-2022-49759)

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

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

  - perf/core排序 PMU 清單以修正有關未排序 pmu_ctx_list 的警告 Syskaller 觸發了一個警告這是因為 perf_event_swap_task_ctx_data() 中的 prev_epc->pmu != next_epc->pmu 所致。 vmcore 顯示兩個清單具有相同的 perf_event_pmu_context但順序不同。問題是父項的 pmu_ctx_list 順序受到新增事件/PMU 的時間影響。子項的順序受到 pinned_groups 和 Flexible_groups 中事件順序的影響。因此父項與子項中的 pmu_ctx_list 順序可能不同。若要修正此問題請將 perf_event_pmu_context 插入 pmu_ctx_list 重複後的適當位置。下列測試案例會觸發上述警告# perf record -ecycles
    --call-graph lbr -- taskset -c 3 ./a.out & # perf stat -e cpu-clock,cs -p xxx // xxx 是 a.out test.c 的 pid void main() { int count = 0 ; pid_t pid; printf(執行中的 %d\n、getpid()) sleep(30)
    printf(running\n); pid = fork(); if (pid == -1) { printf(fork error\n);傳回} if (pid == 0) {while (1) { count++; } } else { while (1) { count++; } } } 測試案例會先開啟 LBR 事件因此會配置 task_ctx_data然後再開啟追踪點和軟體事件因此父項內容會有 3 個不同的 perf_event_pmu_contexts。繼承時子 ctx 會以其他順序插入 perf_event_pmu_context且會觸發警告。 [ Mingo已清理變更記錄。 ] (CVE-2025-21895)

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

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

  - 適用於所有平台的 NVIDIA CUDA Toolkit 在 cuobjdump 二進位檔中含有一個弱點其中檢查緩衝區長度失敗可允許使用者傳入格式錯誤的 ELF 檔案進而造成工具損毀或執行任意程式碼。成功惡意利用此弱點可導致任意程式碼執行。 (CVE-2025-23247)

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

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

  - 已解決 Linux 核心中的下列弱點：tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP:
    0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX:
    0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08:
    0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
    ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417]
    __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 (tracing: Check length before giving out the filter buffer) adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. (CVE-2021-47274)

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

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

  - 在 Linux 核心 5.8.2 之前版本中，net/nfc/rawsock.c 的 NFC 通訊端建立遺漏 CAP_NET_RAW 檢查，本機攻擊者可利用此問題建立原始通訊端、繞過安全性機制 (即 CID-26896f01467a)。(CVE-2020-26088)

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

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

  - Apache Tomcat 中存在逸出、中繼或控制序列不當中和的弱點。針對不太可能的重寫規則組態子集，特製的要求可能繞過某些重寫規則。如果這些重寫規則有效地強制執行安全限制，則可繞過這些限制。此問題會影響以下版本的 Apache Tomcat：11.0.0-M1 至 11.0.5 (含)、10.1.0-M1 至 10.1.39 (含)、9.0.0.M1 至 9.0.102 (含)。下列版本在建立 CVE 時已達 EOL但已知會受到影響 8.5.0 至 8.5.100。其他較舊的停產版本也可能受到影響。建議使用者升級至 [FIXED_VERSION] 版，即可修正此問題。(CVE-2025-31651)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件: Server: Optimizer)。受到影響的支援版本是 8.0.34 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2023-22064)

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

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

  - 已解決 Linux 核心中的下列弱點：net: ethernet: ti: am65-cpsw: Fix NULL dereference on XDP_TX If number of TX queues are set to 1 we get a NULL pointer dereference during XDP_TX.
    ~# ethtool -L eth0 tx 1 ~# ./xdp-trafficgen udp -A <ipv6-src> -a <ipv6-dst> eth0 -t 2 Transmitting on eth0 (ifindex 2) [ 241.135257] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 Fix this by using actual TX queues instead of max TX queues when picking the TX channel in am65_cpsw_ndo_xdp_xmit(). (CVE-2024-46799)

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

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

  - netethernetrtsn修正 rtsn_probe() 中的 null 指標解除參照。新增 rcar_gen4_ptp_alloc() 傳回值的檢查防止可能發生的 null 指標解除參照。 (CVE-2025-38452)

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

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

  - ecryptfs修正標籤 66 封包的緩衝區大小「TAG 66 封包格式」描述遺漏封裝到訊息封包中的加密程式碼和總和檢查碼欄位。因此配置給封包的緩衝區太小而 write_tag_66_packet() 會寫入最多 3 個位元組超過緩衝區結尾。透過增加配置的大小來修正此緩衝區讓整個封包永遠都適合。其可修正下列常見 slab 超出邊界錯誤： 錯誤： KASAN：task touch/181 CPU: 0 PID: 181 通訊錯誤於 addr ffff88800afbb2a5 寫入大小為 1 的 ecryptfs_generate_key_packet_set+0x7d6/0xde0 中的 slab-out-of-bounds 錯誤touch 未受污染的 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.2/GNU Guix 04/01/2014 呼叫追踪 <TASK> dump_stack_lvl+0x4c/0x70 print_report+xc5 /0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_complete_mode_report_info+0x44/0x210 ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ?
    __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [重疊 30837f11141636a8e1793533a02e6e2e885dad1d] dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ?
    __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ?
    __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ?
    __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP
    0033:0x7f00a703fd67 程式碼25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff 30 ff b8 0f 01 5 0 30 ff <48> b8 001 0 0 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAXffffffRBffffffda
    00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11:
    0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK> Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set +0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 (CVE-2024-38578)

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

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

  - usbacpi防止 usb_acpi_add_usb4_devlink() 中發生 null 指標解除參照如 update_port_device_state 修正提交 12783c0b9e2c (usb核心防止 update_port_device_state 中發生 null 指標解除參照)所示usb_hub_to_struct_hub() 可在特定情況下傳回 NULL例如在集線器期間驅動程式解除系結或卸除爭用情形即使存在基礎 usb_device 結構亦然。此外在相同檔案中呼叫 usb_hub_to_struct_hub() 的所有其他位置都會檢查 NULL 傳回值。如果 usb_hub_to_struct_hub() 傳回 NULL則後續存取 hub->ports[udev->portnum - 1] 時將會造成 null 指標解除參照。 (CVE-2025-38134)

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

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

  - 已解決 Linux 核心中的下列弱點：s390/bpf: Fix bpf_plt pointer arithmetic Kui-Feng Lee reported a crash on s390x triggered by the dummy_st_ops/dummy_init_ptr_arg test [1]: [<0000000000000002>] 0x2 [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 This is caused by GCC moving memcpy() after assignments in bpf_jit_plt(), resulting in NULL pointers being written instead of the return and the target addresses. Looking at the GCC internals, the reordering is allowed because the alias analysis thinks that the memcpy() destination and the assignments' left-hand-sides are based on different objects: new_plt and bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot alias.
    This is in turn due to a violation of the C standard: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ... From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects and cannot be subtracted. In the practical terms, doing so confuses the GCC's alias analysis. The code was written this way in order to let the C side know a few offsets defined in the assembly. While nice, this is by no means necessary. Fix the noncompliance by hardcoding these offsets. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/ (CVE-2024-35917)

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

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

  - atalibata-transport修正 ata_tport_add() 中的錯誤處理在 ata_tport_add() 中未檢查 transport_add_device() 的傳回值。因此在移除模組時會造成 null-ptr-deref因為系統呼叫了 transport_remove_device() 來移除未新增的裝置。無法處理虛擬位址 00000000000000d0 的核心 NULL 指標解除參照 CPU: 12 PID13605 Commmod Kdump
    已載入 污染GW 6.1.0-rc3+ #8 pstate 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+ 0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] 檢查並處理 ata_tport_add() 中 transport_add_device() 的傳回值藉此修正此問題。 (CVE-2022-49825)

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

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

  - 已解決 Linux 核心中的下列弱點：octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated vf->hw.lmt_info in order to avoid memory leak, same as the pf->hw.lmt_info in `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`. (CVE-2023-53069)

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

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

  - NVIDIA GPU 顯示驅動程式在核心模式層處理常式中含有一個弱點其中從使用者傳遞至驅動程式的值未正確驗證且用作陣列索引進而可能導致拒絕服務或可能提升權限。 (CVE-2017-6272)

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

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

  - net修正geneve_opt 長度整數溢位結構geneve_opt 針對每個單一選項使用 5 位元長度這表示每個變動大小選項都應小於 128 位元組。但是所有目前相關的 Netlink 原則都無法保證此長度條件攻擊者可惡意利用確切的 128 位元組大小選項在
    *fake* 零長度選項和混淆剖析邏輯進一步達到堆積超出邊界讀取。如下損毀記錄範例 [ 3.905425] ====================================== ============================ [ 3.905925] 錯誤KASANnla_put+0xa9/0xe0 中平台超出邊界 [ 3.906255] 工作 poc/177 在 addr ffff888005f291cc 讀取大小 124 [3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read 未受污染 6.1.132 #1 [ 3.907131] 硬體名稱
    QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [3.907784] 呼叫追踪[ 3.907925] <TASK> [ 3.908048] dump_stack_lvl +0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] ] fw_dump+0x18b/0x2d0[ 3.913483] tcf_w_dump+0x2d0 0x2ee/0x460 [3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814hwframe +0SYS_64_after /0xd8 [ 3.924122] RIP
    0033:0x7e83eab84407 [ 3.924331] 代碼48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 020 10 8 4 4 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [3.925330] RSP002b:00007ffff505e370 EFLAGS00000202 ORIG_RAX000000000000002c [ 3.925752] RAX
    ffffffffffffffda RBX 00007e83eaafa740 RCX 00007e83eab84407 [ 3.926173] RDX 00000000000001a8 RSI
    00007ffff505e3c0 RDI 0000000000000003 [ 3.926587] RBP 00007ffff505f460 R0800007e83eace1000 R09
    000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. (CVE-2025-22055)

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

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

  - jfs修正 diAlloc 中的 array-index-out-of-bounds 目前在配置新 inode 時不會檢查 iag 的 agno 以避免分割問題。新增必要的檢查。
    (CVE-2023-52805)

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

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

  - 已解決 Linux 核心中的下列弱點：f2fs: fix to drop meta_inode's page cache in f2fs_put_super() syzbot reports a kernel bug as below: F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1 kernel BUG at fs/f2fs/super.c:1639! CPU: 0 PID:
    15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0 RIP:
    0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639 Call Trace: generic_shutdown_super+0x161/0x3c0 fs/super.c:693 kill_block_super+0x3b/0x70 fs/super.c:1646 kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879 deactivate_locked_super+0x9a/0x170 fs/super.c:481 deactivate_super+0xde/0x100 fs/super.c:514 cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254 task_work_run+0x14d/0x240 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204
    __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd In f2fs_put_super(), it tries to do sanity check on dirty and IO reference count of f2fs, once there is any reference count leak, it will trigger panic. The root case is, during f2fs_put_super(), if there is any IO error in f2fs_wait_on_all_pages(), we missed to truncate meta_inode's page cache later, result in panic, fix this case. (CVE-2023-52848)

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

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

  - Oracle MySQL 的 MySQL Server 產品中的弱點 (元件：Server：FTS)。受到影響的支援版本是 8.0.26 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2021-35648)

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

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

  - wifiath12k啟用統計資料時避免記憶體洩漏 驅動程式將監控目的地環用於延伸統計資料模式和獨立監控模式。在延伸統計資料模式中系統會剖析從監控器目的地環接收的緩衝區中的 TLV並指派給 ppdu_info 結構以更新每個封包的統計資料。在獨立監控模式下系統會擷取封包資料 (有效負載) 和封包統計資料並將每個 MSDU 的驅動程式更新至 mac80211。啟用 AP 介面時只會啟動延伸統計資料模式。在啟用監控環以收集統計資料的過程中驅動程式會訂閱篩選器組態中的 HAL_RX_MPDU_START TLV。此 TLV 是從監控目的地環接收且會發生未釋放的 mon_mpdu 物件 kzalloc導致記憶體洩漏。只有在啟用獨立的監控介面時才需要 mon_mpdu 物件的 kzalloc。這會在驅動程式中啟用延伸統計資料模式時造成記憶體洩漏。透過移除 HAL_RX_MPDU_START TLV 處理中 mon_mpdu 物件的 kzalloc 來修正此記憶體洩漏。
    此外移除 HAL_MON_BUF_ADDR 和 HAL_RX_MSDU_END TLV 中的獨立監控模式處理。日後啟用獨立監控模式時將正確處理這些 TLV 標籤。經由測試 QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 經由測試 WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 (CVE-2025-37743)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件：Server：Encryption)。
    受到影響的支援版本是 8.0.31 和之前的版本。攻擊此弱點有一定難度，可以透過多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，攻擊者未經授權即可建立、刪除或修改重要資料或所有的 MySQL Server 可存取資料，並且可在未經授權的情況下造成 MySQL Server 懸置或經常重複性當機 (完全 DOS)。(CVE-2023-21875)

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

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

  - 在 Linux 核心 4.12 之前版本中，drivers/acpi/acpica/nsutils.c 的 acpi_ns_terminate() 函式未排清運算元快取並會造成核心堆疊轉儲存，這讓本機使用者可以透過特製的 ACPI 表格，從核心記憶體取得敏感資訊並繞過 KASLR 保護機制 (在 4.9 及更早版本的核心中)。(CVE-2017-11472)

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

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

  - 依循該值的原型鏈時，可能保留地區設定參照、將之刪除後再予以參照。這會導致釋放後使用及可能遭惡意利用的損毀。此弱點會影響 Firefox < 70、Thunderbird < 68.2 和 Firefox ESR < 68.2。(CVE-2019-11757)

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

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

  - tcp更正 skb 剩餘空間計算中的正負號 Syzkaller 報告了一個錯誤 [1]其中 sk->sk_forward_alloc 可能溢位。當我們傳送資料時如果 skb 存在於寫入佇列的結尾則核心會嘗試將新資料附加至該 skb。但是在 skb 中檢查可用空間的程式碼有瑕疵''' copy = size_goal - skb->len ''' 所涉及的變數類型有''' copy: ssize_t (64 位元系統上的 s64 ) size_goalint skb->lenunsigned int ''' 由於 C 的類型提升規則有符號 size_goal 會在減法前轉換為無符號 int 以符合 skb->len。結果為未簽署的 int。然後將此無正負號的 int 結果指派給 s64 複製變數時系統會對其進行零延伸並保留其非負值。因此copy 一律 >= 0。假設我們要傳送 2GB 的資料且 size_goal 已調整為小於 skb->len 的值。減法將導致副本保留非常大的正整數。在後續的邏輯中這個大值會用來更新 sk->sk_forward_alloc而這很容易造成其溢位。syzkaller 複製器使用 TCP_REPAIR 以可靠的方式建立此情形。但是，在實際情況中也會發生這種情況。tcp_bound_to_half_wnd() 函式也可以將 size_goal 減小到較小的值。這會造成後續的 tcp_wmem_schedule() 將 sk->sk_forward_alloc 設定為接近 INT_MAX 的值。後續的記憶體配置要求會造成 sk_forward_alloc 換行並變成負值。 [1]
    https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47 (CVE-2025-38463)

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

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

  - wificarl9170不 ping 無法載入韌體的裝置 Syzkaller 報告 [1、2] 當機這是因為嘗試 ping 無法載入韌體的裝置所致。由於此類裝置不會傳遞「ieee80211_register_hw()」因此尚未建立由「ieee80211_queue_work()」管理的內部工作佇列若嘗試將其上的工作排入佇列會造成 null-ptr-deref。 [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 (CVE-2025-38420)

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

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

  - 已解決 Linux 核心中的下列弱點：block: fix memory leak in disk_register_independent_access_ranges kobject_init_and_add() takes reference even when it fails.
    According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by adding kobject_put().
    Callback function blk_ia_ranges_sysfs_release() in kobject_put() can handle the pointer iars properly.
    (CVE-2022-48753)

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

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

  - 已解決 Linux 核心中的下列弱點：cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path Dan Carpenter reported a Smack static checker warning:
    fs/smb/client/cifsfs.c:1981 init_cifs() error: we previously assumed 'serverclose_wq' could be null (see line 1895) The patch which introduced the serverclose workqueue used the wrong oredering in error paths in init_cifs() for freeing it on errors. (CVE-2024-42307)

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

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

  - XSLT 文件載入並未正確傳播繞過其 CSP 的來源文件。此弱點會影響 Firefox < 141、Firefox ESR < 128.13、Firefox ESR < 140.1、Thunderbird < 141、Thunderbird < 128.13，以及 Thunderbird < 140.1。(CVE-2025-8032)

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

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

  - 已解決 Linux 核心中的下列弱點：btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path Since the input data length passed to zlib_compress_folios() can be arbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may cause read-in bytes to exceed the input range. Currently this triggers an assert in btrfs_compress_folios() on the debug kernel (see below).
    Fix strm.avail_in calculation for S390 hardware acceleration path. assertion failed: *total_in <= orig_len, in fs/btrfs/compression.c:1041 ------------[ cut here ]------------ kernel BUG at fs/btrfs/compression.c:1041! monitor event: 0040 ilc:2 [#1] PREEMPT SMP CPU: 16 UID: 0 PID: 325 Comm:
    kworker/u273:3 Not tainted 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1 Hardware name:
    IBM 3931 A01 703 (z/VM 7.4.0) Workqueue: btrfs-delalloc btrfs_work_helper Krnl PSW : 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 0000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58 Krnl Code:
    0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8 #0000021761df6534: af000000 mc 0,0 >0000021761df6538: 0707 bcr 0,%r7 0000021761df653a: 0707 bcr 0,%r7 0000021761df653c: 0707 bcr 0,%r7 0000021761df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Call Trace: [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0 ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0) [<0000021761d97788>] compress_file_range+0x3b8/0x6d0 [<0000021761dcee7c>] btrfs_work_helper+0x10c/0x160 [<0000021761645760>] process_one_work+0x2b0/0x5d0 [<000002176164637e>] worker_thread+0x20e/0x3e0 [<000002176165221a>] kthread+0x15a/0x170 [<00000217615b859c>] __ret_from_fork+0x3c/0x60 [<00000217626e72d2>] ret_from_fork+0xa/0x38 INFO: lockdep is turned off. Last Breaking-Event-Address:
    [<0000021761597924>] _printk+0x4c/0x58 Kernel panic - not syncing: Fatal exception: panic_on_oops (CVE-2024-57923)

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

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

  - net由 sock_lock_init_class_and_name() 和 rmmod 修正 null-ptr-deref。當我執行 repro [0] 並等待幾秒种時發現兩個 LOCKDEP 展開警告緊接著是 null-ptr-deref。 [1] 複製步驟1) 掛載 CIFS 2) 新增 iptables 規則以放置 CIFS 的傳入 FIN 封包 3) 卸載 CIFS 4) 卸載 CIFS 模組 5) 移除 iptables 規則在步驟 3)CIFS 模組呼叫 sock_release( ) 適用於基礎 TCP 通訊端。不過因為傳入的 FIN 封包遭到捨棄因此通訊端仍保留在 FIN_WAIT_1 中。此時模組的 refcnt 為 0 而通訊端仍處於作用中因此下列 rmmod 命令會成功執行。 # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 這會醒目提示 CIFS 模組和基礎 TCP 通訊端的存留期之間的差異。即使在 CIFS 呼叫 sock_release() 且其傳回之後TCP 通訊端也不會立即終止以正常關閉連線。雖然這通常沒有問題但是它會造成 LOCKDEP 問題因為 CIFS 使用 sock_lock_init_class_and_name() 將不同的鎖定類別指派給 TCP 通訊端的 sk->sk_lock。一旦針對通訊端處理了傳入封包或觸發計時器就會取得 sk->sk_lock。然後LOCKDEP 會檢查 check_wait_context() 中的鎖定內容其中會呼叫 hlock_class() 以擷取鎖定類別。不過由於模組已卸載因此 hlock_class() 會記錄警告並傳回 NULL進而觸發 null-ptr-deref。如果啟用了 LOCKDEP我們必須確保呼叫 sock_lock_init_class_and_name() (CIFS、NFS 等) 的模組在此類通訊端仍處於作用中時無法卸載以防止此問題。我們保留 sock_lock_init_class_and_name() 中的模組參照並在 sk_prot_free() 中釋放通訊端時將其釋放。請注意sock_lock_init() 會清除 svc_create_socket() 的 sk->sk_owner該函式會呼叫接聽通訊端的 sock_lock_init_class_and_name()進而在無 GFP_ZERO 的情況下透過 sk_clone_lock() 複製通訊端。 [0]
    CIFS_SERVER=10.0.0.137 CIFS_PATH=//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST DEV=enp0s3 CRED=/root/WindowsCredential.txt MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers =3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10)do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) 警告 CPU: 10 PID: 0 at kernel/ locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) 模組連結cifs_arc4 nls_ucs2_utils cifs_md4 [上次卸載cifs] CPU10 UID0 PID0 Commswapper/10 未受污染 6.14.0 #36 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP 0010:hlock_class ( kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... 呼叫追踪 <IRQ>
    __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816 )
    _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... 錯誤核心 NULL 指標解除參照位址
    00000000000000c4 PF核心模式中的監督讀取存取 PFerror_code(0x0000) - 不存在頁面 PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 污染GW 6.14.0 #36 受污染[W]=WARN 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP0010:__lock_acquire (kernel/ ---truncated--- (CVE-2025-23143)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/v3d: Validate passed in drm syncobj handles in the performance extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213) (CVE-2024-42260)

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

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

  - Oracle MySQL 的 MySQL Server 產品中存有弱點 (元件：Server：Parser)。受到影響的支援版本是 5.7.29 與更早版本，以及 8.0.19 與更早版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若攻擊成功，攻擊者可以接管 MySQL 伺服器。(CVE-2021-2144)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件: Server: Optimizer)。受到影響的支援版本是 8.0.25 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2021-2383)

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

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

  - mm/shmem、swap以 mTHP swapin 修正 softlockup 以下 softlockup 可以在我的測試機器上輕鬆重現 echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 是48G 交換裝置 mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true do dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done 一段時間後watchdog錯誤軟鎖定 - CPU#0 因 763s 而停滯[cat5787] 模組連結於 zram virtiofs CPU0 UID0 PID5787 Comm
    cat Kdump已載入 受污染的 GL 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(自發) 受污染的
    [L]=SOFTLOCKUP 硬體名稱Red Hat KVM/RHEL-AV、BIOS 0.0.0 02/06/2015 RIP
    0010:mpol_shared_policy_lookup+0xd/0x70 程式碼e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 000 1f 545 0 0 4 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP0018:ffffc90002b1fc28 EFLAGS00000202 RAX00000000001c20ca RBX
    0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11:
     R120000000000000000  : 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR40000000000770eb0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 0 0f 1f 44 00 0 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI:
    0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15:
    0000000000000000 </TASK> 原因很簡單即 readahead 在交換快取中造成某個 order 0 作品集而且要配置的 swapin mTHP 作品集與之相衝突因此 swapcache_prepare 失敗並造成 shmem_swap_alloc_folio 傳回 -EEXIST而 shmem 只是一次又一次地重試造成此迴圈。透過針對 anon mTHP swapin 套用類似的修正來修正此問題。使用 shmem 的 swapin 10g 零作品集時間 (測試 12 次)效能變更非常輕微。之前2.47s 之後2.48s [kasong@tencent.com新增註解] (CVE-2025-38241)

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

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

  - 未正確限制使用者提供的特定 blit 值，導致某些視訊驅動程式上發生堆積緩衝區溢位。此弱點會影響 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-26971)

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

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

  - powerpc/64在 parse_early_param() 前初始化跳躍標籤 在 64 位元中呼叫 setup_feature_keys() 中的 jump_label_init() 為時過晚因為靜態金鑰可能用於 parse_early_param() 的子常式中而這又是 early_init_devtree() 的子常式。例如使用 threadirqs 開機
    static_key_enable_cpuslocked()呼叫 jump_label_init() 之前使用了靜態金鑰 '0xc000000002953260' 警告 CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 呼叫追踪
    static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 So call early_init_devtree() 中 parse_early_param() 之前的 jump_label_init()。
    [mpe將呼叫追踪新增至變更記錄和次要文字編輯。] (CVE-2022-50012)

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

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

  - 操控選取節點快取時攻擊者可能造成未預期的行為進而可能導致可遭惡意利用的損毀。此弱點影響 Firefox < 131.0.3。(CVE-2024-9936)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件: Server: Optimizer)。受到影響的支援版本是 8.0.30 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2022-39400)

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

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

  - 在某些組態中，4.14 及之前版本的 Squid 以及 5.x 至 5.0.5 版本的 Squid 都允許資訊洩漏，這是由於 WCCP 通訊協定資料中存在超出邊界讀取問題所致。使用者可以在不暴露身分的情況下以遠端程式碼執行鏈的一部分利用此缺陷。(CVE-2021-28116)

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

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

  - mod_auth_openidc 是 Apache 2.x HTTP 伺服器的驗證/授權模組，做為 OpenID Connect 依賴方提供服務，為 OpenID Connect 提供者驗證使用者的身分。在 mod_auth_openidc 2.4.9 之前版本中使用「OIDCPreservePost On」時，出現一個 XSS 弱點。
    (CVE-2021-32792)

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

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

  在 4.15 版之前和 5.0.6 之前 5.x 版的 Squid 中，發現一個問題。由於輸入驗證錯誤，此弱點容易遭受拒絕服務攻擊 (針對使用 Proxy 的所有用戶端)。用戶端會傳送 HTTP 範圍請求以觸發此要求。(CVE-2021-31808)

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

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

  - Rack::Session 是適用於 Rack 的工作階段管理實作。在從 2.0.0 開始到 2.1.1之前的版本中當使用 Rack::Session::Pool 中介軟體時若攻擊者可取得工作階段 cookie (這已是一個重大問題)若攻擊者可觸發與使用者登出相鄰的長時間執行要求 (在相同工作階段內)以便即使在使用者嘗試登出後仍保留非法存取。此問題已在 2.1.1 版中修正。(CVE-2025-46336)

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

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

  - Loofah 是建立在 Nokogiri 之上，用於操控及轉換 HTML/XML 文件和片段的一般程式庫。Loofah 2.19.1 之前版本包含效率低下的規則運算式，在嘗試清理特定的 SVG 屬性時，容易發生過度回溯。這可能會透過 CPU 資源消耗而導致拒絕服務。此問題已在 2.19.1 版中修補。(CVE-2022-23514)

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

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

  - Jackson-core 包含 Jackson Data Processor 使用的核心低階累加 (資料流) 剖析器與產生器提取。從 2.0.0 版開始及 2.13.0版之前的版本中 jackson-core 的「JsonLocation._appendSourceDesc」方法中有一個瑕疵會允許最多 500 個位元組的非預定記憶體內容包含在例外狀況訊息中。從具有位移和長度的位元組陣列剖析 JSON 時例外狀況訊息會不正確地從陣列開頭 (而非邏輯承載開頭) 讀取。這會導致在使用共用或重複使用緩衝區的系統 (如 Netty 或 Vert.x) 中可能發生資訊洩漏。此問題已透過 PR #652在 2021 年 9 月 30 日發布的 jackson-core 版本 2.13.0中以無訊息模式修正。所有使用者皆應升級至 2.13.0 版或更新版本。若無法立即升級應用程式可透過停用例外狀況給用戶端的訊息來避免在 HTTP 回應中傳回剖析例外狀況訊息和/或停用例外狀況中的來源包含以防止 Jackson 在例外狀況訊息中內嵌任何來源內容進而避免洩漏藉此減輕問題的影響。 。 (CVE-2025-49128)

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

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

  - 由於 CVE-2020-1945 的緩解措施Apache Ant 1.10.8 已變更其建立的暫存檔權限現在僅允許目前使用者存取。遺憾的是 fixcrlf 工作會刪除暫存檔並建立沒有上述保護的新檔案因此實際上使工作無效。這仍會允許攻擊者將修改過的來源檔案插入構建處理程序中。 (CVE-2020-11979)

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

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

  - 適用於 32 位元系統的 libuv 和 Node.js 特定構建處理程序例如到 nodejs_20.19.0+ 的 nodejs 二進位套件dfsg-2_i386.deb for Debian GNU/Linux具有不一致的 off_t 大小 (例如在 i386 Debian 上構建libuv 動態程式庫一律使用 _FILE_OFFSET_BITS=64但使用
    _FILE_OFFSET_BITS 全域系統對於 nodejs 的預設值 32)導致超出邊界存取。注意這不是 Node.js 軟體本身的問題。特別是Node.js 網站的下載頁面在 i386 上並未提供適用於 Linux 的預構建 Node.js。 (CVE-2025-47153)

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

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

  - 因為在 index.js 的 re_attr 變數中使用不安全的規則運算式，低於 2.1.3 版的套件 css-what 容易受到規則運算式拒絕服務 (ReDoS) 影響。可透過剖析函式觸發惡意利用此弱點。(CVE-2022-21222)

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

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

  - Net::IMAP 在 Ruby 中實作網際網路訊息存取通訊協定 (IMAP) 用戶端功能。在 0.5.7、 0.4.20、 0.3.9和 0.2.5版之前net-imap 讀取伺服器回應時有可能因記憶體耗盡而發生拒絕服務。用戶端連線時惡意伺服器可隨時傳送可傳送常值位元組計數由用戶端的接收執行緒自動讀取。回應讀取器會立即針對伺服器回應所指示的位元組數配置記憶體。安全地連線至受信任且運作良好的 IMAP 伺服器時這應該不是問題。其可影響不安全的連線以及錯誤、不受信任或遭入侵的伺服器 (例如連線至使用者提供的主機名稱)。此問題已在 0.5.7、 0.4.20、 0.3.9和 0.2.5版中修補。 (CVE-2025-43857)

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

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

  - Loofah 是建立在 Nokogiri 之上，用於操控及轉換 HTML/XML 文件和片段的一般程式庫。Loofah 2.1.0 及更高版本和 2.19.1 之前版本容易因資料 URI 中的 image/svg+xml 媒體類型而受到跨網站指令碼攻擊。此問題已在 2.19.1 版中修補。(CVE-2022-23515)

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

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

  - Oracle MySQL 的 MySQL Server 產品中的弱點 (元件ServerPAM Auth Plugin)。受到影響的支援版本是 5.7.32 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2021-2014)

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

ID	名稱	嚴重性
253008	Linux Distros 未修補的弱點：CVE-2022-49759	medium
253007	Linux Distros 未修補的弱點：CVE-2025-21895	medium
253006	Linux Distros 未修補的弱點：CVE-2025-23247	medium
253005	Linux Distros 未修補的弱點：CVE-2021-47274	critical
253004	Linux Distros 未修補的弱點：CVE-2020-26088	medium
253003	Linux Distros 未修補的弱點：CVE-2025-31651	critical
253002	Linux Distros 未修補的弱點：CVE-2023-22064	medium
253001	Linux Distros 未修補的弱點：CVE-2024-46799	medium
253000	Linux Distros 未修補的弱點：CVE-2025-38452	medium
252999	Linux Distros 未修補的弱點：CVE-2024-38578	medium
252998	Linux Distros 未修補的弱點：CVE-2025-38134	medium
252997	Linux Distros 未修補的弱點：CVE-2024-35917	medium
252996	Linux Distros 未修補的弱點：CVE-2022-49825	medium
252995	Linux Distros 未修補的弱點：CVE-2023-53069	medium
252994	Linux Distros 未修補的弱點：CVE-2017-6272	high
252993	Linux Distros 未修補的弱點：CVE-2025-22055	high
252992	Linux Distros 未修補的弱點：CVE-2023-52805	high
252991	Linux Distros 未修補的弱點：CVE-2023-52848	medium
252990	Linux Distros 未修補的弱點：CVE-2021-35648	medium
252989	Linux Distros 未修補的弱點：CVE-2025-37743	medium
252988	Linux Distros 未修補的弱點：CVE-2023-21875	medium
252987	Linux Distros 未修補的弱點：CVE-2017-11472	high
252986	Linux Distros 未修補的弱點：CVE-2019-11757	high
252985	Linux Distros 未修補的弱點：CVE-2025-38463	high
252983	Linux Distros 未修補的弱點：CVE-2025-38420	medium
252982	Linux Distros 未修補的弱點：CVE-2022-48753	medium
252981	Linux Distros 未修補的弱點：CVE-2024-42307	medium
252980	Linux Distros 未修補的弱點：CVE-2025-8032	high
252979	Linux Distros 未修補的弱點：CVE-2024-57923	medium
252978	Linux Distros 未修補的弱點：CVE-2025-23143	medium
252977	Linux Distros 未修補的弱點：CVE-2024-42260	medium
252976	Linux Distros 未修補的弱點：CVE-2021-2144	high
252975	Linux Distros 未修補的弱點：CVE-2021-2383	medium
252974	Linux Distros 未修補的弱點：CVE-2025-38241	medium
252973	Linux Distros 未修補的弱點：CVE-2020-26971	high
252972	Linux Distros 未修補的弱點：CVE-2022-50012	high
252971	Linux Distros 未修補的弱點：CVE-2024-9936	medium
252970	Linux Distros 未修補的弱點：CVE-2022-39400	medium
252913	Linux Distros 未修補的弱點：CVE-2021-28116	medium
252912	Linux Distros 未修補的弱點：CVE-2021-32792	medium
252911	Linux Distros 未修補的弱點：CVE-2021-31808	medium
252910	Linux Distros 未修補的弱點：CVE-2025-46336	medium
252909	Linux Distros 未修補的弱點：CVE-2022-23514	high
252908	Linux Distros 未修補的弱點：CVE-2025-49128	medium
252907	Linux Distros 未修補的弱點：CVE-2020-11979	high
252906	Linux Distros 未修補的弱點：CVE-2025-47153	medium
252905	Linux Distros 未修補的弱點：CVE-2022-21222	high
252904	Linux Distros 未修補的弱點：CVE-2025-43857	high
252903	Linux Distros 未修補的弱點：CVE-2022-23515	medium
252902	Linux Distros 未修補的弱點：CVE-2021-2014	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

critical

medium

critical

medium

medium

medium

medium

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

high

medium

medium