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

  - wifiath11k忽略 dp 中来自未初始化对等机的碎片。如果在所有具有 ACS 的区域中配置 max virtual ap 接口并且每 60 秒进行 hostapd 重新启动则会在随机时间观察到崩溃。在这种情况下系统会收到自身对等体的拆分数据包其 rx_tid 和 rx_frags 未在数据路径中初始化。在处理此碎片时由于 rx_frag 列表未初始化而且当进入 ath11k_dp_rx_h_sort_frags 时由于 skb null 导致异常发现崩溃。为解决此问题在处理收到的片段之前我们会检查 dp_setup_done 标记是否设置以确保对等机已为片段队列完成其 dp 对等机设置否则将忽略对片段的处理。调用跟踪
    ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0 /0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1CVE-2023-53822

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

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

  - s390/idle标记 arch_cpu_idle() noinstr linux-next 提交 (cpuidle跟踪: 关于 !rcu_is_watching() 的警告) 增加了命中 s390 的 arch_cpu_idle() 函数的新警告RCU not on for
    arch_cpu_idle+0x0/0x28 WARNINGinclude/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258 中链接的 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6 -next-20230202 #4 硬件名称IBM 8561 T01 703 (z/VM 7.3.0) Krnl PSW : 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258) R:0 T:1 IO:0 EX:0 Key:0 M 1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000 0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000 0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0 0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8 Krnl Code: 00000000002b55b0: c02000840051 larl %r2 ,0000000001335652 00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58 #00000000002b55bc: af000000 mc 0,0 >00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e 00000000002b55c4: 0707 bcr 0,%r7 00000000002b55c6: 0707 bcr 0,%r7 00000000002b55c8:
    eb6ff0480024 stmg %r6,%r15,72(%r15) 00000000002b55ceb90400ef lgr %r14,%r15 调用跟踪
    [<00000000002b55c0>] arch_ftrace_ops_list_func+0x250/0x258 ([<00000000002b55bc>] arch_ftrace_ops_list_func+0x24c/0x258) [<0000000000f5f0fc>] ftrace_common+0x1c/0x20 [<00000000001044f6>] arch_cpu_idle+0x6/0x28 [<0000000000f4acf6>] default_idle_call+0x76/0x128 [<00000000001cc374>] do_idle+0xf4/0x1b0 [<00000000001cc6ce>] cpu_startup_entry+0x36/0x40 [<0000000000119d00>] smp_start_secondary+0x140/0x150 [<0000000000f5d2ae>] restart_int_handler+0x6e/0x90 将 arch_cpu_idle() 标记为 noinstr与所有其他具有 CONFIG_ARCH_WANTS_NO_INSTR 的架构一样具有 CONFIG_ARCH_WANTS_NO_INSTR应该将其设置为修复此问题。
    (CVE-2023-53859)

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

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

  - drm/gpusvm修复 hmm_pfn_to_map_order() 的使用。处理 hmm 范围部分覆盖一个大页面如 2M的情况否则我们可能会以执行某些恶意操作而告终例如映射超出范围甚至可能未映射的内存以 mm 为单位。修复基于 xe userptr 代码该代码在未来的修补程序中将直接使用 gpusvm因此此处需要对齐。 v2 - 添加 kernel-doc (Matt B) - s/fls/ilog2/ (Thomas) (CVE-2025-40336)

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

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

  - ASoCIntelavs关闭 PCM 时禁用经过时间工作 avs_dai_fe_shutdown() 在经过时间工作为其 IRQ 服务时处理主机 HDAudio 流的关闭程序。由于前者释放 DAI 的私有上下文因此应同步这两个操作以避免 slab 释放后使用或更严重的错误。 (CVE-2025-40344)

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

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

  - drm/amdgpu验证 userq 输入参数 这有助于验证 userq 输入参数并在 IOCTL 首先位置拒绝无效的 userq 请求。 (CVE-2025-40335)

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

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

  - iavf使用内部状态释放流量 IRQ如果系统尝试在 iavf_reset_task() 运行时关闭 netdev__LINK_STATE_START 将被清除且 netif_running() 将在 iavf_reinit_interrupt_scheme() 中返回 false。这将导致 iavf_free_traffic_irqs() 不被调用并导致如下泄漏[7632.489326] remove_proc_entry删除非空目录 'irq/999'至少泄漏 'iavf-enp24s0f0v0-TxRx-0' [7632.490214] 警告之后调用 pci_disable_msix() 时会显示 fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0 中的 CPU0 PID10。通过使用内部适配器状态进行修复。如果 state == __IAVF_RUNNING流量 IRQ 将始终存在。 (CVE-2023-53850)

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

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

  - drm/sched修复 drm_sched_entity_kill_jobs_cb 中的死锁 下面引用的 Mesa 问题指出了可能的死锁[ 1231.611031] 可能的中断不安全锁定场景[ 1231.611033] CPU0 CPU1 [1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** 在此示例中CPU0 可以是通过不禁用中断的 xa_* 函数访问 job->dependencies 的任何函数例如
    drm_sched_job_add_dependency()、drm_sched_entity_kill_jobs_cb()。CPU1 正在中断上下文中将 drm_sched_entity_kill_jobs_cb() 作为屏蔽信号回调执行。当尝试获取已由 CPU0 占用的 xa_lock 时将会死锁。将所有 xa_* 使用替换为其 xa_*_irq 副本可以修复此问题但 Christian 指出了另一个问题dma_fence_signal 占用 fence.lockdma_fence_add_callback 也如此。 dma_fence_signal() // 锁定 f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreachdependencies -> dma_fence_add_callback() // 锁定 f2.lock如果 f1 和 f2 共享相同的旋转锁将会死锁。为修复两个问题迭代依存关系并重新配置它们的代码被移出 drm_sched_entity_kill_jobs_work()。 [phasta提交消息 nits]CVE-2025-40329

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

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

  - drm/xe修复运行 core_hotunplug 测试时 xe_gem_fault 中的 oops。对未启用调试选项的实时内核运行 xe-fast-feedback 测试列表时我在 xe_gem_fault 中发现一个 oops。core_hotunplug unbind-rebind 完成后会发生错误。据推测发生的情况是进程 mmap由于 FAULT_FLAG_RETRY_NOWAIT 逻辑而解锁时没有剩余任何进程内存从而导致 ttm_bo_vm_dummy_page() 返回 VM_FAULT_NOPAGE因为没有剩余可填充的内存然后在 mem_type_is_vram(tbo->resource-> mem_type)因为 tbo->resource 为 NULL。它虽然复杂，但适合数据并解释测试退出后的 oops。 (CVE-2025-40340)

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

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

  - netstmmac正确处理 Rx 校验和卸载错误 如果启用了硬件校验和卸载 (CoE) 并且数据包为已知 IP ethertype 则 stmmac_rx 函数会之前将 skb->ip_summed 设置为 CHECKSUM_UNNECESSARY。但是，此逻辑无法检查硬件是否实际报告了校验和错误。此阶段指示标头或负载校验和失败的硬件状态被忽略。这可导致损坏的数据包当有效时在网络堆栈中向上传递。此修补程序通过检查“csum_none”状态标记修正逻辑该标记是在硬件报告校验和错误时设置的。如果设置了此标记skb->ip_summed 现在会正确设置为 CHECKSUM_NONE从而确保内核的网络堆栈将执行其自身的验证并正确处理损坏的数据包。
    (CVE-2025-40337)

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

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

  - drm/amdkfd修复 mmap 写入锁定未释放如果在耗尽重试错误时采用 mmap 写入锁定则 mmap 写入锁定不会释放因为 svm_range_restore_pages 调用 mmap_read_unlock 然后返回。这会在稍后造成死锁和系统挂起因为无法进行 mmap 读取或写入锁定。如果耗尽重试错误修复此缺陷将 mmap 写入锁定降级为读取锁定。 (CVE-2025-40332)

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

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

  +
    1) 如果借助 cgroupfs 启用 iocost/iolatency 来触发 rq_qos_add()则可与 del_gendisk() 并发但并发写入“q->rq_qos”不安全。 2) 激活依赖的 cgroup 策略rq_qos 将调用 rq_qos_add() 和 blkcg_activate_policy()如果在中间调用 rq_qos_exit()则将在 blkcg_activate_policy() 中触发 null-ptr-dereference。 3) blkg_conf_open_bdev() 可首先调用 blkdev_get_no_open() 以寻找磁盘此后如果在 rq_qos_add() 之前完成 del_gendisk() 中的 rq_qos_exit()则会泄露内存。此修补程序添加了新的磁盘级别互斥体“rq_qos_mutex”1) 锁定将直接保护 rq_qos_exit()。 2) 对于不依赖 blk-cgroup 的 wbt目前只能从磁盘初始化调用 rq_qos_add()因为在 rq_qos_exit() 之前无法破坏 wbt因此目前不保护 wbt 是安全的。然而如果未来支持 rq_qos 动态破坏此修补程序也会直接保护 rq_qos_add() 不受 wbt_init() 影响这已足够因为 blk-sysfs 已使写入程序与磁盘删除同步。 3) 对于 iocost 和 iolatency为了同步磁盘删除和 cgroup 配置会在 blkg_conf_open_bdev() 的 blkdev_get_no_open() 之后保持锁定并在 blkg_conf_exit() 中释放。为了修复上述内存泄漏会在持有新的锁之后检查 disk_live()。 (CVE-2023-53823)

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

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

  - RDMA/siw修复 QP 破坏以等待丢弃所有引用。延迟 QP 破坏完成直到终止所有引用 QP 的 siw。调用 RDMA 核心将在从 siw_qp_destroy() 调用成功返回之后释放 QP 结构因此 siw 在返回时不得持有任何对 QP 的剩余引用。测试 NFSoRDMA 时在 xfstest generic/460 中遇到释放后使用。此处在 TCP 连接被对等机中断后触发的 siw_cm_work_handler 会延迟直到引用已释放的 QP 的 QP 破坏调用之后。 (CVE-2022-50666)

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

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

  - nvme-fc使用锁定访问 port_state 和 rport 状态 当没有活动关联时nvme_fc_unregister_remote 会随时删除 lport 对象上的远程端口。这与重新连接逻辑争用，因为 nvme_fc_create_association 未锁定以检查 port_state 及自动增加 rport 上的活动计数。 (CVE-2025-40342)

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

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

  - drm/amdgpu修复 vm_handle_moved 的 nullptr 错误若 amdgpu_bo_va 为 fpriv->prt_va则其 bo 始终为 NULL。因此此类 amdgpu_bo_va 应在 amdgpu_vm_handle_moved 之前单独更新。
    (CVE-2025-40339)

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

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

  - f2fs修复以对 truncate_dnode() 中的直接节点进行健全性检查 syzbot 报告如下缺陷BUG: KASAN
    存在 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 在 addr ffff88802a25c000 中大小为 4 的读取 (syz-executor148/5000 CPU: 1 PID: 5000 Comm: syz-executor148 未受感染 6.4) .0-rc7-syzkaller-00041-ge660abd551f1 #0 硬件名称Google Google Compute Engine/Google Compute EngineBIOS Google 05/27/2023 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9 /0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report .c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/fs0fs0fs_block_donode.c:1154/ 0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h :825 [内联] f2fs_setattr+0x1738 /0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [内联] do_open fs/namei .c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c 1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd根本原因是 inodeA 通过 inodeB 的 ino 引用 inodeB一旦 inodeA 被截断它将调用 truncate_dnode() 来截断数据块在 inodeB 的节点页面中其会遍历从 node->i.i_addr[0] 到 node->i.i_addr[ADDRS_PER_BLOCK() - 1] 的映射数据导致越界访问。此修补程序用于在 truncate_dnode() 中的 dnode 页面上添加健全性检查以便有助于避免触发此类问题一旦遇到此类问题会将新引入的 ERROR_INVALID_NODE_REFERENCE 错误记录到超级块中稍后 fsck 可以检测到此类问题并尝试修复。
    此外其还删除了 f2fs_truncate_data_blocks() 进行清理原因是此函数只有一个调用者并改用 f2fs_truncate_data_blocks_range()。 (CVE-2023-53846)

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

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

  - f2fs修复 __insert_extent_tree() 中的无限循环 获取错误的范围信息数据并在 rb 树中查找 extent_node 时会造成无限循环 (CONFIG_F2FS_CHECK_FS=n)。通过在这种情况下返回 NULL 并打印一些内核消息来避免这种情况。 (CVE-2025-40333)

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

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

  - ofoverlay过早调用 of_changeset_init() of_overlay_fdt_apply() 失败时更改集可能会部分应用调用程序仍会调用 of_overlay_remove() 以清理此部分状态。然而 of_overlay_apply() 在 init_overlay_changeset() 之前调用 of_resolve_phandles()。因此如果叠加因未解析的符号而无法应用overlay_changeset.cset.entries 列表仍将未初始化清理将因 overlay_removal_is_ok() 中的空指针取消引用而崩溃。通过将对 of_changeset_init() 的调用从 init_overlay_changeset() 移动到 of_overlay_fdt_apply()在所有其他早期初始化完成的地方可修复此问题。 (CVE-2023-53856)

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

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

  - nvmet-fc避免两次计划关联删除。通过 configfs 接口强制关闭端口时nvmet_port_subsys_drop_link() 首先调用 nvmet_port_del_ctrls() 然后调用 nvmet_disable_port()。这两个函数最终都将计划删除所有剩余的关联。当前实现会检查关联是否将要删除但仅在计划工作项目之后才会检查。因此第一个计划的工作项目可能会释放所有资源然后同一个工作项目可能会被再次计划删除。由于关联列表为 RCU 列表因此无法锁定和直接删除列表条目因此无法再次查找。相反，必须使用标记（正在终止）来确定该关联是否正在被删除。 (CVE-2025-40343)

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

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

  - sctp防止 TOCTOU 越界写入 对于不保持 sock 锁定的以下路径sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() 确保不越界以防地址列表在缓冲区分配期间增长(time-of-check) 和写入 (time-of-use)。 (CVE-2025-40331)

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

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

  - drm/msm/dp终止 aux 设备以及 DP 控制器使用 devres 取消填充 aux 总线可确保在探测延迟时EDP 面板设备会在下次尝试时遭到破坏并重新创建。但 devres 绑定到的结构设备是 DPU (drm_dev->dev)这可能在破坏 DP 控制器后发生。在日志中常见的全为零的 EDID-hexdump或偶尔/罕见的 KASAN 错误其中面板尝试读取 EDID 信息造成释放后使用 DP 资源时可以看到此问题的迹象。您可能会倾向于将 devres 移动到 DP 控制器的 struct device但 aux 总线上的设备使用的资源已在错误路径中明确拆卸。
    KASAN 报告的释放后使用仍然存在因为 DP aux 模块会在此代码路径中明确释放其 devres 分配的内存。因此请明确错误路径中和组件取消绑定路径中的 aux 总线以避免这些问题。patchwork
    https://patchwork.freedesktop.org/patch/542163/ (CVE-2023-53851)

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

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

  - iio: adc: ina2xx避免 OF 设备匹配上的空指针取消引用受影响的行在我们的平台上会导致空指针取消引用因为设备树包含下列兼容字符串power- sensor@40 {compatible = ti, ina232、ti、ina231; ... };由于 驱动程序未声明兼容字符串 ti,ina232OF 在 ti,ina231 上匹配成功。但 I2C 设备 ID 信息是通过第一个兼容字符串填充的请参阅of_i2c_get_board_info() 中的 modalias 填充。由于在旧 I2C 设备 ID 表中也没有 ina232 条目因此探测函数中的 struct i2c_device_id *id 指针为 NULL。通过使用已填充的类型变量使该变量指向正确的驱动程序数据来修复此问题。由于也需要名称因此请向 ina2xx_config 表添加一个通用名称。 (CVE-2023-53834)

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

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

  - ASoCIntelavs请勿在组件之间共享名称指针通过直接共享“name”拆卸组件可能会导致释放后使用错误。复制名称以避免发生这种情况。同时更新操作顺序 - 自提交 cee28113db17ASoCdmaengine_pcm允许通过配置传递组件名称如果在调用初始化程序之前设置框架不会替代component->name。
    (CVE-2025-40338)

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

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

  - bpfbpf_sk_storage修复无效的等待上下文 lockdep 报告“./test_progs -t test_local_storage”报告了 splat[ 27.137569] ======================= ====== [ 27.138122] [ BUG无效等待上下文 ] [27.138650] 6.5.0-03980-gd11ae1b16b0a #247 受感染GO [ 27.139542] ------------- ---------------- [27.140106] test_progs/1729 尝试锁定[ 27.140713] ffff8883ef047b88 ( stock_lock){-.-.}-{3:3}位于
    local_lock_acquire+0x9/0x130 [ 27.141834] 可能有助于我们调试此问题的其他信息[ 27.142437] context-{5:5} [ 27.142856] test_progs/1729 保留的 2 个锁[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock ){....}-{1:3}在 rcu_lock_acquire+0x4/0x40 中 [ 27.144492] #1ffff888107deb2c0 (&storage->lock){..-.}-{2:2}在 bpf_local_storage_update+ 0x39e/0x8e0 [ 27.145855] 堆栈回溯[27.146274] CPU: 0 PID: 1729 Comm: test_progs 受感染的 GO 6.5.0-03980-gd11ae1b16b0a #247 [ 27.147550] 硬件名称QEMU Standard PC（i440FX + PIIX、 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org04/01/2014 [ 27.149127] 调用跟踪[ 27.149490] <TASK> [ 27.149867] dump_stack_lvl+0x130/0x1d0 [27.152609] dump_stack +0x14/0x20 [ 27.153131] __lock_acquire+0x1657/0x2220 [ 27.153677] lock_acquire+0x1b8/0x510 [ 27.157908] local_lock_acquire+0x29/0x130 [ 27.159048] obj_cgroup_charge+0xf4/0x3c0 [ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0 [ 27.161931]
    __kmem_cache_alloc_node+0x51/0x210 [ 27.163557] __kmalloc+0xaa/0x210 [ 27.164593] bpf_map_kzalloc+0xbc/0x170 [ 27.165147] bpf_selem_alloc+0x130/0x510 [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0 [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0 [ 27.169199] bpf_map_update_value+0x415/0x4f0 [ 27.169871] map_update_elem+0x413/0x550 [ 27.170330]
    __sys_bpf+0x5e9/0x640 [ 27.174065] __x64_sys_bpf+0x80/0x90 [ 27.174568] do_syscall_64+0x48/0xa0 [27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 27.175932] RIP: 0033:0x7effb40e41ad [ 27.17635766 ff c 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff 01 ff 73 8 8b 0d8 [ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141 [ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX:
    00007effb40e41ad [ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002 [27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788 [ 27.183038] R10:
    0000000000000064 R110000000000000202 R120000000000000000 [ 27.184006R13]  00007ffe64c22788 R14
    00007effb42a1000 R15: 0000000000000000 [ 27.184958</TASK> ] 抱怨在保持 raw_spin_lock 的同时获取 local_lock。这意味着它不应在持有 raw_spin_lock 时分配内存，因为它对 RT 不安全。需要 raw_spin_lock 是因为 bpf_local_storage 支持跟踪上下文。特别是对于任务本地存储可以轻松跟踪 bpf prog 中的获取当前任务 PTR_TO_BTF_ID。
    不过任务和 cgroup 本地存储已移动到 bpf mem 分配器其可在 raw_spin_lock 之后使用。splat 用于 sk 存储。对于 sk（和 inode）存储，尚未将其移动到 bpf mem 分配器。无论是否使用 raw_spin_lockkzalloc(GFP_ATOMIC) 理论上在跟踪上下文中都可能是不安全的。但是，本地存储帮助程序需要验证程序接受的 sk 指针 (PTR_TO_BTF_ID)这是假设如果可能发生即意味着在 kzalloc 不安全的上下文中运行 bpf prog 并且也能够保持验证程序接受的 sk 指针。此修补程序避免 raw_spin_lock 之后的 kzalloc 来静默 splat。在 raw_spin_lock 之前存在一个 kzalloc。此时很可能需要 kzalloc因为之前刚完成过查找。因此此修补程序始终在 acq 之前执行 kzalloc ---truncated--- (CVE-2023-53857)

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

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

  - ASoCsoc-compress重新定位并添加 pcm_mutex如果已设置 panic_on_warn 并启动 compress stream(DPCM)则会发生内核错误这是因为未适当保留 card->pcm_mutex。在以下函数中此行发出警告 snd_soc_dpcm_mutex_assert_held。 static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ...
    snd_soc_dpcm_mutex_assert_held(fe) ... } void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { ... snd_soc_dpcm_mutex_assert_held(rtd); ... } int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, int event) { ...
    snd_soc_dpcm_mutex_assert_held(fe) ... } 这些函数由 soc_compr_set_params_fe、soc_compr_open_fe 和 soc_compr_free_fe 调用而无 pcm_mutex 锁定。这是调用堆栈。 [ 414.527841][T2179] pcdpcm_process_paths+0x5a4/0x750 [ 414.527848][ T2179] lrdpcm_process_paths+0x37c/0x750 [414.527945][ T2179] 调用跟踪 [ 414.527949][ T2179] dpcm_process_paths +0x5a4/0x750 [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc [ 414.527972][ T2179] snd_compr_open+0x180/0x248 [ 414.527981][ T2179] snd_open+0x15c/0x194 [ 414.528003][ T2179] chrdev_open+0x1b0/0x220 [ 414.528023][ T2179] do_dentry_open+0x30c/0x594 [ 414.528045][ T2179] vfs_open+0x34/0x44 [ 414.528053][ T2179] path_openat+0x914/0xb08 [ 414.528062][ T2179] do_filp_open+0xc0/0x170 [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4 [ 414.528084][ T2179] invoke_syscall+0x48/0x10c [ 414.528094][ T2179] el0_svc_common+0xbc/0x104 [ 414.528099][ T2179] do_el0_svc+0x34/0xd8 [ 414.528103][ T2179] el0_svc+0x34/0xc4 [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4 [ 414.528142][ T2179] 内核错误 - 不同步panic_on_warn 设置 ... 因此，我重新定位并添加 pcm_mutex 以解决 lockdep 错误。
    (CVE-2023-53866)

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

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

  - vc_screen重新加载 vcs_write() 中结构 vc_data 指针以避免 UAF 在 vcs_write() 中调用 console_unlock() 后vc_port_destruct() 可释放 vc_data 结构。因此必须在 console_lock() 之后在 vcs_write() 中的 while 循环中重新加载 struct vc_data 指针以避免在调用 vcs_size() 时发生 UAF。Syzkaller 报告了 vcs_size() 中的 UAF。BUGKASANvcs_size 中存在 slab 释放后使用 (drivers/tty/vt/vc_screen.c:215) 通过任务 repro_vcs_size/4119 调用跟踪在地址 ffff8880beab89a8 读取大小 4 <TASK> __asan_report_load4_noabort (mm/kasan/report_generic) .c:380) vcs_size (drivers/tty/vt/vc_screen.c:215) vcs_write (drivers/tty/vt/vc_screen.c:664) vfs_write (fs/read_write.c:582 fs/read_write.c:564) ...<TASK> 按任务分配 1213kmalloc_trace (mm/slab_common.c:1064) vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680 drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058con_install (drivers/tty/vt/vt.c:3334) tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415 drivers/tty/ tty_io.c:1392) tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128) chrdev_open (fs/char_dev.c:415) do_dentry_open (fs/open.c:921) vfs_open (fs /open.c:1052) ... 由任务 4116kfree (mm/slab_common.c:1016) vc_port_destruct (drivers/tty/vt/vt.c:1044) tty_port_destructor (drivers/tty/tty_port.c:296) tty_port_put (drivers/tty/tty_port.c) 释放312) vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discharger 2)) vt_ioctl (drivers/tty/vt/vt_ioctl.c:903) tty_ioctl (drivers/tty/tty_io.c:2778) ... 有缺陷的地址属于 ffff8880beab8800 的对象该对象属于大小为 1024 的缓存 kmalloc-1k 有缺陷的地址位于已释放的 1024 字节区域内 424 字节 [ffff8880beab8800、ffff8880beab8c00) 有缺陷的地址属于物理页: 页00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbeab8 head:00000000afc77580 order:3 complete_mapcount:0 nr_pages_mapped:0 pincount:0 flags
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    ffff8880beab8880fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8900fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880beab8980fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880beab8a00fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8a80fb fb fb fb fb fb fb fb fb fb fb fb fb fb ======== ================================================== ======== 由于内核感染而禁用锁定调试 (CVE-2023-53747)

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

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

  - HIDhidraw修复设备引用计数上的数据争用 hidraw_open() 函数会递增 hidraw 设备引用计数器。该计数器没有专用的同步机制因此在并发打开设备时可能导致数据争用。争用为提交 8590222e4b02 引入的回归 (HID
    hidraw将 hidraw 设备表互斥体替换为 rwsem。尽管 minors_rwsem 本应通过获取写入锁定来保护 hidraw_table 本身但引用计数器也会受到保护。
    这与 hidraw_release() 对称。 (CVE-2023-53759)

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

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

  - net处理 kmalloc_reserve() 责备的提交中处理整数溢出 ptr = kmalloc(size); if (ptr) 大小 = ksize(ptr);大小 = kmalloc_size_roundup(size); ptr = kmalloc(size);这允许 syzbot [1] 和 Kyle Zeng 报告的多种崩溃。问题是如果 @size 大于 0x80000001kmalloc_size_roundup(size) 会返回 2^32。 kmalloc_reserve() 使用 32 位变量 (obj_size)因此 2^32 被截断为 0。kmalloc(0) 返回 ZERO_SIZE_PTR 未经 skb 分配处理。如果 netdev->mtu 设置为接近 0x7ffffffff 则可触发以下跟踪 我们将来可能会将 netdev->mtu 限制为更合理的限制如 KMALLOC_MAX_SIZE。此修补程序基于 syzbot 报告以及 Kyle Zeng 提供的报告和试用补丁。 [1] BUGKASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [内联] BUG:KASAN: user-memory-access 在 __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 中由任务 syz-executor.4/22554 CPU10在地址 00000000fffffd10写入大小 32 PID1
    22554 Commsyz-executor.4 Not tainted 6.1.39-syzkaller #0 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 07/03/2023 调用跟踪 dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/ stacktrace.c:279 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106 print_report+0xe4/0x4b4 mm /kasan/report.c:398 kasan_report+0x150/0x1ac mm/kasan/report.c:495 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 memset+0x40/0x70 mm/kasan/shadow.c:44 __build_skb_around net/core/skbuff.c:294 [内联] __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 alloc_skb include/linux/skbuff.h:1316 [内联] igmpv3_newpack+0x104/0x1088 net/ipv4/igmp .c:359 add_grec+0x81c/0x1124 net/ipv4/igmp.c:534 igmpv3_send_cr net/ipv4/igmp.c:667 [inline] igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810 call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [内联]
    __run_timers+0x54c/0x710 kernel/time/timer.c:1790 run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
    _stext+0x380/0xfbc____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79 call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891 do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq。 c:84 invoke_softirq kernel/softirq.c:437 [内联] __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683 irq_exit_rcu+0x14/0x78 kernel/softirq.c:695 el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry -common.c:717
    __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724 el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729 el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S 584 (CVE-2023-53752)

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

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

  - drm/amdgpu/powerplay/psm修复电源状态 init 中的内存泄漏 Commit 902bc65de0b3drm/amdgpu/powerplay/psm在电源状态 init 中返回错误使电源状态 init 函数在无法获取条目期间未正确清理返回之前为当前电源状态分配的内存。 (CVE-2022-50617)

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

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

  - 在 release-4.3.5-patches 之前的 libcoap 中libcoap 的 OSCORE 配置解析器中存在内存泄露漏洞。解析某些配置值时可能发生越界读取从而允许攻击者推断或读取 .rodata 部分中字符串边界之外的内存。这可能导致信息泄露或拒绝服务。 (CVE-2025-59391)

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

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

  - PCI在合并 release_resource() 之后释放已释放的资源实际上未释放资源或资源列表条目因此会释放资源列表条目以避免泄漏。 (CVE-2023-53743)

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

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

  - mmcmeson-gx修复 mmc_add_host() 的返回值检查 mmc_add_host() 可能返回错误如果忽略其返回值将导致两个问题1. 在 mmc_alloc_host() 中分配的内存泄漏。 2. 在 remove() 路径中将调用 mmc_remove_host() 来删除设备但尚未添加设备会将内核崩溃因为 device_del() 中的 null-ptr-deref。通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题。 (CVE-2022-50618)

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

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

  - dmverity-loadpin仅信任具有强制执行 Verity 目标的 verity 目标可配置为忽略损坏的数据块。LoadPin 必须仅信任配置为在检测到数据损坏时执行某种强制执行的版本目标，例如返回错误、重新启动系统或触发错误。 (CVE-2022-50621)

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

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

  - scsiufscoremcq修复 &hwq->cq_lock 死锁问题 当 ufshcd_err_handler() 执行时CQ 事件中断可进入等待相同的锁定。ufshcd_handle_mcq_cq_events() 和 ufs_mtk_mcq_intr() 中可能发生这种情况。在启用了 IRQ 的 IRQ 上下文中使用 &hwq->cq_lock 时将生成以下警告消息。将 ufshcd_mcq_poll_cqe_lock() 与 spin_lock_irqsave 搭配使用而非 spin_lock 以解决死锁问题。 [name:lockdep&]警告不一致的锁定状态 [name:lockdep&]-------------------------------- [name lockdep]{IN-HARDIRQ-W} -> {HARDIRQ-ON-W} 用法不一致。 [name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] getsffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}位于ufshcd_mcq_poll_cqe_lock+0x30/0xe0 [name:lockdep&]{IN-HARDIRQ-W} state was registered at: lock_acquire+0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod] __handle_irq_event_percpu+0x140/0x3ec handle_irq_event+0x50/0xd8 handle_fasteoi_irq+0x148/0x2b0 generic_handle_domain_irq+0x4c/0x6c gic_handle_irq+0x58/0x134 call_on_irq_stack+0x40/0x74 do_interrupt_handler+0x84/0xe4 el1_interrupt+0x3c/0x78 <snip> 可能不安全的锁定情况CPU0 ---- lock(&hwq->cq_lock);
    <Interrupt> lock(&hwq->cq_lock); *** DEADLOCK *** kworker/u16:4/260: [name:lockdep&] 堆栈回溯保持的 2 个锁CPU: 7 PID: 260 Comm: kworker/u16:4 受感染: GSW OE 6.1.17-mainline-android14-2-g277223301adb#1 Workqueue: ufs_eh_wq_0 ufshcd_err_handler Call trace: dump_backtrace+0x10c/0x160 show_stack+0x20/0x30 dump_stack_lvl+0x98/0xd8 dump_stack+0x20/0x60 print_usage_bug+0x584/0x76c mark_lock_irq+0x488/0x510 mark_lock+0x1ec/0x25c __lock_acquire+0x4d8/0xffc lock_acquire +0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufshcd_poll+0x68/0x1b0 ufshcd_transfer_req_compl+0x9c/0xc8 ufshcd_err_handler+0x3bc/0xea0 process_one_work+0x2f4/0x7e8 worker_thread+0x234/0x450 kthread+0x110/0x134 ret_from_fork+0x10/0x20 (CVE-2023-53760

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

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

  - USBusbtmc修复 0 长度 ioctl 控制消息的方向 syzbot fuzzer 在 usbtmc 驱动程序中发现一个问题 用户提交 0 长度控制传输的 ioctl 时驱动程序未检查方向是否设置为OUT:------------[ cut here ]------------ usb 3-1BOGUS 控制目录、管道 80000b80 与 bRequestType fd 警告不匹配 CPU 0 PID5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 中链接的模块CPU: 0 PID: 5100 Comm: syz-executor428 未受感染6.3.0-syzkaller-12049-g58390c8ce1bd #0 硬件名称Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411代码7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41 RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ff ff8880789e9058 RCX0000000000000000 RDXffff888029593b80 RSIffffffff814c1447 RDI0000000000000001 RBP
     R08ffff88801ea742f8  : 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528 R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100 FS:
    0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 调用跟踪 <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message。 c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline] usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097 若要修复此问题我们必须替代控件的 bRequestType 字段中的指示长度为 0 时的请求结构。(CVE-2023-53761

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

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

  - io_uring/rw确保清除分配的 iovec 以防止早期故障 之前的提交为及早清理重用了回收基础设施但这对于内部缓存已溢出的情况是不够的。如果发生这种情况并且请求也提早中止则可能会泄露分配的 iovec。
    恢复针对该情况之前的强制释放 iovec。 (CVE-2025-40267)

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

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

  - mediadvb-usb修复 dvb_usb_adapter_init() 中的内存泄漏 Syzbot 报告 dvb_usb_adapter_init() 中存在内存泄漏。造成此次泄漏的原因是在发生错误时未考虑和释放当前迭代的 adapter->priv。当前如果发生错误将在递增 num_adapters_initalized 之前退出其用作释放 dvb_usb_adapter_exit() 中所有 adap->priv 的引用计数器。在递增计数器之前有多个可导致 退出的错误路径。包含 dvb_usb_adapter_init() 内的 dvb_usb_adapter_stream_init()、dvb_usb_adapter_dvb_init() 和 dvb_usb_adapter_frontend_init() 的错误处理路径。这意味着如果其中任何函数发生错误，都不会考虑当前迭代，并且不会释放当前迭代的 adap->priv。通过在错误路径中的 stream_init_err: 标签中释放当前迭代的 adap->priv 以修复此问题。按照预期使用 num_adapters_initalized 变量在 dvb_usb_adapter_exit() 中释放其余的已解释的 adap->priv 对象。Syzbot 报告
    BUG内存泄露未引用对象 0xffff8881172f1a00 (大小 512)comm kworker/0:2pid 139jiffies 4294994873使用期限 10.960s) 十六进制转储前 32 字节前 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 00 00 00 ...... backtrace
    [<ffffffff844af012>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [inline] [<ffffffff844af012>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c 184 [inline] [<ffffffff844af012>] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308 [<ffffffff830db21d>] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb -usb/dib0700_core.c:883 [<ffffffff82d3fdc7>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [inline] [<ffffffff8274ab37>] real_probe .part.0+0xe7/0x310 drivers/base/dd.c:621 [<ffffffff8274ae6c>] real_probe drivers/base/dd.c:583 [inline] [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c 752 [<ffffffff8274af6a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782 [<ffffffff8274b786>]
    __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899 [<ffffffff82747c87>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [<ffffffff8274b352>] __device_attach+0x122/0x260 drivers/base/dd.c:970 [<ffffffff827498f6>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [<ffffffff82745cdb>] device_add+0x5fb/0xdf0 drivers/base/core.c:3405 [<ffffffff82d3d202>] usb_set_configuration+0x8f2/0xb80 drivers/usb/core /message.c:2170 [<ffffffff82d4dbfc>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<ffffffff82d3f49c>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [inline] [<ffffffff8274ab37>] real_probe.part.0+0xe7/0x310 drivers/base/dd.c:621 [<ffffffff8274ae6c>] real_probe drivers/base/dd.c:583 [ inline] [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752 (CVE-2022-50626)

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

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

  - virt/coco/sev-guest双缓冲区消息加密算法直接读取和写入未加密的共享内存这可能会泄露信息并允许主机篡改消息完整性。而是应在对其进行任何计算之前根据需要将整个消息复制进或复制出。
    (CVE-2023-53769)

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

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

  - serial: amba-pl011避免 SBSA UART 访问 DMACR 寄存器 ARM Server Base System Architecture [1] 文档中的 Chapter B Generic UART介绍了通用的 UART 接口。此类通用 UART 不支持 DMA。在当前代码中sbsa_uart_pops 和 amba_pl011_pops 共享相同的 stop_rx 操作这将调用 pl011_dma_rx_stop从而导致访问 DMACR 寄存器。此提交在 pl011_dma_rx_stop 中添加了using_rx_dma 检查以避免不支持 DMA 的 SBSA UART 访问 DMACR 寄存器。当内核通过 CONFIG_DMA_ENGINE=y 启用 DMA 引擎时Linux SBSA PL011 驱动程序将访问某些函数中的 PL011 DMACR 寄存器。对于大多数实际的 SBSA Pl011 硬件实现DMACR 写入行为将被忽略。因此这些 DMACR 操作不会造成明显的问题。但是某些虚拟 SBSA PL011 硬件如 Xen 虚拟 SBSA PL011 (vpl011) 设备则行为可能不同。当客户机访问未实现的 UART 寄存器时Xen vpl011 仿真将向客户机注入数据中止。由于 Xen VPL011 兼容 SBSA因此不会实现 DMACR 寄存器。因此当 Linux SBSA PL011 驱动程序访问 DMACR 寄存器时它将收到未处理的数据中止错误并且应用程序将收到分段错误Unhandled Fault at 0xffffffc00944d048 Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL)IL = 32 位 SET = 0FnV = 0 EA = 0S1PTW = 0 FSC = 0x00ttbr 地址大小错误 Data abort infoISV = 0ISS = 0x00000000 CM = 0WnR = 0 交换程序 pgtable4k 页 39 -bit VAs, pgdp=0000000020e2e000 [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 内部错误ttbr 地址大小错误 96000000 [#1] PREEMPT SMP ... Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+ 0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 代码b9000083 b901f001 794038a0 8b000042 (b9000041) ---[结束跟踪 83dd93df15c3216f ]--- 注意
    bootlogd[132] 退出并显示 preempt_count 1 /etc/rcS.d/S07bootlogd第 47 行132 分段错误 start-stop-daemon 此问题已在 Xen 社区中进行过讨论我们认为应在 Linux 中修复此问题。有关更多信息请参阅 [2]。 [1] https://developer.arm.com/documentation/den0094/c/?lang=en [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html (CVE-2022-50625)

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

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

  - drm/gud修复了 UBSAN 警告 UBSAN 抱怨 bool 的值无效[ 101.165172] [drm] 已初始化 2-3 的 gud 1.0.0 20200422。2:1.0 (针对次要 1) [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb 帧缓冲区设备 [ 101.213426] usbcore已注册新接口驱动程序 gud [ 101.989431] ===================== ================================================== ========= [ 101.989441] UBSAN
    linux/include/linux/iosys-map.h:253:9 中的 invalid-load [ 101.989447] 值 121 的负载不是“_Bool”类型的有效值 [ 101.989451] CPU: 1 PID: 455 Comm: kworker /1:6 未受感染 5.18.0-rc5-gud-5.18-rc5 #3 [101.989456] 硬件名称Hewlett-Packard HP EliteBook 820 G1/1991BIOS L71 Ver. 01.44 04/12/2018 [101.989459] Workqueueevents_long gud_flush_work [gud] [ 101.989471] 调用跟踪[ 101.989474] <TASK> [ [101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busies_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ [] ] drm_gem_vmap+0x26/0x1b0 [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_vmap+0x26/0x60 [drm] [[] ] [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [101.989708] ========================== ================================================== ==== 此警告的来源在从 dma_buf_vmap() 调用的 iosys_map_clear() 中。它会根据 map->is_iomem 有条件地设置值。未初始化在堆栈上分配 iosys_map 变量这将导致 ->is_iomem 具有所有类型的值而不仅仅是 0/1。通过将 iosys_map 变量清零来修复此问题。 (CVE-2022-50628)

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

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

  - c-ares 是一种异步解析器库。 1.32.3 到 1.34.5 版本在使用 read_answer() 和 process_answer() 时会在达到最大尝试次数后终止查询从而可造成拒绝服务。此问题已在 1.34.6 版本中修复。(CVE-2025-62408)

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

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

  - scsilpfc修复 lpfc_sli4_pci_mem_setup() 中的 ioremap 问题当 if_type 等于 0 且 pci_resource_start(pdev, PCI_64BIT_BAR4) 返回 false 时drbl_regs_memmap_p 未重新映射。这会将空指针传递给 iounmap()后者可在某些架构上触发 WARN()。当 if_type 等于 6 且 pci_resource_start(pdev, PCI_64BIT_BAR4) 返回 true 时drbl_regs_memmap_p 可能已重新映射而 ctrl_regs_memmap_p 未重新映射。这是资源泄漏会将空指针传递给 iounmap()。要修复这些问题需要在 iounmap() 之前添加 null 检查并更改某些 goto 标签。 (CVE-2023-53754)

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

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

  - miscpci_endpoint_test修复 pci_endpoint_test_{copy,write,read}() 错误dma_map_single() 不允许零长度映射。它会造成跟随错误。报告了 arm64 中的错误[ 60.137988]
    ------------[在这里切换 ]------------ [ 60.142630] kernel/dma/swiotlb.c:624! 的内核缺陷 60.147508[  ] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237 [60.193387] 硬件名称基于 r8a77951 的 Renesas Salvator-X 2nd 版本板 ( DT) [ 60.201302] pstate
    00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 60.208263] pc
    swiotlb_tbl_map_single+0x2c0/0x590 [ 60.213149] lrswiotlb_map+0x88/0x1f0 [ 60.216982] sp
    ffff80000a883bc0 [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000 [60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0 [ 60.234567] x23:
    0000000000000002 x22: 0001000040000010 x21: 000000007a000000 [ 60.241703] x20: 0000000000200000 x19
    0000000000000000 x18: 0000000000000000 [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15:
    ffff0006ff7b9180 [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000 [60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 60.270249] x8 :
    0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000 [ 60.277385] x5 : ffff0004c0da2090 x4
    0000000000000000 x3 : 0000000000000001 [ 60.284521] x2 : 0000000040000000 x1: 0000000000000000 x0
    0000000040000010 [ 60.291658] 调用跟踪[ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590 [ 60.298629] swiotlb_map+0x88/0x1f0 [ 60.302115] dma_map_page_attrs+0x188/0x230 [ 60.306299] pci_endpoint_test_ioctl+0xd90 [testpci_point/0xd90 60.312660] __arm64_sys_ioctl+0xa8/0xf0 [60.316583] invoke_syscall+0x44/0x108 [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0 [ 60.325038] do_el0_svc+0x2c/0xb8 [ 60.328351] el0_svc+0x2c/0x88 [ 60.331406] el0t_64_sync_handler+0xb8/0xc0 [60.335587] el0t_64_sync+0x18c/0x190 [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000) [60.345344] ---[ 结束跟踪 0000000000000要修复此修补程序检查负载长度是否为零。 (CVE-2022-50614)

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

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

  - 攻击者通过 TCP 发送 NOTIFY 查询可触发缓存记录的删除。 (CVE-2025-59030)

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

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

  - 攻击者可通过请求特制的 DNS 记录等待将其插入记录缓存然后发送 qtype 设置为 ANY 的查询进而触发断言失败。 (CVE-2025-59029)

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

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

  - io_uring修复 regbuf 矢量大小截断 有报告称 io_es推测_bvec_size() 会截断计算的段数从而导致损坏问题。检查其不会在稍后使用的整数上溢出。粗糙但简单可在此基础上进一步改进。 (CVE-2025-40291)

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

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

  - ext4修复 ext4_fc_record_modified_inode() 中潜在的内存泄漏由于 krealloc 可能返回 NULL在此情况下krealloc 可能不会释放“state->fc_modified_inodes”但“state->fc_modified_inodes”已设置为 NULL。然后 将导致“state->fc_modified_inodes”内存泄漏。 (CVE-2022-50622)

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

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

  - 磁盘管理工具 duc 的 buffer_get 函数中存在一个堆栈缓冲区溢出漏洞其中由于下溢可将一个条件评估为真从而允许越界读取。 (CVE-2025-13654)

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

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

  - exfat验证分配位图的群集分配位 syzbot 通过未为分配位图设置的群集位创建了 exfat 图像。 exfat-fs 读取并使用分配位图而不检查此项。问题在于如果分配位图的起始群集为 6则在使用 mkdir 创建目录时可分配群集 6。 exfat 会将 exfat_mkdir 中的此群集清零这可删除现有条目。这可以重新分配已分配的条目。此外分配位图也被清零因此可重新分配群集 6。此修补程序添加了 exfat_test_bitmap_range 以验证用于分配位图的群集是否正确标记为使用中。 (CVE-2025-40307)

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

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

  - usb小工具f_fs修复 ep 启用后的 epfile 空指针访问。当 ffs_func_eps_enable() 与 ffs_data_reset() 同时运行时发生争用条件。ffs_data_reset() 中调用的 ffs_data_clear() 先将 ffs->eps_count 重置为 0 之前将 ffs->epfiles 设为空进而导致在成功执行 usb_ep_enable() 之后访问 ffs_func_eps_enable() 中的 epfile->ep 时发生空指针取消引用。ffs->epfiles 指针在 ffs_data_clear() 和 ffs_data_close() 函数中设置为 NULL其修改受到旋转锁 ffs->eps_lock 保护。整个 ffs_func_eps_enable() 函数也受到 ffs->eps_lock 的保护。因此在 ffs_func_eps_enable() 函数中添加针对 ffs->epfiles 的空指针处理以修复问题 (CVE-2025-40315)

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

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

  - sctp防止 sctp_transport_update_rto 中可能的位移越界 syzbot 报告一个可能的位移越界 [1] 归责提交已添加 rto_alpha_max 和 rto_beta_max 设置为 1000。尚不清楚某些 sctp 用户是否正在设置非常大的 rto_alpha 和/或 rto_beta。为防止用户回归，请在运行时执行测试。此外还添加了 READ_ONCE() 注释因为我们可能会更改 sysctl 值。 [1] UBSAN
    net/sctp/transport.c:509:41 位移指数 64 中的位移越界对于 32 位类型“unsigned int”而言过大 CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 未受感染syzkaller #0 PREEMPT(full) 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 10/02/2025 调用跟踪 <TASK>
    __dump_stack lib/dump_stack.c:94 [内联] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [内联] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+ 0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline] (CVE-2025-40281)

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

ID	名称	严重性
277874	Linux Distros 未修补的漏洞：CVE-2023-53822	medium
277873	Linux Distros 未修补的漏洞：CVE-2023-53859	medium
277853	Linux Distros 未修补的漏洞：CVE-2025-40336	high
277852	Linux Distros 未修补的漏洞：CVE-2025-40344	medium
277851	Linux Distros 未修补的漏洞：CVE-2025-40335	medium
277850	Linux Distros 未修补的漏洞：CVE-2023-53850	medium
277849	Linux Distros 未修补的漏洞：CVE-2025-40329	medium
277848	Linux Distros 未修补的漏洞：CVE-2025-40340	medium
277847	Linux Distros 未修补的漏洞：CVE-2025-40337	medium
277846	Linux Distros 未修补的漏洞：CVE-2025-40332	high
277845	Linux Distros 未修补的漏洞：CVE-2023-53823	medium
277844	Linux Distros 未修补的漏洞：CVE-2022-50666	high
277843	Linux Distros 未修补的漏洞：CVE-2025-40342	high
277840	Linux Distros 未修补的漏洞：CVE-2025-40339	medium
277839	Linux Distros 未修补的漏洞：CVE-2023-53846	medium
277838	Linux Distros 未修补的漏洞：CVE-2025-40333	medium
277837	Linux Distros 未修补的漏洞：CVE-2023-53856	medium
277836	Linux Distros 未修补的漏洞：CVE-2025-40343	high
277835	Linux Distros 未修补的漏洞：CVE-2025-40331	high
277834	Linux Distros 未修补的漏洞：CVE-2023-53851	high
277833	Linux Distros 未修补的漏洞：CVE-2023-53834	medium
277832	Linux Distros 未修补的漏洞：CVE-2025-40338	high
277831	Linux Distros 未修补的漏洞：CVE-2023-53857	medium
277830	Linux Distros 未修补的漏洞：CVE-2023-53866	medium
277787	Linux Distros 未修补的漏洞：CVE-2023-53747	high
277786	Linux Distros 未修补的漏洞：CVE-2023-53759	medium
277785	Linux Distros 未修补的漏洞：CVE-2023-53752	high
277784	Linux Distros 未修补的漏洞：CVE-2022-50617	medium
277783	Linux Distros 未修补的漏洞：CVE-2025-59391	medium
277782	Linux Distros 未修补的漏洞：CVE-2023-53743	high
277781	Linux Distros 未修补的漏洞：CVE-2022-50618	medium
277780	Linux Distros 未修补的漏洞：CVE-2022-50621	medium
277779	Linux Distros 未修补的漏洞：CVE-2023-53760	medium
277778	Linux Distros 未修补的漏洞：CVE-2023-53761	medium
277777	Linux Distros 未修补的漏洞：CVE-2025-40267	medium
277776	Linux Distros 未修补的漏洞：CVE-2022-50626	medium
277775	Linux Distros 未修补的漏洞：CVE-2023-53769	high
277774	Linux Distros 未修补的漏洞：CVE-2022-50625	medium
277773	Linux Distros 未修补的漏洞：CVE-2022-50628	high
277772	Linux Distros 未修补的漏洞：CVE-2025-62408	medium
277771	Linux Distros 未修补的漏洞：CVE-2023-53754	medium
277770	Linux Distros 未修补的漏洞：CVE-2022-50614	medium
277742	Linux Distros 未修补的漏洞：CVE-2025-59030	high
277741	Linux Distros 未修补的漏洞：CVE-2025-59029	medium
277740	Linux Distros 未修补的漏洞：CVE-2025-40291	high
277739	Linux Distros 未修补的漏洞：CVE-2022-50622	medium
277730	Linux Distros 未修补的漏洞：CVE-2025-13654	high
277729	Linux Distros 未修补的漏洞：CVE-2025-40307	medium
277728	Linux Distros 未修补的漏洞：CVE-2025-40315	medium
277727	Linux Distros 未修补的漏洞：CVE-2025-40281	high

检测

Nessus 的 Misc. 系列

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

medium

medium

medium

high

medium

high

medium

high

medium

medium

high