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

  - nfc修正 nfc_genl_dump_ses_done 中潛在的 NULL 指標解除參照。dumpit() 中的配置提早失敗 (nfc_genl_dump_ses_done())done() netlink 回呼 nfc_genl_dump_ses_done() 應檢查其是否為非 NULL。 (CVE-2021-47518)

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

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

  - powerpc/imc-pmu修正 IRQ 已停用區段中 mutex 的使用。目前的 imc-pmu 程式碼在執行 thread_imc 事件時會在啟用 CONFIG_DEBUG_ATOMIC_SLEEP 和 CONFIG_PROVE_LOCKING 的情況下觸發警告。觸發警告的命令# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5「sleep 5」效能計數器統計資料0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 秒數時間耗用 0.000131000 秒數使用者 0.001063000 秒數 sys 以下是警告摘要在 dmesg錯誤中從 kernel/locking/mutex.c:580 的無效內容呼叫休眠函式 in_atomic()1、irqs_disabled()1、non_block
    0、pid2869、名稱perf-exec preempt_count 2、預期 0 perf-exec/2869 保留的 4 個鎖定 #0
    c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}、@bprm_execve+0x64/0xa90 #1c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}、位於begin_new_exec+0x460/0xef0 #2c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}、at: perf_event_exec+0x290/0x510 #3c000000017ab8418 (&ctx->lock){....}-2:2{ ] }, at: perf_event_exec+0x29c/0x510 irq 事件戳記4806 hardirqs 上次於 (4805) 啟用
    [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs 上次停用是在 (4806)
    [<c0000000003fae44>] perf_event_exec+0x394/0x510 softirqs 上次於 (0) 啟用 [<c00000000013c404>] copy_process+0xc34/0x1ff0 softirqs 上次停用於 (0) [<0000000000000000>] 0x0 CPU36 PID 2869 Comm
    perf-exec 未受污染的 6.2.0-rc2-00011-g1247637727f2 #61 硬體名稱8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV 呼叫追踪dump_stack_lvl+0x98/0xe0 (不可靠)
    __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+ 0x104/0x1c0 perf_event_exec+0x340/0x510begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... !TASK_RUNNING 時不呼叫封鎖 ops在 [<00000000fd63e7cf>] 設定的 state=2001 do_nanosleep+0x60/0x1a0 警告
    CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep 受污染的 GW 6.2.0-rc2-00011-g1247637727f2 #61 硬體名稱8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIPc000000000194a1c LRc000000000194a18 CTRc000000000a78670 REGS
    c00000004d2134e0 TRAP0700 受污染GW (6.2.0-rc2-00011-g1247637727f2) MSR9000000000021033<SF,HV,ME,IR,DR,RI,LE> CR48002824 XER00000000 CFARc00000000013fb64 IRQMASK1 以上警告已觸發因為目前的 imc-pmu 程式碼在中斷停用區段中使用 mutex 鎖定。mutex_lock() 函式會在內部呼叫 __might_resched()其會檢查 IRQ 是否已停用如果 IRQ 已停用則會觸發警告。將 mutex 鎖定變更為 spinlock以修正此問題。 [mpe修正註解、修剪變更記錄中的 oops、新增報告者標籤] (CVE-2023-53031)

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

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

  - x86/kvm關機時停用所有 CPU 上的 kvmclock我們目前停用了 machine_shutdown() 勾點的 kvmclock且只有開機 CPU 會發生此情況。我們需要針對所有 CPU 將其停用以防止記憶體損毀例如從休眠還原時。請注意將 '0' 寫入 kvmclock MSR 並不會清除記憶體位置它只會防止 Hypervisor 更新位置因此在寫入後短時間內以及 CPU 仍在使用中時時鐘會維持可用且正確因此我們不需要切換至其他某個時鐘來源。 (CVE-2021-47110)

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

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

  - 攻擊者可造成選取下拉式清單顯示在另一個索引標籤上。這可導致使用者混淆及可能的偽造攻擊。此弱點會影響 Firefox < 133、Firefox ESR < 128.5、Thunderbird < 133 和 Thunderbird < 128.5。 (CVE-2024-11692)

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

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

  - [歷程記錄] 窗格中的 [忘記此網站] 功能用於移除所有表示使用者造訪過網站的已儲存使用者資料。這包括移除從使用 HTTP Strict Transport Security (HSTS) 設定的網站收到的任何設定。由於存在一個錯誤預先載入清單上的網站也會將其 HSTS 設定移除。下次造訪該網站時如果使用者指定 http: URL而非安全 https:其將不會受到預先載入的 HSTS 設定保護。之後造訪網站的 HSTS 設定將會還原。此弱點會影響 Firefox < 69 和 Firefox ESR < 68.1。 (CVE-2019-11747)

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

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

  - 在 Ubuntu 18.04.2 上的 Linux 核心 4.15.0 中drivers/gpu/drm/i915/i915_gem_userptr.c 的 i915_gem_userptr_get_pages 允許本機使用者造成拒絕服務 (NULL 指標解除參照和錯誤) 或可能透過特製的 ioctl 呼叫產生其他不明影響複製到 /dev/dri/card0。 (CVE-2019-12881)

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

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

  - 已解決 Linux 核心中的下列弱點：io_uring: fix multishot accept request leaks Having REQ_F_POLLED set doesn't guarantee that the request is executed as a multishot from the polling path. Fortunately for us, if the code thinks it's multishot issue when it's not, it can only ask to skip completion so leaking the request. Use issue_flags to mark multipoll issues. (CVE-2022-49791)

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

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

  - 已解決 Linux 核心中的下列弱點：binder: fix node UAF in binder_add_freeze_work() In binder_add_freeze_work() we iterate over the proc->nodes with the proc->inner_lock held. However, this lock is temporarily dropped in order to acquire the node->lock first (lock nesting order). This can race with binder_node_release() and trigger a use-after-free:
    ================================================================== BUG: KASAN: slab-use-after-free in
    _raw_spin_lock+0xe4/0x19c Write of size 4 at addr ffff53c04c29dd04 by task freeze/640 CPU: 5 UID: 0 PID:
    640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17 Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x19c binder_add_freeze_work+0x148/0x478 binder_ioctl+0x1e70/0x25ac
    __arm64_sys_ioctl+0x124/0x190 Allocated by task 637: __kmalloc_cache_noprof+0x12c/0x27c binder_new_node+0x50/0x700 binder_transaction+0x35ac/0x6f74 binder_thread_write+0xfb8/0x42a0 binder_ioctl+0x18f0/0x25ac __arm64_sys_ioctl+0x124/0x190 Freed by task 637: kfree+0xf0/0x330 binder_thread_read+0x1e88/0x3a68 binder_ioctl+0x16d8/0x25ac __arm64_sys_ioctl+0x124/0x190 ================================================================== Fix the race by taking a temporary reference on the node before releasing the proc->inner lock. This ensures the node remains alive while in use. (CVE-2024-56556)

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

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

  - scsilpfc使用 BIOS 版本的 memcpy()。具有 FORTIFY 支援的 strlcat() 觸發了不穩定的情況這是因為它認為儘管傳入了正確的目標緩衝區大小但目標緩衝區還是會溢位。無論如何不要使用 memset() (0 後跟 strlcat()) 直接使用 memcpy() 並確認產生的緩衝區是以 NULL 終止。BIOSVersion 僅用於預期得到正確終止字串的 lpfc_printf_log()。 (CVE-2025-38332)

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

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

  - 在 Linux 核心的 ccp_run_aes_gcm_cmd() 函式中發現記憶體洩漏弱點，攻擊者可藉此造成拒絕服務。此弱點與早先的 CVE-2019-18808 類似。此弱點對系統可用性威脅最大。(CVE-2021-3764)

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

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

  - mediastk1160修正 stk1160_copy_video() 中的邊界檢查。此情況中的減法發生反轉。
    ->length 是緩衝區的長度。->bytesused 是到目前為止我們已復制的位元組數量。當條件相反時這表示減法的結果一律為負但是由於它是無正負號的因此結果是非常高的正值。這表示溢位檢查永遠不會為 true。
    此外->bytesused 無法用於此目的因為我們並未寫入至 buf->mem + buf->bytesused。反而有點牽涉到寫入目的地的數學運算。您可以計算已寫入的完整行數乘以 2並視需要略過一行從奇數行開始然後將位移新增到行中。若要修正此緩衝區溢位只要取得我們寫入的實際目的地即可若位移已超出邊界列印錯誤並傳回。否則最多寫入 buf->length 位元組。 (CVE-2024-38621)

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

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

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

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

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

  - 在 Linux 核心 3.16 至 5.5.6 版中發現一個問題。drivers/block/floppy.c 中的 set_fdc 會導致 wait_til_ready 超出邊界讀取，這是因為指派前未檢查 FDC 索引是否有錯誤所導致，亦即 CID-2e90ca68b0d2。(CVE-2020-9383)

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

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

  - 在 0.10.0之前的 janus-gateway (即 Janus WebRTC Server) 中發現一個問題。 sdp.c 中的 janus_sdp_process 有一個 NULL 指標解除參照。 (CVE-2020-13898)

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

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

  - 在 Linux 核心 4.13.11 之前版本中，arch/powerpc/kvm/powerpc.c 中的 kvm_vm_ioctl_check_extension 函式允許本機使用者透過對 /dev/kvm 的 KVM_CHECK_EXTENSION KVM_CAP_PPC_HTM ioctl 呼叫，來造成拒絕服務 (NULL 指標解除參照和系統當機)。(CVE-2017-15306)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs Patch series mm: fixes for device-exclusive entries (hmm), v2. Discussing the PageTail() call in make_device_exclusive_range() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system.
    Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs. The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIG_TEST_HMM. Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONE_MOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882]
    __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it. I wish we could just use some special present PROT_NONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed. With this series, make_device_exclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day. I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected. <program> #include <stdio.h> #include <fcntl.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/ioctl.h> #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd) struct hmm_dmirror_cmd { __u64 addr; __u64 ptr; __u64 npages; __u64 cpages; __u64 faults;
    }; const size_t size = 1 * 1024 * 1024 * 1024ul; const size_t chunk_size = 2 * 1024 * 1024ul; int m
    ---truncated--- (CVE-2025-22034)

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

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

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix out of bounds in init_smb2_rsp_hdr() If client send smb2 negotiate request and then send smb1 negotiate request, init_smb2_rsp_hdr is called for smb1 negotiate request since need_neg is set to false. This patch ignore smb1 packets after ->need_neg is set to false. (CVE-2023-52441)

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

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

  - bpf、test_run修正 eth_skb_pkt_type() 中的釋放後使用問題 KMSAN 報告 eth_skb_pkt_type()[1] 中存在一個釋放後使用問題。問題的原因是 eth_skb_pkt_type() 存取了不包含乙太網路標頭的 skb 資料。bpf_prog_test_run_xdp() 將無效的值做為 user_data 引數傳遞至 bpf_test_init() 時會發生此情況。當 user_data 小於 bpf_test_init() 的 ETH_HLEN 時傳回錯誤以修正此問題。此外移除不必要的 if (user_size > size) 檢查。 [1] 錯誤KMSANeth_skb_pkt_type include/linux/etherdevice.h:627 中的釋放後使用 [內嵌] 錯誤KMSANeth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165 中的釋放後使用eth_skb_pkt_type include/linux/etherdevice.h:627 [內嵌] eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165
    __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635 xdp_recv_frames net/bpf/test_run.c:272 [內嵌] xdp_test_run_batch net/bpf/test_run.c:361 [內嵌] bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test .c:390 bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318 bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371 __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777
    __do_sys_bpf kernel/bpf/syscall.c:5866 [內嵌] __se_sys_bpf kernel/bpf/syscall.c:5864 [內嵌]
    __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864 x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [內嵌] do_syscall_64 +0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit 建立於 free_pages_prepare mm/page_alloc.c:1056 [內嵌] free_unref_page+0x156/0x1320 mm/page_alloc.c:2657 __free_pages+ 0xa3/0x1b0 mm/page_alloc.c:4838 bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [內嵌] ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235 bpf_map_free kernel/bpf/syscall.c:838 [內嵌] bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310 worker_thread+0xedf/0x1550 kernel/workqueue.c:3391 kthread +0x535/0x6b0 kernel/kthread.c:389 ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 CPU: 1 UID: 0 PID 17276 Commsyz.1.1 6450 未受污染的 6.12.0-05490-g9bb88c659673 #8 硬體名稱: QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.3-3.fc41 2014 年 4 月 1 日 (CVE-2025-21867)

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

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

  - usbgadgetncm避免放置已正確剖析 NTB 的資料包。據發現有時在 Windows 11 做為主機透過 NCM 使用網路分享時在某些情況下gadget_giveback 會在適當 NTB 的結尾附加一個位元組。剖析 NTB 時解開包裝呼叫會在 SKB 中尋找 u_ether 提供的任何剩餘位元組如果有任何擱置的位元組則會將其視為獨立的 NTB 並加以剖析。但若第二個 NTB (依據解開包裝呼叫) 發生錯誤/損毀在第一個 NTB 中正確剖析及儲存在 rx_list 中的所有資料包都會遭到捨棄。新增一些自訂追踪顯示如下[002] d..1 7828.532866dwc3_gadget_giveback: ep1out: req 000000003868811a 長度 1025/16384 zsI ==> 0 [002] d..1 7828.532867ncm_unwrap_ntbKncm_unwrap_ntb toprocess 1025 [002] d..1 7828.532867ncm_unwrap_ntbK
    ncm_unwrap_ntb nth 1751999342 [002] d..1 7828.532868ncm_unwrap_ntbKncm_unwrap_ntb seq0xce67 [002] d..1 7828.532868ncm_unwrap_ntbKncm_unwrap_ntb blk_len0x400 [002] d..1 7828.532868ncm_unwrap_ntb
    Kncm_unwrap_ntb ndp_len0x10 [002] d..1 7828.532869ncm_unwrap_ntbK以 1 框架剖析 NTB在此情況下交回是 1025 位元組而區塊長度是 1024。其餘 1 個位元組 (0x00) 將不會遭到剖析導致 rx_list 中的所有資料包損毀。大小為 2048 的封包 7828.557949也是 7828.557948如此1751999342 [002] d..1 7828.557950
    ncm_unwrap_ntb: Kncm_unwrap_ntb blk_len: 0x800 Lecroy 顯示額外傳入一個位元組，確認該位元組是從 PC 傳入傳輸 2959 - 傳輸位元組 (1025) 時間戳記((18.524 843 590) - 交易 8391 - 資料 (1025 位元組) Timestamp(18.524 843 590) --- 封包 4063861 資料(1024 位元組) 持續時間 (2.117us) 閒置 (14.700ns) 時間戳記(18.524 843 590) --- 封包 4063863 資料(1 位元組) 持續時間 (66.160ns) 時間(282.000ns) Timestamp(18.524 845 722) 根據 Windows 驅動程式如果 wBlockLength 不是零則不需要 ZLP因為非零 wBlockLength 已告知函式端預期的傳輸大小。但是只要 wBlockLength 是 wMaxPacketSize 的倍數，就會有依賴 ZLP 的銷售中 NCM 裝置。為了處理這類裝置會在結尾填補一個額外的 0因此傳輸不再是 wMaxPacketSize 的倍數。 (CVE-2024-27405)

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

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

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

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

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

  - 已解決 Linux 核心中的下列弱點：xen-netback: take a reference to the RX task thread Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthread_stop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061ce97f4. Reintroduce the reference taking and add a comment this time explaining why it's needed. This is XSA-374 / CVE-2021-28691. (CVE-2021-47111)

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

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

  - e1000移動 cancel_work_sync 以避免鎖死。之前e1000_down 會針對 e1000 重設工作呼叫 cancel_work_sync (透過 e1000_down_and_stop)而該工作會採用 RTNL。根據使用者和 syzbot 的報告在下列情況下可能會發生鎖死CPU 0 - RTNL 保留 - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL 修正此問題請避免從 e1000_down 呼叫 cancel_work_sync (若裝置出現故障則 e1000_reset_task 不會執行任何動作)。而是在移除裝置時呼叫 e1000_reset_task 的 cancel_work_sync。
    (CVE-2025-38114)

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

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

  - 瀏覽器可能受到混淆而將指標鎖定狀態傳輸至另一個索引標籤進而導致點擊劫持攻擊。此弱點會影響 Firefox < 85。(CVE-2021-23955)

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

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

  - Mozilla 開發人員和社群成員 Ronald Crane、Andrew McCreight、Randell Jesup 及 Mozilla Fuzzing 團隊報告 Firefox 112 中存在記憶體安全性錯誤。某些錯誤顯示記憶體會遭到損毀，我們推測若有心人士有意操控，可能惡意利用其中部分錯誤執行任意程式碼。此弱點影響 Firefox < 113。(CVE-2023-32216)

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

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

  - f2fs修正以對 sbi->total_valid_block_count 進行功能健全檢查 syzbot 報告的 f2fs 錯誤如下
    ------------[ 此處截斷 ]------------ fs/f2fs/f2fs.h:2521! 的核心錯誤RIP
    0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 呼叫追踪
    f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode11_blocks+0/fef23/0x70 /node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setr+ 0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [內嵌] do_open fs/ namei.c:3849 [內嵌] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c :1444 [內嵌] __do_sys_creat fs/open.c:1522 [內嵌] __se_sys_creat fs/open.c:1516 [內嵌] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c 63 [內嵌] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 原因是在模糊影像、sbi->tot al_valid_block_count 與 inode 索引的對應區塊不一致因此我們不應在此情況下觸發錯誤我們應改為列印記錄並設定 fsck 旗標。 (CVE-2025-38163)

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

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

  - 在使用者於移除裝置期間於 unregister_netdev 之後觸發 cancel_work_sync 的方式中發現 Linux 核心管理元件傳輸通訊協定 (MCTP) 子系統中有一個釋放後使用缺陷。本機使用者可利用此缺陷來損毀系統或提高自己的系統權限。從 Linux 核心 5.17-rc1 (引入 mctp-serial.c 時) 到 5.17-rc5 版本中它都是實際存在的。 (CVE-2022-0646)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/mcde: Fix refcount leak in mcde_dsi_bind Every iteration of for_each_available_child_of_node() decrements the reference counter of the previous node. There is no decrement when break out from the loop and results in refcount leak. Add missing of_node_put() to fix this. (CVE-2022-50176)

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

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

  - 不正確的程式碼產生可導致未預期的數值轉換和潛在的未定義行為。*注意：此問題只會影響 32 位元 ARM 系統。此弱點會影響 Firefox < 123、Firefox ESR < 115.8 和 Thunderbird < 115.8。(CVE-2024-1552)

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

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

  - 用於檢查 PKCS#1 v1.5 的 NSS 程式碼洩漏了可用於裝載 Bleichenbacher 式攻擊的資訊。填補的整體正確性以及加密訊息的長度都會透過計時旁路洩漏。透過傳送大量攻擊者選取的加密文字，攻擊者將能夠解密先前攔截的 PKCS#1 v1.5 加密文字 (例如，解密使用 RSA 金鑰交換的 TLS 工作階段)，或使用受害者的金鑰偽造簽章。此問題已透過實作隱含拒絕演算法修復，其中 NSS 會在偵測到無效填補時傳回確定性隨機訊息，如 Marvin 攻擊報告中所建議。此弱點會影響 NSS < 3.61。(CVE-2023-4421)

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

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

  - 已解決 Linux 核心中的下列弱點：Bluetooth: btusb: Fix memory leak This checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone the skb and also make sure btmtk_process_coredump frees the skb passed following the same logic. (CVE-2024-26887)

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

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

  - 已解決 Linux 核心中的下列弱點：net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. (CVE-2022-48959)

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

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

  - LoongArchcpuinfo修正 CONFIG_CPUMASK_OFFSTACK 的警告。當選取 CONFIG_CPUMASK_OFFSTACK 和 CONFIG_DEBUG_PER_CPU_MAPS 時我們顯示 /proc/cpuinfo 時cpu_max_bits_warn() 會產生類似以下的運行時間警告。透過使用 nr_cpu_ids (運行時間限制) 而非 NR_CPUS 來重複 CPU 來修正此問題。 [ 3.052463] ------------[cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask .h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] 連結的模組efivarfs autofs4 [3.076257] CPU0 PID1 通訊systemd 未受污染的 5.19-rc5+ #1052 [ 3.084034] 硬體名稱 Loongson Loongson-3A5000 -7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 90000 00000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60 /0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter +0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- (CVE-2022-50223)

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

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

  - 已解決 Linux 核心中的下列弱點：net: dsa: fix NULL pointer dereference in dsa_port_reset_vlan_filtering The ds iterator variable used in dsa_port_reset_vlan_filtering() -> dsa_switch_for_each_port() overwrites the dp received as argument, which is later used to call dsa_port_vlan_filtering() proper. As a result, switches which do enter that code path (the ones with vlan_filtering_is_global=true) will dereference an invalid dp in dsa_port_reset_vlan_filtering() after leaving a VLAN-aware bridge. Use a dedicated other_dp iterator variable to avoid this from happening.
    (CVE-2022-49582)

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

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

  - 已解決 Linux 核心中的下列弱點：vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps. (CVE-2022-50117)

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

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

  - 在 Linux 核心 6.0.8 中，fs/ntfs3/bitmap.c 的 ntfs_trim_fs 中存在釋放後使用問題。
    (CVE-2023-26606)

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

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

  - xhci修正中止命令時的命令環指標損毀。命令環指標位於命令環控制暫存器 (CRCR) 的 [6:63] 位元中。所有控制位元 (如命令停止、中止) 皆位於 [0:3] 位元。在中止命令時我們會讀取 CRCR並設定中止位元並寫入 CRCR。讀取將一律將命令環指標視為全零。因此我們基本上只寫入了控制位元。由於我們將 64 位元寫入分割為兩個 32 位元寫入因此 xHC 命令環可能在寫入大寫字元 (全零) 之前即已停止。如果發生此情況xHC 會以全零更新其內部命令環指標的大寫 dword。下次重新啟動命令環時我們會看到 xHC 記憶體存取失敗。藉由僅寫入所有控制位元所在位置的 CRCR 較低 dword 來修正此問題。 (CVE-2021-47434)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.0.22 之前版本和 7.1.2 之前版本。低權限攻擊者可利用難以利用的弱點，登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。雖然弱點存在於 Oracle VM VirtualBox 中，但攻擊可能對其他產品造成重大影響 (範圍變更)。成功攻擊此弱點可能導致未經授權地更新、插入或刪除某些可供存取之 Oracle VM VirtualBox 資料的存取權、未經授權地讀取可供存取之 Oracle VM VirtualBox 資料子集的存取權以及未經授權造成部分拒絕服務 (partial DOS) 的 Oracle VM VirtualBox。 (CVE-2024-21248)

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

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

  - powerpc/powernv/memtrace修正 memtrace mmap 中的超出邊界問題 memtrace mmap 問題有一個超出邊界問題。此修補程式透過檢查要求的對應區域大小是否應維持在配置的區域大小內來修正 。 (CVE-2025-38088)

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

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

  - 5.4.3之前的 Open Asset Import Library Assimp 中發現一個分類為重大的弱點。此問題會影響元件檔案處置程式之程式庫 include/assimp/types.h 中的 aiString::Set 函式。攻擊者可利用此弱點造成堆積型緩衝區溢位。攻擊者可在本機主機上發動攻擊。攻擊程式已向公眾披露且可能會遭到利用。建議套用修補程式以修復此問題。(CVE-2025-3548)

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

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

  - 已解決 Linux 核心中的下列弱點：powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b850d (powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC) added a new function pmi_irq_pending in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c]
    __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740]
    __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function any_pmc_overflown checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5:
    pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6:
    0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 (powerpc/perf: Fix finding overflowed PMC in interrupt) Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function:
    perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2:
    optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated--- (CVE-2022-50118)

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

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

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

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

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

  - Oracle MySQL 的 MySQL Cluster 產品中存在的弱點 (元件：Cluster: General)。受到影響的支援版本是 7.4.33 與先前的版本、7.5.23 與先前的版本、7.6.19 與先前的版本，以及 8.0.26 與先前的版本。
    難以惡意利用的弱點允許能夠存取附加到 MySQL Cluster 執行所在硬體的高權限攻擊者以危害 MySQL Cluster。若要成功攻擊，必須有攻擊者以外之他人的互動。若攻擊成功，攻擊者可以接管 MySQL Cluster。(CVE-2021-35598)

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

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

  - 在 5.3.2 版及之前版本的 Linux 核心中，在 drivers/infiniband/hw/cxgb4/mem.c 的 write_tpt_entry 中發現一個問題。cxgb4 驅動程式會直接從堆疊變數呼叫 dma_map_single (一個 DMA 函式)。
    攻擊者可以藉此觸發拒絕服務，若在此堆疊/DMA 互動具有安全相關性的架構上使用此驅動程式，則此弱點可被攻擊者利用。(CVE-2019-17075)

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

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

  - scsizfcp修正 qdio 傳送失敗時 FSF 要求的重複釋放。我們過去常在「zfcp_fsf_req_send()」中使用錯誤的整數類型來快取 FSF 要求 ID。這會在傳送失敗而我們需要再次從內部雜湊表中移除要求時使用 (如此我們就不會保留無效的參照而在我們再次釋放要求時使用它)。在「zfcp_fsf_req_send()」中我們將 ID 快取為「int」(帶正負號的 32 位元寬)但其餘 zfcp 程式碼 (和韌體規格) 將 ID 視為「unsigned long」/「u64」( 64 位元寬 [s390x ELF ABI])。其中一個原因是當 ID 增長到超過 32 位元時 (這可能發生得相當快)它會在快取變數中儲存時截斷為 32 位元因此與原始 ID 不再相符。第二個較不明顯的問題是即使原始 ID 尚未成長超過 32 位元但只要在原始 ID 中設定第 32 位元 (0x80000000 = 2'147'483'648)將其轉換回「unsigned long」。由於快取變數屬於已簽署類型因此編譯器會選擇符號延伸指示將 32 位元變數載入 64 位元暫存器 (例如「lgf %r11,188(%r15)」)。因此當我們將快取變數傳遞至「zfcp_reqlist_find_rm()」以再次移除要求時所有最前面的零都會翻轉為 1 以延伸正負號且不會再符合原始 ID (實務中已觀察到此情況)。如果我們無法在「zfcp_qdio_send()」失敗後再次成功移除雜湊表中的要求 (當 zfcp 無法通知介面卡有關新工作的情況時通常會發生這種情況因為介面卡在 ChpID 切換等期間已經消失)我們最終會具有重複釋放錯誤。當「zfcp_fsf_req_send()」失敗時我們會在呼叫函式中無條件釋放要求但因為要求仍在雜湊表中我們最終會得到過時的記憶體參照而且一旦 zfcp 介面卡在復原或關機期間重設我們就會結束兩次釋放相同的記憶體。產生的堆疊追踪因核心而異且與發生錯誤的位置沒有直接關聯。以下是實際使用過的三個範例： list_del 損毀。 next->prev 應為 00000001b9d13800但之前為 00000000dead4ead。 (next=00000001bd131a00) ------------[ 此處剪切 ]------------ lib/list_debug.c:62! 的核心錯誤監控事件0040 ilc:2 [#1] PREEMPT SMP 模組連結於... CPU:
    9 PID1617 Commzfcperp0.0.1740 Kdumploaded 硬體名稱... Krnl PSW 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) 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: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code:
    00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,% r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 呼叫追踪
    [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>]
    __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated--- (CVE-2022-49789)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/imagination: Free pvr_vm_gpuva after unlink This caused a measurable memory leak. Although the individual allocations are small, the leaks occurs in a high-usage codepath (remapping or unmapping device memory) so they add up quickly.
    (CVE-2024-46779)

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

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

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

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

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

  - ice修正錯誤路徑中取消初始化的 VF 如果 ice_ena_vfs() 在呼叫 ice_create_vf_entries() 後失敗它會釋放所有 VF而不將其從快照 PF-VF 信箱清單移除進而導致清單損毀。
    Reproducer: devlink dev eswitch set $PF1_PCI mode switchdev ip ls $PF1 up ip ls $PF1 promisc on sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs sleep 1 echo 1 > /sys /class/net/$PF1/device/sriov_numvfs Trace (minimized)list_add 損毀。 next->prev 應該是 prev (ffff8882e241c6f0)但原來是 0000000000000000。(next=ffff888455da1330)。 lib/list_debug.c:29! 的核心錯誤RIP
    0010:__list_add_valid_or_report+0xa6/0x100 ice_mbx_init_vf_info+0xa7/0x180 [ice] ice_initialize_vf_entry+0x1fa/0x250 [ice] ice_sriov_configure+0x8d7/0x1520 [ice]
    __percpu_ref_switch_mode+0x1b1/0x5d0 ? __pfx_ice_sriov_configure+0x10/0x10 [ice] 有時可以看到 KASAN 報告而不是類似堆疊追踪錯誤KASAN 中的釋放後使用
    __list_add_valid_or_report+0xf1/0x100 VF 會新增至 ice_mbx_init_vf_info() 的此清單但只會在 ice_free_vfs() 中移除。將移除作業移至 ice_free_vf_entries()該函式也會在其他移除 VF 的地方遭到呼叫 (包括 ice_free_vfs() 本身)。 (CVE-2025-21883)

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

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

  - 在 core.c 的 create_pinctrl 中，可能因釋放後使用而發生超出邊界讀取。這可以導致本機資訊洩漏，而不需要額外的執行特權。惡意利用弱點不需要使用者互動。產品：AndroidVersions：Android kernelAndroid ID：A-140550171 (CVE-2020-0427)

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

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

  - hidcp2112修正重複的 workqueue 初始化。之前的 cp2112 驅動程式在 cp2112_gpio_irq_startup 中呼叫了 INIT_DELAYED_WORK造成後續遵循初始要求的 IRQ 啟動時會出現重複的 workqueue 初始化。這會導致在 workqueue.c 的 set_work_data 中出現警告以及在 workqueue.c 的 process_one_work 中導致罕見的 NULL 解除參照。改為在 _probe 內初始化工作佇列。 (CVE-2023-52853)

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

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

  - 已解決 Linux 核心中的下列弱點：kcm: fix strp_init() order and cleanup strp_init() is called just a few lines above this csk->sk_user_data check, it also initializes strp->work etc., therefore, it is unnecessary to call strp_done() to cancel the freshly initialized work. And if sk_user_data is already used by KCM, psock->strp should not be touched, particularly strp->work state, so we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go away. (CVE-2022-49957)

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

ID	名稱	嚴重性
246672	Linux Distros 未修補的弱點：CVE-2021-47518	medium
246671	Linux Distros 未修補的弱點：CVE-2023-53031	medium
246670	Linux Distros 未修補的弱點：CVE-2021-47110	high
246669	Linux Distros 未修補的弱點：CVE-2024-11692	medium
246668	Linux Distros 未修補的弱點：CVE-2019-11747	medium
246667	Linux Distros 未修補的弱點：CVE-2019-12881	high
246666	Linux Distros 未修補的弱點：CVE-2022-49791	high
246665	Linux Distros 未修補的弱點：CVE-2024-56556	high
246664	Linux Distros 未修補的弱點：CVE-2025-38332	high
246663	Linux Distros 未修補的弱點：CVE-2021-3764	medium
246662	Linux Distros 未修補的弱點：CVE-2024-38621	high
246661	Linux Distros 未修補的弱點：CVE-2020-14836	medium
246660	Linux Distros 未修補的弱點：CVE-2020-9383	high
246659	Linux Distros 未修補的弱點：CVE-2020-13898	high
246658	Linux Distros 未修補的弱點：CVE-2017-15306	medium
246657	Linux Distros 未修補的弱點：CVE-2025-22034	medium
246656	Linux Distros 未修補的弱點：CVE-2023-52441	high
246655	Linux Distros 未修補的弱點：CVE-2025-21867	high
246654	Linux Distros 未修補的弱點：CVE-2024-27405	high
246653	Linux Distros 未修補的弱點：CVE-2022-21270	medium
246652	Linux Distros 未修補的弱點：CVE-2021-47111	high
246651	Linux Distros 未修補的弱點：CVE-2025-38114	medium
246650	Linux Distros 未修補的弱點：CVE-2021-23955	medium
246649	Linux Distros 未修補的弱點：CVE-2023-32216	critical
246648	Linux Distros 未修補的弱點：CVE-2025-38163	high
246647	Linux Distros 未修補的弱點：CVE-2022-0646	high
246646	Linux Distros 未修補的弱點：CVE-2022-50176	medium
246645	Linux Distros 未修補的弱點：CVE-2024-1552	high
246644	Linux Distros 未修補的弱點：CVE-2023-4421	medium
246643	Linux Distros 未修補的弱點：CVE-2024-26887	medium
246642	Linux Distros 未修補的弱點：CVE-2022-48959	medium
246641	Linux Distros 未修補的弱點：CVE-2022-50223	medium
246640	Linux Distros 未修補的弱點：CVE-2022-49582	medium
246639	Linux Distros 未修補的弱點：CVE-2022-50117	high
246638	Linux Distros 未修補的弱點：CVE-2023-26606	high
246637	Linux Distros 未修補的弱點：CVE-2021-47434	high
246636	Linux Distros 未修補的弱點：CVE-2024-21248	medium
246635	Linux Distros 未修補的弱點：CVE-2025-38088	high
246634	Linux Distros 未修補的弱點：CVE-2025-3548	medium
246633	Linux Distros 未修補的弱點：CVE-2022-50118	medium
246632	Linux Distros 未修補的弱點：CVE-2020-14773	medium
246631	Linux Distros 未修補的弱點：CVE-2021-35598	medium
246630	Linux Distros 未修補的弱點：CVE-2019-17075	high
246629	Linux Distros 未修補的弱點：CVE-2022-49789	high
246628	Linux Distros 未修補的弱點：CVE-2024-46779	medium
246627	Linux Distros 未修補的弱點：CVE-2022-21435	medium
246626	Linux Distros 未修補的弱點：CVE-2025-21883	medium
246625	Linux Distros 未修補的弱點：CVE-2020-0427	medium
246624	Linux Distros 未修補的弱點：CVE-2023-52853	medium
246623	Linux Distros 未修補的弱點：CVE-2022-49957	medium

偵測

Nessus 的 Misc. 系列

medium

medium

high

medium

medium

high

high

high

high

medium

high

medium

high

high

medium

medium

high

high

high

medium

high

medium

medium

critical

high

high

medium

high

medium

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

medium

high

high

medium

medium

medium

medium

medium

medium