Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ptpocp修复由 ptp_ocp_watchdog 造成的释放后使用缺陷 ptp_ocp_detach() 仅会关闭待定的监控程序定时器。但是如果定时器处理程序已在运行则不会调用 timer_delete_sync()。这会导致争用条件其中包含 ptp_ocp 的 devlink 被释放时定时器处理程序仍在访问它从而导致释放后使用缺陷。以下内容详细说明了其中一种争用情况。线程 1|线程 2ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_detach() ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | bp | devlink_free(devlink) | bp-> //使用 通过无条件调用 timer_delete_sync() 解决此问题以确保可靠地停用定时器从而防止任何释放后访问。 (CVE-2025-39859)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程 Linux 主机上安装了 Aviatrix Cloud Network Controller。

远程主机上安装的 Keycloak 版本低于 26.2.9。因此受到公告 GHSA-wc64-wmfm-46vw 和 GHSA-xmcw-mv9p-7pq2 中提及的多个漏洞的影响。

  - Windows 上 Keycloak 的 Vault 密钥处理中存在路径遍历验证缺陷。之前针对 CVE-2024-10492 的修复未考虑 Windows 文件分隔符 (\)。因此高权限管理员可通过特制的 Vault 密码查找探测是否存在预期领域上下文之外的文件。这是 的平台特定变体/不完整的修复 CVE-2024-10492。 (CVE-2025-10043)

  - 在 Keycloak 中发现一个缺陷。Keycloak 的帐户控制台和其他页面接受 error_description 查询参数中的任意文本。此文本会直接在错误页面中呈现，未经验证或审查。HTML 编码可防止 XSS 的同时攻击者可构建包含误导性消息例如假的支持电话号码或 URL 的 URL这些信息将显示在受信任的 Keycloak UI 中。这会创建钓鱼矢量可能诱骗用户联系恶意执行者。 (CVE-2025-10044)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此如公告 APSB25-88 所述远程主机上安装的 Adobe Commerce B2B 版本受到一个漏洞的影响。

  - Adobe Commerce 版本 2.4.9-alpha2、2.4.8-p2、2.4.7-p7、2.4.6-p12、2.4.5-p14、2.4.4-p15 及更早版本会受到不当输入验证漏洞的影响。成功的攻击者可滥用此缺陷实现会话接管、将机密性和完整性影响提升至高。若要利用此问题，并不需要用户交互。(CVE-2025-54236)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 Adobe Commerce/Magento Open Source 版本因此受到公告 APSB25-88 中提及的一个漏洞的影响。

  - Adobe Commerce 版本 2.4.9-alpha2、2.4.8-p2、2.4.7-p7、2.4.6-p12、2.4.5-p14、2.4.4-p15 及更早版本会受到不当输入验证漏洞的影响。成功的攻击者可滥用此缺陷实现会话接管、将机密性和完整性影响提升至高。若要利用此问题，并不需要用户交互。(CVE-2025-54236)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

在远程主机上检测到 Dell PowerScale OneFS（原名 Isilon OneFS、EMC Isilon OneFS、Dell EMC Isilon OneFS 和 Dell EMC PowerScale OneFS）。

远程主机为 Dell PowerScale 设备（原名 EMC Isilon、Dell EMC Isilon 和 Dell EMC PowerScale）。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - tracing 修复 cpu 缓冲区写入与交换警告之间的争用问题代码处的 rb_end_commit() 中发生 if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) 警告内核/trace/ 处的 CPU: 0 PID: 139 ring_buffer.c:3142 rb_commit+0x402/0x4a0 调用跟踪 ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_switch+0x2c0x2c0x2c0x2c_event_sched
    __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 原因是通过文件 per_cpu/cpu0/snapshot 写入 cpu 缓冲区和交换 cpu 缓冲区之间存在争用: 在 CPU 0 交换缓冲区上写入CPU 1 上的 per_cpu/cpu0/snapshot -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1.假设找到 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b buffer_b->buffers[cpu] = cpu_buffer_a // 2. cpu_buffer 已交换此处。 rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. 此检查已通过因为“cpu_buffer->buffer”[...] // 未在此处更改。返回 NULL } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. 保留来自“cpu_buffer_a”的事件。 ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. 现在查找“cpu_buffer_b” rb_commit(cpu_buffer) rb_end_commit() // 6. WARN 错误的“提交”状态根据上述分析我们可以通过下面的测试案例轻松重现 `` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR} /buffer_size_kb echo sched:sched_switch > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot did & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot did & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot Done & `为了修复此问题IIUC我们可以使用 smp_call_function_single() 在缓冲区所在的目标 cpu 上执行交换因此上述争用被避免的情况。 (CVE-2023-53368)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ubifs释放 tmpfile 名称的内存当打开加密目录中的 ubifs tmpfile 时函数 fscrypt_setup_filename 为要存储在目录条目中的名称分配内存但在将该名称复制到目录条目 inode 后系统将重新分配内存未释放。当在其上运行 kmemleak 时发现其已注册为泄漏。只要打开一个简单的程序 'tmpfile' 即可触发下列报告 a tmpfile: unreferenced object 0xffff88810178f380 (size 32) (size 32): comm tmpfile, pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename this Freed_openfile memory vubifs_tmpfileafter它已被复制到 inode。 (CVE-2023-53276)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - NVIDIA Mellanox DPDK 在轮询模式驱动程序 (PMD) 中含有漏洞攻击者可在系统中的 VM 上造成网络接口上的信息泄露和拒绝服务。
    (CVE-2025-23259)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Firefox for Android 中隐私组件中的信息泄露、缓解措施绕过。此漏洞影响 Firefox < 143。(CVE-2025-10535)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler() Commit 041879b12ddb (drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()) besides fixing the deadlock also modified _rtw_join_timeout_handler() to use spin_[un]lock_irq() instead of spin_[un]lock_bh(). _rtw_join_timeout_handler() calls rtw_do_join() which takes pmlmepriv->scanned_queue.lock using spin_[un]lock_bh(). This spin_unlock_bh() call re-enables softirqs which triggers an oops in kernel/softirq.c: __local_bh_enable_ip() when it calls lockdep_assert_irqs_enabled(): [ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376
    __local_bh_enable_ip+0xa6/0x100 ... [ 244.509022] Call Trace: [ 244.509048] <IRQ> [ 244.509100]
    _rtw_join_timeout_handler+0x134/0x170 [r8723bs] [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.510076] call_timer_fn+0x95/0x2a0 [ 244.510200] __run_timers.part.0+0x1da/0x2d0 This oops is causd by the switch to spin_[un]lock_irq() which disables the IRQs for the entire duration of _rtw_join_timeout_handler().
    Disabling the IRQs is not necessary since all code taking this lock runs from either user contexts or from softirqs, switch back to spin_[un]lock_bh() to fix this. (CVE-2023-53281)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - recordmcount修复 uwrite 函数中的内存泄漏常见 realloc 错误失败时“file_append”为空但未释放 (CVE-2023-53318)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init() Fault injection test reports this issue: kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_probe+0xe4/0x140 really_probe+0x17e/0x3f0 __driver_probe_device+0xe3/0x170 driver_probe_device+0x49/0x120 The root case here is alloc_ordered_workqueue() fails, but cfg80211_unregister_netdevice() or unregister_netdev() not be called in error handling path. To fix add unregister_netdev goto lable to add the unregister operation in error handling path. (CVE-2022-50361)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup() Syzbot reported a null-ptr-deref bug: ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512) ntfs3: loop0: Mark volume as dirty due to NTFS errors general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline] RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796 Call Trace: <TASK> d_splice_alias+0x122/0x3b0 fs/dcache.c:3191 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3688 do_filp_open+0x264/0x4f0 fs/namei.c:3718 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline]
    __do_sys_open fs/open.c:1334 [inline] __se_sys_open fs/open.c:1330 [inline] __x64_sys_open+0x221/0x270 fs/open.c:1330 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd If the MFT record of ntfs inode is not a base record, inode->i_op can be NULL. And a null-ptr-deref may happen: ntfs_lookup() dir_search_u() # inode->i_op is set to NULL d_splice_alias() __d_add() d_flags_for_inode() # inode->i_op->get_link null-ptr-deref Fix this by adding a Check on inode->i_op before calling the d_splice_alias() function.
    (CVE-2023-53294)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - caif修复 cfctrl_linkup_request() 中的内存泄漏。当 cfctrl_linkup_request() 中的 linktype 为未知或 kzalloc 失败时未释放 pkt。向错误路径添加发布进程。 (CVE-2023-53330)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mmcwmt-sdmmc修复 mmc_add_host() 的返回值检查 mmc_add_host() 可能返回错误可能如果忽略其返回值在 mmc_alloc_host() 中分配的内存将因删除而泄漏并将导致内核崩溃未在删除路径中添加设备。因此通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题此外还需要调用 clk_disable_unprepare()。
    (CVE-2022-50353)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU reset test we see again oops despite of commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling timeout handling). It uses ready condition whether to call drm_sched_fault which unwind the TDR leads to GPU reset. However it looks the ready condition is overloaded with other meanings, for example, for the following stack is related GPU reset : 0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2 does the following: /* start the ring */ gfx_v9_0_cp_gfx_start(adev);
    ring->sched.ready = true; The same approach is for other ASICs as well : gfx_v8_0_cp_gfx_resume gfx_v10_0_kiq_resume, etc... As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault and then drm_sched_fault. However now it depends on whether the interrupt service routine drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready field of the scheduler to true even for uninitialized schedulers and causes oops vs no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and NULL pointer dereference does not occur. Use the field timeout_wq to prevent oops for uninitialized schedulers. The field could be initialized by the work queue of resetting the domain. v1: Corrections to commit message (Luben) (CVE-2023-53351)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - btrfs修复 btrfs_cancel_balance 中的 BUG_ON 条件 暂停和取消平衡可争用中断平衡导致 btrfs_cancel_balance 中的 BUG_ON 错误。btrfs_cancel_balance 中的 BUG_ON 条件未考虑此争用情况。但是，争用条件没有其他副作用。我们可以修复该问题。使用如下所示的错误跟踪对其进行重现：kernel BUG at fs/btrfs/volumes.c:4618! RIP
    0010:btrfs_cancel_balance+0x5cf/0x6a0 调用跟踪 <TASK> ? do_nanosleep+0x60/0x120 hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......在另一线程中发出暂停和取消 req > ------------ -------- > ret = __btrfs_balance(fs_info); >> mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, balance:暂停); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);
    > } (CVE-2023-53339)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - drm/vkms修复 vkms_release() 中的 null-ptr-deref 尝试破坏 vkms_release() 中的 vkms->output.composer_workq 中的工作队列时会触发 null-ptr-deref。KASAN范围 [0x0000000000000118-0x00000000000011f] CPU:5 PID:17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 [] RIP:0010:destroy_workqueue+0x2f/0x710bf  RIP:destroy_workqueue+0x2f/0x710bf 调用跟踪 <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110
    __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 原因是发生了 OOM这触发了工作队列的破坏但是工作队列在后面的进程中被分配因此发生了 null-ptr-deref。一个简单的调用关系图如下所示
    vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # 发生错误 devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue occurred() vkms_modeset_init() vkms_output_init() vkms_crtc_init() # 分配工作队列的位置可以通过在将 composer_workq 传递到 vkms_release() 中的 destroy_workqueue() 之前检查是否为空来修复此问题。
    (CVE-2022-50369)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - RDMA/cxgb4修复 pass_establish() 中潜在的 null-ptr-deref 如果 get_ep_from_tid() 无法查找 ep 的非 NULL 值则 ep 无论是否为空都会在之后取消引用。此修补程序添加了简单的健全性检查以修复 问题。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2023-53335)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：PCI: Fix use-after-free in pci_bus_release_domain_nr() Commit c14f7ccc9f5d (PCI: Assign PCI domain IDs by ida_alloc()) introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE:
    use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. (CVE-2023-53363)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：f2fs: fix kernel crash due to null io->bio We should return when io->bio is null before doing anything. Otherwise, panic. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs] Call Trace: <TASK> f2fs_submit_merged_write+0x1d/0x30 [f2fs] commit_checkpoint+0x110/0x1e0 [f2fs] f2fs_write_checkpoint+0x9f7/0xf00 [f2fs] ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs]
    __checkpoint_and_complete_reqs+0x84/0x190 [f2fs] ? preempt_count_add+0x82/0xc0 ?
    __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] issue_checkpoint_thread+0x4c/0xf0 [f2fs] ?
    __pfx_autoremove_wake_function+0x10/0x10 kthread+0xff/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> (CVE-2023-53301)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mediavimc修复 vimc_init() 失败时调用的错误函数在 vimc_init() 中当 platform_driver_register(&vimc_pdrv) 失败时错误地调用 platform_driver_unregister(&vimc_pdrv) 而非 platform_device_unregister(&vimc_pdev)从而导致内核警告: 意外的驱动程序取消注册警告drivers/base/driver.c:270 driver_unregister+0x8f/0xb0 上的 CPU1PID14517 RIP
    0010:driver_unregister+0x8f/0xb0 调用跟踪 <TASK> vimc_init+0x7d/0x1000 [vimc] do_one_initcall+0xd0/0x4e0 do_init_module+0x1cf/0x6b0 load_module+0x65c2/0x7820 (CVE-2022-50340)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - btrfs修复在使用 scrub 进行重定位期间中止事务时死锁的情况在迁移区块群组暂停 scrub、然后执行重定位、然后取消暂停 scrub。重定位进程需要启动和提交事务如果事务提交路径的关键部分发生故障事务状态 >= TRANS_STATE_COMMIT_START则在暂停的清理时我们将死锁。这会导致类似于如下的堆栈跟踪[42.479] BTRFS 信息设备 sdc重新定位块群组 53876686848 标记元数据|raid6 [42.936] BTRFS 警告设备 sdc跳过提交中止的事务。 [42.936] ------------[ 在此处切换 ]------------ [42.936] BTRFS事务中止错误 -28[42.936] 警告CPU11 PID346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] 链接的模块dm_flakey dm_mod 循环 btrfs (...) [42.936] CPU11 PID 346822 Comm
    btrfs TaintedGW 6.3.0-rc2-btrfs-next-127+ #1 [42.936] 硬件名称QEMU Standard PC(i440FX + PIIX,1996)、BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu .org 2014 年 04 月 1 日 [42.936] RIP
    0010btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (...) [42.936] RSP
    0018ffffb58649633b48 EFLAGS00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX
    0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP
    ffff8be6ef4d5c98 R080000000000000000 R09ffffb586496339e8 [42.936] R100000000000000001 R11
    0000000000000001 R12ffff8be6d38c7c00 [42.936] R1300000000ffffffe4 R14ffff8be6c268c000 R15
    ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3:
    0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] 调用跟踪 [42.936] <TASK> [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_Stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ?
    __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ?
    __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b: Code42.9370x9b [89]4 44 24 (...) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX
    ffffffffffffffda RBX0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI
    00000000c4009420 RDI 0000000000000003 [42.937] RBP 0000000000000003 R080000000000000013 R09
    0000000000000000 [42.937] R1000007f381a60c878 R110000000000000246 R12: 00007ffd45ed0423 [42.937] R13
    00007ffd45ecf150 R14: 00000000000000000 R15: 00007ffd45ecf148 [42.937] </TASK> [42.937] ---[ 结束跟踪 0000000000000000 ]--- [42.937] BTRFScleanup_transaction:1977 中存在错误（设备 sdc状态 A）: errno =-28 剩余空间不足 [59.196] INFO任务 btrfs:346772 阻断时间超过 120 秒。 [59.196] 受感染GW 6.3.0-rc2-btrfs-next-127+ #1 [59.196] echo 0 > /proc/sys/kernel/hung_ ---truncated--- (CVE-2023-53348)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - powercap: intel_rapl修复 UBSAN 位移越界问题 当 value < time_unit 时ilog2() 的参数为零且返回值为 -1。 u64(-1) 对于位移指数而言过大随后将触发位移越界移位指数 18446744073709551615 对于 32 位类型“int”调用跟踪而言过大
    rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us (CVE-2022-50366)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - wifiiwl4965对 create_singlethread_workqueue() 添加缺少的检查 对 create_singlethread_workqueue() 的返回值添加检查以避免空指针取消引用。 (CVE-2023-53302)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：clk: mediatek: mt8183: Add back SSPM related clocks This reverts commit 860690a93ef23b567f781c1b631623e27190f101. On the MT8183, the SSPM related clocks were removed claiming a lack of usage. This however causes some issues when the driver was converted to the new simple-probe mechanism. This mechanism allocates enough space for all the clocks defined in the clock driver, not the highest index in the DT binding. This leads to out-of-bound writes if their are holes in the DT binding or the driver (due to deprecated or unimplemented clocks). These errors can go unnoticed and cause memory corruption, leading to crashes in unrelated areas, or nothing at all.
    KASAN will detect them. Add the SSPM related clocks back to the MT8183 clock driver to fully implement the DT binding. The SSPM clocks are for the power management co-processor, and should never be turned off.
    They are marked as such. (CVE-2023-53274)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/ttm: check null pointer before accessing when swapping Add a check to avoid null pointer dereference as below: [ 90.002283] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 90.002292] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 90.002346] ? exc_general_protection+0x159/0x240 [ 90.002352] ? asm_exc_general_protection+0x26/0x30 [ 90.002357] ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm] [ 90.002365] ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm] [ 90.002373] ttm_bo_swapout+0x134/0x7f0 [ttm] [ 90.002383] ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm] [90.002391] ? lock_acquire+0x44d/0x4f0 [ 90.002398] ? ttm_device_swapout+0xa5/0x260 [ttm] [ 90.002412] ? lock_acquired+0x355/0xa00 [ 90.002416] ? do_raw_spin_trylock+0xb6/0x190 [ 90.002421] ?
    __pfx_lock_acquired+0x10/0x10 [ 90.002426] ? ttm_global_swapout+0x25/0x210 [ttm] [ 90.002442] ttm_device_swapout+0x198/0x260 [ttm] [ 90.002456] ? __pfx_ttm_device_swapout+0x10/0x10 [ttm] [ 90.002472] ttm_global_swapout+0x75/0x210 [ttm] [ 90.002486] ttm_tt_populate+0x187/0x3f0 [ttm] [ 90.002501] ttm_bo_handle_move_mem+0x437/0x590 [ttm] [ 90.002517] ttm_bo_validate+0x275/0x430 [ttm] [ 90.002530] ?
    __pfx_ttm_bo_validate+0x10/0x10 [ttm] [ 90.002544] ? kasan_save_stack+0x33/0x60 [ 90.002550] ? kasan_set_track+0x25/0x30 [ 90.002554] ? __kasan_kmalloc+0x8f/0xa0 [ 90.002558] ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu] [ 90.003023] ? ttm_resource_alloc+0xf6/0x220 [ttm] [ 90.003038] amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu] [ 90.003210] ? __x64_sys_ioctl+0x131/0x1a0 [ 90.003210] ? do_syscall_64+0x60/0x90 (CVE-2023-53352)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net: sched: sfb修复 sfb_init() 失败时的空指针访问问题默认 qdisc 为 sfb 时如果 dev_queue 的 qdisc 在 mqprio_init() 期间初始化失败则将调用 sfb_reset() 以清除资源。在这种情况下q->qdisc 为空并将导致 gpf 问题。流程如下：
    qdisc_create_dflt() sfb_init() tcf_block_get() ---> 失败q->qdisc 为空 ... qdisc_put() ...
    sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc 为空 ops = qdisc->ops 以下是调用跟踪信息一般保护错误可能针对非规范地址 0xdffffc00000000030000 [#1] PREEMPT SMP KASAN KASAN范围 [0x0000000000000018-0x000000000000001f] 中存在 null-ptr-deref RIP
    0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK> sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408 /0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46 /0xb0 RIP0033:0x7f2164122d04 </TASK> (CVE-2022-50356)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mediabdisp对 create_workqueue 添加缺少的检查 对 create_workqueue 的返回值添加检查以避免空指针取消引用。 (CVE-2023-53289)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/msm/dpu: check for null return of devm_kzalloc() in dpu_writeback_init() Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might be NULL and will cause null pointer dereference later. Therefore, it might be better to check it and directly return -ENOMEM. Patchwork: https://patchwork.freedesktop.org/patch/512277/ [DB: fixed typo in commit message] (CVE-2023-53284)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mediacx88修复 buffer_prepare() 中的 null-ptr-deref 缺陷当驱动程序调用 cx88_risc_buffer() 以准备缓冲区时函数调用可能失败随后在 buffer_queue() 中导致空缓冲区和 null-ptr-deref 。#1以下 41.822762日 41.824488​[ 41.828027] RIP0010:buffer_queue+0xc2/0x500 [41.836311] 调用跟踪[ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516]
    __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 通过检查 cbufferbuffer_risc8888 的返回值修复此问题() [hverkuil修复编码样式问题] (CVE-2022-50359)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - drm/msm/mdp5不泄漏某些平面状态 显然没有人注意到自从我们一年前在 21a01abbe32a (drm/atomic
    修复了通过跟踪提交过早释放连接器/平面状态的问题v3。通过使用正确的帮助程序修复该问题。
    Patchwork https://patchwork.freedesktop.org/patch/551236/ (CVE-2023-53324)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ext2/dax修复 len 为页面对齐时的 ext2_setsize PAGE_ALIGN(x) 宏提供下一个最大值该值是 pagesize 的倍数。但如果 x 已进行页面对齐则仅返回 x。因此如果在 dax_zero_range() 函数中传递的 x 为 0则表示长度作为 0 传递到 ->iomap_begin()。在 ext2 中其随后以 0 调用 ext2_get_blocks -> max_blocks 并在 ext2_get_blocks() 中命中 bug_on。BUG_ON(maxblocks == 0);相反我们应该在此处调用 dax_truncate_page() 以解决此问题。即仅当偏移未页面/ 块对齐时它才会调用 dax_zero_range。可通过在 fsdax 挂载的 pmem 设备上关注来轻松触发此问题。 dd if=/dev/zero of=file count=1 bs=512 truncate -s 0 file [79.525838] EXT2-fs (pmem0)DAX 已启用。警告试验性使用后果自负 [79.529376] 在 /mnt1/test 处挂载的 ext2 文件系统在 2038 年之前支持时间戳 (0x7fffffff) [93.793207]------------[在此切换]- ----------- [93.795102] fs/ext2/inode.c:637! 的内核缺陷[93.796904] 无效的 opcode0000 [#1] PREEMPT SMP PTI [93.798659] CPU: 0 PID: 1192 Comm: truncate 未受感染 6.3.0-rc2-xfstests-00056-g131086faa369#139 [93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610 <...> [93.835298] 调用跟踪
    [93.836253] <TASK> [93.837103] lock_acquire+0xf8/0x110 [93.838479] ? d_lookup+0x69/0xd0 [93.839779] ext2_iomap_begin+0xa7/0x1c0 [93.841154] iomap_iter+0xc7/0x150 [93.842425] dax_zero_range+0x6e/0xa0 [93.843813] ext2_setsize+0x176/0x1b0 [93.845164] ext2_setattr+0x176/0x1b0 [93.846467] notify_change+0x341/0x4e0 [93.847805] ? lock_acquire+0xf8/0x110 [93.849143] ? do_truncate+0x74/0xe0 [93.850452] ? do_truncate+0x84/0xe0 [93.851739] do_truncate+0x84/0xe0 [93.852974] do_sys_ftruncate+0x2b4/0x2f0 [93.854404] do_syscall_64+0x3f/0x90 [93.855789] entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53323)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：net: fix net_dev_start_xmit trace event vs skb_transport_offset() After blamed commit, we must be more careful about using skb_transport_offset(), as reminded us by syzbot: WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline] WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14 Modules linked in: CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline] RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline] RIP:
    0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14 Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff RSP: 0018:ffffc900002bf700 EFLAGS: 00010293 RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280 RDX: 0000000000000000 RSI:
    000000000000ffff RDI: 000000000000ffff RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67 R13: ffff88810bec7b3a R14:
    dffffc0000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f96cf6d52f0 CR3:
    000000012224c000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff84715e35>] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline] [<ffffffff84715e35>] xmit_one net/core/dev.c:3643 [inline] [<ffffffff84715e35>] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660 [<ffffffff8471a232>]
    __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff85416493>] dev_queue_xmit include/linux/netdevice.h:3030 [inline] [<ffffffff85416493>] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108 [<ffffffff85416744>] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 [<ffffffff853bc52a>] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline] [<ffffffff853bc52a>] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline] [<ffffffff853bc52a>] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701 [<ffffffff8151023c>] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289 [<ffffffff81511938>] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436 (CVE-2023-53312)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：media: hi846: Fix memleak in hi846_init_controls() hi846_init_controls doesn't clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly. (CVE-2023-53300)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - fs修复 nilfs_mdt_destroy 中的 UAF/GPF 缺陷。在 alloc_inode 中如果 security_inode_alloc() 失败inode_init_always() 可能返回 -ENOMEM从而导致 inode->i_private 未初始化。然后nilfs_is_metadata_file_inode() 返回 true 并且 nilfs_free_inode() 错误地调用 nilfs_mdt_destroy()释放未初始化的 inode->i_private 并导致崩溃例如 UAF/GPF。通过将 security_inode_alloc 移动到 this_cpu_inc(nr_inodes) 之前修复此问题 (CVE-2022-50367)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：skbuff: skb_segment, Call zero copy functions before using skbuff frags Commit bf5c25d60861 (skbuff: in skb_segment, call zerocopy functions once per nskb) added the call to zero copy functions in skb_segment(). The change introduced a bug in skb_segment() because skb_orphan_frags() may possibly change the number of fragments or allocate new fragments altogether leaving nrfrags and frag to point to the old values. This can cause a panic with stacktrace like the one below. [ 193.894380] BUG: kernel NULL pointer dereference, address:
    00000000000000bc [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26 [ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0 [ 194.021892] Call Trace: [ 194.027422] <TASK> [194.072861] tcp_gso_segment+0x107/0x540 [ 194.082031] inet_gso_segment+0x15c/0x3d0 [ 194.090783] skb_mac_gso_segment+0x9f/0x110 [ 194.095016] __skb_gso_segment+0xc1/0x190 [ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem] [ 194.107071] dev_qdisc_enqueue+0x16/0x70 [ 194.110884]
    __dev_queue_xmit+0x63b/0xb30 [ 194.121670] bond_start_xmit+0x159/0x380 [bonding] [ 194.128506] dev_hard_start_xmit+0xc3/0x1e0 [ 194.131787] __dev_queue_xmit+0x8a0/0xb30 [ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan] [ 194.141477] dev_hard_start_xmit+0xc3/0x1e0 [ 194.144622] sch_direct_xmit+0xe3/0x280 [ 194.147748] __dev_queue_xmit+0x54a/0xb30 [ 194.154131] tap_get_user+0x2a8/0x9c0 [tap] [ 194.157358] tap_sendmsg+0x52/0x8e0 [tap] [ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net] [ 194.173631] handle_tx+0xcd/0xe0 [vhost_net] [ 194.176959] vhost_worker+0x76/0xb0 [vhost] [ 194.183667] kthread+0x118/0x140 [ 194.190358] ret_from_fork+0x1f/0x30 [194.193670] </TASK> In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags local variable in skb_segment() stale. This resulted in the code hitting i >= nrfrags prematurely and trying to move to next frag_skb using list_skb pointer, which was NULL, and caused kernel panic. Move the call to zero copy functions before using frags and nr_frags. (CVE-2023-53354)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/msm/dp: Free resources after unregistering them The DP component's unbind operation walks through the submodules to unregister and clean things up. But if the unbind happens because the DP controller itself is being removed, all the memory for those submodules has just been freed. Change the order of these operations to avoid the many use-after-free that otherwise happens in this code path. Patchwork:
    https://patchwork.freedesktop.org/patch/542166/ (CVE-2023-53316)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 站点权限组件中的欺骗问题。此漏洞影响 Firefox < 143 和 Thunderbird < 143。 (CVE-2025-10534

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ext4“ext4_rename”中“old.inode”的初始化配额 Syzbot 发现以下问题ext4_parse_param
    s_want_extra_isize=128 ext4_inode_info_inits_want_extra_isize=32 ext4_rename 旧。inode=ffff88823869a2c8 旧。dir=ffff888238699828 new。inode=ffff88823869d7e8 new。dir=ffff888238699828 __ext4_mark_inode_dirty
    inode=ffff888238699828 ea_isize=32want_ea_size=128__ext4_mark_inode_dirty inode=ffff88823869a2c8 ea_isize=32want_ea_size=128ext4_xattr_block_set inode=ffff88823869a2c8 ------------[在此剪切]------------ WARNING: CPU13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980 模块中链接的 RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980 RSP: 0018:ffff888227d3f3b0 EFLAGS
    00010202 RAX0000000000000001 RBXffff88823007a000 RCX0000000000000000 RDX0000000000000a03 RSI
    0000000000000040 RDI: ffff888230078178 RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000 R13: ffff88823869a2c8 R14:
     R15ffff8881012e0460  : dffffc0000000000 FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f350a6ed6a0 CR3:
    0000000237456000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? ext4_xattr_set_entry+0x3b7/0x2320 ? ext4_xattr_block_set+0x0/0x2020 ? ext4_xattr_set_entry+0x0/0x2320 ? ext4_xattr_check_entries+0x77/0x310 ? ext4_xattr_ibody_set+0x23b/0x340 ext4_xattr_move_to_block+0x594/0x720 ext4_expand_extra_isize_ea+0x59a/0x10f0
    __ext4_expand_extra_isize+0x278/0x3f0 __ext4_mark_inode_dirty.cold+0x347/0x410 ext4_rename+0xed3/0x174f vfs_rename+0x13a7/0x2510 do_renameat2+0x55d/0x920 __x64_sys_rename+0x7d/0xb0 do_syscall_64+0x3b/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc As 'ext4_rename' will modify 'old .inode”ctime 并将 inode 标记为脏这可能会触发扩展“extra_isize”并分配区块。inode 未初始化配额时将导致警告。要解决上述问题请首先初始化“ext4_rename”中的“old.inode”。 (CVE-2022-50346)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：ubifs: Fix memory leak in ubifs_sysfs_init() When insmod ubifs.ko, a kmemleak reported as below: unreferenced object 0xffff88817fb1a780 (size 8): comm insmod, pid 25265, jiffies 4295239702 (age 100.130s) hex dump (first 8 bytes): 75 62 69 66 73 00 ff ff ubifs... backtrace: [<ffffffff81b3fc4c>] slab_post_alloc_hook+0x9c/0x3c0 [<ffffffff81b44bf3>] __kmalloc_track_caller+0x183/0x410 [<ffffffff8198d3da>] kstrdup+0x3a/0x80 [<ffffffff8198d486>] kstrdup_const+0x66/0x80 [<ffffffff83989325>] kvasprintf_const+0x155/0x190 [<ffffffff83bf55bb>] kobject_set_name_vargs+0x5b/0x150 [<ffffffff83bf576b>] kobject_set_name+0xbb/0xf0 [<ffffffff8100204c>] do_one_initcall+0x14c/0x5a0 [<ffffffff8157e380>] do_init_module+0x1f0/0x660 [<ffffffff815857be>] load_module+0x6d7e/0x7590 [<ffffffff8158644f>] __do_sys_finit_module+0x19f/0x230 [<ffffffff815866b3>] __x64_sys_finit_module+0x73/0xb0 [<ffffffff88c98e85>] do_syscall_64+0x35/0x80 [<ffffffff88e00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd When kset_register() failed, we should call kset_put to cleanup it. (CVE-2023-53278)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - netfec优化处理 .remove() 中失败的 pm_runtime_get() 在不可能的事件中 pm_runtime_get()伪装为 pm_runtime_resume_and_get() 失败删除回调会提前返回错误。此时的问题是驱动程序核心会忽略错误值并继续删除设备。这会导致资源泄漏。更糟糕的是devm 分配的资源已释放因此如果稍后调用驱动程序的回调则寄存器映射已消失这可能导致崩溃。
    (CVE-2023-53308)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - nfc修复 nfc_genl_se_io 中的 se_io 上下文内存泄漏。用于向所选安全元素发送 APDU 和从所选安全元素接收 APDU 的回调上下文在 nfc_genl_se_io 内分配并且最终应在 se_io_cb 回调函数中释放。但是在多个错误路径中bwi_timer 不会被控以稍后调用 se_io_cb并且泄漏 cb_context。修补程序建议在这些错误路径上明确释放 cb_context。目前我们不能简单地检查“dev->ops->se_io()”返回值因为它在以下两种情况下可能为负即定时器已记账和未记账。 (CVE-2023-53298)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：skmsg: pass gfp argument to alloc_sk_msg() syzbot found that alloc_sk_msg() could be called from a non sleepable context.
    sk_psock_verdict_recv() uses rcu_read_lock() protection. We need the callers to pass a gfp_t argument to avoid issues. syzbot report was: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU:
    0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 __might_resched+0x538/0x6a0 kernel/sched/core.c:9877 might_alloc include/linux/sched/mm.h:274 [inline] slab_pre_alloc_hook mm/slab.h:700 [inline] slab_alloc_node mm/slub.c:3162 [inline] slab_alloc mm/slub.c:3256 [inline] kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] alloc_sk_msg net/core/skmsg.c:507 [inline] sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600 sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014 sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201 tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971 tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681 sk_backlog_rcv include/net/sock.h:1109 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2906 release_sock+0x5d/0x1c0 net/core/sock.c:3462 tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]
    __sys_sendto+0x46d/0x5f0 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50363)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - canbcmbcm_tx_setup()修复 vfs_write 中的 KMSAN uninit-value Syzkaller 报告了以下问题
    ================================================== === BUGKMSANaio_rw_done fs/aio.c:1520 中的 uninit-value [内联] BUGKMSANaio_write+0x899/0x950 fs/aio.c:1600 aio_rw_done fs/aio.c:1520 中的 uninit-value [内联] aio_write+0x899/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
    __do_sys_io_submit fs/aio.c:2078 [内联] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
    __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit创建于 slab_post_alloc_hook mm/slab.h:766 [内联] slab_alloc_node mm/slub.c:3452 [内联]
    __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [内联]
    __kmalloc+0x11d/0x3b0 mm/slab_common.c:981 kmalloc_array include/linux/slab.h:636 [内联] bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930 bcm_sendmsg+0x3a2/0xce0 net/can/bcm。 c:1351 sock_sendmsg_nosec net/socket.c:714 [内联] sock_sendmsg net/socket.c:734 [内联] sock_write_iter+0x495/0x5e0 net/socket.c:1108 call_write_iter include/linux/fs.h:2189 [内联] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [内联]
    __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x3d/0xb0 arch/x86/entry/ common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 1 月 12 日 ============================================= ======== 我们可以跟踪调用链发现“bcm_tx_setup”函数调用“memcpy_from_msg”以将某些内容复制到“op->frames”新分配的帧。此后将复制的结构的“len”字段与某个常量值64 或 8进行比较。但是如果“memcpy_from_msg”返回错误我们将比较某些未初始化的内存。这会触发“uninit-value”问题。此修补程序将添加可能的“memcpy_from_msg”错误处理以避免 uninit-value 问题。通过 syzkaller 测试 (CVE-2023-53344)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule() Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak occurs. If kzalloc() for duprule succeeds, but the following kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree them in the error path. unreferenced object 0xffff122744c50600 (size 192):
    comm kunit_try_catch, pid 346, jiffies 4294896122 (age 911.812s) hex dump (first 32 bytes): 10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,... 00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'... backtrace: [<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8 [<0000000001bedc67>] kmalloc_trace+0x38/0x88 [<00000000b0612f98>] vcap_dup_rule+0x50/0x460 [<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038 [<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494 [<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698 [<00000000c8766299>] kunit_try_run_case+0xe0/0x20c [<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94 [<00000000f6864acf>] kthread+0x2e8/0x374 [<0000000022e639b3>] ret_from_fork+0x10/0x20 (CVE-2023-53303)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Android 版 Firefox 的 WebAuthn 组件中的欺骗问题。此漏洞影响 Firefox < 143 和 Thunderbird < 143。 (CVE-2025-10530

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ip6mr修复 ip6mr_cache_report() 中的 skb_under_panic skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------ [在此处剪切]------------ 位于 net/core/skbuff.c:192! 的内核缺陷无效 opcode0000 [#1] PREEMPT SMP KASAN CPU2 PID
    22968 Commkworker/2:11 未受感染 6.5.0-rc3-00044-g0a8db05b571a #236 硬件名称QEMU Standard PC (i440FX + PIIX)、BIOS 1.15.0-1 04/01/2014 工作队列ipv6_addrconf addrconf_dad_work RIP
    0010:skb_panic+0x152/0x1d0 Call Trace: <TASK> skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a /0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/ 0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20 在 dev pim6reg 上设置 vlan 设备时可能会在 reg_vif_xmit() 上发送 DAD ns 数据包。 reg_vif_xmit() ip6mr_cache_report() skb_push(skb,
    -skb_network_offset(pkt));//skb_network_offset(pkt) 为 4 skb_push 声明为 void *skb_push(struct sk_buff *skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xffffffffc = 0xffff887f5f86a850 skb->data 设置为 0xffff887f5f86a850这是无效的内存地址会导致 skb_push() 失败。
    (CVE-2023-53365)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
265844	Linux Distros 未修补的漏洞：CVE-2025-39859	high
265842	安装了 Aviatrix 云网络控制器 (Linux)	info
265769	Keycloak < 26.2.9 多种漏洞 (GHSA-wc64-wmfm-46vw)(GHSA-xmcw-mv9p-7pq2)	medium
265751	Adobe Commerce B2B 不当输入验证APSB25-88	critical
265750	Adobe Commerce/Magento Open Source 不正确的输入验证APSB25-88	critical
265703	Dell PowerScale OneFS 操作系统检测	info
265702	Dell PowerScale 硬件检测	info
265675	Linux Distros 未修补的漏洞：CVE-2023-53368	medium
265674	Linux Distros 未修补的漏洞：CVE-2023-53276	medium
265673	Linux Distros 未修补的漏洞：CVE-2025-23259	medium
265672	Linux Distros 未修补的漏洞：CVE-2025-10535	high
265671	Linux Distros 未修补的漏洞：CVE-2023-53281	medium
265670	Linux Distros 未修补的漏洞：CVE-2023-53318	medium
265669	Linux Distros 未修补的漏洞：CVE-2022-50361	medium
265668	Linux Distros 未修补的漏洞：CVE-2023-53294	medium
265667	Linux Distros 未修补的漏洞：CVE-2023-53330	medium
265666	Linux Distros 未修补的漏洞：CVE-2022-50353	medium
265665	Linux Distros 未修补的漏洞：CVE-2023-53351	medium
265664	Linux Distros 未修补的漏洞：CVE-2023-53339	medium
265663	Linux Distros 未修补的漏洞：CVE-2022-50369	medium
265662	Linux Distros 未修补的漏洞：CVE-2023-53335	medium
265661	Linux Distros 未修补的漏洞：CVE-2023-53363	high
265660	Linux Distros 未修补的漏洞：CVE-2023-53301	high
265659	Linux Distros 未修补的漏洞：CVE-2022-50340	medium
265658	Linux Distros 未修补的漏洞：CVE-2023-53348	medium
265657	Linux Distros 未修补的漏洞：CVE-2022-50366	high
265656	Linux Distros 未修补的漏洞：CVE-2023-53302	medium
265655	Linux Distros 未修补的漏洞：CVE-2023-53274	high
265654	Linux Distros 未修补的漏洞：CVE-2023-53352	medium
265653	Linux Distros 未修补的漏洞：CVE-2022-50356	medium
265652	Linux Distros 未修补的漏洞：CVE-2023-53289	medium
265651	Linux Distros 未修补的漏洞：CVE-2023-53284	medium
265650	Linux Distros 未修补的漏洞：CVE-2022-50359	medium
265649	Linux Distros 未修补的漏洞：CVE-2023-53324	medium
265648	Linux Distros 未修补的漏洞：CVE-2023-53323	medium
265647	Linux Distros 未修补的漏洞：CVE-2023-53312	medium
265646	Linux Distros 未修补的漏洞：CVE-2023-53300	medium
265645	Linux Distros 未修补的漏洞：CVE-2022-50367	high
265644	Linux Distros 未修补的漏洞：CVE-2023-53354	medium
265643	Linux Distros 未修补的漏洞：CVE-2023-53316	high
265642	Linux Distros 未修补的漏洞：CVE-2025-10534	high
265641	Linux Distros 未修补的漏洞：CVE-2022-50346	medium
265640	Linux Distros 未修补的漏洞：CVE-2023-53278	medium
265639	Linux Distros 未修补的漏洞：CVE-2023-53308	high
265638	Linux Distros 未修补的漏洞：CVE-2023-53298	medium
265637	Linux Distros 未修补的漏洞：CVE-2022-50363	medium
265636	Linux Distros 未修补的漏洞：CVE-2023-53344	medium
265635	Linux Distros 未修补的漏洞：CVE-2023-53303	medium
265634	Linux Distros 未修补的漏洞：CVE-2025-10530	medium
265633	Linux Distros 未修补的漏洞：CVE-2023-53365	medium

检测

Nessus 的 Misc. 系列

high

info

medium

critical

critical

info

info

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium