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

  - 已解決 Linux 核心中的下列弱點：net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs The hns3 driver define an array of string to show the coalesce info, but if the kernel adds a new mode or a new state, out-of-bounds access may occur when coalesce info is read via debugfs, this patch fix the problem. (CVE-2023-52807)

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

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

  - 在 Mbed TLS  2.24.0 之前的版本中發現一個問題。未正確處理比對預期共用名稱 (mbedtls_x509_crt_verify 的 cn 引數) 與實際憑證名稱時的 X.509 憑證驗證當 subjecAltName 延伸模組存在時無論預期名稱為何類型都會將預期名稱與該延伸模組中的任何名稱進行比較。這表示攻擊者可透過取得 IPv4 或 IPv6 位址對應的憑證來冒充 4 位元組或 16 位元組網域 (前提是攻擊者必須控制該 IP 位址)。(CVE-2020-36477)

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

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

  - 在某些情況下，Drupal 核心表單 API 會錯誤評估表單元素的存取權，這可能導致使用者能夠變更他們不應存取的資料。已知 Drupal 核心提供的表單都不會受到影響，不過透過提供或自訂模組或主題新增的表單可能會受到影響。 (CVE-2022-25278)

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

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

  - 已解決 Linux 核心中的下列弱點：virtio-blk: Avoid use-after-free on suspend/resume hctx->user_data is set to vq in virtblk_init_hctx(). However, vq is freed on suspend and reallocated on resume. So, hctx->user_data is invalid after resume, and it will cause use-after-free accessing which will result in the kernel crash something like below: [ 22.428391] Call Trace: [22.428899] <TASK> [ 22.429339] virtqueue_add_split+0x3eb/0x620 [ 22.430035] ?
    __blk_mq_alloc_requests+0x17f/0x2d0 [ 22.430789] ? kvm_clock_get_cycles+0x14/0x30 [ 22.431496] virtqueue_add_sgs+0xad/0xd0 [ 22.432108] virtblk_add_req+0xe8/0x150 [ 22.432692] virtio_queue_rqs+0xeb/0x210 [ 22.433330] blk_mq_flush_plug_list+0x1b8/0x280 [ 22.434059]
    __blk_flush_plug+0xe1/0x140 [ 22.434853] blk_finish_plug+0x20/0x40 [ 22.435512] read_pages+0x20a/0x2e0 [22.436063] ? folio_add_lru+0x62/0xa0 [ 22.436652] page_cache_ra_unbounded+0x112/0x160 [ 22.437365] filemap_get_pages+0xe1/0x5b0 [ 22.437964] ? context_to_sid+0x70/0x100 [ 22.438580] ? sidtab_context_to_sid+0x32/0x400 [ 22.439979] filemap_read+0xcd/0x3d0 [ 22.440917] xfs_file_buffered_read+0x4a/0xc0 [ 22.441984] xfs_file_read_iter+0x65/0xd0 [ 22.442970]
    __kernel_read+0x160/0x2e0 [ 22.443921] bprm_execve+0x21b/0x640 [ 22.444809] do_execveat_common.isra.0+0x1a8/0x220 [ 22.446008] __x64_sys_execve+0x2d/0x40 [ 22.446920] do_syscall_64+0x37/0x90 [ 22.447773] entry_SYSCALL_64_after_hwframe+0x63/0xcd This patch fixes this issue by getting vq from vblk, and removes virtblk_init_hctx(). (CVE-2022-50064)

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

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

  - 已解決 Linux 核心中的下列弱點：mptcp: fix sleep in atomic at close time Matt reported a splat at msk close time: BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by packetdrill/155: #0:
    ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650) #1:
    ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973) #2:
    ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363) #3:
    ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820) Preemption disabled at: 0x0 CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) __might_resched.cold (kernel/sched/core.c:9891) __mptcp_destroy_sock (include/linux/kernel.h:110) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_subflow_queue_clean (include/net/sock.h:1777) __mptcp_close_ssk (net/mptcp/protocol.c:2363) mptcp_destroy_common (net/mptcp/protocol.c:3170) mptcp_destroy (include/net/sock.h:1495) __mptcp_destroy_sock (net/mptcp/protocol.c:2886) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_close (net/mptcp/protocol.c:2974) inet_release (net/ipv4/af_inet.c:432) __sock_release (net/socket.c:651) sock_close (net/socket.c:1367) __fput (fs/file_table.c:320) task_work_run (kernel/task_work.c:181 (discriminator 1)) exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49) syscall_exit_to_user_mode (kernel/entry/common.c:130) do_syscall_64 (arch/x86/entry/common.c:87) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) We can't call mptcp_close under the 'fast' socket lock variant, replace it with a sock_lock_nested() as the relevant code is already under the listening msk socket lock protection. (CVE-2022-49018)

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

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

  - fbdevhyperv_fb修正 Hyper-V Gen 2 VM 第 2 代 Hyper-V VM 上透過 EFI 開機並擁有標準 EFI 框架緩衝區裝置時kdump 核心中的懸置。kdump 核心在這類 VM 中執行時載入 efifb 驅動程式可能會因存取錯誤記憶體位址的框架緩衝區而懸置。當原始核心中的 hyperv_fb 驅動程式因為與已執行的 efifb 或 simplefb 驅動程式衝突而將框架緩衝區移動至其他 MMIO 位址時會發生此狀況。然後hyperv_fb 驅動程式會將變更通知 Hyper-VHyper-V FB VMBus 裝置通訊協定允許這麼做。不過當 kexec 命令透過 kexec_file_load() 系統呼叫將 kdump 核心載入損毀記憶體時系統呼叫並不知道 framebuffer 已移動它會使用原始 framebuffer 位址來設定 kdump screen_info。轉換至 kdump 核心時不會經過 Hyper-V 主機因此 Hyper-V 不會像重新開機時一樣重設框架緩衝區位址。當 efifb 嘗試執行時它會存取不存在的 framebuffer 位址進而設陷到 Hyper-V 主機。在多次此類存取之後Hyper-V 主機會認為來賓是惡意的來賓並將其限制為執行速度非常緩慢或似乎已懸置的程度。當 kdump 核心透過 kexec_load() 系統呼叫載入至損毀記憶體時不會發生此問題。在此情況下kexec 命令會根據 FBIOGET_FSCREENINFO ioctl 對 /dev/fb0 傳回的資料在使用者空間中自行構建 screen_info 表格並為其提供新的框架緩衝區位置。此問題最初報告於 2020 [1]進而導致提交 3cb73bc3fa2a (hyperv_fb移除舊框架緩衝區後更新 screen_info)。此認可透過將 orig_video_isVGA 設為 0 來解決問題因此 kdump 核心不會察覺 EFI 框架緩衝區。efifb 驅動程式並未嘗試載入因此沒有發生懸置。但在 2024 年認可 c25a19afb81c (fbdev/hyperv_fb不清除全域 screen_info) 有效還原了 3cb73bc3fa2a。認可 c25a19afb81c 並未參照 3cb73bc3fa2a因此可能在不知道 3cb73bc3fa2a 所報告之影響的情況下完成。無論如何從認可 c25a19afb81c 開始原始問題再次出現。有趣的是hyperv_drm 驅動程式沒有這個問題因為它從不移動框架緩衝區。不同之處在於hyperv_drm 驅動程式會在配置 MMIO 位址之前*移除任何衝突的框架緩衝區而 hyperv_fb 驅動程式則會在配置 MMIO 位址*之後*移除衝突的框架緩衝區。若使用 after 排序hyperv_fb 可能會發生衝突並將框架緩衝區移至不同的 MMIO 位址。
    但此衝突本質上是假的因為它會在幾行程式碼之後被移除。與其在認可 3cb73bc3fa2a 中使用 2020 年後的方法修正問題不如稍微重新排序 hyperv_fb 中的步驟以便在配置 MMIO 位址之前移除衝突的框架緩衝區。則預設的 framebuffer MMIO 位址應該永遠可以使用而且不會再混淆 kdump 核心應該使用哪個 framebuffer 位址它永遠是 Hyper-V 主機提供的原始位址。此方法已由 hyperv_drm 驅動程式使用且與具有函式 emerge_remove_conflicting_devices() 之模組開頭的使用準則一致。此方法也可解決使用 kexec_load() 載入 kdump 核心時發生的一個相關次要問題。若使用目前的程式碼解除系結和重新系結 hyperv_fb 驅動程式可導致框架緩衝區移回預設的框架緩衝區位址因為在重新系結時沒有衝突。若在使用新框架緩衝區位址載入 kdump 核心之後執行此類移動則在 kdump 時其位址可再次錯誤。此問題及修正是根據 kdump 核心描述但也可能會發生
    ---truncated--- (CVE-2025-21977)

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

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

  - axios 1.7.2 會透過非預期行為允許 SSRF其中路徑相對 URL 的要求被視為通訊協定相對 URL。 (CVE-2024-39338)

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

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

  - virtio_ring藉由將 event_triggered 標記為 racy 來修正資料爭用 syzbot 報告存取 event_triggered 時發生資料爭用以下是問題發生時的簡化堆疊
    ================================================== ================ 錯誤KCSANvirtqueue_disable_cb / virtqueue_enable_cb_delayed 中的資料爭用由 cpu 0 上的工作 3288 寫入 0xffff8881025bc452 (共 1 個位元組)virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring .c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [內嵌] netdev_start_xmit include/linux/netdevice.h:5160 [內嵌] xmit_one net/core/dev .c:3800 [內嵌] 在 1 個 cpu 1 上發生中斷導致 1 位元組的 0xffff8881025bc452 讀取 virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [內嵌] virtqueue_disable_cb+0x92/0x180 drivers/virtio_ring.c:2566 skb_xmit_done 0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [內嵌] 值變更0x01 -> 0x00 ========================================== ============ ============ 發生資料爭用時由於爭用情形virtqueue_enable_cb_delayed() 函式會將 event_triggered 設定為 false而 virtqueue_disable_cb_split/packed() 會將其讀取為 false。由於 event_triggered 是用於最佳化的不可靠提示因此這只會造成驅動程式暫時建議裝置在使用事件索引時不傳送中斷通知。修正此 KCSAN 報告的資料爭用問題將存取明確標記為 data_racy。 (CVE-2025-38048)

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

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

  - clkmediatekclk-mt2701新增 mtk_alloc_clk_data 檢查。新增 mtk_alloc_clk_data() 傳回值的檢查以避免 NULL 指標解除參照。 (CVE-2023-52875)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init Add a unreference bo in the error path, to prevent leaking a bo ref. Return 0 on success to clarify the success path. (cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549) (CVE-2024-26985)

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

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

  - 在 4.12 之前的 Linux 核心中，Hisilicon Network Subsystem (HNS) 在擷取 sset_count 資料時並未考量 ETH_SS_PRIV_FLAGS 情況，進而允許本機使用者造成拒絕服務 (緩衝區溢位和記憶體損毀)，或可能造成其他不明影響，hns_get_sset_count 和 ethtool_get_strings 之間的不相容性即為一例。(CVE-2017-18222)

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

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

  - net/niuNiu 需要接觸 MSIX ENTRY_DATA 欄位後才能讀取項目。修正 niu_try_msix()使其不在 sparc 系統上造成嚴重設陷。設定結構 pci_dev 上的 PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST 以解決硬體或韌體中的一個錯誤。針對 msix 表格中的每個向量項目如果在寫入項目的 ENTRY_DATA 暫存器之前讀取該項目中的任何暫存器則 niu 晶片會造成嚴重設陷。
    測試顯示寫入其他暫存器的記錄不足以防止嚴重設陷不過該值似乎無關緊要。這只需要在啟動後發生一次因此直接重新開機進入缺少此修正的核心不會造成設陷。不可解決的錯誤cpu 的報告有 64 個不可解決的錯誤 TPC [0x00000000005f6900]<msix_prepare_msi_desc+0x90/0xa0>不可恢復的錯誤原始 [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff 不可恢復的錯誤
    0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE錯誤raddr [0xffffffffffffffff] 不可回收錯誤insn 有效位址 [0x000000c50020000c] 不可回收錯誤
    大小 [0x8] 不可恢復的錯誤asi [0x00] CPU 64 UID: 0 PID: 745 Comm: kworker/64:1 未受污染 6.11.5 #63 工作佇列事件 work_for_cpu_fn TSTATE0000000011001602 TPC00000000005f6900 TNP
    00000000005f6904 Y 00000000 未受污染 TPC<msix_prepare_msi_desc+0x90/0xa0> g000000000000002e9 g1
    000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6
    ffff800047a08000 g70000000000000000 o0ffff800014feb000 o1ffff800047a0b620 o20000000000000011 o3
    ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1 ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 000000808111<niu_try_msix.constprop.0+0xc0/0x130 [niu]>呼叫追踪[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28 /0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 核心錯誤 - 未同步不可恢復的錯誤。 (CVE-2025-37833)

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

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

  - 在 3.1 之前的 Linux 核心中，drivers/target/loopback/tcm_loop.c tcm_loop_make_naa_tpg() 函式中的差一錯誤至少可導致記憶體損毀。(CVE-2011-5327)

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

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

  - 在 Linux 核心 4.15.15 及之前版本中，fs/ext4/balloc.c 的 ext4_valid_block_bitmap 函式可以讓攻擊者透過特製的 ext4 影像引致拒絕服務 (超出邊界讀取和系統當機)，其原因在於 balloc.c 和 ialloc 不會驗證點陣圖區塊編號。(CVE-2018-1093)

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

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

  - 9p/net修正假負值讀取/寫入回覆的不當處理。在 p9_client_write() 和 p9_client_read_once() 中如果伺服器未正確回覆成功但寫入/讀取計數為負值那麼我們會考慮寫入 (負值) <= rsize (正)因為兩個變數皆已簽署。將變數設為不帶正負號以避免此問題。以下連結的複制器現在會失敗並出現下列錯誤而非 null 指標解除參照9pnet假的 RWRITE 計數 (4294967295 > 3) (CVE-2025-37879)

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

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

  - 在 Apache Tomcat 8.5.0 至 8.5.75 或 Apache Tomcat 9.0.0.M1 至 9.0.20 版本上，如果執行的 Web 應用程式在關閉 WebSocket 連線的同時傳送 WebSocket 訊息，則應用程式可能會在關閉後繼續使用該通訊端。在此情況下觸發的錯誤處理可造成共用物件被放置在集區中兩次。這就有可能導致後續連線同時使用同一個物件，進而導致錯誤使用傳回的資料和/或發生其他錯誤。(CVE-2022-25762)

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

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

  - 有心人士可利用含有資料 URI 的表單，存取已被複製到內容中的有權限 JSONView 物件。洩漏此物件的影響似乎微不足道，但這會導致繞過深度機制中的現有防禦。此弱點會影響 Firefox < 70、Thunderbird < 68.2 和 Firefox ESR < 68.2。(CVE-2019-11761)

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

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

  - 已解決 Linux 核心中的下列弱點：net: bcmasp: fix memory leak when bringing down interface When bringing down the TX rings we flush the rings but forget to reclaimed the flushed packets. This leads to a memory leak since we do not free the dma mapped buffers. This also leads to tx control block corruption when bringing down the interface for power management. (CVE-2024-35858)

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

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

  - GNU C 程式庫 2.27 至 2.38 版中未受信任的 LD_LIBRARY_PATH 環境變數弱點會讓攻擊者得以在呼叫 dlopen 的靜態編譯 setuid 二進位中控制動態共用程式庫的載入 (包括 setlocale 後的內部 dlopen 呼叫或 NSS 函式的呼叫例如 getaddrinfo)。 (CVE-2025-4802)

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

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

  - i2ccros-ec-tunnel如果父項 EC 不存在則延遲探查。內建 i2c-cros-ec-tunnel 和 EC 驅動程式時將找不到 EC 父項裝置進而導致 NULL 指標解除參照。解除系結控制器驅動程式然後載入 i2c-cros-ec-tunnel 模組 (或系結裝置)也可重現該情形。 [ 271.991245] 錯誤核心 NULL 指標解除參照位址0000000000000058 [ 271.998215] #PF
    核心模式中的監督讀取存取 [ 272.003351] #PFerror_code(0x0000) - 不存在頁面 [272.008485] PGD 0 P4D 0 [ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI [ 272.015207] CPU 0 UID0 PID
    3859 Comminsmod 污染的 GS 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(完整) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5 [ 272.030312] 污染的 [S]=CPU_OUT_OF_SPEC 272.034233, 435_Berknip6./Berknip6 .0 2021 年 5 月 17 日 [ 272.042400] RIP
    0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel] [ 272.048577] 程式碼1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48c 8b 05 06 a0 6c e7 4 1048 4 9 47 2 2 08 4 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9 [ 272.067317] RSP0018:ffffa32082a03940 EFLAGS
    00010282 [ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000 [ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00 [ 272.086804] RBP: 00000000fffffdfb R08:
    0000000000000000 R090000000000000000 [ 272.093936] R100000000000000000 R11ffffffffc0600000 R12
    0000000000000000 [ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10 [272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000 [ 272.116282] CS:
    0010 DS 0000 ES 0000 CR0 0000000080050033 [ 272.122024] CR2 0000000000000058 CR3 000000012631c000 CR4 00000000003506f0 [ 272.129155] 呼叫追踪 [ 272.131606] ] <TASK> [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110 [ 272.137985] platform_probe+0x69/0xa0 [ 272.141652] emerge_probe+0x152/0x310 [ 272.145318] __driver_probe_device+0x77/0x110 [ 272.149678] driver_probe_device+0x1e/0x190 [ 272.153864] __edriver_attach+0x10b/0x10 [ 272.157790] ? driver_attach+0x20/0x20 [ 272.161542] bus_for_each_dev+0x107/0x150 [ 272.165553] bus_add_driver+0x15d/0x270 [ 272.169392] driver_register+0x65/0x110 [ 272.173232] cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698] [ 272.182617] do_one_initcall+0x110/0x350 [ 272.186543] security_kernfs_init_security+0x49/0xd0 [ 272.191682] ?
    __kernfs_new_node+0x1b9/0x240 [ 272.195954] security_kernfs_init_security+0x49/0xd0 [ 272.201093] ?
    __kernfs_new_node+0x1b9/0x240 [ 272.205365] kernfs_link_sibling+0x105/0x130 [ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0 [ 272.214773] kernfs_activate+0x57/0x70 [ 272.218699] ? kernfs_add_one+0x118/0x160 [ 272.222710] ? __kernfs_create_file+0x71/0xa0 [ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110 [ 272.232033] ? internal_create_group+0x453/0x4a0 [ 272.236651] ?
    __vunmap_range_noflush+0x214/0x2d0 [ 272.241355] __free_frozen_pages+0x1dc/0x420 [ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0 [ 272.250505] load_module+0x1509/0x16f0 [ 272.254431] do_init_module+0x60/0x230 [ 272.258181] __se_sys_finit_module+0x27a/0x370 [ 272.262627] do_syscall_64+0x6a/0xf0 [ 272.266206] ? do_syscall_64+0x76/0xf0 [ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90 [ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 272.279887] RIP 0033:0x7b9309168d39 [ 272.283466] 程式碼5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 4 900 4 0 8 f 86 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8 [ 272.302210] ] RSP 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000
    ---truncated--- (CVE-2025-37781)

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

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

  - 特定情形下，在裝置方向檢查期間檢查 Resist Fingerprinting 喜好設定時，爭用情形可能造成釋放後使用及可能遭利用的當機。此弱點會影響 Thunderbird < 68.3、Firefox ESR < 68.3 和 Firefox < 71。(CVE-2019-17010)

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

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

  - 已解決 Linux 核心中的下列弱點：net: wwan: iosm: fix memory leak in ipc_mux_init() When failed to alloc ipc_mux->ul_adb.pp_qlt in ipc_mux_init(), ipc_mux is not released.
    (CVE-2022-48963)

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

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

  - fbdevsavagepixclock 等於零時會發生錯誤。使用者空間程式可透過 ioctl() 介面將任何值傳遞至驅動程式。如果驅動程式未檢查 pixclock 的值可能會造成除以零錯誤。雖然在 savagefb_decode_var() 中檢查了 pixclock但它並未在 savagefb_probe() 中正確檢查。透過在使用 info->var.pixclock 作為除數之前檢查函式 savagefb_check_var() 中的 pixclock 是否為零來修正此問題。此問題類似於 i740fb 中的 CVE-2022-3061 其已由認可 15cf0b8 修正。 (CVE-2024-26778)

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

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

  - nilfs2修正重新掛載 ns_writer 時的釋放後使用錯誤寫入器與同步檔案系統可同時進行。在這些情況下記錄寫入器 (以下簡稱 nilfs->ns_writer) 可能會發生釋放後使用情形如下面的狀況所示： Task1 Task2 ------------------- ------------- ------------------ nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue 排程 nilfs_remount (R/W 重新掛載大小寫) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait
    _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- 釋放後使用 Task1 睡眠時nilfs->ns_writer 會由 Task2 釋放。Task1 喚醒後Task1 會存取已釋放的 nilfs->ns_writer。此狀況圖是以 Shigeru Yoshida 的貼文 [1] 為基礎。
    此修補程式修正了此問題不在重新掛載時卸離 nilfs->ns_writer 從而避免發生此 UAF 爭用。除了此變更此修補程式也插入了一些必要的具有超級區塊執行個體的唯讀檢查其中僅使用 ns_writer 指標來檢查檔案系統是否為唯讀。
    (CVE-2022-49834)

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

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

  - Linux 核心的 net/sched: cls_fw 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。如果 tcf_change_indev() 失敗，fw_set_parms() 會在增加或減少 tcf_bind_filter() 中的參照計數器後立即傳回錯誤。如果攻擊者可控制參照計數器並將其設定為零，便可造成參照釋放，進而導致釋放後使用弱點。建議升級過去的 Commit 0323bce598eea038714f941ce2b22541c46d488f。
    (CVE-2023-3776)

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

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

  - bpf不將堆疊 ptr 暫存器包含在精確度回溯簿記中Yi Lai 報告了一個問題 ([1])其中核心 dmesg 中會出現下列警告[ 60.643604] 驗證器回溯錯誤 [60.643635] 警告 CPU10 PID kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 的 2315 [60.648428] 連結於 bpf_testmod(OE) 的模組 [ 60.650471] CPU10 UID: 0 PID: 2315 Comm: test_progs 受污染的 G OE 6.15. 0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] 受污染[O]=OOT_MODULE、[E]=UNSIGNED_MODULE [ 60.656682] 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel -1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP
    0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] 程式碼5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 4 c7 00 5 30 8 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP 0018:ffff888116cc7298 EFLAGS00010246 [ 60.671075] RAX 54d70e82dfd31900 RBX
    ffff888115b65e20 RCX 0000000000000000 [ 60.673659] RDX 0000000000000001 RSI 0000000000000004 RDI
    00000000ffffffff [ 60.676241] RBP0000000000000400 R08ffff8881f6f23bd3 R091ffff1103ede477a [60.678787] R10dffffc0000000000 R11ffffed103ede477b 1] 560 [ R12]1] 560 []1] 560 60.681420R13888ae
     R141ffff11022b6cbc4  : 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 60.689027] CR2000056325369e000 CR3000000011088b002 CR40000000000370ef0 [60.691623] 呼叫追踪 [ 60.692821] <TASK> [ 60.693960] __pfx_verbose+0x10/0x10 [ 60.695656] ?
    __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... 進一步分析顯示警告位於第 4302 行如下4294 /* 靜態 subprog 呼叫指示其中 4295 * 表示我們正在結束目前的 subprog4296 * 因此只有 r1-r5 仍可要求為 4297 * 精確的 r0 和 r6 -r10 或 4298 中的任何堆疊插槽 * 到現在為止目前框架應該是零 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env、BUG regs %x\n、bt_reg_mask(bt)); 4302 WARN_ONCE(1驗證器回溯錯誤) 4303 傳回 -EFAULT 4304 } 透過下列測試 (也在下一個修補程式中) __used __naked static void __bpf_jmp_r10(void) { asm volatile (r2 = 2314885393468386424 ll; goto +0; if r2 <= r10 goto +3; if r1 >= -1835016 goto +0 if r2 <= 8 goto +0 if r3 <= 0 goto +0 exit::: __clobber_all) } SEC(?raw_tp) __naked void bpf_jmp_r10(void) { asm volatile ( r3 = 0 ll; call __bpf_jmp_r10; r0 = 0; exit; :::
    __clobber_all);以下是驗證程式失敗記錄 0 (18) r3 = 0x0 R3_w=0 2(85) 呼叫 pc+2 呼叫者 R10=fp0 被呼叫者frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile ( \ @ verifier_precision.c:184 5(18) r2 = 0x20202000256c6c78 frame1 R2_w=0x20202000256c6c78 7(05) goto pc+0 8(bd) 如果 r2 <= r10 goto pc+3 R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precision: frame1last_idx 10 first_idx 0 subseq_idx -1 mark_precision: frame1: regs=r2 stack= Before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precision: frame1: regs=r2 stack= Before 8: (bd) if r2 <= r10 goto pc +3 mark_precision ---truncated--- (CVE-2025-38279)

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

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

  - 在 Linux 核心 5.1 之前版本中，因為 register_snap_client 可能傳回 NULL，AppleTalk 子系統中可能會發生 NULL 指標解除參照。這會導致 net/appletalk/aarp.c 和 net/appletalk/ddp.c 中發生拒絕服務，unregister_snap_client 即為一例，即 CID-9804501fa122。(CVE-2019-19227)

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

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

  - isofs防止使用過小的 fid syzbot 報告 isofs_fh_to_parent 中有 slab-out-of-bounds Read。
    [1] 複製程式傳入的 handle_bytes 值等於 12。在 handle_to_path() 中只配置 12 位元組的記憶體給結構 file_handle->f_handle 成員這會在 isofs 中存取 isofs_fid 結構的成員 parent_block 時造成超出邊界存取因為存取 parent_block 至少需要 16 個位元組的 f_handle。此處的 fh_len 用於在存取 parent_block 之前間接確認 handle_bytes 的值是否大於 3。 [1] 錯誤KASAN工作syz-executor215/6466 在 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 讀取位址 ffff0000cc030d94 的大小 4 CPU1 UID 0 PID 發生平台超出邊界問題6466 Commsyz-executor215 未受污染的 6.14.0-rc7-syzkaller-ga2392f333575 #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 02/12/2025 呼叫追踪show_stack+0x2c/0x3c arch/arm64 /kernel/stacktrace.c:466 (C)
    __dump_stack lib/dump_stack.c:94 [內嵌] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [內嵌] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_s/export /expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [內嵌] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403
    __do_sys_open_by_handle_at fs/fhandle.c:443 [內嵌] __se_sys_open_by_handle_at fs/fhandle.c:434 [內嵌]
    __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [內嵌] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/ arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/ arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 由工作 6466 分配 kasan_save_stack mm/kasan/common.c:47 [內嵌] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 pox_kmalloc_redzone mm/kasan/common.c:377 [內嵌] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [內嵌]
    __do_kmalloc_node mm/slub.c:4294 [內嵌] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [內嵌] handle_to_path fs/fhandle.c:357 [內嵌] do_handle_open+0x5a4 /0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [內嵌] __se_sys_open_by_handle_at fs/fhandle.c:434 [內嵌] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64//fhandle.c:434 syscall.c:35 [內嵌] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel /syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64 /kernel/entry.S:600 (CVE-2025-37780)

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

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

  - Linux 核心的 netfilter: nf_tables 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。邊界鏈結的錯誤處理中存在瑕疵，可導致 NFT_MSG_NEWRULE 的中止路徑發生釋放後使用。利用此弱點需要觸發 CAP_NET_ADMIN。建議升級過去的 Commit 4bedf9eee016286c835e3d8fa981ddece5338795。(CVE-2023-3610)

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

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

  - 已解決 Linux 核心中的下列弱點：usb: typec: ucsi: Move unregister out of atomic section Commit '9329933699b3 (soc: qcom: pmic_glink: Make client-lock non-sleeping)' moved the pmic_glink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context. This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration. A side effect of this is that ucsi_unregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmic_glink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5 (CVE-2024-46691)

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

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

  - 已解決 Linux 核心中的下列弱點：ASoC: codecs: wcd934x: handle channel mappping list correctly Currently each channel is added as list to dai channel list, however there is danger of adding same channel to multiple dai channel list which endups corrupting the other list where its already added. This patch ensures that the channel is actually free before adding to the dai channel list and also ensures that the channel is on the list before deleting it. This check was missing previously, and we did not hit this issue as we were testing very simple usecases with sequence of amixer commands. (CVE-2021-47502)

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

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

  - 據發現，在 v5.1-rc6 及之前的 Linux 核心中，處理 handle_rx() 中的傳入封包時，在 vhost_net 核心模組中存在無限迴圈問題。若一端傳送封包的速度比另一端處理封包的速度還快，就可能發生此問題。客體使用者 (可能是遠端使用者) 可利用此缺陷停止 vhost_net 核心執行緒，進而導致 DoS 狀況。(CVE-2019-3900)

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

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

  - 已解決 Linux 核心中的下列弱點：gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE.
    (CVE-2024-42092)

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

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

  - 已解決 Linux 核心中的下列弱點：drivers: perf: ctr_get_width function for legacy is not defined With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n linux kernel crashes when you try perf record: $ perf record ls [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 46.750199] Oops [#1] [ 46.750342] Modules linked in: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Hardware name: riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e [46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0 [ 46.751958] gp :
    ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 :
    0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 :
    ff600000028fb000 [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004 [46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2 [ 46.753117] s2 :
    ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000 [ 46.753338] s5 : ffffffff8153e290 s6 :
    ff600000863b9000 s7 : ff60000002961078 [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10:
    0000000000000001 [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff [46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30 [ 46.754179] status: 0000000200000100 badaddr:
    0000000000000000 cause: 000000000000000c [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] note: perf-exec[107] exited with irqs disabled [ 46.755546] note: perf-exec[107] exited with preempt_count 4 This happens because in the legacy case the ctr_get_width function was not defined, but it is used in arch_perf_update_userpage. Also remove extra check in riscv_pmu_ctr_get_width_mask (CVE-2024-26796)

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

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

  - wifimt76mt7915修正 mt7915_mmio_wed_init() 中的 null-ptr-deref 錯誤 devm_ioremap() 會傳回 NULL。
    目前mt7915_mmio_wed_init() 並未檢查此情況進而導致 NULL 指標解除參照。防止 mt7915_mmio_wed_init() 中發生 null 指標解除參照。 (CVE-2025-38155)

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

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

  - Firefox 可能未正確剖析 URL並在剖析在 `embed` 標籤中指定的 URL 時將其重寫為 YouTube.com 網域。這可能會繞過網站安全性檢查，這些檢查限制了允許使用者內嵌網域的範圍。此弱點會影響 Firefox < 140、Firefox ESR < 128.12、Thunderbird < 140 和 Thunderbird < 128.12。 (CVE-2025-6429)

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

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

  - 新的 iframe 沙箱關鍵字 <code>allow-top-navigation-by-user-activation</code> 實作不當，可導致程式在沒有 <code>allow-scripts</code> 的情況下執行指令碼。此弱點會影響 Thunderbird < 91.9、Firefox ESR < 91.9 和 Firefox < 100。(CVE-2022-29911)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c Before using list_first_entry, make sure to check that list is not empty, if list is empty return -ENODATA. Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL? (CVE-2023-52678)

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

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

  - 在 72.0.3626.81 之前的 Google Chrome 中，Skia 的凸度計算不正確，遠端攻擊者因而得以透過特製的 HTML 頁面執行越界記憶體寫入。(CVE-2019-5785)

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

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

  - 已解決 Linux 核心中的下列弱點：drivers: perf: Do not broadcast to other cpus when starting a counter This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU:
    0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc :
    smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 :
    ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 :
    0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 :
    ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 :
    0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 :
    0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323339a4 (drivers: perf: Fix panic in riscv SBI mmap support) was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. (CVE-2023-52839)

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

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

  - 已解決 Linux 核心中的下列弱點：btrfs: fix removed dentries still existing after log is synced When we move one inode from one directory to another and both the inode and its previous parent directory were logged before, we are not supposed to have the dentry for the old parent if we have a power failure after the log is synced. Only the new dentry is supposed to exist.
    Generally this works correctly, however there is a scenario where this is not currently working, because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This case is better explained with the following example and reproducer: # The test requires a very specific layout of keys and items in the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported node/leaf size (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # testdir is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory testdir with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory dira, inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 (testdir) that points to # the entry named dira is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 (testdir) that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing to inode 1458 (directory dira). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. So for the sake of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is th ---truncated--- (CVE-2021-47072)

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

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

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

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

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

  - 在 0.11.1 之前的 Wikimedia Parsoid 和 0.12.x 之前的 0.12.2中發現一個問題。攻擊者可使用 <meta> 標籤繞過清理步驟並可能允許 XSS 傳送特製的 wikitextUtils/WTUtils.php 將轉換該 wikitext。 (CVE-2021-30458)

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

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

  - cifs修正 SMB2_negotiate() 中的小型 mempool 洩漏。在 SMB2_negotiate() 中某些失敗 (方言不相符) 的情況下傳送要求之後檢查應該設定 rc = -EIO 並跳至 時才會傳回 -EIO neg_exit 從 mempool 釋放回應緩衝區。 (CVE-2022-49938)

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

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

  - 已解決 Linux 核心中的下列弱點：cachefiles: defer exposing anon_fd until after copy_to_user() succeeds After installing the anonymous fd, we can now see it in userland and close it. However, at this point we may not have gotten the reference count of the cache, but we will put it during colse fd, so this may cause a cache UAF. So grab the cache reference count before fd_install().
    In addition, by kernel convention, fd is taken over by the user land after fd_install(), and the kernel should not call close_fd() after that, i.e., it should call fd_install() after everything is ready, thus fd_install() is called after copy_to_user() succeeds. (CVE-2024-40913)

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

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

  - x86/sgx防止嘗試回收受害頁面 TL;DR: SGX 頁面回收會接觸頁面以將其內容複製到次要儲存裝置。SGX 指示未適當處理機器檢查。儘管如此現有的 SGX 程式碼仍會嘗試回收它知道已感染的頁面。甚至避免嘗試回收受毒害的頁面。詳細資訊enclave 使用的頁面只會在 arch_memory_failure() 中取得 epc_page->poison 集但目前在 sgx_encl_release() 之前它們會停留在 sgx_active_page_list 上且 SGX_EPC_PAGE_RECLAIMER_TRACKED 旗標不受影響。回收程式邏輯中並未檢查 epc_page->poison這表示如果符合其他條件則會嘗試回收遭到破壞的 EPC 頁面。這很糟糕因為 1.我們不希望該頁面最後被新增到另一個 enclave 以及 2.這可能會造成一個核心關機及核心錯誤。具體而言回收使用包含 EWB 的微碼作業其會存取 EPC 頁面內容以加密並將其寫出至非 SGX 記憶體。這些作業只能將執行中的核心置於特殊的關機狀態 (使用 HT 影響兩個執行緒) 才能處理其存取中的 MCE。隨後在其餘核心上發現核心未進入 中的 MCE 處置程式之核心時間。呼叫 sgx_unmark_page_reclaimable()從 sgx_active_page_list on memory 錯誤中移除受影響的 EPC 頁面以停止考慮對其進行回收。測試 sgx_reclaim_pages() 中的 epc_page->poison 亦可運作但我假設還是在不太可能的路徑新增程式碼比較好。受影響的 EPC 頁面在執行 EREMOVEd 時直到稍後在 sgx_encl_release()->sgx_free_epc_page() 中之後才會新增至 &node->sgx_poison_page_list。其他清單上的成員資格不會變更以避免變更任何清單的語意 (sgx_active_page_list 除外)。在 arch_memory_failure() 中有一個有關先佔式動作的待定註解其目的並非解決其可能隱含的所有問題。當記憶體錯誤通知將是嚴重的 (對於之前未毒害的 EPC 頁面) 時這也不會完全關閉時間範圍 -- MCE 可能發生在 sgx_reclaim_pages() 已選取其候選者之後甚至「內部」微碼作業 ( sgx_unmark_page_reclaimable() 中的 spinlock 是安全的因為 memory_failure() 在處理程序內容中執行且沒有保留任何 spinlocks這點在 mm/memory-failure.c 註解中有明確說明。
    (CVE-2025-38334)

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

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

  - 到 1.32.1 的 MediaWiki 具有不正確的存取控制。暴露隱藏的使用者名稱或 Special:EditTags。已在 1.32.2、 1.31.2、 1.30.2 和 1.27.6中修正。 (CVE-2019-12469)

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

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

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

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

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

  - pppol2tp_connect 中可能存在記憶體損毀，這是釋放後使用所致。這可能會導致本機特權提升，並需要系統執行權限。 不需使用者互動即可惡意利用。產品：Android。版本：Android 核心。Android ID：A-38159931。(CVE-2018-9517)

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

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

  - Windows 和 Linux 版 NVIDIA GPU 顯示驅動程式的核心模式層處理常式中有一個弱點，即未正確檢查記憶體權限。攻擊者可利用此弱點造成拒絕服務和資料竄改。(CVE-2023-0181)

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

ID	名稱	嚴重性
244433	Linux Distros 未修補的弱點：CVE-2023-52807	high
244432	Linux Distros 未修補的弱點：CVE-2020-36477	medium
244431	Linux Distros 未修補的弱點：CVE-2022-25278	medium
244430	Linux Distros 未修補的弱點：CVE-2022-50064	high
244429	Linux Distros 未修補的弱點：CVE-2022-49018	medium
244428	Linux Distros 未修補的弱點：CVE-2025-21977	medium
244427	Linux Distros 未修補的弱點：CVE-2024-39338	high
244426	Linux Distros 未修補的弱點：CVE-2025-38048	medium
244425	Linux Distros 未修補的弱點：CVE-2023-52875	medium
244424	Linux Distros 未修補的弱點：CVE-2024-26985	high
244423	Linux Distros 未修補的弱點：CVE-2017-18222	high
244422	Linux Distros 未修補的弱點：CVE-2025-37833	medium
244421	Linux Distros 未修補的弱點：CVE-2011-5327	critical
244420	Linux Distros 未修補的弱點：CVE-2018-1093	medium
244419	Linux Distros 未修補的弱點：CVE-2025-37879	high
244418	Linux Distros 未修補的弱點：CVE-2022-25762	high
244417	Linux Distros 未修補的弱點：CVE-2019-11761	medium
244416	Linux Distros 未修補的弱點：CVE-2024-35858	medium
244415	Linux Distros 未修補的弱點：CVE-2025-4802	high
244414	Linux Distros 未修補的弱點：CVE-2025-37781	high
244413	Linux Distros 未修補的弱點：CVE-2019-17010	high
244412	Linux Distros 未修補的弱點：CVE-2022-48963	medium
244411	Linux Distros 未修補的弱點：CVE-2024-26778	medium
244410	Linux Distros 未修補的弱點：CVE-2022-49834	high
244409	Linux Distros 未修補的弱點：CVE-2023-3776	high
244408	Linux Distros 未修補的弱點：CVE-2025-38279	high
244407	Linux Distros 未修補的弱點：CVE-2019-19227	medium
244406	Linux Distros 未修補的弱點：CVE-2025-37780	high
244405	Linux Distros 未修補的弱點：CVE-2023-3610	high
244404	Linux Distros 未修補的弱點：CVE-2024-46691	medium
244403	Linux Distros 未修補的弱點：CVE-2021-47502	medium
244402	Linux Distros 未修補的弱點：CVE-2019-3900	high
244401	Linux Distros 未修補的弱點：CVE-2024-42092	medium
244400	Linux Distros 未修補的弱點：CVE-2024-26796	medium
244399	Linux Distros 未修補的弱點：CVE-2025-38155	medium
244398	Linux Distros 未修補的弱點：CVE-2025-6429	medium
244397	Linux Distros 未修補的弱點：CVE-2022-29911	medium
244396	Linux Distros 未修補的弱點：CVE-2023-52678	medium
244395	Linux Distros 未修補的弱點：CVE-2019-5785	medium
244394	Linux Distros 未修補的弱點：CVE-2023-52839	medium
244393	Linux Distros 未修補的弱點：CVE-2021-47072	medium
244392	Linux Distros 未修補的弱點：CVE-2023-22084	medium
244391	Linux Distros 未修補的弱點：CVE-2021-30458	medium
244390	Linux Distros 未修補的弱點：CVE-2022-49938	medium
244389	Linux Distros 未修補的弱點：CVE-2024-40913	medium
244388	Linux Distros 未修補的弱點：CVE-2025-38334	medium
244387	Linux Distros 未修補的弱點：CVE-2019-12469	medium
244386	Linux Distros 未修補的弱點：CVE-2022-21641	medium
244385	Linux Distros 未修補的弱點：CVE-2018-9517	medium
244384	Linux Distros 未修補的弱點：CVE-2023-0181	high

偵測

Nessus 的 Misc. 系列

high

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

critical

medium

high

high

medium

medium

high

high

high

medium

medium

high

high

high

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high