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

  - mediaipu-bridge修复当 ipu_bridge_parse_rotation() 和 ipu_bridge_parse_orientation() 运行时 sensor->adev 尚未设置时SSDB/PLD 解析警告上的空指针取消引用。因此如果命中任一有关未知值的 dev_warn() 调用将导致空指针取消引用。提早使用借用的 ref 设置 sensor->adev以避免发生错误时更难展开以修复此问题。 (CVE-2023-53336)

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

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

  - 已修复 Linux 内核中的下列漏洞：mlx5: fix possible ptp queue fifo use-after-free Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index).
    (CVE-2023-53398)

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

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

  - USBdwc3使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则随着时间的推移内存将泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。请注意需要保存设备的 debugfs 目录的根 dentry以便我们不必继续查找它需要更多位重构以便在需要时正确创建和删除它。 (CVE-2023-53415)

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

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

  - RDMA/mlx5修复用于设备的 mlx5_ib_get_hw_stats 当前在 mlx5_ib_get_hw_stats() 用于设备 (port_num = 0) 时存在特殊处理以便使用正确的计数器但是 port_num 会在不知情的情况下向下传递堆栈的任何更改。此外某些函数假设 port_num >=1。因此可能会发生以下 oops。BUG无法处理地址的页面错误ffff89510294f1a8 #PF
    内核模式下的主管写入访问 #PFerror_code(0x0002) - not-present page PGD 0 P4D 0 Oops0002 [#1] SMP CPU: 8 PID: 1382 Commdevlink Tainted: GW 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware nameQEMU Standard PC (Q35 + ICH92009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 RIP0010:_raw_spin_lock+0xc/0x20 调用跟踪 <TASK> mlx5_ib_get_native_port_mdev+ 0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510] [ib_core] [ib_core] atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 driver_sysfs_add+0x6b/0x90 real_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90
    __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70
    __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x570/0x480 devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 devlink_nl_cmd_region_read_dumpit+0x540/0x540 devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x100 handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 通过将 port_num 设置为 1 以获取设备状态并删除未使用的变量来修复此问题。 (CVE-2023-53393)

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

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

  - ALSAhda修复 9.1 环绕通道名称 get_line_out_pfx() 中的 Oops 可能通过使静态数组溢出超过 8 个通道来触发 Oops。报告称具有 Cirrus 编解码器的 MacBookPro 12,1 存在此问题。解决方法是扩展 9.1 通道并且通过将访问相同数组的代码路径与正确的大小检查统一来修复潜在的 Oops。 (CVE-2023-53400)

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

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

  - driversbasedd使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53390)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: Fix potential use-after-free when clear keys Similar to commit c5d2b6fa26b5 (Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk). We can not access k after kfree_rcu() call. (CVE-2023-53386)

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

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

  - ttyserialfsl_lpuart在 lpuart_dma_shutdown 中禁用 dma rx/tx 使用标记 lpuart_dma_shutdown 会破坏 lpuart dma但仍会发生 lpuart_flush_buffer如果 lpuart_dma_tx_use 标记为真则其转而尝试访问 dma api。此时由于 dma 已破坏这些 dma api 可能中止。在 lpuart_dma_shutdown 中将 lpuart_dma_tx_use 和相应的 rx 标记 lpuart_dma_rx_use 设置为 false以便在释放 dmas 后不会对其进行访问。否则在尝试终止 btattach 时内核可能会发生错误。
    此修补程序可以修复此问题。 root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] 内部错误同步外部中止96000210 [#1] PREEMPT SMP [ 90.189806] 链接的模块用于
    moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach 受感染GO 5.15.32-06136-g34eecdf2f9e4 #37 [90.203554] 硬件名称NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate600000c5 (nZCv daIF -PAN -UAO
    -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr
    fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24:
    ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17:
    0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13:
    0000000000000000 x120000000000000040 [ 90.271344] x11ffff00000600c248 x10ffff800013f0bb10 x9
    ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 :
    ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+ 0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652]____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code
    17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ 结束跟踪 2f60524b4a43f1f6 ]--- [90.397073] 注意btattach[503] 因 preempt_count 1 退出 [ 90.402636] 修复了递归错误但需要重新启动(CVE-2022-50375)

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

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

  - V8 中的类型混淆。由 Google Threat Analysis Group 于 2025 年 9 月 16 日报告。(CVE-2025-10585)

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

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

  - mediamdp3修复 of_find_device_by_node 中的资源泄漏 使用 put_device 通过 of_find_device_by_node 释放对象从而避免资源泄漏。 (CVE-2023-53385)

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

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

  - mmkmem修复 obj_Stock_flush_required() 中的一个空指针取消引用 KCSAN 在 obj_Stock_flush_required() 中发现一个问题 stock->cached_objcg 可在检查和取消引用之间重置
    ================================================== ================ BUGKCSAN由任务 19625 在 cpu 0 上drain_all_Stock /rain_obj_store 写入 0xffff888237c2a2f8 8 字节中的数据争用
    rain_obj_Stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_Stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/ slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [内联]
    __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913
    __fput+0x3bf/0x570 fs/file_table.c:329____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop +0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [内联] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common .c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd 在 cpu 1:obj_Stock_flush_required mm/memcontrol.c:3319 上被任务 19632 读取到 0xffff888237c2a2f8（共 8 个字节） +0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [内联] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/ 0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [内联] __se_sys_setsockopt net/socket.c:2279 [内联] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x41/0xc0 arch/x86/entry/ common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 值已更改0xffff8881382d52c0 -> 0xffff888138893740 已由位于 CPU 上的内核并发审查器报告1 PID19632 Commsyz-executor.0 Nottainted 6.3.0-rc2-syzkaller-03627father-03627a-03627a-03627a-038893893740 #0 硬件名称Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 通过针对 stock->cached_objcg 的所有访问使用 READ_ONCE()/WRITE_ONCE() 来修复此问题。 (CVE-2023-53401)

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

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

  - 已修复 Linux 内核中的下列漏洞：cifs: prevent use-after-free by freeing the cfile later In smb2_compound_op we have a possible use-after-free which can cause hard to debug problems later on. This was revealed during stress testing with KASAN enabled kernel. Fixing it by moving the cfile free call to a few lines below, after the usage. (CVE-2023-53377)

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

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

  - mm/proc/pid/smaps_rollup修复 no vma 的 null-deref Commit 258f669e7e88mm/proc/pid/smaps_rollup
    转换为单值 seq_file如果 show_smaps_rollup 中的任务中没有 vma则引入 null-deref。 (CVE-2022-50380)

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

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

  - btrfs修复配额启用和配额重新扫描 ioctl 之间的争用。启用配额时在 btrfs_quota_enable() 提交事务后我们将 fs_info->quota_root 更改为指向我们创建的配额根并在 fs_info->flags 设置 BTRFS_FS_QUOTA_ENABLED。然后我们尝试启动 qgroup 重新扫描工作线程首先通过调用 qgroup_rescan_init() 将其初始化 - 但是如果启动失败我们最终会释放 quota root 但使 fs_info->quota_root 仍指向它这可在之后导致其他地方的释放后使用。我们之前已设置标记 BTRFS_FS_QUOTA_ENABLED 和 BTRFS_QGROUP_STATUS_FLAG_ON因此我们只能在 btrfs_quota_enable() 处因 -EINPROGRESS 失败而如果有人已调用配额重新扫描 ioctl并因此启动重新扫描工作线程则可能出现这种情况。因此通过忽略 -EINPROGRESS 和断言我们无法得到任何其他错误来修复此问题。 (CVE-2022-50379)

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

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

  - net/smc尝试使用 SMCRv2 失败时重置连接。我们发现将 SMCRv2 与 2 Mellanox ConnectX-4 配合使用时会发生崩溃。它<port> 可以<ip>通过以下方式重现PFerror_code(0x0000) - not-present 页面 PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump已加载 Tainted: GWE 6.4.0 -rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP:
    0010smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP0018:ffffb8294b2d7c78 EFLAGS00010a06 RAX
    ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10:
     R110000000000000400  : 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3:000000 DR3:000000000000000000000
    00000000fffe0ff0 DR7: 0000000000000400 调用跟踪 <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> 在 CLC 握手期间服务器会按顺序尝试 smc_listen_work() 中可用的 SMCRv2 和 SMCRv1 设备。是否找到 SMCRv2 设备。基于 SMCv2 的链接组和链接将分配给该连接。然后假设稍后在 CLC 握手中发生某些缓冲区分配错误例如 MBR 注册失败服务器将放弃 SMCRv2 并尝试使用 SMCRv1 设备。但不会重置分配给该连接的资源。服务器尝试 SMCRv1 设备时将再次执行连接创建过程。由于在尝试 SMCRv2 时已分配 conn->lnk因此不会在 smcr_lgr_conn_assign_link() 中将其设置为正确的 SMCRv1 链接。因此在这种情况下conn->lgr 会正确指向 SMCRv1 链接组但 conn->lnk 会错误地指向 SMCRv2 链接。然后在 smc_clc_send_confirm_accept() 中将会访问 conn->rmb_desc->mr[link->link_idx]。由于 link->link_idx 不正确相关 MR 可能未初始化因此会发生崩溃。 |先试用 SMCRv2 设备 | |-> conn->lgr分配已存在的 SMCRv2 链接组| |-> conn->link分配已存在的 SMCRv2 链接SMC_LGR_SYMMETRIC 中的 link_idx 可能为 1 | |-> sndbuf 和 RM 创建失败退出| |然后试用 SMCRv1 设备 | |-> conn->lgr创建 SMCRv1 链接组并分配| |-> conn->link错误地保留 SMCRv2 链接| |-> sndbuf 和RMB 创建成功仅限RMB->mr[link_idx = 0] |已初始化。 | | |则 smc_clc_send_confirm_accept() 访问conn->rmb_desc->mr[conn->link->link_idx即 1]然后崩溃。
    v 此修补程序尝试通过在分配链接之前清除 conn->lnk 来修复此问题。此外如果在创建或注册缓冲区时尝试 SMCRv2 失败最好重置连接并清理分配的资源。 (CVE-2023-53382)

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

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

  - driversbasecomponent修复内存泄漏使用 debugfs_lookup() 调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53409)

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

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

  - 已修复 Linux 内核中的下列漏洞：sctp: fix a potential overflow in sctp_ifwdtsn_skip Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against the end of the chunk - sizeof(struct sctp_ifwdtsn_skip) in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip. (CVE-2023-53372)

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

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

  - Spring Framework 批注检测机制可能无法正确解析具有无限泛型的参数化超类型的类型层次结构内方法上的批注。如果将此类注释用于授权决策这可能会成为一个问题。如果您使用 Spring Security 的 @EnableMethodSecurity 功能您的应用程序可能会受到此漏洞的影响。如果您未使用 @EnableMethodSecurity或者不在泛型超类或泛型接口的方法上使用安全注释则不受此问题影响。此 CVE 与 CVE-2025-41248 https://spring.io/security/cve-2025-41248 一并发布。 (CVE-2025-41249)

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

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

  - 在 LemonLDAP::NG 2.16.7 之前的版本以及 2.21.3 之前的 2.17 至 2.21 版中，Safe jail 中可发生 OS 命令注入。在规则评估期间，未对 _ 进行本地化处理。因此，能够编辑 Safe jail 评估的规则的管理员能够在服务器上执行命令。(CVE-2025-59518)

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

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

  - 已修复 Linux 内核中的下列漏洞：skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc :
    skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c
    __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. (CVE-2022-50365)

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

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

  - block当轮询 Wei 报告应用程序使用轮询 IO 时要更小心地检查 NULL bdev: PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm iocore_0 Kdump已加载被污染的GS 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1 硬件名称Wiwynn delta Lake MP T8/delta Lake-Class2BIOS Y3DLM08 04/10/2022 RIP0010:bio_poll+0x25/0x200代码0f 1f 44 00 00 0f 1f 44 00 00 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 5c 6b 8b 80 70 02 00 8f0 34 31 db 83 fd ff 75 25 65 RSP
    0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08:
     R090000000000000000  : 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocb_bio_iopoll+0x1d/0x30 io_do_iopoll+0xac/0x250 __se_sys_io_uring_enter+0x3c5/0x5a0 ?
    __x64_sys_write+0x89/0xd0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP
    0033:0x94f225d 代码24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 001 c0f 05 <85> [05] 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP002b:00007fd194ffcd88 EFLAGS00000202 ORIG_RAX:00000000000001aa RAX:ffdaffXffffff
    00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11:
    0000000000000202 R1200007fd269d68030 R130000000000000000 R140000000000000001 R150000000000000000 原因在于 bio->bi_bdev 为空。如果有两个任务在执行轮询 IO并且共享轮询队列任务 B 最终从任务 A 完成 IO就会发生这种情况。如果任务 B 完成 IO 并将 bio 放入缓存中则它可在任务 A 完成对该 bio 的轮询之前再次分配该 bio。由于这将需要两个任务之间的抢占因此在检查 bio->bi_bdev 是否为空时只要更仔细一些就足够了。 (CVE-2023-53366)

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

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

  -rapidio修复 rio_add_device() 失败时可能的名称泄漏 修补程序系列rapidio修复三个可能的内存泄漏。此修补程序集修复错误处理中的三个名称泄漏。 - 修补程序 #1 修复 rio_add_device() 失败时的两个名称泄漏。 - 修补程序 #2 修复 rio_register_mport() 失败时的名称泄漏。此修补程序共 2 个修补程序如果 rio_add_device() 返回错误则需要释放由 dev_set_name() 分配的名称。应使用 put_device() 放弃错误路径中的引用以便可在 kobject_cleanup() 中释放该名称并可在 rio_release_dev() 中释放“rdev”。 (CVE-2022-50343)

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

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

  - brcmfmac从加密狗获取无效 max_flowrings 时返回错误当固件在初始化时命中陷阱时主机将从加密狗读取异常的 max_flowrings 编号并且在进行 iowrite 以初始化加密狗环时造成内核错误。为了及早检测此错误我们在获取无效的 max_flowrings(>256) 时直接返回错误。 (CVE-2022-50358)

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

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

  - usbdwc3核心修复探测中的一些泄漏 dwc3_get_properties() 函数调用 dwc->usb_psy = power_supply_get_by_name(usb_psy_name);因此需要对这些错误路径进行一些额外的清理。 (CVE-2022-50357)

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

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

  - fbdev/ep93xx-fb不分配到 struct fb_info.dev 不将 Linux 设备分配到 struct fb_info.dev。
    对 register_framebuffer() 的调用会将该字段初始化为 fbdev 设备。驱动程序不应替代其值。修复了驱动程序错误地减少硬件设备的引用计数器并泄漏 fbdev 设备的缺陷。 v2* 添加修复标签 (Dan) (CVE-2023-53314)

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

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

  - nilfs2通过 iput 修复 dirtying inode 中 nilfs_root 的释放后使用错误在 nilfs2 的卸载进程中在 nilfs2 分离其在 nilfs_detach_log_writer() 中的写入器之后没有任何操作保留 nilfs_root 结构。
    以前如果 inode 留在garbage_list 中并在 nilfs_detach_log_writer() 结束时由 nilfs_dispose_list 释放nilfs_evict_inode() 可造成 nilfs_root 释放后使用读取提交 9b5a04ac3ad9 中修复了此缺陷 (nilfs2修复释放后使用nilfs_evict_inode() 中 nilfs_root 的缺陷。
    然而事实证明在从 iput() 调用 mark_inode_dirty_sync() 的调用路径中存在 UAF 的另一种可能性nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block( ) --> 造成 nilfs_root 结构的 UAF 这会在提交 0ae45f63d4ef vfs添加对 lazytime 挂载选项的支持这会将 iput() 更改为如果 i_state 具有 I_DIRTY_TIME 标记且 i_nlink 为非-zero。当使用 syzbot 复制程序时提交 28a65b49eb53 (nilfs2在降级为只读后不写入脏数据) 之后出现此问题但之前可能就存在该问题。可通过以下方法修复此问题
    __nilfs_mark_inode_dirty()。与提交 9b5a04ac3ad9 不同nilfs2修复 nilfs_evict_inode() 中 nilfs_root 的释放后使用缺陷此修补程序不依赖 ns_writer 来确定是否跳过操作以便在挂载时不中断恢复。nilfs_salvage_orphan_logs 例程在附加日志编写器之前会脏抢占数据的缓冲区因此当 ns_writer 为 NULL 时变更 __nilfs_mark_inode_dirty() 以跳过该操作将造成恢复写入失败。使用 cleanup-only 标记的目的是缩小此类条件的范围。 (CVE-2023-53311)

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

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

  - 已修复 Linux 内核中的下列漏洞：rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to see if it should exit the loop without first checking the call state. This is probably safe as if call->error is set, the call is dead anyway, but we should probably wait for the call state to have been set to completion first, lest it cause surprise on the way out. Fix this by only accessing call->error if the call is complete. We don't actually need to access the error inside the loop as we'll do that after. This caused the following report: BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1: rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22 rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479 rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714 rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline] rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350 rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464 rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461 kthread+0x1ac/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
    rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296 rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726 rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501 ___sys_sendmsg net/socket.c:2555 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2641 __do_sys_sendmmsg net/socket.c:2670 [inline] __se_sys_sendmmsg net/socket.c:2667 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0xffffffea (CVE-2023-53345)

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

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

  - drm/amdkfd修复 kfd_process_device_init_vm 错误处理“应仅破坏 ib_mem并让进程清理工作线程释放未完成的 BO”。重置 pdd->qpd 结构中的指针以避免进程破坏工作线程中的空指针访问。BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0CVE-2022-50354

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

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

  - trace/blktrace使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53408)

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

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

  - ASoCmediatekmt8183修复 mt8183_mt6358_ts3a227_max98357_dev_probe() 中的 refcount 泄漏 of_parse_phandle() 返回引用计数递增的节点使用完时需要调用 of_node_put()。因此请将其添加至 mt8183_mt6358_ts3a227_max98357_dev_probe() 的错误路径中。 (CVE-2022-50392)

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

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

  - netdcb选择正确的策略来解析 DCB_ATTR_BCN dcbnl_bcn_setcfg 使用错误的策略解析 tb[DCB_ATTR_BCN] 在提交 859ee3c43812 中引入 DCB添加对 DCB BCN 的支持。请参阅以下代码中的注释 static int dcbnl_bcn_setcfg(...) { ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_attrs 中属性的 dcbnl_pfc_up_nest // DCB_PFC_UP_ATTR_0 至 DCB_PFC_UP_ATTR_ALL ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7;
    i++) { // !!! enum dcbnl_bcn_attrs 中的 DCB_BCN_ATTR_RP_0 至 DCB_BCN_ATTR_RP_7 ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { //!!! enum dcbnl_bcn_attrs 中的 DCB_BCN_ATTR_BCNA_0 更改为 DCB_BCN_ATTR_RI ... value_int = nla_get_u32(data[i]); ... } ... } 即 nla_parse_nested_deprecated 使用 dcbnl_pfc_up_nest 属性来解析 dcbnl_pfc_up_attrs 中定义的 nlattr。但以下访问代码会提取每个 nlattr 作为 dcbnl_bcn_attrs 属性。通过为 dcbnl_bcn_attrs 查找相关联的 nla_policy。可以发现这两个策略的开头部分是相同的。 static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = { .type = NLA_U8}、[DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_7] = {.type = NLA_U8} [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, } static const struct nla_policy dcbnl_bcn_nest[...] = {[DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_3] = { .type = NLA_U8}、[DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_7] = {.type = NLA_U8} [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // 此处稍有不同 [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, };因此当前的代码是有缺陷的而且此 nla_parse_nested_deprecated 可溢出 dcbnl_pfc_up_nest 并使用邻近的 nla_policy 来解析 DCB_BCN_ATTR_BCNA_0 的属性。因此使用正确的策略 dcbnl_bcn_nest 解析嵌套的 tb[DCB_ATTR_BCN] TLV。 (CVE-2023-53369)

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

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

  - nvme修复启用 blktrace 时由刷新请求导致的多路径崩溃 blk_kick_flush 初始化的刷新请求具有空 bio可能会在 io 完成期间由 nvme_end_req 进行处理。启用 blktrace 时激活多路径的 nvme_trace_bio_complete 尝试访问刷新请求中的空指针 bio导致以下崩溃[ 2517.831677] 缺陷内核空指针取消引用解决
    000000000000001a [ 2517.835213] #PF内核模式下的主管读取访问 [ 2517.838724] #PF
    error_code(0x0000) - 不存在页面 [ 2517.842222] PGD 7b2d51067 P4D 0 [ 2517.845684] Oops: 0000 [#1] SMP NOPTI [ 2517.849125] CPU:2 PID:732 Comm:kworker/2:1H Kdump受感染GS 5.15.67-0.cl9.x86_64 #1 [ 2517.852723] 硬件名称XFUSION 2288H V6/BC13MBSBC、BIOS 1.13 07/27/2022 [2517.856358] 工作队列nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [ 2517.859993] RIP
    0010:blk_add_trace_bio_complete+0x6/0x30 [ 2517.863628] Code1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 01 001f 44 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286 [2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000 [ 2517.878966] RDX
    0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000 [ 2517.882849] RBP: ff3d5b0b96a6fa00 R08
    0000000000000001 R090000000000000000 [ 2517.886718] R10000000000000000c R11000000000000000c R12
    ff3d5b0b021fb9f8 [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018 [2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000 [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 [ 2517.902157] CR2: 000000000000001a CR3:
    00000004f023e005 CR4: 0000000000771ee0 [ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000 [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2517.913761] PKRU: 55555554 [ 2517.917558] Call Trace: [ 2517.921294] <TASK> [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core] [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp] [2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp] [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp] [ 2517.939830] tcp_read_sock+0x9c 2517.950834/ 0x260 [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp] [2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp0x3one] [ework/0x3] [2517.954473] worker_thread+0x53/0x3c0 [ 2517.958069] ? process_one_work+0x390/0x390 [ 2517.961655] kthread+0x10c/0x130 [ 2517.965211] ? set_kthread_struct+0x40/0x40 [ 2517.968760] ret_from_fork+0x1f/0x30 [2517.972285] </TASK> 若要避免此情况请在调用 trace_block_bio_complete 之前为 req->bio 添加空检查。 (CVE-2022-50388)

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

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

  - shmem将 ramfs_kill_sb() 用于基于 ramfs 的 tmpfs 的 kill_sb 方法由于基于 ramfs 的 tmpfs 将 ramfs_init_fs_context() 用于 init_fs_context 方法这会分配 fc->s_fs_info因此使用 ramfs_kill_sb() 将其释放并避免内存泄漏。 (CVE-2023-53391)

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

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

  - 已修复 Linux 内核中的下列漏洞：md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request There are two check of 'mreplace' in raid10_sync_request(). In the first check, 'need_replace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'need_replace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same. (CVE-2023-53380)

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

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

  - USBULPI使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时其结果必须调用 dput()否则一段时间后内存将泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53410)

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

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

  - kernel/printk/index.c修复使用 debugfs_lookup() 时的内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53402)

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

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

  - scsiufscore修复设备管理 cmd 超时流程 在 UFS 错误处理流程中主机会将设备管理 cmd (NOP OUT) 发送到设备进行链接恢复。如果此 cmd 超时且清除门铃失败ufshcd_wait_for_dev_cmd() 将不执行任何操作并返回。 hba->dev_cmd.complete 结构未设置为 NULL。发生这种情况时如果设备已完成 cmd我们将调用
    __ufshcd_transfer_req_compl()。由于在堆栈上分配了完整的 struct因此将发生以下崩溃ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync +0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork +0x10/0x30CVE-2023-53387

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

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

  - drm/amdgpu可从解锁的上下文调用使用解锁的迭代器 SDMA 更新页表的 SDMA 更新并生成以下警告。使用解锁的迭代器处理此情况。警告CPU0 PID1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next 调用跟踪dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x29c/0x29dma-resv.c:483 dma_resv_iter_next 调用跟踪/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+0x10] (CVE-2022-50393)

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

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

  - i2cismt修复 ismt_access() 中的越界缺陷 当驱动程序未检查来自用户的数据时变量“data->block[0]”可能很大从而导致越界-bounds 缺陷。以下日志可揭示该漏洞[ 33.995542] i2c i2c-1ioctl、 cmd=0x720、 arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ========= ================================================== ======= [ 33.996995] BUGKASANismt_access.cold+0x374/0x214b 中存在越界 [ 33.997473] 任务 ismt_poc/485 在 addr ffff88810efcfdb1 处读取大小 18446744073709551615 [ 33.999450] 调用跟踪[ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x710 [/0x7108 34.005196] i2cdev_ioctl+0x5ec/0x74c 通过首先检查“data->block[0]”的大小来修复此缺陷。 (CVE-2022-50394)

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

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

  - netsched修复 tcindex_set_parms 中的内存泄漏 Syzkaller 报告内存泄漏如下
    ==================================== 缺陷内存泄漏未引用对象 0xffff88810c287f00大小 256
    comm syz-executor105、pid 3600、jiffies 4294943292(age 12.990s) 十六进制转储前 32 字节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 ......回溯[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [内联] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [内联] [<ffffffff839c9e07>] kcalloc include/linux/slab。 h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb +0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [内联] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c 1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [内联] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86 /entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ========== ========================== 内核使用 tcindex_change() 更改现有过滤器属性。
    但问题是在更改过程中如果从“p->perfect”检索“old_r”则内核使用 tcindex_alloc_perfect_hash() 重新分配筛选结果使用 tcindex_filter_result_init() 清除旧筛选结果而不需要破坏其 tcf_exts 结构从而触发上述内存泄漏。更具体地说，根据 tcindex_lookup()，“old_r”只有两个来源。是从“p->perfect”检索“old_r”或从“p->h”检索“old_r”。 * 如果从 `p->perfect` 检索 `old_r`内核使用 tcindex_alloc_perfect_hash() 重新分配过滤器结果。然后为新分配的“cp->perfect + handle”分配“r”。
    因此这种情况下条件 `old_r && old_r != r` 为真内核使用 tcindex_filter_result_init() 清除旧过滤结果而不会破坏其 tcf_exts 结构 * 如果从 `p->h` 中检索 `old_r`则根据 tcindex_lookup()“p->perfect”为空。考虑到“cp->h”是直接从“p->h”复制并且“p->perfect”为空向“r”分配“tcindex_lookup(cp, handle)”其值应与 相同“old_r”因此在这种情况下条件“old_r && old_r != r”为假内核会忽略使用 tcindex_filter_result_init() 清除旧过滤结果。因此仅当从“p->perfect”检索“old_r”时内核才会使用 tcindex_filter_result_init() 清除旧的过滤结果这会触发上述内存泄漏。考虑已存在 tc_filter_wq 工作队列破坏旧的 tcindex_d ---truncated--- (CVE-2022-50396)

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

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

  - cryptoseqiv - 正确处理 EBUSY 因为现在的 seqiv 只处理 EINPROGERSS 的特殊返回值这意味着在所有其他情况下它将释放与请求相关的数据。但是，由于 seqiv 的调用程序可能指定 MAY_BACKLOG，因此我们还需要预期 EBUSY 并以相同方式对其进行处理。
    否则积压的请求将触发释放后使用。 (CVE-2023-53373)

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

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

  - net/mlx5exsk修复常规 rq 重新激活时的崩溃在 XSK 套接字关闭后重新激活常规 rq 时它可能正在读取过时的 cqes最终损坏 rq。这将导致常规 rq 上不再接收流量以及 rq 的下一次关闭或停用时崩溃。Kal Cuttler Conely 报告将此问题描述为当流量运行时按顺序停止（终止）并重新启动 xdpsock 示例程序时版本路径中的崩溃。此修补程序在 rq 刷新期间刷新所有 cqes。cqe 刷新在 rq 的重置状态下完成。 mlx5e_rq_to_ready 代码已移动到 flush 函数中以实现此目的。 (CVE-2023-53394)

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

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

  - 在某些情况下当 DNSdist 配置为使用 nghttp2 库来处理通过 HTTPS 查询的传入 DNS 查询时攻击者可能会通过构建可触发不受限制的 I/O 读取循环的 DoH 交换导致拒绝服务意外消耗 CPU 资源。 (CVE-2025-30187)

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

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

  - WebRTC 中的释放后使用。由 sherkito 于 2025 年 8 月 23 日报告。(CVE-2025-10501)

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

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

  - PMEM修复使用 debugfs_lookup() 时的内存泄漏调用 debugfs_lookup() 时结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53411)

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

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

  - md修复 mempool_free 中的崩溃运行 lvm 测试 shell/lvchange-rebuild-raid.sh 时mempool_free 中存在崩溃。崩溃的原因如下* super_written 调用 atomic_dec_and_test(&mddev->pending_writes) 和 wake_up(&mddev->sb_wait)。然后它调用 rdev_dec_pending(rdev, mddev) 和 bio_put(bio)。 * 因此在 sb_wait 上等待并唤醒的进程与 bio_put(bio) 争用。 * 如果进程赢得争用则会在执行 bio_put(bio) 之前调用 bioset_exit。 * bio_put(bio) 尝试将 bio 释放到已破坏的 bio 集中 - 造成 mempool_free 中的崩溃。我们通过在 atomic_dec_and_test 之前移动 bio_put 来修复此缺陷。我们也按照 Neil Brown 的建议将 rdev_dec_pending 移动到 atomic_dec_and_test 之前。函数 md_end_flush 有类似的缺陷 - 我们必须在减少正在进行的 bios 数量之前调用 bio_put。缺陷内核空指针取消引用地址0000000000000000 #PF 内核模式中的主管写入访问 #PFerror_code (0x0002)
    - not-present 页 PGD 11557f0067 P4D 11557f0067 PUD 0 Oops0002 [#1] PREEMPT SMP CPU: 0 PID: 73 Comm
    kworker/0:1 未受感染 6.1.0-rc3 #5 硬件名称QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 工作队列kdelayd flush_expired_bios [dm_delay] RIP: 0010:mempool_free+0x47/ 0x80 代码48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 89 <48> 2c] df 89 4b 89 2c e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00 RSP
    0018:ffff88910036bda8 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8 RBP: ffff8891447ba240 R08:
     R090000000000012908  : 00000000003d0900 R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000 R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05 FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0 Call Trace: <TASK> clone_endio+0xf4/0x1c0 [dm_mod] clone_endio+0xf4/0x1c0 [dm_mod] __submit_bio+0x76/0x120 submit_bio_noacct_nocheck+0xb6/0x2a0 flush_expired_bios+0x28/0x2f [dm_delay] process_one_work+0x1b4/ 0x300 worker_thread+0x45/0x3e0 rescuer_thread+0x380/0x380 kthread+0xc2/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [上次卸载的: brd] CR2: 0000000000000000 ---[ 结束跟踪 0000000000000000 ---CVE-2022-503810

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

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

  - 已修复 Linux 内核中的下列漏洞：padata: Always leave BHs disabled when running ->parallel() A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled <interrupt> ... __do_softirq ... padata_do_serial spin_lock(&reorder->lock) It's a bug for BHs to be on in _do_serial as Steffen points out, so ensure they're off in the current task case like they are in padata_parallel_worker to avoid this situation.
    (CVE-2022-50382)

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

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

  - net/mlx5e修复 mlx5e_fs_tt_redirect_any_create 中的内存泄漏 在 mlx5e_fs_tt_redirect_any_create 的错误路径中未释放 fs->any 指针指向的内存可导致内存泄漏。通过释放错误路径中的内存从而使错误路径等同于 mlx5e_fs_tt_redirect_any_destroy() 来修复。 (CVE-2023-53371)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) (CVE-2023-53378)

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

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

  - ANGLE 中的堆缓冲区溢出漏洞。由 Google Big Sleep 于 2025 年 8 月 12 日报告。(CVE-2025-10502)

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

ID	名称	严重性
265613	Linux Distros 未修补的漏洞：CVE-2023-53336	medium
265612	Linux Distros 未修补的漏洞：CVE-2023-53398	high
265611	Linux Distros 未修补的漏洞：CVE-2023-53415	medium
265610	Linux Distros 未修补的漏洞：CVE-2023-53393	medium
265609	Linux Distros 未修补的漏洞：CVE-2023-53400	medium
265608	Linux Distros 未修补的漏洞：CVE-2023-53390	medium
265607	Linux Distros 未修补的漏洞：CVE-2023-53386	high
265606	Linux Distros 未修补的漏洞：CVE-2022-50375	medium
265605	Linux Distros 未修补的漏洞：CVE-2025-10585	high
265604	Linux Distros 未修补的漏洞：CVE-2023-53385	medium
265603	Linux Distros 未修补的漏洞：CVE-2023-53401	medium
265602	Linux Distros 未修补的漏洞：CVE-2023-53377	high
265601	Linux Distros 未修补的漏洞：CVE-2022-50380	medium
265600	Linux Distros 未修补的漏洞：CVE-2022-50379	medium
265599	Linux Distros 未修补的漏洞：CVE-2023-53382	medium
265598	Linux Distros 未修补的漏洞：CVE-2023-53409	medium
265597	Linux Distros 未修补的漏洞：CVE-2023-53372	high
265596	Linux Distros 未修补的漏洞：CVE-2025-41249	high
265595	Linux Distros 未修补的漏洞：CVE-2025-59518	high
265594	Linux Distros 未修补的漏洞：CVE-2022-50365	medium
265593	Linux Distros 未修补的漏洞：CVE-2023-53366	medium
265592	Linux Distros 未修补的漏洞：CVE-2022-50343	medium
265591	Linux Distros 未修补的漏洞：CVE-2022-50358	medium
265590	Linux Distros 未修补的漏洞：CVE-2022-50357	medium
265589	Linux Distros 未修补的漏洞：CVE-2023-53314	medium
265588	Linux Distros 未修补的漏洞：CVE-2023-53311	high
265587	Linux Distros 未修补的漏洞：CVE-2023-53345	medium
265586	Linux Distros 未修补的漏洞：CVE-2022-50354	medium
265585	Linux Distros 未修补的漏洞：CVE-2023-53408	medium
265584	Linux Distros 未修补的漏洞：CVE-2022-50392	medium
265583	Linux Distros 未修补的漏洞：CVE-2023-53369	medium
265582	Linux Distros 未修补的漏洞：CVE-2022-50388	medium
265581	Linux Distros 未修补的漏洞：CVE-2023-53391	medium
265580	Linux Distros 未修补的漏洞：CVE-2023-53380	medium
265579	Linux Distros 未修补的漏洞：CVE-2023-53410	medium
265578	Linux Distros 未修补的漏洞：CVE-2023-53402	medium
265577	Linux Distros 未修补的漏洞：CVE-2023-53387	medium
265576	Linux Distros 未修补的漏洞：CVE-2022-50393	medium
265575	Linux Distros 未修补的漏洞：CVE-2022-50394	high
265574	Linux Distros 未修补的漏洞：CVE-2022-50396	medium
265573	Linux Distros 未修补的漏洞：CVE-2023-53373	high
265572	Linux Distros 未修补的漏洞：CVE-2023-53394	medium
265571	Linux Distros 未修补的漏洞：CVE-2025-30187	low
265570	Linux Distros 未修补的漏洞：CVE-2025-10501	high
265569	Linux Distros 未修补的漏洞：CVE-2023-53411	medium
265568	Linux Distros 未修补的漏洞：CVE-2022-50381	medium
265567	Linux Distros 未修补的漏洞：CVE-2022-50382	medium
265566	Linux Distros 未修补的漏洞：CVE-2023-53371	medium
265565	Linux Distros 未修补的漏洞：CVE-2023-53378	medium
265564	Linux Distros 未修补的漏洞：CVE-2025-10502	high

检测

Nessus 的 Misc. 系列

medium

high

medium

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

low

high

medium

medium

medium

medium

medium

high