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

  - USB小工具修复 usb config 切换期间的释放后重用。在将 USB config 从 rndis 切换到其他配置的过程中如果硬件不支持 ->pullup 回调或者硬件遇到低概率错误其中一个可能会造成 ->pullup 回调失败进而造成系统错误释放后使用。有时需要卸载小工具驱动程序而不管硬件的行为如何。分析如下============================================== ========================= (1) 写入 /config/usb_gadget/g1/UDC 无 gether_disconnect+0x2c/0x1f8 rndis_disable+0x4c/0x74 compound_disconnect+ 0x74/0xb0 configfs_composite_disconnect+0x60/0x7c usb_gadget_disconnect+0x70/0x124 usb_gadget_unregister_driver+0xc8/0x1d8 gadget_dev_desc_UDC_store+0xec/0x1e4 (2) rm /config/usb_gadget/g1/configs/b.1/f1 rndis_deregister+0x54/f1 rndis_deregister+0x54/f1 rndis_deregister+0x54/f1 0x7c usb_put_function+0x14/0x1c config_usb_cfg_unlink+0xc4/0xe0 configfs_unlink+0x124/0x1c8 vfs_unlink+0x114/0x1dc (3) rmdir /config/usb_gadget/g1/functions/rndis.gs4 panic+0x1fc/0x3d0 do_page_fault/0x4c8t+0x1dc8 /0xac el1_sync_handler+0x40/0x78 0xffffff801138f880 rndis_close+0x28/0x34 eth_stop+0x74/0x110 dev_close_many+0x48/0x194 rollback_registered_many+0x118/0x814 unregister_netdev+0x20/0x30 gether_cleanup+0x1c/0x38 rndis_attr_release+0xc/0x14 kref_put+0x74/0xb8 configfs_rmdir+ 0x314/0x374 如果 gadget->ops->pullup() 返回错误将调用函数 rndis_close()然后导致释放后使用问题。
    ================================================== ===================== (CVE-2022-50704)

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

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

  - cryptoasymmetric_keys - 防止 asymmetric_key_generate_id 中的溢出。在相加二进制 blob 长度和 asymmetric_key_id 结构的大小时使用 check_add_overflow() 防止潜在的整数溢出并相应地返回 ERR_PTR(-EOVERFLOW)。这可防止从可任意大的潜在恶意 X.509 证书字段例如 ASN.1 INTEGER 序列号、颁发者名称等复制数据时可能发生的缓冲区溢出 (CVE-2025-68724)

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

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

  - bpf将 preempt_count_{sub,add} 添加至 btf id 拒绝列表 __bpf_prog_enter* 和 中的递归检查
    __bpf_prog_exit* 使 preempt_count_{sub,add} 不受保护。当对它们附加 trampoline 时我们得到如下恐慌[ 867.843050] BUG在 0000000009d325cf 处命中 TASK 堆栈保护页面堆栈为 0000000046a46a15..00000000537e7b28[ 867.843064] 堆栈保护页面: 0000 [#1] PREEMPT SMP NOPTI [867.843067] CPU8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4 [ 867.843100] Call Trace[867.843101] <TASK> [ 867.843104] asm_exc_int3+0x3a/0x40 [ 867.843108] RIP 0010:preempt_count_sub+0x1/0xa0 [ 867.843135] __bpf_prog_enter_recur+0x17/0x90 [ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000 [867.843154] ? preempt_count_sub+0x1/0xa0 [ 867.843157] preempt_count_sub+0x5/0xa0 [ 867.843159] ? migrate_enable+0xac/0xf0 [ 867.843164] __bpf_prog_exit_recur+0x2d/0x40 [ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000 ... [ 867.843788] preempt_count_sub+0x5/0xa0 [ 867.843793] ? migrate_enable+0xac/0xf0 [ 867.843829] __bpf_prog_exit_recur+0x2d/0x40 [ 867.843837] 缺陷在 0000000099bd8228 处命中 IRQ 堆栈保护页面堆栈为 00000000b23e2bc4..000000006d95af35[ 867.843841] 缺陷堆栈为 00000000ffd69623..0000000014eb594c[ 867.843843] 缺陷在 00000000028320f0 处命中了 IRQ 堆栈保护页面堆栈为 00000000034b6438..0000000078d1bcec) [867.843842] bpf_trampoline_610505+0808246 这是因为在 __bpf_prog_exit_recur 中preempt_count_{sub,add} 在 prog->active 减少后调用。已通过将这两个函数添加至 btf ID 拒绝列表来修复此问题。 (CVE-2023-54086)

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

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

  - netfilternf_tables修复链引用计数器中的下溢设置元素添加错误路径会在链上两次减少引用计数器一次在元素释放时一次通过 nft_data_release() 再次减少。然后d6b478666ffa (netfilternf_tables修复对象引用计数器中的下溢)通过删除有状态对象引用计数减量错误地修复了此问题。如 b91d90368837 中一样恢复有状态对象减少 (netfilter nf_tables修复泄漏的对象引用计数)并让 nft_data_release() 减少链引用计数器因此此操作仅执行一次。 (CVE-2023-54035)

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

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

  - binder修复与 munmap() 争用中的 alloc->vma 的 UAF [ cmllamas清除来自提交 015ac18be7de 的转发端口 (binder修复 5.10 稳定中与 munmap() 争用中 alloc->vma 的 UAF)。Liam 指出在还原提交 a43cfc87caaf (androidbinder停止将指针保存至 VMA) 之后干线中需要此更新。已调整提交日志和标签以反映此问题。 ] 在提交 720c24192404 (Androidbinder) 中将 down_write 更改为 down_readbinder 假设 mmap 读取锁定足以保护 binder_update_page_range() 内的 alloc->vma。在提交 dd2283f2605e mmapmunmap 中包含读取 mmap_sem 的 zap 页面之前这通常是准确的现在可在将 vma 从 munmap() 中的 rbtree 分离后降级 mmap_lock。然后继续拆卸并释放仅保持读取锁定的 vma。这意味着访问 binder_update_page_range() 中的 alloc->vma 现在将与 munmap() 中的 vm_area_free() 争用并可造成 UAF，如以下 KASAN 跟踪所示
    ================================================== ================ 缺陷KASAN通过任务 server/558 CPU: 3 PID: 558 Comm在地址 ffff16204ad00600 发生的大小 8 的 vm_insert_page+0x7c/0x1f0 读取中存在释放后使用其他
    服务器 未受感染 5.10.150-00001-gdc8dcf942daa #1 硬件名称linux,dummy-virt (DT) 调用跟踪
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction +0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由任务分配 559:
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common .constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由任务 560 释放
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc +0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ========================== ======================================== 若要防止上述争用请将binder_update_page_range() 内的 mmap 写入锁定。mmap 锁争用可能会增加。但是 binder 已通过顶层 alloc->mutex 序列化了这些调用。此外运行 binder 基准测试时未显示出任何性能影响。
    (CVE-2023-54157)

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

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

  - mptcp修复 fastopen 早期回退中的空指针取消引用如果是早期回退到 TCPsubflow_syn_recv_sock() 会在将新分配的 sock 返回给调用程序之前删除 subflow 上下文。fastopen 路径不处理上述无条件取消引用子流上下文。
    (CVE-2023-54085)

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

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

  - drm/fbdev-generic禁止潜在的越界访问 IGT 的 fbdev 测试可能在 EOF 之后写入这导致对包含 fbdev-generic 的 drm 驱动程序进行越界访问。例如在 x86+ast2400 平台上以 1680x1050 分辨率运行 fbdev 测试将导致 linux 内核挂起并显示以下调用跟踪Oops: 0000 [#1] PREEMPT SMP PTI [IGT] fbdev正在启动 Subtest eof Workqueue: 事件drm_fb_helper_damage_work [drm_kms_helper] [IGT] fbdev正在启动子测试 nullptr RIP
    0010:memcpy_erms+0xa/0x20 RSP0018:ffffa17d40167d98 EFLAGS: 00010246 RAX: ffffa17d4eb7fa80 RBX
    ffffa17d40e0aa80 RCX: 00000000000014c0 RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000 RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0 R10: ffffa17d4e4c5000 R11:
     R120000000000000000  : ffffa17d4eb7fa80 R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30 FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0 调用跟踪 <TASK> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper] drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper] process_one_work+0x21f/0x430 work_thread+0x4e/0x3c0 ? __pfx_worker_thread+0x10/0x10 kthread+0xf4/0x120 __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[end trace 0000000000000000 ]--- 原因是不能保证由 drm_fb_helper_memory_range_to_clip() 函数计算出的损坏矩形会绑定在屏幕的活动显示区域中。可能的原因如下: 1) 针对 mmap 系统调用支持以页面大小的粒度分配缓冲区。fbdev 仿真消耗的阴影屏幕缓冲区也可能选择与页面大小对齐。 2) drm_fb_helper_memory_range_to_clip() 中使用的 DIV_ROUND_UP() 将引入差一错误。例如在 16KB 页面大小的系统上为了存储 1920x1080 XRGB 帧缓冲区我们需要分配 507 页面。遗憾的是大小 1920*1080*4 无法被 16KB 整除。 1920 * 1080 * 4 = 8294400 字节506 * 16 * 1024 = 8290304 字节507 * 16 * 1024 = 8306688 字节 line_length = 1920*4 = 7680 字节507 * 16 * 1024 / 7680 = 1081.6 off / line_length = 507 * 16 * 1024 / 7680 = 1081 DIV_ROUND_UP(507 * 16 * 1024, 7680) 将会产生 1082 memcpy_toio() 通常会发出逐行复制命令当复制最后一行时会发生越界访问。因为1082 * line_length = 1082 * 7680 = 8309760且 8309760 > 8306688 请注意如果暴露的缓冲区大于宽度 x 步幅则用户空间仍可能向不可见区域写入数据。但只要目前为止未草稿仍有内存便可解决访问问题。- 也限制 y1 (Daniel) - 将修复修补程序保持在最小 (Daniel) - screen_size 为页面大小对齐因为它需要 mmap (Thomas) - 添加补丁标签 (Thomas) (CVE-2023-54116)

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

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

  - mediaimx-jpeg禁用无用的中断以避免内核错误 存在一个硬件缺陷在禁用中断之后或时可能触发中断 STMBUF_HALF。可能会导致非预期的内核错误。中断 STMBUF_HALF 和 STMBUF_RTND 无其他影响。因此禁用它们以及未使用的中断。同时禁用中断时清除中断状态。 (CVE-2022-50741)

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

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

  - scsilpfc修复从 debugfs 读取 rx_monitor 时的硬锁定 在 /sys/kernel/debug/lpfc/fnX/rx_monitor 的 I/O 和同步 cat 期间可能发生与下面的调用跟踪类似的硬锁定。lpfc_rx_monitor_report 中的 spin_lock_bh 没有按预期保护定时器中断因此将旋转锁定的强度更改为 _irq。Kernel panic - not syncing: Hard LOCKUP CPU: 3 PID: 110402 Comm: cat Kdump: loaded exception RIP: native_queued_spin_lock_slowpath+91 [IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]
    __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f [End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad (CVE-2022-50744)

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

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

  - NFSv4/pNFS清除 pnfs_mark_layout_stateid_invalid 中的 NFS_INO_LAYOUTCOMMIT 修复了在此调用堆栈期间布局为空时的崩溃write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit 依赖 lseg refcount 来保持布局。需要清除 NFS_INO_LAYOUTCOMMIT 否则我们可能会尝试引用空布局。 (CVE-2025-68349)

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

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

  - autofs修复 autofs_catatonic_mode 中 waitqueues 的内存泄漏 Syzkaller 报告内存泄漏缺陷
    内存泄漏未引用对象 0xffff88810b279e00（大小 96）：comm syz-executor399，pid 3631，jiffies 4294964921（使用期限 23.870s）十六进制转储前 32 个字节：00 00 00 00 00 00 00 00 08 9e 27 0b 81 . ......'......08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ......'......回溯
    [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c 378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/ root.c:897 [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue 结构的 wait_ctr 为零时应释放。否则它们将会丢失。在这种情况下完成了 AUTOFS_IOC_EXPIRE_MULTI ioctl然后在 autofs_wait() 中分配了一个新的 waitqueue struct,其初始 wait_ctr 等于 2。之后 wait_event_killable() 中断它返回 -ERESTARTSYS因此“wq->name.name” == NULL”条件可能无法满足。实际上调用 autofs_wait_release() 或 autofs_catatonic_mode() 时可满足此条件并且同样重要的是 wait_ctr 在这些位置中减少。
    退出 autofs_wait() 时wait_ctr 减少到 1。然后卸载进程开始kill_sb 调用 autofs_catatonic_mode()本应释放 waitqueue但它只是将其使用情况计数器减少到零此行为不正确。 edit:imk 这种描述当然是不正确的。因到期而执行的 umount 是已 automount 的挂载的 umount而非 autofs 挂载本身。它们独立发生，通常在 autofs 文件系统内挂载的所有内容都过期之后发生。如果所有内容尚未过期automount 后台程序仍可退出并保留挂载。但是这两种情况下的过期将导致出现调用 autofs_wait_release() 的通知并显示结果状态。问题案例为 automount 后台程序的 汇总执行。在这种情况下任何等待中的进程都不会被唤醒直到它们终止或卸载挂载。 end edit: imk因此在 catatonic 模式下我们应该释放计数器变为零的 waitqueues。
    编辑 imk 最初我担心 autofs_wait_release() 和 autofs_catatonic_mode() 的调用不是相互排除的但情况不可能(显然)因为当其中一个会调用两个函数。因此，等待条目将仅由其中一个函数释放，或由 autofs_wait() 中唤醒的进程释放，具体取决于调用顺序。结束编辑imk (CVE-2023-54134)

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

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

  - NSF Unidata NetCDF-C 变量名称基于堆栈的缓冲区溢出远程代码执行漏洞。此漏洞可让远程攻击者在受影响的 NSF Unidata NetCDF-C 安装上执行任意代码。利用此漏洞需要用户交互，因为目标必须访问恶意页面或打开恶意文件。变量名称的解析中存在特定缺陷。
    造成这一问题的原因是，在将用户提供的数据复制到固定长度的基于堆栈的缓冲区之前，未正确验证这些数据的长度。攻击者可利用此漏洞在当前用户环境中执行任意代码。为 ZDI-CAN-27267。 (CVE-2025-14934)

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

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

  - ALSAwavefront修复了示例大小验证中的整数溢出wavefront_send_sample() 函数在验证示例大小时存在一个整数溢出问题。header->size 字段为 u32 但被转换为 int以便与 dev->freemem 进行修复通过使用无符号比较来避免整数溢出。
    (CVE-2025-68344)

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

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

  - ceph修复修剪端点时潜在的释放后使用缺陷修剪端点时以及在 ceph_iterate_session_caps() 中释放 'session->s_cap_lock' 后即端点可能被另一线程删除以及使用 中的过时端点内存时将触发释放后使用崩溃的回调。我们需要在获取“ci->i_ceph_lock”之后立即检查端点是否存在。如果已将其删除则不执行任何操作。 (CVE-2023-53867)

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

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

  - ext4如果启用配额 Yi 在检查修补程序 ext4 期间发现挂载失败则关闭配额
    不要在不一致的日志上进行 BUG 功能当 ext4_mark_recovery_complete() 返回错误值时错误处理路径不会关闭已启用的配额这会触发以下 kmemleak
    ================================================== ============== 未引用的对象 0xffff8cf68678e7c0 (size 64): comm mount, pid 746, jiffies 4294871231 (age 11.540s) hex dump(头 32 个字节): 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ....A... c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00............ ...H... 回溯[<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880 [<00000000d4e621d7>] kmalloc_trace+0x39/0x140 [<00000000837eee74>] v2_read_file_info+0x18a/0x3a0 [<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770 [<00000000340a4782>] dquot_load_quota_inode +0xc6/0x1c0 [<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4] [<000000003a0268fa>]
    __ext4_fill_super+0x3448/0x3910 [ext4] [<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4] [<000000004a9489c4>] get_tree_bdev+0x1dc/0x370 [<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4] [<00000000c7cb663d>] vfs_get_tree+0x31/0x160 [<00000000320e1bed>] do_new_mount+0x1d5/0x480 [<00000000c074654c>] path_mount+0x22e/0xbe0 [<0000000003e97a8e>] do_mount+0x95/0xc0 [<000000002f3d3736>]
    __x64_sys_mount+0xc4/0x160 [<0000000027d2140c>] do_syscall_64+0x3f/0x90 ================================== ============================ 我们添加了 failed_mount10 标签并调用此标签中的 ext4_quota_off_umount() 以释放已启用 qoutas。
    (CVE-2023-54153)

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

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

  - md可能需要在 md_run() 之前执行 mddev_init IO 操作中的初始化 bioset例如在写入 sysfs 之后更新元数据。如果没有 bioset则会触发空指针取消引用如下 BUG内核空指针取消引用地址0000000000000020 调用跟踪 md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0x6f/0xa0 kernfs_kernfs_kf_write+0x6f/00_writeit/0x658 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Re Producer `` /dev/mdadm -ldev/s1d2 cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level 每个 mddev 只能调用一次 mddev_init()无需测试 bioset 是否已更新不再进行初始化。 (CVE-2025-68368)

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

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

  - btrfs修复 btrfs_clear_space_info_full() 中的不良位字段写入 摘自有关内存屏障排序保证的 memory-barriers.txt 文档: (*) 这些保证不适用于位字段因为编译器经常生成代码以使用非原子 read-修改这些修改写入序列。不尝试使用位字段来同步并行算法。 (*) 即使在位域受到锁保护的情况下给定位域中的所有字段也必须受到锁保护。如果给定位字段中的两个字段受到不同的锁保护则编译器的非原子读取-修改-写入序列可造成对一个字段的更新损坏邻近字段的值。 btrfs_space_info 具有共享基础字的位字段该位字段由字段 full、chunk_alloc 和 flush 组成：struct btrfs_space_info { struct btrfs_fs_info
    * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int claw; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 1762 4 */ ...
    因此为防止并行读取-修改-写入丢失对受锁定保护的其中一个位字段成员的写入对所有位字段的所有写入都必须使用该锁定。除了 btrfs_clear_space_info_full() 会迭代 space_infos 并在不锁定的情况下写出 found->full = 0 外，它们几乎都会执行此操作。假设有一个线程完成了其中 block_group 的删除操作因此在数据回收票证基础架构运行 do_async_reclaim_data_space() 的同时我们调用了 btrfs_clear_space_info_full(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full: 0、chunk_alloc:0、 flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READfull: 0, chunk_alloc:0, flush:1 MOD/WRITEfull: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock);返回MOD/WRITEfull:0、chunk_alloc:0、flush:1现在 data_sinfo->flush 为 1但回收工作线程已退出。这破坏了当没有工作排队或运行时刷新为 0 的不变量。一旦违反此不变量，
    __reserve_bytes() 会将票证添加到 space_info->tickets但会将 space_info->flush 设置为 1且不会将工作排入队列。此后，它们将在生成的票证上永远阻断，因为现在不可能再次踢出工作线程。我还通过查看受影响内核的程序集确认它正在执行 RMW 操作。例如要将刷新第3位设置为 0则程序集为andb $0xfb,0x60(%rbx) 以类似的方式将完整第1位设置为 0andb $0xfe,-0x20(%rax)因此我认为这确实是实际系统中的缺陷。我发现许多系统都处于此状态，但目前无法重现。与其将此 footgun 留待将来使用，不如利用 struct 中无论如何还有空间这一事实，并且它已经相当大，只需将三个位域成员更改为 bool 即可。这可避免写入 space_info->full 对 ---truncated--- (CVE-2025-68358)

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

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

  - acct修复 encode_comp_t() 中可能的整数溢出 以下代码描述的整数溢出> 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp、rnd; ...... > 第 341 章 exp <<= MANTSIZE > 342 exp += value > 343 返回 exp > 344 } 当前 comp_t 被定义为“__u16”类型但变量“exp”为“int”类型因此当第 343 行中的变量“exp”大于 65535 时将发生溢出。(CVE-2022-50749

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

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

  - phytegraxusb清除 usb-phy dev 中的驱动程序引用 对于双重角色端口会将 phy dev 分配给 usb-phy dev并将该端口 dev 驱动程序用作 usb-phy 的 dev 驱动程序。当尝试破坏端口 dev 时也将破坏其 dev 驱动程序。但我们未删除对 usb-phy dev 的引用。
    这可能会在 KASAN 中造成释放后使用问题。 (CVE-2023-54083)

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

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

  - x86/apic锁定时不禁用 x2APIC APIC 支持两种模式即旧 APIC（或 xAPIC）和扩展 APIC（或 x2APIC）。X2APIC 模式基本兼容旧 APIC但其会禁用内存映射 APIC 接口以支持使用 MSR 的接口。APIC 模式由 APIC MSR 中的 EXT 位控制。
    MMIO/xAPIC 接口有一些问题尤其是 APIC LEAK [1]。此缺陷允许攻击者使用 APIC MMIO 接口从 SGX enclave 提取数据。引入对新功能的支持允许 BIOS 在 x2APIC 模式下锁定 APIC。如果 APIC 在 x2APIC 模式下锁定并且内核尝试禁用 APIC 或恢复为旧 APIC 模式将发生 GP 错误。通过防止内核尝试禁用 x2APIC 设置 LEGACY_XAPIC_DISABLED 位时引入对新 MSR (IA32_XAPIC_DISABLE_STATUS) 的支持并处理新的锁定模式。在具有 IA32_XAPIC_DISABLE_STATUS MSR 的平台上如果启用了 SGX 或 TDXBIOS 将设置 LEGACY_XAPIC_DISABLED。如果需要旧 APIC则需要在 BIOS 中禁用它的 SGX 和 TDX。 [1]
    https://aepicleak.com/aepicleak.pdf (CVE-2022-50720)

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

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

  - drm/panthor防止群组创建中潜在的 UAF 此提交防止 GROUP_CREATE ioctl 函数中释放后使用问题的可能性该函数将其存储在 Xarray 中后访问该 ioctl 函数中访问组的指针时会出现此问题。恶意用户空间可二次猜测群组的句柄并在与 GROUP_CREATE ioctl 时间大约相同的时间尝试从另一个线程调用 GROUP_DESTROY ioctl。
    为防止释放后使用漏洞此提交在刚好从 GROUP_CREATE ioctl 函数返回之前添加的群组池 Xarray 的条目上使用标记。已检查指定群组句柄的所有 ioctl 的标记因此用户空间不会删除尚未标记的群组。 v2添加 R-bs 并修复了 标签 (CVE-2025-68735)

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

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

  - bpf修复 __bpf_get_stackid() 中的堆栈映射溢出检查。Syzkaller 报告当复制堆栈跟踪数据时在 __bpf_get_stackid() 中存在 KASAN slab 越界写入。当 perf 跟踪包含的堆栈条目多于堆栈映射存储段可容纳时会出现此问题从而导致存储段的数据数组中发生越界写入。 (CVE-2025-68378)

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

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

  - drm/panel/panel-sitronix-st7701删除 DSI 附加面板失败如果 mipi_dsi_attach() 失败请调用 drm_panel_remove() 以避免内存泄漏。 (CVE-2022-50750)

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

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

  - perf/x86修复空事件访问和可能的 PEBS 记录丢失当调用 intel_pmu_drain_pebs_icl() 以耗尽 PEBS 记录时可调用 perf_event_overflow() 以处理最后的 PEBS 记录。而 perf_event_overflow() 可触发中断节流并停止该组的所有事件如以下调用链所示。 perf_event_overflow() -> __perf_event_overflow()
    ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() 停止事件的副作用是 cpuc->events[ 中所有相应的事件指针] 数组清除为 NULL。假设一个组中有两个 PEBS 事件（事件 a 和事件 b）。intel_pmu_drain_pebs_icl() 调用 perf_event_overflow() 以处理 PEBS 事件 a 的最后一个 PEBS 记录时会触发中断调节并将事件 a 和事件 b 的所有指针清除为空。随后intel_pmu_drain_pebs_icl() 尝试处理事件 b 的最后一个 PEBS 记录并遇到空指针访问。要避免此问题请将 cpuc->events[] 清除从 x86_pmu_stop() 移至 x86_pmu_del()。之所以安全是因为在从 cpuc->events[] 访问事件指针之前始终会检查 cpuc->active_mask 或 cpuc->pebs_enabled。 (CVE-2025-68375)

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

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

  - canj1939移动 j1939_sk_errqueue() 来防止死锁 此提交解决了某些情况下可能发生的死锁情况例如在接收网络故障事件的同时运行数据 TP/ETP 传输和订阅错误队列时。死锁涉及按以下顺序排列的锁定3 j1939_session_list_lock -> active_session_list_lock j1939_session_activate ...
    j1939_sk_queue_activate_next -> sk_session_queue_lock ... j1939_xtp_rx_eoma_one 2 j1939_sk_queue_drop_all
    * lock(&jsk->sk_session_queue_lock);
    lock(&priv->active_session_list_lock); lock(&priv->j1939_socks_lock);此提交中实现的解决方案是将 j1939_sk_errqueue() 调用移出 active_session_list_lock 上下文从而防止死锁情况。 (CVE-2023-54152)

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

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

  - regulatorstm32-pwr修复 of_iomap 泄漏 Smatch 报告drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() 警告未在第 151,166 行发布 of_iomap() 中的“base”。在 stm32_pwr_regulator_probe() 中当 devm_kzalloc() 未能分配内存或 devm_regulator_register() 未能注册新的调节器设备时未释放 base 可造成泄漏。要修复此问题用 devm_platform_ioremap_resource() 替换 of_iomap()。 devm_platform_ioremap_resource() 是用于 平台设备的专用函数。它允许自动释放 'base'无论 probe 函数成功还是失败。此外请使用 IS_ERR(base) 而不是 !base因为 devm_platform_ioremap_resource() 的返回值可能是指向重新映射的内存的指针如果操作失败也可能是 ERR_PTR() 编码的错误代码。 (CVE-2023-54097)

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

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

  - fs/ntfs3使用前初始化分配的内存 KMSAN 报告检测到多个未初始化的值 - KMSANntfs_read_hdr 中存在 uninit-value (3) - KMSANbcmp 中存在 uninit-value (3) 内存由 分配
    __getname()即 kmem_cache_alloc() 的封装程序。此内存在被正确清除之前即已使用。
    将 kmem_cache_alloc() 更改为 kmem_cache_zalloc()以在使用前正确分配和清除内存。
    (CVE-2025-68365)

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

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

  - mshv修复创建内存区域重叠检查当前检查不正确请执行以下操作它仅检查片段的开头或结尾是否在现有片段内。这没有考虑用户空间指定在现有区域之前开始和之后结束的区域。将逻辑更改为针对每个区域的 gfns 和 uaddrs 进行范围交集检查。删除 mshv_partition_region_by_uaddr()因其不再使用。 (CVE-2025-68743)

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

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

  - netphyxgmiitorgmii修复 xgmiitorgmii_probe of_phy_find_device() 返回 refcount 增加的设备节点中的 refcount 泄漏。调用 put_device() 以在不再需要时将其释放。 (CVE-2022-50777)

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

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

  - scsiqla2xxx修复 purex 项目的不当释放在 qla2xxx_process_purls_iocb() 中通过可内部调用 qla24xx_alloc_purls_item() 的 qla27xx_copy_multiple_pkt() 分配项目。对于小分配qla24xx_alloc_purex_item() 函数可能会从每个适配器池返回预分配的项目而非使用 kzalloc() 动态分配内存。qla2xxx_process_purls_iocb() 中的一个错误处理路径未正确使用 kfree() 释放项目。如果项目来自预分配池则在其上调用 kfree() 是可导致内存损坏的缺陷。通过使用正确的解除分配函数 qla24xx_free_purex_item() 修复此问题该函数可正确处理动态分配和预分配的项目。 (CVE-2025-68741)

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

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

  - bpf更新 [lru_,]percpu_hash 映射时释放特殊字段由于 [lru_,]percpu_hash 映射支持 BPF_KPTR_{REF,PERCPU}“pcpu_copy_value()”中缺少对“bpf_obj_free_fields()”的调用可导致 BPF_KPTR_ 引用的内存{REF,PERCPU} 字段将一直保留直到释放映射。可通过在“pcpu_copy_value()”中的“copy_map_value[,_long]()”之后调用“bpf_obj_free_fields()”修复此问题。 (CVE-2025-68744)

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

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

  - miscocxl修复需要调用 afu_ioctl() eventfd_ctx_put 以放置 ocxl_irq_set_handler 失败时由 eventfd_ctx_fdget 获取的 refcount 中可能的 refcount 泄漏。 (CVE-2022-50742)

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

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

  - fs/ntfs3在 inode 操作中添加空指针检查这会针对读取根目录 MFT 记录后返回的 inode 的 i_op 指针添加健全性检查。我们应该在尝试创建根 dentry 之前检查 i_op 是否有效否则我们可能会在挂载具有有趣的根目录 MFT 记录的图像时遇到 NPD。 [ 114.484325] 缺陷内核空指针取消引用地址 0000000000000008 [114.484811] #PF内核模式下的主管读取访问 [ 114.485084] #PF: error_code (0x0000) - 不存在页面 [ 114.485606] PGD 0 P4D 0 [ 114.485975] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.486570] CPU: 0 PID: 237 Comm: mount 受感染: GB 6.0.0-rc4 #28 [ 114.486977] 硬件名称QEMU Standard PC ( i440FX + PIIX,1996, BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 114.488169] RIP
    0010:d_flags_for_inode+0xe0/0x110 [ 114.488816] Code24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 08 20 4c 8b 79 08 20 4 e8 60 241 [ 114.490326] RSP
    0018ffff8880065e7aa8 EFLAGS00000296 [ 114.490695] RAX: 000000000000001 RBX: ffff888008ccd750 RCX
    ffffffff84af2aea [ 114.490986] RDX: 000000000000000001 RSI: 0000000000000008 RDI: ffffffff87abd020 [114.491364] RBP: ffff8880065e7ac8 R08: 0000000000000001 R09: fffffbff0f5] [: fffffbff0f5] [: ffffffbff0f5 114.491675R10: ffffffff84af2aea
    ffffffff87abd027 R11ffffffbfff0f57a04 R120000000000000000 [ 114.491954] R130000000000000008 R14
     R150000000000000000  : ffff888008ccd750 [ 114.492397] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 114.492797] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.493150] CR2:
    0000000000000008 CR3: 00000000013ba000 CR4: 00000000000006f0 [ 114.493671] Call Trace [ 114.493890] <TASK> ]  [ 114.494075] __d_instantiate+0x24/0x1c0 [ 114.494505] d_instantiate.part.0+0x35/0x50 [ 114.494754] dx35/0x50 0x80 [ 114.494998] ntfs_fill_super+0x1232/0x1b50 [ 114.495260] ? put_ntfs+0x1d0/0x1d0 [114.495499] ? vsprintf+0x20/0x20 [ 114.495723] ? set_blocksize+0x95/0x150 [ 114.495964] get_tree_bdev+0x232/0x370 [ 114.496272] ? put_ntfs+0x1d0/0x1d0 [ 114.496502] ntfs_fs_get_tree+0x15/0x20 [114.496859] vfs_get_tree+0x4c/0x130 [ 114.497099] path_mount+0x654/0xfe0 [ 114.497507] ? putname+0x80/0xa0 [ 114.497933] ? finish_automount+0x2e0/0x2e0 [ 114.498362] ? putname+0x80/0xa0 [ 114.498571] ? kmem_cache_free+0x1c4/0x440 [ 114.498819] ? putname+0x80/0xa0 [ 114.499069] do_mount+0xd6/0xf0 [114.499343] ? path_mount+0xfe0/0xfe0 [ 114.499683] ? __kasan_check_write+0x14/0x20 [ 114.500133]
    __x64_sys_mount+0xca/0x110 [ 114.500592] do_syscall_64+0x3b/0x90 [ 114.500930] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 114.501294] RIP0033:0x7fdc898e948a [ 114.501542] 代码48 8b 0d 11 fa 2a 00 617 d8 64 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 114.502716] RSP: 002b:00007ffd793e58f8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [114.503175] RAX: ffffffffffffffda RBX: 0000564b2228f060 RCX: 00007fdc898e948a [ 114.503588] RDX:
    0000564b2228f260 RSI: 0000564b2228f2e0 RDI: 0000564b22297ce0 [ 114.504925] RBP: 0000000000000000 R08
    0000564b2228f280 R090000000000000020 [ 114.505484] R1000000000c0ed0000 R110000000000000202 R12
    0000564b22297ce0 [ 114.505823] R13: 0000564b2228f260 R14: 0000000000000000 R15: 00000000ffffffff [114.506562] </TASK> [ 114.506887] 中链接的模块 [ 114.507648] CR2: 0000000000000008 [ 114.508884]
    ---[ end trace 0000000000000000 ]--- [ 114.509675] RIP: 0010:d_flags_for_inode+0xe0/0x110 [ 114.510140] 代码24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241 [ 114.511762] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296 [ 114.512401] RAX
    0000000000000001 RBXffff888008ccd750 RCXffffffff84af2aea [ 114.51 ---truncated--- (CVE-2022-50739)

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

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

  -erofs限制文件支持的挂载的 fs 堆栈级别。否则可造成潜在内核堆栈溢出例如 EROFS 本身挂载。 (CVE-2025-68361)

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

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

  - accel/ivpu修复取消绑定 BO 时的争用条件 修复当 ivpu_gem_bo_free() 在 BO 取消映射之前将 BO 从 BO 列表中删除时出现的“内存管理器在删除期间不干净”警告。然后 file_priv_unbind() 在上下文清除期间触发 drm_mm_takedown() 中的警告。使用 bo_list_lock 保护取消映射序列可确保 BO 在从列表中删除时始终完全取消映射。这可确保 BO 在上下文拆卸时完全取消映射或是存在于列表中但未由 file_priv_unbind() 取消映射。 (CVE-2025-68749)

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

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

  - ALSA: mts64修复 snd_mts64_interrupt 中可能的 null-ptr-defer 我在 qemu 平台上执行以下测试时收到了 null-ptr-defer 错误报告make defconfig 和 CONFIG_PARPORT=m、CONFIG_PARPORT_PC=m、CONFIG_SND_MTS64=m 然后制作测试脚本cat>test_mod1.sh<
    syzkaller:~# ./test_mod.sh snd_mts64snd_mts64.0 探测失败错误 -5 modprobe ERROR无法插入“snd_mts64”无此设备 BUG内核空指针取消引用地址0000000000000000 #PF
    内核模式中的主管写入访问 #PF error_code (0x0002) - not-present page PGD 0 P4D 0 Oops0002 [#1] PREEMPT SMP PTI CPU: 0 PID: 205 Comm: modprobe 未受感染 6.1.0-rc8-00588 -g76dcd734eca2 #6 调用跟踪 <IRQ> snd_mts64_interrupt+0x24/0xa0 [snd_mts64] parport_irq_handler+0x37/0x50 [parport]
    __handle_irq_event_percpu+0x39/0x190 handle_irq_event_percpu+0xa/0x30 handle_irq_event+0x2f/0x50 handle_edge_irq+0x99/0x1b0 __common_interrupt+0x5d/0x100 common_interrupt+0xa0/0xc0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30 parport_claim+0xbd/ 0x230 [parport] snd_mts64_probe+0x14a/0x465 [snd_mts64] platform_probe+0x3f/0xa0 real_probe+0x129/0x2c0
    __driver_probe_device+0x6d/0xc0 driver_probe_device+0x1a/0xa0 __device_attach_driver+0x7a/0xb0 bus_for_each_drv+0x62/0xb0 __device_attach+0xe4/0x180 bus_probe_device+0x82/0xa0 device_add+0x550/0x920 platform_device_add+0x106/0x220 snd_mts64_attach+0x2e/0x80 [snd_mts64] port_check+ 0x14/0x20 [parport] bus_for_each_dev+0x6e/0xc0 __parport_register_driver+0x7c/0xb0 [parport] snd_mts64_module_init+0x31/0x1000 [snd_mts64] do_one_initcall+0x3c/0x1f0 do_init_module+0x46/0x1c6 load_moduled/0x10d/0x1e+0x14/0x1000
    __do_sys_finit_module+0xa2/0xf0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> 内核错误 - 不同步中断 1 秒内重新启动中的致命异常。mts wa 在中断期间未初始化我们添加了对 mts 的检查以修复此缺陷。 (CVE-2022-50773)

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

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

  - HSIssi_protocol修复 ssip_pn_open() 中潜在的资源泄漏问题 ssip_pn_open() 通过 hsi_claim_port() 声明 HSI 客户端的端口。当 hsi_register_port_event() 发生某些错误并返回负值时应使用 hsi_release_port() 释放 HSI 客户端的端口。通过在 hsi_register_port_event() 失败时调用 hsi_release_port() 来修复此问题。 (CVE-2022-50708)

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

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

  - nbd置入 recv_work 的延迟配置 运行 NBD_CLEAR_SOCK 和 NBD_CMD_RECONFIGURE 时recv_work 中存在一个 uaf 问题nbd_genl_connect // conf_ref=2连接和 recv_work Anbd_open // conf_ref=3 recv_work A finish // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2触发 recv_work B关闭 nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF 或仅运行 NBD_CLEAR_SOCKnbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF 提交 87aac3a80af5 (nbd
    将 nbd_config_put()移动到唤醒 recv_work 中的等待程序之前调用 nbd_config_put()这是为了确保当 nbd->task_recv 仍处于未清除状态时不唤醒 nbd_start_device_ioctl()。但是在 nbd_start_device_ioctl() 中在被唤醒后明确调用 flush_workqueue() 以确保完成所有当前工作。因此无需移动在唤醒之前放置的配置。将 nbd_config_put() 移动到 recv_work 的末尾以便在工作线程的整个生命周期中保留该引用。这可确保当 recv_work 仍在运行时即使清除 + 重新配置交错也无法释放配置。此外我们无需担心 recv_work 丢弃最后一个 nbd_put 可造成死锁path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work 完成 nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work 路径 B不含 NBD_CFLAG_DESTROY_ON_DISCONNECT 的 netlink连接 // nbd_refs=2触发 recv_work打开 nbd // nbd_refsSOC_CLEAR_confs=3 // =2 关闭 nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work 完成 // conf_refs=0、nbd_refs=1 rmmod // nbd_refs=0 取决于e2daec488c57nbd_config_put 时修复挂起任务CVE-2025-68372)

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

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

  - drm/panthor修复内核 BO VA 节点上的 UAF 如果 MMU 关闭panthor_vm_unmap_range() 可能会返回错误。我们预计页表仍会更新并且如果 MMU 被阻断则 GPU 的其余部分也应被阻断因此系统不存在访问物理内存的风险当前的代码无论如何不涉及此问题。继续其余的清理而不是取出和保留在 drm_mm 中插入的 va_node否则会在从 drm_mm 树中删除其他邻近节点时导致 UAF。 (CVE-2025-68747)

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

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

  - blk-cgroup在删除 blkg->q_node 时保留 queue_lock当 blkg 从 blkg_free_workfn() 的 q->blkg_list 中删除时必须保留 queue_lock否则各种缺陷(列表损坏、硬锁定等)由 blkg_destroy_all() 触发。 (CVE-2023-54088)

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

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

  - PM / devfreqhisi修复 OPP 处理中潜在的 UAF 确保在调用 dev_pm_opp_put(opp) 之前获取所有必需的数据以维护正确的资源获取和释放顺序。 (CVE-2025-68739)

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

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

  - wifiath10k延迟缓冲区的取消映射。在 WCN3990上我们发现一种罕见的情况即复制引擎硬件向主机驱动程序发送复制完成中断同时仍在处理驱动程序已发送的缓冲区这会导致SMMU 错误触发内核错误。这是在复制引擎通道 3 (CE3) 上发生的情况，其中驱动程序通常会将 WMI 命令排入队列并发送至固件。在接收到复制完成中断时主机驱动程序会假定硬件已处理该缓冲区从而立即取消映射并释放缓冲区。在此问题情况下接收到复制完成中断后主机驱动程序将取消映射并释放缓冲区但由于硬件仍在访问缓冲区在此情况下会并行取消映射SMMU 硬件将触发 SMMU 错误导致内核错误。为避免此问题作为变通方案可在取消映射复制引擎源 DMA 缓冲区之前添加延迟。这是有条件地针对 WCN3990 并且仅针对发现问题的 CE3 通道。以下是崩溃签名wifi smmu 错误内核[ 10.120965] arm-smmu 15000000.iommu未处理的上下文错误
    fsr=0x402、 iova=0x7fdfd8ac0、 fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu未处理的上下文错误fsr=0x402、 iova=0x7fe06fdc0、 fsynr=0x710003, cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000. remoteproc收到了致命错误err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091
    cmnos_thread.c:3998在 copy_engine.c:AXI_ERROR_DETECTED:2149 中断言 remoteproc remoteproc0在 4080000.remoteproc 中检测到崩溃类型致命错误 <3> remoteproc remoteproc0处理 4080000.remoteproc 中的崩溃 #1 pc : __arm_lpae_unmap+0x500/0x514 lr __arm_lpae_unmap+0x4bc/0x514 sp
    ffffffc011ffb530 x29: ffffffc011ffb590 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000004 x25: 0000000000000003 x24: ffffffc011ffb890 x23: ffffffa762ef9be0 x22: ffffffa77244ef00 x21:
    0000000000000009 x20: 00000007fff7c000 x19: 0000000000000003 x18: 0000000000000000 x17: 0000000000000004 x16: ffffffd7a357d9f0 x15: 0000000000000000 x14: 00fd5d4fa7ffffff x13: 000000000000000e x12:
    0000000000000000 x11: 00000000ffffffff x10: 00000000fffffe00 x9 : 000000000000017c x8 : 000000000000000c x7 : 0000000000000000 x6 : ffffffa762ef9000 x5 : 0000000000000003 x4 : 0000000000000004 x3 :
    0000000000001000 x2 : 00000007fff7c000 x1 : ffffffc011ffb890 x0 : 0000000000000000 调用跟踪
    __arm_lpae_unmap+0x500/0x514 __arm_lpae_unmap+0x4bc/0x514 __arm_lpae_unmap+0x4bc/0x514 arm_lpae_unmap_pages+0x78/0xa4 arm_smmu_unmap_pages+0x78/0x104 __iommu_unmap+0xc8/0x1e4 iommu_unmap_fast+0x38/0x48 __iommu_dma_unmap+0x84/0x104 iommu_dma_free+0x34/0x50 dma_free_attrs+0xa4/0xd0 ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c [ath10k_core] ath10k_halt+0x11c/0x180 [ath10k_core] ath10k_stop+0x54/0x94 [ath10k_core] drv_stop+0x48/0x1c8 [mac80211] ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+ 0x48/0x5c [mac80211] __dev_open+0xb4/0x174
    __dev_change_flags+0xc4/0x1dc dev_change_flags+0x3c/0x7c devinet_ioctl+0x2b4/0x580 inet_ioctl+0xb0/0x1b4 sock_do_ioctl+0x4c/0x16c compat_ifreq_ioctl+0x1cc/0x35c compat_sock_ioctl+0x110/0x2actl
    __arm64_compat_sys_ioctl+0xf4/0x3e0 el0_svc_common+0xb4/0x17c el0_svc_compat_handler+0x2c/0x58 el0_svc_compat+0x8/0x2c 已在下列环境中测试 WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 (CVE-2022-50700)

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

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

  - NSF Unidata NetCDF-C 属性名称基于堆栈的缓冲区溢出远程代码执行漏洞。此漏洞可让远程攻击者在受影响的 NSF Unidata NetCDF-C 安装上执行任意代码。利用此漏洞需要用户交互，因为目标必须访问恶意页面或打开恶意文件。解析属性名称时存在特定缺陷。
    造成这一问题的原因是，在将用户提供的数据复制到固定长度的基于堆栈的缓冲区之前，未正确验证这些数据的长度。攻击者可利用此漏洞在当前用户环境中执行任意代码。为 ZDI-CAN-27269。 (CVE-2025-14936)

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

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

  - rcu安全转储 vmalloc 内存信息 当前对于双重调用 call_rcu()将转储 rcu_head 对象内存信息如果对象未从 slab 分配器分配则将调用 vmalloc_dump_obj() 并需要保留 vmap_area_lock 旋转锁由于可在中断上下文中调用 call_rcu()因此可能存在旋转锁死锁情况。并且在 Preempt-RT 内核中rcutorture 测试也会触发以下 lockdep 警告BUG从位于 kernel/locking/spinlock_rt.c:48 的无效上下文调用的休眠函数 in_atomic(): 1, irqs_disabled(): 1, non_block: 0 、pid1、name
    swapper/0 preempt_count1、预期0 RCU 嵌套深度1、预期1 swapper/0/1 保留的 3 锁 #0
    ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}位于torture_init_begin+0x24/0xa0 #1ffffffffb5307940 (rcu_read_lock){....}-{1:3} #2位于rcu_torture_init+0x1ec7/0x2370  ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}@find_vmap_area+0x1f/0x70 irq 事件标记 565512 hardirqs 上次启用于 (565511)[<ffffffffb379b138>] __call_rcu_common+0x218/0x940 hardirqs 上次禁用(565512)
    [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370 softirqs 最后启用的时间为 (399112)
    [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170 softirqs 上次禁用的时间为 (399106)
    [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0 Preempt 禁用于 [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 受感染GW 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 硬件名称QEMU Standard PC (Q35 + ICH92009)BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org04/01/2014 调用跟踪 <TASK> dump_stack_lvl+0x68/0xb0 dump_stack+0x14/ 0x20 __might_resched+0x1aa/0x280
    __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 debug_smp_processor_id+0x1b/0x30 call_rcu_herry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ?
    __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ?
    __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> 之前的修补程序通过使用 find_vm_area 的死锁安全尽力版本修复了此问题。但是如果发生故障则会打印指针是 vmalloc 指针的事实以便我们至少打印一些内容。
    (CVE-2023-54113)

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

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

  * =2 NBD_CLEAR_SOCK // config_refs=1 关闭 nbd // config_refs=0 refcount_inc -> uaf ------------[此处剪切 ]------------ refcount_t添加在 0 上释放后使用。WARNING: CPU24 PID: 1014 at lib/refcount.c:25 refcount_warn_slurate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 添加延迟可通过&nbd->config_refs) in nbd_genl_connect()
    mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk休眠前\n) + mdelay(5 * 1000); + printk休眠后\n) refcount_inc(&nbd->config_refs);
    nbd_connect_reply(info, nbd->index); } (CVE-2025-68366)

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

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

  - coresighttmc将事件句柄添加到路径句柄对于检索每个 CPU 的 AUX_EVENT 至关重要并且在 perf 模式下是必需的。它已添加到 coresight_path以便从属设备可在需要时通过该路径访问它。可通过以下命令重现现有缺陷 perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null 显示 oops 如下无法处理虚拟地址 000f6e84934ed19e 上的内核分页请求调用跟踪tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight] (CVE-2025-68370)

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

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

  - NSF Unidata NetCDF-C 维度名称基于堆的缓冲区溢出远程代码执行漏洞。此漏洞可让远程攻击者在受影响的 NSF Unidata NetCDF-C 安装上执行任意代码。利用此漏洞需要用户交互，因为目标必须访问恶意页面或打开恶意文件。特定缺陷存在于维度名称解析中。
    造成这一问题的原因是，在将用户提供的数据复制到固定长度的基于堆的缓冲区之前，未正确验证这些数据的长度。攻击者可利用此漏洞在当前用户环境中执行任意代码。为 ZDI-CAN-27168。 (CVE-2025-14935)

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

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

  - net nsh使用正确的 mac_offset 来展开 nsh_gso_segment() 中的 gso skb 如调用跟踪所示skb_panic 是由 nsh_gso_segment() 中的错误 skb->mac_header 造成的 opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU 3 PID2737 Commsyz 未受感染 6.3.0-next-20230505 #1 RIP: 0010:skb_panic+0xda/0xe0 调用追踪
    skb_push+0x91/0xa0 nsh_gso_segment+0x4f3/0x570 skb_mac_gso_segment+0x19e/0x270
    __skb_gso_segment+0x1e8/0x3c0 validate_xmit_skb+0x452/0x890 validate_xmit_skb_list+0x99/0xd0 sch_direct_xmit+0x294/0x7c0 __dev_queue_xmit+0x16f0/0x1d70 packet_xmit+0x185/0x210 packet_snd+0xc15/0x1170 packet_sendmsg+0x7b/0xa0 sock_sendmsg+0x14f/0x160 The root cause is: nsh_gso_segment() 使用 skb->network_header - 如果内层协议 gso 失败则 nhoff 重置 skb_gso_error_unwind() 中的 mac_header。然而 skb->network_header 可以通过内层协议 gso 函数重置如
    mpls_gso_segment。由不准确的 network_header 重置的 skb->mac_header 将大于 skb 余量。
    nsh_gso_segment nhoff = skb->network_header - skb->mac_header; __skb_pull(skb,nsh_len) skb_mac_gso_segment mpls_gso_segment skb_reset_network_header(skb);//skb->network_header+=nsh_len return -EINVAL;
    skb_gso_error_unwind skb_push(skb, nsh_len); skb->mac_header = skb->network_header - nhoff // skb->mac_header > skb->headroom造成 skb_push 错误使用正确的 mac_offset 来恢复 mac_header 并删除 nhoff。 (CVE-2023-54114)

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

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

  - wifiath12k修复 rx_desc 和 tx_desc 中的内存泄漏目前当调用 ath12k_dp_cc_desc_init() 时我们会向 rx_descs 和 tx_descs 分配内存。在 ath12k_dp_cc_cleanup() 中描述符清理期间 rx_descs 和 tx_descs 内存未释放。这是造成内存泄漏的原因。应在 ath12k_dp_cc_cleanup 中释放这些分配的内存。在 ath12k_dp_cc_desc_init() 中可以保存 rx_descs 和 tx_descs 的基址。在 ath12k_dp_cc_cleanup() 中我们可以使用基址释放 rx_descs 和 tx_descs 内存。已在以下设备上测试
    QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 (CVE-2023-54016)

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

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

  - gfs2防止递归内存回收函数 new_inode() 返回一个将 inode->i_mapping->gfp_mask 设置为 GFP_HIGHUSER_MOVABLE 的新 inode。此值包括 __GFP_FS 标记因此该地址空间中的分配可递归到文件系统内存回收。我们不希望这种情况发生因为它会消耗大量的堆栈内存。更糟糕的是它还可能在以下情况下发生死锁
    例如在多个位置会在文件系统事务内部调用 gfs2_unstuff_dinode()。这会调用 filemap_grab_folio()分配新的 folio从而触发内存回收。如果内存回收递归到文件系统中并启动另一个事务则将发生死锁。要修复此类问题请通过确保 inode 地址空间的 gfp_mask 不包括 __GFP_FS 来防止递归到文件系统代码中的内存回收。元和资源群组地址空间已在使用 GFP_NOFS 作为其 gfp_mask不包括 __GFP_FS。但 GFP_HIGHUSER_MOVABLE 的默认值的限制比 GFP_NOFS 宽松。为避免过度限制请使用默认值并且仅替换 __GFP_FS 标记。我不确定这是否会真正产生影响但应该不会造成什么影响。此修补程序宽松地基于 提交 ad22c7a043c2xfs防止因页面缓存分配造成堆栈溢出。修复 xfstest generic/273。 (CVE-2025-68356)

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

ID	名称	严重性
279785	Linux Distros 未修补的漏洞：CVE-2022-50704	medium
279784	Linux Distros 未修补的漏洞：CVE-2025-68724	high
279782	Linux Distros 未修补的漏洞：CVE-2023-54086	medium
279781	Linux Distros 未修补的漏洞：CVE-2023-54035	high
279780	Linux Distros 未修补的漏洞：CVE-2023-54157	medium
279779	Linux Distros 未修补的漏洞：CVE-2023-54085	medium
279778	Linux Distros 未修补的漏洞：CVE-2023-54116	high
279777	Linux Distros 未修补的漏洞：CVE-2022-50741	medium
279776	Linux Distros 未修补的漏洞：CVE-2022-50744	medium
279775	Linux Distros 未修补的漏洞：CVE-2025-68349	high
279774	Linux Distros 未修补的漏洞：CVE-2023-54134	medium
279773	Linux Distros 未修补的漏洞：CVE-2025-14934	high
279772	Linux Distros 未修补的漏洞：CVE-2025-68344	high
279771	Linux Distros 未修补的漏洞：CVE-2023-53867	high
279770	Linux Distros 未修补的漏洞：CVE-2023-54153	medium
279769	Linux Distros 未修补的漏洞：CVE-2025-68368	medium
279768	Linux Distros 未修补的漏洞：CVE-2025-68358	medium
279767	Linux Distros 未修补的漏洞：CVE-2022-50749	high
279766	Linux Distros 未修补的漏洞：CVE-2023-54083	high
279765	Linux Distros 未修补的漏洞：CVE-2022-50720	medium
279764	Linux Distros 未修补的漏洞：CVE-2025-68735	high
279763	Linux Distros 未修补的漏洞：CVE-2025-68378	high
279762	Linux Distros 未修补的漏洞：CVE-2022-50750	medium
279761	Linux Distros 未修补的漏洞：CVE-2025-68375	medium
279760	Linux Distros 未修补的漏洞：CVE-2023-54152	medium
279759	Linux Distros 未修补的漏洞：CVE-2023-54097	high
279758	Linux Distros 未修补的漏洞：CVE-2025-68365	medium
279757	Linux Distros 未修补的漏洞：CVE-2025-68743	high
279756	Linux Distros 未修补的漏洞：CVE-2022-50777	medium
279754	Linux Distros 未修补的漏洞：CVE-2025-68741	medium
279753	Linux Distros 未修补的漏洞：CVE-2025-68744	high
279752	Linux Distros 未修补的漏洞：CVE-2022-50742	high
279751	Linux Distros 未修补的漏洞：CVE-2022-50739	high
279750	Linux Distros 未修补的漏洞：CVE-2025-68361	high
279749	Linux Distros 未修补的漏洞：CVE-2025-68749	medium
279748	Linux Distros 未修补的漏洞：CVE-2022-50773	medium
279747	Linux Distros 未修补的漏洞：CVE-2022-50708	high
279746	Linux Distros 未修补的漏洞：CVE-2025-68372	high
279745	Linux Distros 未修补的漏洞：CVE-2025-68747	high
279744	Linux Distros 未修补的漏洞：CVE-2023-54088	high
279743	Linux Distros 未修补的漏洞：CVE-2025-68739	medium
279742	Linux Distros 未修补的漏洞：CVE-2022-50700	medium
279741	Linux Distros 未修补的漏洞：CVE-2025-14936	high
279740	Linux Distros 未修补的漏洞：CVE-2023-54113	medium
279739	Linux Distros 未修补的漏洞：CVE-2025-68366	high
279738	Linux Distros 未修补的漏洞：CVE-2025-68370	medium
279737	Linux Distros 未修补的漏洞：CVE-2025-14935	high
279736	Linux Distros 未修补的漏洞：CVE-2023-54114	medium
279735	Linux Distros 未修补的漏洞：CVE-2023-54016	medium
279734	Linux Distros 未修补的漏洞：CVE-2025-68356	medium

检测

Nessus 的 Misc. 系列

medium

high

medium

high

medium

medium

high

medium

medium

high

medium

high

high

high

medium

medium

medium

high

high

medium

high

high

medium

medium

medium

high

medium

high

medium

medium

high

high

high

high

medium

medium

high

high

high

high

medium

medium

high

medium

high

medium

high

medium

medium

medium