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

  - 已解決 Linux 核心中的下列弱點：crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up. This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*]. [*] Is this a bug in aesni-intel_glue.c? The s390x oops looks something like: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE.
    AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390] (CVE-2023-53599)

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

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

  - ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK:
    ffff974a676dcd00 CPU: 67 COMMAND: defragfs.ocfs2 #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [例外狀況 RIPjbd2_journal_dirty_metadata+0x2ba] RIPffffffffc09ca54a RSP
    ffffb25d8dad3b70 RFLAGS00010207 RAX 0000000000000000 RBXffff9706eedc5248 RCX0000000000000000 RDX
    0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13:
    0000000000000000 R14ffff9703de59bf60 R15ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty@ffffffad2]3 [befffb95 #8 [ocfsdfad23] 3 [beffffad23]
    __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e (ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock())'. 針對此錯誤在重組時ocfs2_split_extent() 會呼叫 jbd2_journal_restart()。如何修正針對 ocfs2_split_extent() 可以完全自行處理日誌作業。呼叫者不需要呼叫日誌存取/已變更組且呼叫者只需要呼叫日誌開始/停止組。修正方法是從 __ocfs2_move_extent() 中移除日誌存取/變更項目。此修補程式的討論
    https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html (CVE-2023-53564)

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

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

  - 在處理 MPEG-DASH 資訊清單時計算內容路徑時發生超出邊界 NULL 位元組在超出緩衝區結尾一個位元組的情況下寫入。當我們呼叫 [0] 之下的 xmlNodeGetContent 時它會傳回精確配置至 的緩衝區在內部使用 strdup 比對字串長度。如果此緩衝區不是空字串系統會將其指派給 [1] 的 root_url。如果此緩衝區中的最後一個 (非 NUL) 位元組不是「/」則我們會在 [2] 就地附加「/」。這會將兩個位元組寫入緩衝區從緩衝區中的最後一個有效位元組開始寫入超出配置緩衝區結尾處的 NULL 位元組。建議升級至 8.0 版或更新版本。 (CVE-2025-59728)

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

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

  - zram修正插槽寫入爭用情形對相同 zram 索引的並行並行寫入導致洩漏的 zsmalloc 控點。基本上我們可以有類似這樣的內容 CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle (handle) zram_slot_lock CPU0 或 CPU1 zsmalloc 處置程式將會洩漏因為 zs_free() 太早完成。實際上我們必須在設定 zram 項目的新控制代碼前立即重設該項目所有這些都在相同的插槽鎖定範圍內。 (CVE-2025-39941)

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

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

  - drm/amdgpu放置 gfx_v11_0_cp_ecc_error_irq_funcsgfx11 中的 gfx.cp_ecc_error_irq 已淘汰。在 gfx_v11_0_hw_fini 中仍使用 amdgpu_irq_put 來停用此中斷進而造成此函式中的呼叫追踪。 [ 102.873958] 呼叫追踪 [ 102.873959] <TASK> [ 102.873961] gfx_v11_0_hw_fini+0x23/0x1e0 [amdgpu] [ 102.874019] gfx_v11_0_suspend+0xe/0x20 [amdgpu] [ 102.874072] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu] [ 102.874122] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 102.874172] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu] [ 102.874223] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu] [ 102.874321] amdgpu_debugfs_reset_work+0x4 [c/070] [c/070] 102.874375] process_one_work+0x21f/0x3f0 [ 102.874377] worker_thread+0x200/0x3e0 [ 102.874378] ? process_one_work+0x3f0/0x3f0 [ 102.874379] kthread+0xfd/0x130 [ 102.874380] ? kthread_complete_and_exit+0x20/0x20 [ 102.874381] ret_from_fork+0x22/0x30 v2 - 處理個別修補程式中的 umc 和 gfx ras 案例 - 淘汰 gfx11 v3 中的 gfx_v11_0_cp_ecc_error_irq_funcs - 改善主旨和程式碼註解 - 新增函式中 gfx11 的判斷amdgpu_gfx_ras_late_init v4- 中斷 CP_ME1_PIPE_INST_ADDR_INTERVAL 和 SET_ECC_ME_PIPE_STATE 的定義其在 gfx_v11_0_set_cp_ecc_error_state 中使用 - 檢查 cp_ecc_error_irq.funcs 而非 ip 版本以獲得更可持續的生命 v5- 簡化判斷條件 (CVE-2023-53628)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915/perf: add sentinel to xehp_oa_b_counters Arrays passed to reg_in_range_table should end with empty record. The patch solves KASAN detected bug with signature: BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] Read of size 4 at addr ffffffffa1555d90 by task perf/1518 CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1 Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023 Call Trace: <TASK> ... xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] (cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798) (CVE-2023-53646)

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

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

  - ext4修正 ext4_fc_record_regions() 中潛在的記憶體洩漏因為 krealloc 可能傳回 NULL在此情況下「state->fc_regions」可能不會由 krealloc 釋放但「state->fc_regions」已經設定 NULL。然後會導致 'state->fc_regions' 記憶體洩漏。 (CVE-2022-50512)

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

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

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: Take RTNL lock when needed before calling xdp_set_features() Hold RTNL lock when calling xdp_set_features() with a registered netdev, as the call triggers the netdev notifiers. This could happen when switching from uplink rep to nic profile for example. This resolves the following call trace: RTNL: assertion failed at net/core/dev.c (1953) WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80 Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded:
    ib_uverbs] CPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 RIP: 0010:call_netdevice_notifiers_info+0x7c/0x80 Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff <0f> 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec RSP: 0018:ffff8882a21c3948 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027 RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0 RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003 R10:
    ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968 R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0 FS: 00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x79/0x120 ? call_netdevice_notifiers_info+0x7c/0x80 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? call_netdevice_notifiers_info+0x7c/0x80 ? call_netdevice_notifiers_info+0x7c/0x80 call_netdevice_notifiers+0x2e/0x50 mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core] mlx5e_nic_init+0xf1/0x1a0 [mlx5_core] mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core] mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core] mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core] mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]
    __esw_offloads_unload_rep+0x52/0x60 [mlx5_core] mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core] esw_offloads_unload_rep+0x34/0x70 [mlx5_core] esw_offloads_disable+0x2b/0x90 [mlx5_core] mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core] mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core] ? devlink_get_from_attrs_lock+0x9e/0x110 devlink_nl_cmd_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x17d/0x2b0 ? devlink_get_from_attrs_lock+0x110/0x110 ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290 ? devlink_pernet_pre_exit+0xf0/0xf0 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x232/0x4a0 sock_sendmsg+0x38/0x60 ?
    _copy_from_user+0x2a/0x60 __sys_sendto+0x110/0x160 ? __count_memcg_events+0x48/0x90 ? handle_mm_fault+0x161/0x260 ? do_user_addr_fault+0x278/0x6e0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033 ---truncated--- (CVE-2023-53632)

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

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

  - srcu如果使用 SRCU_SIZE_SMALL則將工作委派給開機 cpu 提交 994f706872e6 (srcu使樹狀結構 SRCU 能夠在沒有 snp_node 陣列的情況下運作) 假設 cpu 0 永遠在線。不過確實有其他 CPU 是開機 CPU 的情況例如以 maxcpus=1 開機參數啟動 kdump 核心時。在 PowerPC 上kdump 核心可能會懸置... [ 1.740036] systemd[1]
    主機名稱設定為 <xyz.com> [ 243.686240] 資訊systemd:1 工作被封鎖超過 122 秒。 [243.686264] 未受污染的 6.1.0-rc1 #1 [ 243.686272] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此訊息。 [ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000 [243.686296] 呼叫追踪[ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (不可靠) [ 243.686317] [c00000001665] [c00000001001dec0] __switch_to+0x130/0x220 [ 243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580 [ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140 [ 243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+ 0x168/0x1c0 [ 243.686374] [c000000016657a80] [c000000010f61de8]
    __wait_for_common+0x148/0x360 [ 243.686387] [c000000016657b20] [c000000010176bb0]
    __flush_work.isra.0+0x1c0/0x3d0 [ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40 [ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160 [ 243.686428] [c000000016657c40] [c0000000105f6500] inotify_release +0x30/0xa0 [ 243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350 [243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170 [ 243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140 [ 243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270 [ 243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180 [ 243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280 [ 243.686520] -- - interrupt: 3000 at 0x7fffa47d5ba4 [ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000 [ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1) [ 243.686548] MSR: 800000000000d033<SF,EE,PR,ME,IR,DR,RI,LE> CR
    42044440 XER: 00000000 [ 243.686572] IRQMASK: 0 [ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000 [ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001 [ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000 [ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR20:
    0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000 [ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570 [ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98 [ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4 [ 243.686691] LR [0000000000000000] 0x0 [ 243.686698] ---中斷3000 [ 243.686708] 資訊kworker/u16:1:24 工作封鎖超過 122 秒。 [ 243.686717] 未受污染的 6.1.0-rc1 #1 [ 243.686724] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此訊息。 [ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800 [ 243.686747] 工作佇列events_unbound fsnotify_mark_destroy_workfn [ 243.686758] 呼叫追踪[ 243.686762] [c0000000166736e0] [c00000004fd91000 ] 0xc00000004fd91000 (不可靠) [ 243.686775] [c0000000166738d0] [c00000001001dec0]
    __switch_to+0x130/0x220 [ 243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x
    ---truncated--- (CVE-2023-53671)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf, cpumap: Handle skb as well when clean up ptr_ring The following warning was reported when running xdp_redirect_cpu with both skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events
    __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ?
    __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150
    __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The reason for the warning is twofold. One is due to the kthread cpu_map_kthread_run() is stopped prematurely. Another one is __cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be fixed by the preceding patch and ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But as the comments in __cpu_map_ring_cleanup() said, handling and freeing skbs in ptr_ring as well to catch any broken behaviour gracefully. (CVE-2023-53660)

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

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

  - netcdc_ncm處理過小的 dwNtbOutMaxSize 目前在 cdc_ncm_check_tx_max() 中如果 dwNtbOutMaxSize 小於計算的最小值但大於零邏輯會將 tx_max 設定為 dwNtbOutMaxSize。然後這會用來在 cdc_ncm_fill_tx_frame() 中處理所有資料的位置配置新的 SKB。針對較小的 dwNtbOutMaxSize 值由於在配置時對齊大小的方式size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));因此我們以認可 2be6d4d16a084 (netcdc_ncm允許將 dwNtbOutMaxSize 取消設定或為零) 遇到了相同的錯誤。dwNtbOutMaxSize 的值過低目前不會造成問題因為在 alloc_skb() 時間會使用更多的記憶體 (512b)比單獨為 SKB 標頭所需的空間 (320b)留下一些空間 (512b - 320b = 192b) 給 CDC 資料 (172b)。但是，如果將更多元素 (例如 3 x u64 = [24b]) 新增至其中一個 SKB 標頭結構 (例如「struct skb_shared_info」)其原始大小 (320b [320b 對齊]) 就會增加至更大 (344b [384b aligned])則 CDC 資料 (172b) 突然無法再放入備用 SKB 資料區 (512b - 384b = 128b)。因此 SKB 邊界檢查語意會失敗並發生錯誤
    skbuffskb_over_panictext:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[cut here ]----- ------- net/core/skbuff.c:113! 的核心錯誤無效 opcode0000 [#1] PREEMPT SMP KASAN CPU0 PID 57 Commkworker/0:2 未受污染的 5.15.106-syzkaller-00249-g19c0ed55a470 #0 硬體名稱 Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 4 月 14 日 工作佇列mld mld_ifc_work RIP0010:skb_panic net/core/skbuff.c:113 [內嵌] RIP0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118 [snip] 呼叫追踪 <TASK> skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [內嵌] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [內嵌] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers /net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100 處理過低的 dwNtbOutMaxSize 值將其限制在 [USB_CDC_NCM_NTB_MIN_OUT_SIZE、CDC_NCM_NTB_MAX_SIZE_TX] 的範圍內。我們確保 dwNtbOutMaxSize 不小於 USB_CDC_NCM_NTB_MIN_OUT_SIZE以確保已配置足夠的資料空間來處理 CDC 資料。
    (CVE-2023-53667)

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

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

  - bnxt避免 bnxt_get_nvram_directory() 中發生溢位。因為在執行算術之前無法將運算元轉換為較大的資料類型因此算術運算式的值可能容易溢位。
    使用巨集進行乘法而非運算子來避免溢位。由安全性程式碼及 Linux 驗證中心 (linuxtesting.org) 的 SVACE 發現。 (CVE-2023-53661)

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

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

  - 已解決 Linux 核心中的下列弱點：RDMA/rxe: Fix mr->map double free rxe_mr_cleanup() which tries to free mr->map again will be called when rxe_mr_init_user() fails: CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe] __rxe_cleanup+0x10a/0x1e0 [rdma_rxe] rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe] ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs] This issue was firstly exposed since commit b18c7da63fcb (RDMA/rxe: Fix memory leak in error path code) and then we fixed it in commit 8ff5f5d9d8cf (RDMA/rxe: Prevent double freeing rxe_map_set()) but this fix was reverted together at last by commit 1e75550648da (Revert RDMA/rxe: Create duplicate mapping tables for FMRs) Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is successfully allocated. (CVE-2022-50543)

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

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

  - 已解決 Linux 核心中的下列弱點：nvme-core: fix dev_pm_qos memleak Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to avoid following kmemleak:- blktests (master) # kmemleak-clear; ./check nvme/044; blktests (master) # kmemleak-scan ; kmemleak-show nvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124s unreferenced object 0xffff888110c46240 (size 96): comm nvme, pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53670)

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

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

  - dmaenginetik3-udma重設 UDMA_CHAN_RT 位元組計數器以防止溢位 UDMA_CHAN_RT_*BCNT_REG 儲存即時通道位元組計數統計資料。這些暫存器是 32 位元硬體計數器且驅動程式會使用這些計數器來監控通道的作業進度狀態在傳輸超過 4GB 的資料時據發現這些計數器會溢位且作業的完成計算會受到影響且傳輸懸置無限期。此認可會新增變更以減少每個完整交易的位元組計數因此這些暫存器將永遠不會溢位且 RT 計數器會針對進行中的交易維持適當的位元組計數統計資料。舊版 uc->bcnt 用於維護驅動程式端的已完成位元組計數由於 RT 計數器現在會維護目前交易的統計資料因此不需要維護 uc->bcnt。 (CVE-2022-50541)

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

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

  - ext4修正「ext4_evict_inode」中的未初始化值。Syzbot 發現下列問題
    ================================================== === 錯誤KMSANext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c 中的 uninit-value 664 iput_final fs/inode.c:1747 [內嵌] iput+0x985/0xdd0 fs/inode.c:1773
    __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0/named_dnodatfarm c:3992 [內嵌]
    __se_sys_mknodat fs/namei.c:3989 [內嵌] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [內嵌] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common .c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit 的建立於 __alloc_pages+0x9f1/ 0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [內嵌] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c 1992 [內嵌] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [內嵌] slab_alloc_node mm/slub.c:3364 [內嵌] slab_alloc mm/slub.c:3406 [內嵌] __kmem_cache_alloc_lru mm/slub.c:3413 [內嵌] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [內嵌] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode +0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/ino de.c:1018 [內嵌] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+ 0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [內嵌] __se_sys_mkdirat fs/namei.c:4073 [內嵌] __ia32_sys_mkdirat+0xc4/0x120fs /namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [內嵌] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common。 c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU1 PID4625 通訊syz-executor.2 未受污染的 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 10/26/2022 ============================= ======================== 現在「ext4_alloc_inode()」並未初始化「ei->i_flags」。若新 inode 在「__ext4_new_inode()」中設定「ei->i_flags」之前失敗則執行「iput()」。因為在 6bc0d63dad7f 之後認可會存取「ext4_evict_inode()」中的「ei->i_flags」進而導致存取 uninit-value。若要解決上述問題只需在「ext4_alloc_inode()」中初始化「ei->i_flags」。 (CVE-2022-50546)

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: mac80211: mlme: fix null-ptr deref on failed assoc If association to an AP without a link 0 fails, then we crash in tracing because it assumes that either ap_mld_addr or link 0 BSS is valid, since we clear sdata->vif.valid_links and then don't add the ap_mld_addr to the struct. Since we clear also sdata->vif.cfg.ap_addr, keep a local copy of it and assign it earlier, before clearing valid_links, to fix this. (CVE-2022-50533)

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

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

  - ASoClpassKASAN use_after_free 超出邊界的修正當我們執行 syzkaller 時出現以下超出邊界錯誤。KASANslab-out-of-bounds Read in regcache_flat_read 以下是問題的反向追踪錯誤
    KASANtask syz-executor.4/14144 CPU 在 addr ffffff8088fbf714 發生大小 4 的 regcache_flat_read+0x10c/0x110 讀取中發生 slab-out-of-bounds CPU6 PID14144 Commsyz-executor.4 受污染GW 硬體名稱Qualcomm Technologies, Inc. sc7280 CRD 平台 (rev5+) (DT) 呼叫追踪dump_backtrace+0x0/0x4ec show_stack+0x34/0x50 dump_stack_lvl+0xdc/0x11c print_address_description+0x30/0x2d8 kasan_report+0x178/0x1e4 __asan_report_load4_noabort+0x44/0x1500 regcache_flat_description+0x1500 regcache_flat_description+0x30/0x2d8 kasan_report+0x178/0x1e4 /0x110 regcache_read+0xf8/0x5a0 _regmap_read+0x45c/0x86c _regmap_update_bits+0x128/0x290 regmap_update_bits_base+0xc0/0x15c snd_soc_component_update_bits+0xa8/0x22c snd_soc_component_write_field+0x68/0xd4 tx_macro_put_dec_enum+0x1d0/0x268 snd_ctl_elem_write+0x288/0x474 By Error checking and checking valid values issue得到修正。 (CVE-2023-53640)

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

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

  - 已解決 Linux 核心中的下列弱點：clk: Fix memory leak in devm_clk_notifier_register() devm_clk_notifier_register() allocates a devres resource for clk notifier but didn't register that to the device, so the notifier didn't get unregistered on device detach and the allocated resource was leaked. Fix the issue by registering the resource through devres_add(). This issue was found with kmemleak on a Chromebook. (CVE-2023-53674)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/huge_memory: do not clobber swp_entry_t during THP split The following has been observed when running stressng mmap since commit b653db77350c (mm: Clear page->private when splitting or migrating a page) watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xas_descend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS:
    00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI:
    ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14:
    0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3:
    00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xas_load+0x3a/0x50
    __filemap_get_folio+0x80/0x370 ? put_swap_page+0x163/0x360 pagecache_get_page+0x13/0x90
    __try_to_reclaim_swap+0x50/0x190 scan_swap_map_slots+0x31e/0x670 get_swap_pages+0x226/0x3c0 folio_alloc_swap+0x1cc/0x240 add_to_swap+0x14/0x70 shrink_page_list+0x968/0xbc0 reclaim_page_list+0x70/0xf0 reclaim_pages+0xdd/0x120 madvise_cold_or_pageout_pte_range+0x814/0xf30 walk_pgd_range+0x637/0xa30 __walk_page_range+0x142/0x170 walk_page_range+0x146/0x170 madvise_pageout+0xb7/0x280 ? asm_common_interrupt+0x22/0x40 madvise_vma_behavior+0x3b7/0xac0 ? find_vma+0x4a/0x70 ? find_vma+0x64/0x70 ? madvise_vma_anon_name+0x40/0x40 madvise_walk_vmas+0xa6/0x130 do_madvise+0x2f4/0x360 __x64_sys_madvise+0x26/0x30 do_syscall_64+0x5b/0x80 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? common_interrupt+0x8b/0xa0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines. The intent of commit b653db77350c patch was to avoid the case where PG_private is clear but folio->private is not-NULL. However, THP tail pages uses page->private for swp_entry_t if folio_test_swapcache() as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value. (CVE-2022-50517)

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path.
    (CVE-2022-50537)

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

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

  - bpf、sockmap修正當 msg 具有more_data 時重複的 sock_put() 呼叫在 tcp_bpf_send_verdict() 重新導向中傳送 apply_bytes 資料後 eval 變數會指派給 __SK_REDIRECT如果 msg 具有more_data則會多次呼叫 sock_put()。我們應在每次啟動more_data 時將 eval 變數重設為 __SK_NONE。這會導致： IPv4：嘗試釋放狀態 1 中的 TCP 通訊端 00000000b4c925d7
    ------------[在此處切入]------------ refcount_t在 0 上加法運算釋放後使用。警告 CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_sature+0x7d/0x110 連結於的模組CPU: 5 PID: 4482 Comm
    sockhash_bypass Kdump已載入 未受污染 6.0.0 #1 硬體名稱Red Hat KVM、BIOS 1.11.0-2.el7 04/01/2014 呼叫追踪 <TASK> __tcp_transmit_skb+0xa1b/0xb90 __alloc_skb+0x8c/0x1a0 ?
    __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410?0x260/0x410 preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50536)

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

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

  - 已解決 Linux 核心中的下列弱點：tcp: fix skb_copy_ubufs() vs BIG TCP David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy using hugepages, and skb length bigger than ~68 KB. skb_copy_ubufs() assumed it could copy all payload using up to MAX_SKB_FRAGS order-0 pages. This assumption broke when BIG TCP was able to put up to 512 KB per skb. We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45 and limit gso_max_size to 180000. A solution is to use higher order pages if needed. v2: add missing __GFP_COMP, or we leak memory. (CVE-2023-53669)

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

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

  - wifiath6kl減少回呼中 dev_dbg() 的 WARN。出現已知爭用情形時會觸發警告且已正確處理且上述測試的程式碼中有所記錄。使用 WARN() 會妨礙自動化測試。
    降低嚴重性。 (CVE-2023-53639)

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

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

  - tun修正卸離 NAPI 佇列的記憶體洩漏。 syzkaller 報告 [0] 與 TUN 裝置相關的 sk 和 skb 記憶體洩漏且無重現但是我們可以使用以下命令輕鬆重現該洩漏struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, /dev/net/tun, O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE
    ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP
    ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)) close(fd_tun);如果我們在 TUN 裝置上啟用 NAPI 和多重佇列我們可以在卸離佇列之後將 skb 放入 tfile->sk.sk_write_queue。我們應該在將 skb 排入佇列之前檢查 tfile->detached以防此問題。請注意這必須在 tfile->sk.sk_write_queue.lock 下完成因為 write() 和 ioctl(IFF_DETACH_QUEUE) 可以並行執行。否則會發生小型爭用視窗write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tfile->detached = tun | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb) 另一個解決方案是在關閉並重新附加卸離的佇列時呼叫 tun_queue_purge()但這可能會掩飾其他問題。此外我們還對 IFF_NAPI_FRAGS 進行了相同類型的測試。 [0]未參照的物件 0xffff88801edbc800 (大小 2048)comm syz-executor.1、pid 33269、jiffies 4295743834 (18.756 秒) 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 00 00 00 000 00 00 00 0 00 00 00 ........ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ........... . backtrace[<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [內嵌] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [內嵌] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c 3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c 920 [<000000008eb24774>] do_open fs/namei.c:3636 [內嵌] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [內嵌] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [內嵌] [<00000000057be699>] __se_sys_openat fs /open.c:1383 [內嵌] [<00000000057be699>]
    __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c 80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc 未參照物件 0xffff88802f671700 (大小 240)comm syz-executor.1, pid 33269, jiffies 4295743854 (18.736s) 十六進位轉儲存 (前 32 個位元組)8068 ff c9 db 1e ff 68 c9 db 1e 80 88 ff ff h........h........ 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/. .. backtrace[<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+ 0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [內嵌] [< ---truncated--- (CVE-2023-53685)

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

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

  - 已解決 Linux 核心中的下列弱點：tipc: fix a null-ptr-deref in tipc_topsrv_accept syzbot found a crash in tipc_topsrv_accept: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP:
    0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 It was caused by srv->listener that might be set to null by tipc_topsrv_stop() in net .exit whereas it's still used in tipc_topsrv_accept() worker. srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop() where it's waiting until the tipc_topsrv_accept worker to be done. Note that sk_callback_lock is used to protect sk->sk_user_data instead of srv->listener, and it should check srv in tipc_topsrv_listener_data_ready() instead. This also ensures that no more tipc_topsrv_accept worker will be started after tipc_conn_close() is called in tipc_topsrv_stop() where it sets sk->sk_user_data to null. (CVE-2022-50555)

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

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

  - 已解決 Linux 核心中的下列弱點：ext4: fix possible double unlock when moving a directory (CVE-2023-53626)

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

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

  - blk-iolatency修正 add_disk() 失敗時發生的記憶體洩漏當 gendisk 初始化成功但 add_disk() 失敗 (例如迴圈裝置指定了無效的次要裝置編號時) 在 init 和 blkcg_exit_disk() 期間系統會呼叫 blkcg_init_disk() ) 期間發生錯誤處理。遺憾的是前者會初始化 iolatency但後者不會清除 iolatency。這是因為在非錯誤情況下清理是由 del_gendisk() 呼叫 rq_qos_exit() 執行且假設 rq_qos 原則 (iolatency 是其中之一) 只有在磁碟完全註冊且可見時才能啟動。此假設適用於 wbt 和 iocost但不適用於 iolatency 因為它會在呼叫 add_disk() 之前初始化。最好消極初始化 rq_qos 原則因為這些原則是選用的功能一旦初始化就會增加熱路徑負荷每個 IO 都必須執行所有已註冊的 rq_qos 原則。因此我們也想要將 iolatency 切換至消極 init。不過這是較大的變更。作為直接問題的修正讓我們在 blkcg_exit_disk() 中新增一個額外的 rq_qos_exit() 呼叫。這是安全的因為重複的 rq_qos_exit() 呼叫會變成 noop。 (CVE-2022-50550)

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

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

  - drm/amdgpu修正非獨占網域的大小驗證 (v4) 修正 amdgpu_bo_validate_size()以檢查所要求記憶體的 TTM 網域管理員是否存在否則我們在解除參照 man 時會收到核心 oops。 v2使修補程式獨立運作即不依賴本機修補程式。 v3保留舊行為並只檢查管理員指標是否為 NULL。 v4投訴 GTT 網域且其未初始化--most 可能是錯誤。 (CVE-2022-50527)

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

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

  - btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 [錯誤] Syzbot 報告在 lookup_inline_extent_backref() 內觸發了數個警告。[原因] 照慣例重現器無法在此處可靠地觸發但至少我們知道 WARN_ON() 會在找不到內嵌反向參照時觸發且它只能在 @insert 為 true 時觸發。(即插入新的內嵌反向參照這表示反向參照應該已經存在) [增強] 在 WARN_ON() 之後轉儲存所有參數和範圍樹狀結構分葉以協助除錯。 (CVE-2023-53672)

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

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

  - blk-mq重新初始化佇列時使用靜止的提升切換重新初始化硬體佇列時hctx 的 run_work 可能與提升切換爭用。佇列只是在此內容中凍結但這只會防止要求配置且不會停止執行 hctx 工作。工作可能會取得即將卸除的提升指標且可能導致釋放後使用錯誤和核心錯誤 (範例如下)。改用停頓的承載交換器並讓先前的承載交換器變成靜態的因為它現在僅用於本機。 nvme nvme0重設控制器 nvme nvme032/0/0 default/read/poll 佇列錯誤
    核心 NULL 指標解除參照、位址0000000000000008 #PF核心模式中的監督讀取存取問題 #PF
    error_code(0x0000) - 不存在頁面 PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops
    0000 [#1] SMP PTI Workqueuekblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... 呼叫追踪：
    __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/CVE-2022-505520x380e worker_

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

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

  - ring-buffer修正讀取 trace_pipe 時的死迴圈問題。讀取檔案 'trace_pipe' 時發生軟鎖定
    看門狗錯誤軟鎖定 - CPU#6 停滯 22 秒[cat:4488] [...] RIP
    0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI:
    ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15:
    0000000000000000 [...] CS0010 DS0000 ES0000 CR00000000080050033 CR200007f8d853c2000 CR3
    000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
    __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ?
    __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 我透過 vmcore 發現這是因為在 tracing_read_pipe()ring_buffer_empty_cpu() 中發現某些緩衝區不是空的但隨後因為 rb_num_of_entries() == 而無法讀取任何內容0 總是 true然後因為使用者緩衝區尚未填滿而使程序無限迴圈請參閱下列程式碼路徑tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. 在此尋找非空白緩衝區 trace_find_next_entry_inc( ) // 2. 在此迴圈嘗試尋找項目 __find_next_entry() ring_buffer_empty_cpu(); // 3. 尋找非空白緩衝區 peek_next_entry() // 4. 但 peek 一律傳回 NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. 因為 rb_num_of_entries() == 0 此處一律為 true // 然後傳回 NULL / / 6. 使用者緩衝區尚未填滿因此前往「waitgain」// 並最終導致核心中出現死迴圈透過分析我發現重設 ringbuffer 時其頁面的「項目」並未全部清除 (請參閱 rb_reset_cpu())。然後在減少 ringbuffer 時如果某些減少的頁面存在已變更的「項目」資料則會將其新增至「cpu_buffer->overrun」(請參閱 rb_remove_pages())其會造成錯誤的「overrun」計數最終造成死迴圈問題。若要修正此問題我們需要清除 rb_reset_cpu() 中的每個頁面。 (CVE-2023-53668)

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

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

  - 驅動程式hvvmbus不解除參照 ACPI root 物件處理自從 中參照的認可
    VMBus 用戶端驅動程式之下的標籤會將 ACPI 命名空間從 VMBus ACPI 裝置向上走至 ACPI 命名空間 root 物件以嘗試尋找 Hyper-V MMIO 範圍。但是如果無法找到它們則會結束嘗試執行 ACPI 命名空間 root 物件本身的資源。此物件具有 all-ones 控點其可造成 ACPI 程式碼中發生 NULL 指標解除參照 (來自此具有位移的指標解除參照)。這進而造成使用在其 VMBus ACPI 裝置或其上階中未提供 Hyper-V MMIO 範圍的 VMBus 主機實作開機時發生 oops。QEMU VMBus 實作即為此類實作的範例。我猜想是否提供這些範圍是選擇性的因為所有經過測試的 Windows 版本在沒有這些範圍的情況下似乎都能使用 VMBus 裝置。透過明確終止 ACPI 命名空間 root 物件的查閱來修正此問題。請注意KVM/QEMU 下的 Linux 來賓預設不使用 Hyper-V PV 介面只有在 KVM PV 介面遺漏或停用時才會使用。此類 oops 的範例堆疊追踪 [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0 [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200 [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0 [ 3.723559] down_timeout+0x3a/0x60 [ 3.724455] ? acpi_ns_get_node+0x3a/0x60 [ 3.725412] acpi_ns_get_node+0x3a/0x60 [ 3.726335] acpi_ns_evalulate+0x1c3/0x2c0 [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0 [ 3.728400] acpi_rs_get_method_data+0x2b/0x70 [ 3.729476] ] vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.730940] vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.732411] acpi_walk_resources+0x78/0xd0 [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus] [ 3.734802] platform_probe+0x3d/0x90 [ 3.735684] real_probe+0x19b/0x400 [ 3.736570] ?
    __device_attach_driver+0x100/0x100 [ 3.737697] __driver_probe_device+0x78/0x160 [ 3.738746] driver_probe_device+0x1f/0x90 [ 3.739743] __driver_attach+0xc2/0x1b0 [ 3.740671] bus_for_each_dev+0x70/0xc0 [ 3.741601] bus_add_driver+0x10e/0x [ 3.742527] driver_register+0x55/0xf0 [3.744412] ? 0xffffffffc039a000 [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus] (CVE-2023-53647)

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

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

  - 已解決 Linux 核心中的下列弱點：net/handshake: fix null-ptr-deref in handshake_nl_done_doit() We should not call trace_handshake_cmd_done_err() if socket lookup has failed.
    Also we should call trace_handshake_cmd_done_err() before releasing the file, otherwise dereferencing sock->sk can return garbage. This also reverts 7afc6d0a107f (net/handshake: Fix uninitialized local variable) Unable to handle kernel paging request at virtual address dfff800000000003 KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] Mem abort info: ESR = 0x0000000096000005 EC = 0x25:
    DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfff800000000003] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193 lr :
    handshake_nl_done_doit+0x180/0x9c8 sp : ffff800096e37180 x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27:
    dfff800000000000 x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8 x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000 x20: ffff800096e371c0 x19: 0000000000000018 x18:
    0000000000000000 x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001 x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 :
    0000000000000003 x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078 x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 :
    0000000000000000 Call trace: handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193 genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline] genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549 genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg net/socket.c:748 [inline] ____sys_sendmsg+0x56c/0x840 net/socket.c:2494 ___sys_sendmsg net/socket.c:2548 [inline] __sys_sendmsg+0x26c/0x33c net/socket.c:2577
    __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline]
    __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908) (CVE-2023-53686)

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

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

  - 已解決 Linux 核心中的下列弱點：iavf: Fix out-of-bounds when setting channels on remove If we set channels greater during iavf_remove(), and waiting reset done would be timeout, then returned with error but changed num_active_queues directly, that will lead to OOB like the following logs. Because the num_active_queues is greater than tx/rx_rings[] allocated actually.
    Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf=0000:41:00.0 vf0_dbsf=0000:41:02.0 g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z $nic ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() {local pid for pid in ${g_pids[@]}; do kill -0 $pid &>/dev/null && kill $pid &>/dev/null done g_pids=() } trap on_exit; exit EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) wait Result: [ 3506.152887] iavf 0000:41:02.0: Removing device [3510.400799] ================================================================== [ 3510.400820] BUG: KASAN:
    slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536 [ 3510.400823] [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 3510.400835] Call Trace: [ 3510.400851] dump_stack+0x71/0xab [3510.400860] print_address_description+0x6b/0x290 [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400868] kasan_report+0x14a/0x2b0 [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf] [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf] [ 3510.400891] ? wait_woken+0x1d0/0x1d0 [ 3510.400895] ? notifier_call_chain+0xc1/0x130 [ 3510.400903] pci_device_remove+0xa8/0x1f0 [ 3510.400910] device_release_driver_internal+0x1c6/0x460 [ 3510.400916] pci_stop_bus_device+0x101/0x150 [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20 [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420 [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10 [ 3510.400929] ? pci_get_subsys+0x90/0x90 [ 3510.400932] sriov_disable+0xed/0x3e0 [ 3510.400936] ? bus_find_device+0x12d/0x1a0 [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e] [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 3510.400968] ? pci_get_device+0x7c/0x90 [ 3510.400970] ? pci_get_subsys+0x90/0x90 [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210 [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 3510.401001] sriov_numvfs_store+0x214/0x290 [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30 [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.401011] ?
    __check_object_size+0x15a/0x350 [ 3510.401018] kernfs_fop_write+0x280/0x3f0 [ 3510.401022] vfs_write+0x145/0x440 [ 3510.401025] ksys_write+0xab/0x160 [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0 [3510.401031] ? fput_many+0x1a/0x120 [ 3510.401032] ? filp_close+0xf0/0x130 [ 3510.401038] do_syscall_64+0xa0/0x370 [ 3510.401041] ? page_fault+0x8/0x30 [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 3510.401073] RIP: 0033:0x7f3a9bb842c0 [ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d ---truncated--- (CVE-2023-53659)

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

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

  - 已解決 Linux 核心中的下列弱點：platform/x86: dell-sysman: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned. This means that we need to dispose it accordingly. Use kobject_put() to dispose the duplicate attribute in such a case. Compile-tested only. (CVE-2023-53631)

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

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

  - dm Thin修正 shrink_slab 和 dm_pool_abort_metadata 之間的 ABBA 鎖死下列並行處理程序
    P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B
    __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) Thin_map | dm_thin_find_block down_read(&pmd->root_lock) --> ABBA 鎖死 其會觸發工作懸置[ 76.974820] 資訊kworker/u4:3:63 工作遭封鎖超過 15 秒。 [76.976019] 未受污染的 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2 [ 76.978534] Workqueue: dm- Thin do_worker [ 76.978552] 呼叫追踪 [ 76.978564]
    __schedule+0x6ba/0x10f0 [ 76.978582] schedule+0x9d/0x1e0 [ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0 [ 76.978600] down_write+0xec/0x110 [ 76.978607] unregister_shrinker+0x2c/0xf0 [ 76.978616] dm_bufio_xx30destroy+0x116/0 [ 76.978625] dm_block_manager_destroy+0x19/0x40 [ 76.978629] __destroy_persistent_data_objects+0x5e/0x70 [ 76.978636] dm_pool_abort_metadata+0x8e/0x100 [ 76.978643] metadata_operation_failed+0x86/0x110 [ 76.978649] commit+0x6a/0x230 [ 76.978655] do_worker +0xc6e/0xd90 [ 76.978702] process_one_work+0x269/0x630 [76.978714] worker_thread+0x266/0x630 [ 76.978730] kthread+0x151/0x1b0 [ 76.978772] 資訊task test.sh:2646 的封鎖時間超過 15 秒。 [ 76.979756] 未受污染的 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459 [ 76.982128] 呼叫追踪[ 76.982139]
    __schedule+0x6ba/0x10f0 [ 76.982155] schedule+0x9d/0x1e0 [ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910 [ 76.982173] down_read+0x84/0x170 [ 76.982177] dm_thin_find_block+0x4c/0xd0 [ 76.982183] Thin_map+0x201/0x3d00x [ 76.982188] __map_bio+0x5b/0x350 [ 76.982195] dm_submit_bio+0x2b6/0x930 [ 76.982202]
    __submit_bio+0x123/0x2d0 [ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0 [ 76.982222] submit_bio_noacct+0x389/0x770 [ 76.982227] submit_bio+0x50/0xc0 [ 76.982232] ] submit_bh_wbc+0x15e/0x230 [76.982238] submit_bh+0x14/0x20 submit_bh+0x14/0xc0 76.982241[  ] ext4_read_bh_nowait+0xc5/0x130 [ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60 [ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0 [ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0 [ 76.982263] ext4_discard_preallocations+0x45d/0x830 [ 76.982274] ext4_clear_inode +0x48/0xf0 [ 76.982280] ext4_evict_inode+0xcf/0xc70 [ 76.982285] evict+0x119/0x2b0 [76.982290] dispose_list+0x43/0xa0 [ 76.982294] prune_icache_sb+0x64/0x90 [ 76.982298] super_cache_scan+0x155/0x210 [ 76.982303] do_shrink_slab+0x19e/0x4e0 [ 76.982310] shrink_slab+0x2bd/0x450 [ 76.982317] drop_slab+0xcc/0x1a0 [ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0 [ 76.982327] proc_sys_call_handler+0x1bc/0x300 [ 76.982331] proc_sys_write+ 0x17/0x20 [ 76.982334] vfs_write+0x3d3/0x570 [ 76.982342] ksys_write+0x73/0x160 [ 76.982347] __x64_sys_write+0x1e/0x30 [ 76.982352] do_syscall_64+0x35/0x80 [ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd Function--truncated--- (CVE-2022-50549)

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

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

  - canj1939實作 NETDEV_UNREGISTER 通知處置程式 syzbot 報告 unregister_netdevice
    等待 vcan0 變為可用。使用量 count = 2 的問題因為 j1939 通訊協定沒有 NETDEV_UNREGISTER 通知處置程式無法復原 j1939_sk_bind() 所做的變更。認可 25fe97cb7620 (canj1939將 j1939_priv_put() 移至 sk_destruct 回呼中)預期對 j1939_priv_put() 的呼叫可無條件延遲直到呼叫 j1939_sk_sock_destruct()。但是我們必須在 NETDEV_UNREGISTER 通知觸發時 (亦即在透過 j1939_sk_release() 呼叫 j1939_sk_sock_destruct() 之前)針對 j1939_sk_bind() 呼叫所保留的額外參照執行 j1939_priv_put() (做為 j1939_sk_bind() 所進行之復原變更的一部分) 。否則 j1939_sk_bind() 呼叫保留的 struct j1939_priv 上的額外參照會防止 struct net_device 將使用量計數減少為 1。使 unregister_netdevice() 無法繼續。 [mkl移除標籤前面的空格] (CVE-2025-39925)

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

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

  - i40e移除對於 debugfs 檔案的讀取存取權。「command」和「netdev_ops」debugfs 檔案是 i40e 驅動程式從早期開始就受到認可 02e9c290814c (i40e
    debugfs interface)。這兩個 debugfs 檔案都提供多數情況下無用且是以有問題的邏輯實作的讀取處置程式。它們都使用初始化為空白字串的靜態 256 位元組緩衝區。若是「command」檔案這個緩衝區實際上從未使用過只會浪費空間。若是「netdev_ops」檔案最後寫入的命令會儲存在此處。讀取時檔案內容顯示為裝置名稱後面接著一個冒號再接著是其各自靜態緩衝區的內容。如果是 'command'則一律為 <device> 若是「netdev_ops」這將為 <device>: <last command written>。但請注意緩衝區是在此模組操作的所有裝置之間共用。充其量只是大多數無意義的資訊最糟的情況是因為似乎沒有任何鎖定機制所以可以同時存取。我們最近也收到了多個關於這兩個讀取函式的報告其有關 snprintf 的使用以及可能導致讀取任意核心記憶體的潛在溢位。對於「command」檔案這絕對是不可能的因為靜態緩衝區一律為零且從未寫入。針對「netdev_ops」檔案如果使用者特製命令輸入似乎有可能將該命令輸入複製到緩衝區大到足以造成 snprintf 截斷進而造成 copy_to_user 讀取範圍超出kzalloc 所配置的緩衝區長度。最低限度的修正是以 scnprintf() 取代 snprintf()其可限制傳回寫入的位元組數防止溢位。較複雜的修正會捨棄大部分無用的靜態緩衝區、節省 512 位元組並修改讀取函式以停止將其視為輸入的必要性。相反讓我們完全中斷這些檔案的讀取存取權。這些是作為 debugfs 一部分暴露的除錯介面而且我不認為中斷讀取存取會中斷任何指令碼因為所提供的輸出相當無用。您可以透過其他更標準的介面找到 netdev 名稱但如果您一次向多個裝置發出同步寫入則「netdev_ops」介面很容易造成無用記憶體。為了正確移除 i40e_dbg_netdev_ops_buf我們需要重構其寫入函式以避免使用靜態緩衝區。請改用與 i40e_dbg_command_write 相同的邏輯並搭配一個已配置的緩衝區。更新程式碼以使用此緩衝區而非靜態緩衝區並確保我們在結束時釋放緩衝區。
    這修正了多個裝置上同時寫入「netdev_ops」的問題並允許我們移除現已未使用的靜態緩衝區以及移除讀取存取權。 (CVE-2025-39901)

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

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

  - wifimwifiex將 chan_stats 陣列初始化為零 在 mwifiex_init_channel_scan_gap() 中使用 vmalloc() 初始化 Adapter->chan_stats[] 陣列這不會將記憶體歸零。陣列會填入 mwifiex_update_chan_statistics()然後使用者即可查詢 mwifiex_cfg80211_dump_survey() 中的資料。
    此處有兩個潛在問題。如果使用者在填入資料之前呼叫 mwifiex_cfg80211_dump_survey() 會發生什麼。此外mwifiex_update_chan_statistics() 函式不一定要初始化整個陣列。由於陣列並未在開始時初始化可導致資訊洩漏。
    此外這個陣列相當小。最多 900 個位元組因此使用 kcalloc() 而非 vmalloc() 更為適當。 (CVE-2025-39891)

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

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

  - netphylink新增鎖定以序列化使用解析器進行的並行 pl->phydev 寫入 目前 phylink_resolve() 可保護自己不受並行 phylink_bringup_phy() 或 phylink_disconnect_phy() 呼叫的影響其會依賴 pl->state_mutex 修改 pl->phydev。問題在於在 phylink_resolve() 中pl->state_mutex 處於 pl->phydev->lock 的鎖定反轉狀態。因此必須在 pl->state_mutex 之前取得 pl->phydev->lock。但這需要先將 pl->phydev 解除參照且沒有 pl->state_mutex才可能發生此問題。因此需要額外鎖定。目前此為多餘但在 mutex_lock(&phy->lock) 移至 mutex_lock(&pl->state_mutex) 區段之外時即可發揮功能性用途。其他考慮過的替代方法是讓 phylink_resolve() 取得 rtnl_mutex其也會在呼叫 phylink_bringup_phy() 和 phylink_disconnect_phy() 時保留。但由於 phylink_disconnect_phy() 在 rtnl_lock() 下執行因此在呼叫 flush_work(&pl->resolve) 時會鎖死 phylink_resolve()。此外這也會是不可取的因為它會在整個核心中不必要地封鎖許多其他呼叫路徑因此偏好較小範圍的鎖定。 (CVE-2025-39905)

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

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

  - mm/slub避免在指標在 object_err() 中無效時存取詮釋資料object_err() 報告供進一步除錯的物件詳細資料例如 freelist 指標、redzone 等。不過如果指標無效嘗試存取物件詮釋資料可能會導致當機因為它並未指向有效的物件。一個已知的當機路徑是當 alloc_consistency_checks() 判斷為已配置物件的指標因為可用清單損毀而無效並呼叫 object_err() 進行報告時。除錯程式碼應適當報告和處理損毀不會在處理程序中損毀。若指標為 NULL 或 check_valid_pointer() 針對指標傳回 false則僅列印指標值而略過存取中繼資料。 (CVE-2025-39902)

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

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

  - ceph修正套用狀態前驗證 r_parent 的爭用情形。新增驗證確保快取的父目錄 inode 符合 MDS 回覆中的目錄資訊。這可防止用戶端爭用情形 (並行作業 (例如 rename) 造成 r_parent 在要求起始和回覆處理之間過時而導致將狀態變更套用至不正確的目錄 inode)。
    [ idryomov折疊了 Alex 的 kerneldoc 修正和後續修正以在 r_parent 更新時移動 CEPH_CAP_PIN 參照。當父目錄沒有鎖定時req->r_parent 會過時並更新為指向正確的 inode。不過相關聯的 CEPH_CAP_PIN 參照並未調整。CEPH_CAP_PIN 是 inode 上的參照其出於計量目的而進行追踪。移動此針腳對於保持計量平衡非常重要。當 pin 未從舊父項移至新父項時會產生兩個問題舊的過時父項上的參照從未釋放造成參照洩漏。從未取得新父項的參照導致之後在 ceph_mdsc_release_request() 中造成參照反向溢位的風險。此修補程式在切換 r_parent 時釋出舊父項的針腳並為新父項取得針腳藉此更正邏輯。這可確保參照計量保持平衡。 ] (CVE-2025-39927)

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

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

  - pcmcia在 do_validate_mem() 中新增 add_interval() 的錯誤處理在 do_validate_mem() 中對 add_interval() 的呼叫不會處理錯誤。如果 kmalloc() 在 add_interval() 中失敗可導致 null 指標插入連結清單中進而導致下次呼叫 sub_interval() 時存取非法記憶體。此修補程式新增了 add_interval() 的錯誤處理。如果 add_interval() 傳回錯誤該函式會提早傳回錯誤碼。 (CVE-2025-39920)

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

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

  - podofo v0.10.0 到 v0.10.5 中PdfTokenizer::ReadDictionary 函式的堆積釋放後使用允許攻擊者藉由提供特製的 PDF 檔案造成拒絕服務 (DoS)。注意供應商對此存有爭議因為沒有可重現此問題的檔案。 (CVE-2025-46205)

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

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

  - [] 之前的 25.x 到 [ ] 的 Poppler 24.06.1 至 25.04.0 透過 PDF 文件之詮釋資料 (例如 GTS_PDFEVersion) 內深度巢狀結構允許堆疊消耗及 SIGSEGV例如長 pdfsubver 字串的規則運算式。Dict::lookup、Catalog::getMetadata 和 PDFDoc 的相關函式中會發生此情形導致 regex 執行程式中發生深度遞回 (std::__detail::_Executor)。 (CVE-2025-43718)

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

遠端主機上安裝的 CyberPanel 受到一個遠端程式碼執行弱點影響。在比 5b08cd6 版本舊的 CyberPanel (即 Cyber Panel) 中，位於 databases/views.py 的 upgrademysqlstatus 函數於允許遠端攻擊者繞過驗證並執行任意命令。攻擊者可藉由存取 /dataBases/upgrademysqlstatus，利用繞過 secMiddleware (僅適用於 POST 請求)，並在 statusfile 屬性中插入 Shell 詮釋字元，來達成攻擊。此弱點於 2024 年 10 月遭 PSAUX 猖獗刺探利用。
到 2.3.6 和 (未修補) 2.3.7 版受到影響。

遠端主機上安裝的 Oracle E-Business Suite 版本受到 CVE-2025-61882 安全性警示公告中提及的遠端程式碼執行弱點影響。

  - Oracle E-Business Suite 之 Oracle Concurrent Processing 產品中的弱點 (元件：BI Publisher Integration)。受影響的支援版本是 12.1.3-12.2.14。攻擊此弱點的難度較小，經由 HTTP 存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle Concurrent Processing。若攻擊成功，可導致 Oracle Concurrent Processing 被接管。(CVE-2025-61882)

Oracle 指出，2023 年 10 月重要修補程式更新是套用 CVE-2025-61882 安全性警示公告中所提供更新的先決條件。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 Oracle E-Business Suite 版本受到 2025 年 7 月 CPU 公告中所提及的多個弱點影響。

  - Oracle E-Business Suite 的 Oracle CRM Technical Foundation 產品中的弱點 (元件Preferences)。受影響的支援版本是 12.2.11-12.2.13。可輕鬆惡意利用的弱點允許具有網路存取權的高權限攻擊者透過 HTTP 來入侵 Oracle CRM Technical Foundation。雖然弱點是在 Oracle CRM Technical Foundation 中但攻擊可能對其他產品造成重大影響 (範圍變更)。成功攻擊此弱點可導致未經授權地更新、插入或刪除某些可供存取之 Oracle CRM Technical Foundation 資料的存取權以及讀取可供存取之 Oracle CRM Technical Foundation 資料子集的存取權。 (CVE-2025-30739)

  - Oracle E-Business Suite 的 Oracle Mobile Field Service 產品中的弱點 (元件多平台同步錯誤)。受影響的支援版本是 12.2.3-12.2.13。可輕鬆惡意利用的弱點允許具有網路存取權的低權限攻擊者透過 HTTP 來入侵 Oracle Mobile Field Service。成功攻擊此弱點可導致未經授權地建立、刪除或修改重要資料或所有 Oracle Mobile Field Service 可存取資料的存取權以及未經授權地存取重要資料或所有 Oracle Mobile Field Service 可存取資料的完整存取權。 (CVE-2025-30744)

  - Oracle E-Business Suite 的 Oracle Universal Work Queue 產品中的弱點 (元件要求處理)。受影響的支援版本是 12.2.5-12.2.14。此弱點較易攻擊成功，能夠透過 HTTP 存取網路的未經驗證攻擊者可藉以入侵 Oracle Universal Work Queue。若要成功攻擊必須有攻擊者以外之他人的互動且雖然弱點位於 Oracle Universal Work Queue 中但攻擊可能對其他產品造成重大影響 (範圍變更)。成功攻擊此弱點可導致未經授權地更新、插入或刪除某些可供存取之 Oracle Universal Work Queue 資料的存取權以及未經授權地讀取可供存取之 Oracle Universal Work Queue 資料的子集存取權。 (CVE-2025-50107)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Dell Repository Manager (DRM) 3.4.7 和 3.4.8版包含一個不當處理不足的權限或權限弱點。具有本機存取權的低權限攻擊者可能惡意利用此弱點進而導致權限提升。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	嚴重性
269295	Linux Distros 未修補的弱點：CVE-2023-53599	medium
269294	Linux Distros 未修補的弱點：CVE-2023-53564	medium
269293	Linux Distros 未修補的弱點：CVE-2025-59728	high
269292	Linux Distros 未修補的弱點：CVE-2025-39941	medium
269291	Linux Distros 未修補的弱點：CVE-2023-53628	medium
269290	Linux Distros 未修補的弱點：CVE-2023-53646	high
269289	Linux Distros 未修補的弱點：CVE-2022-50512	medium
269288	Linux Distros 未修補的弱點：CVE-2023-53632	medium
269287	Linux Distros 未修補的弱點：CVE-2023-53671	medium
269286	Linux Distros 未修補的弱點：CVE-2023-53660	medium
269285	Linux Distros 未修補的弱點：CVE-2023-53667	medium
269284	Linux Distros 未修補的弱點：CVE-2023-53661	high
269283	Linux Distros 未修補的弱點：CVE-2022-50543	high
269282	Linux Distros 未修補的弱點：CVE-2023-53670	medium
269281	Linux Distros 未修補的弱點：CVE-2022-50541	high
269280	Linux Distros 未修補的弱點：CVE-2022-50546	high
269279	Linux Distros 未修補的弱點：CVE-2022-50533	medium
269278	Linux Distros 未修補的弱點：CVE-2023-53640	high
269277	Linux Distros 未修補的弱點：CVE-2023-53674	medium
269276	Linux Distros 未修補的弱點：CVE-2022-50517	high
269275	Linux Distros 未修補的弱點：CVE-2022-50537	medium
269274	Linux Distros 未修補的弱點：CVE-2022-50536	medium
269273	Linux Distros 未修補的弱點：CVE-2023-53669	medium
269272	Linux Distros 未修補的弱點：CVE-2023-53639	high
269271	Linux Distros 未修補的弱點：CVE-2023-53685	medium
269270	Linux Distros 未修補的弱點：CVE-2022-50555	medium
269269	Linux Distros 未修補的弱點：CVE-2023-53626	high
269268	Linux Distros 未修補的弱點：CVE-2022-50550	medium
269267	Linux Distros 未修補的弱點：CVE-2022-50527	medium
269266	Linux Distros 未修補的弱點：CVE-2023-53672	medium
269265	Linux Distros 未修補的弱點：CVE-2022-50552	high
269264	Linux Distros 未修補的弱點：CVE-2023-53668	high
269263	Linux Distros 未修補的弱點：CVE-2023-53647	medium
269262	Linux Distros 未修補的弱點：CVE-2023-53686	high
269261	Linux Distros 未修補的弱點：CVE-2023-53659	high
269260	Linux Distros 未修補的弱點：CVE-2023-53631	high
269259	Linux Distros 未修補的弱點：CVE-2022-50549	medium
269258	Linux Distros 未修補的弱點：CVE-2025-39925	medium
269257	Linux Distros 未修補的弱點：CVE-2025-39901	high
269256	Linux Distros 未修補的弱點：CVE-2025-39891	high
269255	Linux Distros 未修補的弱點：CVE-2025-39905	high
269254	Linux Distros 未修補的弱點：CVE-2025-39902	medium
269253	Linux Distros 未修補的弱點：CVE-2025-39927	medium
269252	Linux Distros 未修補的弱點：CVE-2025-39920	medium
269251	Linux Distros 未修補的弱點：CVE-2025-46205	high
269250	Linux Distros 未修補的弱點：CVE-2025-43718	low
267930	CyberPanel < 2.3.8 RCE Direct Check (CVE-2024-51567)	critical
266696	Oracle E-Business Suite RCE (CVE-2025-61882)	critical
266466	Oracle E-Business Suite (2025 年 7 月 CPU)	high
266457	Dell Repository Manager 3.4.7 < 3.4.9 權限提升 (DSA-2025-373)	high

偵測

Nessus 的 Misc. 系列

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

high

high

medium

high

medium

high

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

high

medium

high

high

high

medium

medium

high

high

high

medium

medium

medium

high

low

critical

critical

high

high