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

  - hfsplus修复 __hfs_bnode_create 中缺少的 hfs_bnode_get() 当同时调用 sync() 和 link() 时两个线程可能进入 hfs_bnode_find()而未在哈希表中找到节点并继续创建节点。线程 Ahfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) 线程 B：hfsplus_create_cat() -> hfs_brec_insert()
    -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0) 在此情况下线程 A 会创建 bnode、设置 refcnt=1然后对其进行哈希处理。线程 B 也尝试创建相同的 bnode、发现其已被插入、终止其自己的实例并在未获取节点的情况下使用哈希实例。 `` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- 线程 A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node;
    tree->node_hash_cnt++; } 其他 { <- 线程 B spin_unlock(&tree->hash_lock); kfree(node);
    wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; } `但是 hfs_bnode_find() 要求每次调用都获取一个引用。此处两个线程都以设置 refcnt=1 告终。当之后放置节点时这会触发 BUG_ON(!atomic_read(&node->refcnt)) 在此情况下线程 B 实际上是在哈希表中查找节点而非创建新节点因此必须获取引用。通过在重复使用由另一个线程新创建的 bnode 时调用 hfs_bnode_get() 来修复此问题以确保正确更新 refcount。很久以前 HFS 中在提交 a9dc087fd3c4 中修复了 __hfs_bnode_create 中缺少的 hfs_bnode_get()修复了一个类似的缺陷但是直到现在HFS+ 中仍然存在相同的问题。
    (CVE-2025-68774)

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

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

  - ublk修复读取分区表时的死锁当一个进程例如 udev打开 ublk 块设备例如通过 bdev_open() 读取分区表时可能发生死锁 [1] 1. bdev_open() 占用磁盘->open_mutex 2. 进程向 ublk 后端发出读取 I/O 以读取分区表 3. 在
    __ublk_complete_rq()、blk_update_request() 或 blk_mq_end_request() 运行 bio->bi_end_io() 回调 4。如果这在 ublk 区块设备的文件描述符上触发 fput()工作可能会推迟到当前任务的任务工作请参阅 fput()实现）5。这最终会从相同的上下文 6 中调用 blkdev_release()。
    blkdev_release() 尝试再次获取 disk->open_mutex 7. 死锁相同任务等待其已持有的 mutex 修复为在禁用bottom half 的情况下运行 blk_update_request() 和 blk_mq_end_request()。
    这会强制 blkdev_release() 在内核工作队列环境而非在当前任务工作环境中运行同时允许 ublk 服务器转发进度及避免死锁。 [axboe重写 ublk 中的注释] (CVE-2025-68823)

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

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

  - usbphyfsl-usb修复设备删除期间延迟工作中的释放后使用延迟的工作项目 otg_event 在 fsl_otg_conf() 中初始化并在以下两种情况下计划使用： 1. 当主机控制器绑定到 OTG 控制器时。 2. 当 USB ID 引脚状态改变时（电缆插入/拔出）。通过 fsl_otg_remove() 删除设备时发生争用条件fsl_otg 实例可能在延迟的工作仍待定或执行时已释放。这会在工作函数 fsl_otg_event() 访问已释放的内存时导致释放后使用。有问题的情况分离线程|延迟工作fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //使用取消分配 fsl_otg 结构之前调用 fsl_otg_remove() 中的 disable_delayed_work_sync() 可以修复此问题。这可确保在内存解除分配之前正确取消延迟的工作并完成执行。此缺陷 是通过静态分析发现的。 (CVE-2025-68781)

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

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

  - perf/x86/amd启用前检查事件以避免 GPF 在 AMD 计算机上cpuc->events[idx] 在 NMI->throttle->x86_pmu_stop() 的细微争用条件中可能变为空。启用之前检查 amd_pmu_enable_all() 中的空事件以避免 GPF。这似乎只是 AMD 的问题。Syzkaller 报告了 amd_pmu_enable_all 中的 GPF。信息NMI 处理程序 (perf_event_nmi_handler) 花费时间过长 13.143 毫秒 Oops
    一般保护错误可能是非规范地址 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: 范围中的 null-ptr-deref [0x0000000000001a0-0x0000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36676.1470rctainted6.1470rctained_3667 -syzk RIP0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP0018:ffff888118009d60 EFLAGS
    00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI:
    0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14:
     R15ffff88811802a240  : ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3:
    0000000103d56000 CR4: 00000000000006f0 调用跟踪 <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (dispensator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core) .c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346
    __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92辨别器 1) kernel/events/core.c:72辨别器1))
    __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/ smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h 99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (标识符 47) arch/x86/kernel/smp.c:266 (标识符 47)) </IRQ> (CVE-2025-68798)

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

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

  - RDMA/cm修复泄漏的多播 GID 表引用 如果在用于多播创建的 CM 事件仍在排队时CM ID 遭到破坏cancel_work_sync() 将阻止该 work 运行这也将阻止破坏 ah_attr。这会泄漏 refcount 并触发警告: dev syz1 index 2 ref=573 的 GID 条目 ref 泄漏警告: CPU: 1 PID: 655 drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache。 c:806 [内联] 警告CPU1 PID655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886 取消工作后破坏 ah_attr调用此函数两次是安全的。 (CVE-2025-71084)

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

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

  - inetfrags刷新 fqdir_pre_exit() 中的待定 skb。在 NIPA 中自 9 月以来我们经常发现 pernet_ops_rwsem 上发生死锁。卡住的任务通常是尝试将锁定作为写入器的 modprobe通常加载 ipvlan 这样的驱动程序。 lockdep 不跟踪 rwsems 的阅读器因此报告中不明显读取。仔细检查发现持有锁定的 Reader 发现在 nf_conntrack_cleanup_net_list() 中永远处于 conntrack 循环。根据过去处理偶尔发生的 NIPA 崩溃的经验，我仔细查看了崩溃前运行的测试，发现崩溃遵循 ip_defrag.sh。即时的危险信号。彻底审查碎片化队列发现 skbs 闲置并持有 conntrack 引用。
    问题在于由于 conntrack 依赖 nf_defrag_ipv6因此将首先加载 nf_defrag_ipv6。由于 nf_defrag_ipv6 首先加载其 netns 退出挂钩会运行 _after_ conntrack 的 netns 退出挂钩。期间 fqdir_pre_exit() 刷新所有片段队列 SKB以在 conntrack 清理运行之前释放 conntrack 引用。
    当定时器到期处理程序发现 fqdir->dead 已设置时也要刷新其中的队列以防数据包在运行 pre_exit 刷新时潜入。问题的原因不完全是“修复”下的提交但我认为之前定时器触发最终会取消阻断旋转的 conntrack。 (CVE-2025-68768)

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

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

  - ipv6作为 calipso_skbuff_setattr() 一部分的 pskb_expand_head() 中存在 BUG() 存在一个由 pskb_expand_head() 中 net/core/skbuff.c:2232 中的 BUG_ON(nhead < 0) 造成的内核 oops。当向 skb_cow() 传递余量 > INT_MAX即 (int)(skb_headroom(skb) + len_delta) < 0时此缺陷作为 calipso_skbuff_setattr() 例程的一部分触发。造成此缺陷的根本原因是 __skb_cow() 中的隐式整数转换。(headroom > skb_headroom(skb)) 检查的目的是确保 delta = headroom - skb_headroom(skb) 永不为负否则将在 pskb_expand_head() 中触发 BUG_ON。但是，如果 headroom > INT_MAX 且 delta <= -NET_SKB_PAD 则检查通过，delta 变为负值并且 nhead 的负值会传递给 pskb_expand_head()。修复 calipso_skbuff_setattr() 中的触发条件。避免仅使用 skb_cow() 增加余量从而将负的余量大小传递到 calipso_skbuff_setattr() 中的 skb_cow()。PoC
    使用 `netlabelctl` 工具netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 然后运行以下 PoC int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP ) // 设置 msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg
    struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL;
    msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // 设置 sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // 设置 cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9 //设置跃点大小 - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0); (CVE-2025-71085)

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

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

  - netopenvswitch修复 push_nsh() 操作中的中间属性验证 push_nsh() 操作结构如下所示: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...)) 最外层的 OVS_ACTION_ATTR_PUSH_NSH 属性由 __ovs_nla_copy_actions 中的 nla_for_each_nested() 执行()。
    最内层的 OVS_NSH_KEY_ATTR_BASE/MD1/MD2 可由 nsh_key_put_from_nlattr() 内的 nla_for_each_nested() 完成 OK。但不检查中间的属性是否正确。我们甚至不检查此属性是否为 OVS_KEY_ATTR_NSH。我们只是通过一对 nla_data() 调用执行双重解包 - 第一次是在调用 validate_push_nsh() 时直接执行第二次是在 nla_for_each_nested() 宏的一部分执行这样不安全如果大小此属性的描述不正确。由于 netlink 缓冲区较大因此在验证期间可能不会注意到该故障但在之后的操作执行期间该故障会造成故障该故障将缓冲区精确分配为大小
    BUGKASANnsh_hdr_from_nlattr+0x1dd/0x6a0 中存在 slab 越界 [openvswitch] 由任务 a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ 在 addr ffff88816459a634 读取大小 184 #115 PREEMPT(optional) 调用跟踪 <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd0x82+shopenvswitch] 0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+ 0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 让我们添加一些检查该属性的大小是否正确以及它是操作中唯一的一个属性。从技术上来说OVS_KEY_ATTR_NSH 并没有真正的理由存在因为我们知道我们已经在推送一个 NSH 标头它只是造成了额外的嵌套不过这就是目前 uAPI 的工作方式。因此，保持原样。 (CVE-2025-68785)

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

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

  - bnxt_en修复 bnxt_rx_xdp() 中的 XDP_TX path For XDP_TX 操作未正确清除事件标记。
    __bnxt_poll_work() -> bnxt_rx_pkt() -> bnxt_rx_xdp() 可在 NAPI 内循环且可在较早的迭代中设置某些事件标记。特别是如果较早设置 BNXT_TX_EVENT 表示某些 XDP_TX 数据包已准备就绪并待定则当再次是 XDP_TX 操作时该设置将被清除。通常我们会在成功调用 __bnxt_xmit_xdp() 时再次设置 BNXT_TX_EVENT。但是如果 TX 环没有更多空间则将不会设置该标记。这将导致 TX 生产者超前但驱动程序不会按 TX 门铃。对于多缓冲区 XDP_TX不需要清除事件标记和设置 BNXT_AGG_EVENT。BNXT_AGG_EVENT 标记本应早点在 bnxt_rx_pkt() 中设定。此问题的明显征兆是与 TX XDP 环关联的 RX 环最终将变空，并且所有数据包将被丢弃。
    因为此情况将导致驱动程序在看到 TX 环具有永远待定的 XDP_TX 数据包时不重新填充 RX 环。修复以仅在成功调用
    __bnxt_xmit_xdp()。 (CVE-2025-68770)

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

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

  - ipvs修复路由错误路径中的 ipv4 null-ptr-deref __ip_vs_get_out_rt() 中的 IPv4 代码路径调用 dst_link_failure()而不确保设置 skb->dev导致当 ipv4_link_failure() 尝试时fib_compute_spec_dst() 中发生空指针取消引用以发送 ICMP 目标不可达消息。
    提交 ed0de45a1008ipv4重新编译 ipv4_link_failure 中的 ip 选项开始从 ipv4_link_failure() 调用 __ip_options_compile() 后出现此问题。此代码路径最终调用 fib_compute_spec_dst()其会取消引用 skb->dev。已尝试修复提交 0113d9c9d1cc 中的空 skb->dev 取消引用ipv4修复 ipv4_link_failure 中的空取消引用但仅通过使用回退设备解决了即时的 dev_net(skb->dev) 取消引用。该修复不完整因为调用链中的 fib_compute_spec_dst() 稍后仍会直接访问 skb->dev当 IPVS 调用 dst_link_failure() 时skb->dev 保持为空。在下列情况下会发生崩溃 1. IPVS 在 NAT 模式下处理数据包时错误配置了目标 2. 在建立路由之前在 __ip_vs_get_out_rt() 中进行路由查找失败 3. 错误路径含有 skb->dev == NULL 调用 dst_link_failure(skb) 4. ipv4_link_failure() ipv4_send_dest_unreach() __ip_options_compile() fib_compute_spec_dst() 5. fib_compute_spec_dst() 取消引用空 skb->dev 应用提交 326bf17ea5d4 中用于 IPv6 的相同补丁ipvs修复 ipv6 路由联系不通错误从设置 skb->dev skb_dst(skb)->dev 在调用 dst_link_failure() 之前。KASAN范围 [0x0000000000000328-0x00000000000032f] CPU:1 PID:12732 Comm: syz.1.3469 未受感染 6.6.114 #2 RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP
    0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 调用跟踪 <TASK> spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764 (CVE-2025-68813)

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

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

  - nfsd修复 nfsd4_add_rdaccess_to_wrdeleg() 中的 nfsd_file 引用泄漏。 nfsd4_add_rdaccess_to_wrdeleg() 无条件使用新获取的 nfsd_file 覆盖 fp->fi_fds[O_RDONLY]。但是如果客户端已在之前的 OPEN 操作中打开了 SHARE_ACCESS_READ则此操作将覆盖现有指针且不会释放其引用从而导致孤立之前的引用。此外该函数最初在只有一个引用的 fp->fi_fds[O_RDONLY] 和 fp->fi_rdeleg_file 中存储相同的 nfsd_file 指针。put_deleg_file() 运行时会清除 fi_rdeleg_file 并调用 nfs4_file_put_access() 以释放文件。但是当 fi_access[O_RDONLY] 计数器降至零时nfs4_file_put_access() 只会释放 fi_fds[O_RDONLY]。如果该文件存在另一个 READ 打开则计数器保持提升状态并且从未释放来自委派的 nfsd_file 引用。这可能导致该文件存在打开冲突。然后在服务器关闭时这些泄露会造成 __nfsd_file_cache_purge() 遇到引用计数无法清理的提升文件最终在 kmem_cache_destroy() 中触发 BUG()因为该缓存中仍有分配的 nfsd_file 对象。 (CVE-2025-71090)

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

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

  - mediadvb-usbdtv5100修复 dtv5100_i2c_msg() 中的越界 rlen 值是用户控制的值但 dtv5100_i2c_msg() 未检查 rlen 值的大小。因此如果将其设置为大于 sizeof(st->data) 的值st->data 会发生越界漏洞。因此我们需要添加适当的范围检查以防止此漏洞。 (CVE-2025-68819)

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

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

  - mlxswspectrum_router修复邻居释放后使用问题。取消引用邻居时我们有时会发现释放后使用问题 [1]。问题似乎在于驱动程序将指针存储到邻居中但未保留对其的引用。仅当邻居由 nexthop 使用时才会采用引用。
    通过简化引用计数方案修复。在邻居条目中存储邻居指针时始终进行 引用。避免在 nexthop 使用邻居时进行引用因为与 nexthop 关联的邻居条目已持有引用。通过运行发现问题的测试超过 300 次进行测试。如果没有此修补程序若干迭代后会重现问题。 [1] BUGKASAN任务 ip/3929 CPU: 3 UID: 0 PID: 3929 Comm: ip 未受感染6.18.0- 在 addr ffff88817f8e3420 进行的大小 8 的 mlxsw_sp_neigh_entry_update+0x2d4/0x310 读取中存在 slab 释放后使用rc4-virtme-g36b21a067510 #3 PREEMPT(full) 硬件名称Nvidia SN5600/VMOD0013BIOS 5.13 05/31/2023 调用跟踪 <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+ 0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130
    __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100
    __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg +0x75b/0xc90 __sock_sendmsg+0xbe/0x160____sys_sendmsg+0x5b2/0x7d0
    ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...] Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0
    ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread +0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 由任务 154 释放
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60
    __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 Last可能相关的工作创建
    kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 (CVE-2025-68801)

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

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

  - 输入ti_am335x_tsc - 修复 wire_order 验证中的差一错误 当前验证“wire_order[i] > ARRAY_SIZE(config_pins)”允许 wire_order[i] 等于 ARRAY_SIZE(config_pins)这会在用作“config_pins[wire_order[i]]”中的索引。由于 config_pins 有 4 个元素索引 0-3因此 wire_order 的有效范围应为 0-3。通过在验证检查中使用 >= 而非 > 修复差一错误。 (CVE-2025-68777)

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

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

  - fuse修复预读回收死锁 Commit e26ee4efbc79fuse仅在需要释放时才分配 ff->release_args如果服务器未实现开放则跳过分配 ff->release_args。但在这样做时fuse_prepare_release() 现在会跳过抓取 inode 上的引用这使得在存在 inflight 预读请求时能够从 dcache 中逐出 inode。如果服务器在为预读请求提供服务的同时触发回收并且回收尝试逐出正在预读的文件的 inode,则会造成死锁。由于 folio 在预读期间已锁定因此当 reclaim 逐出 fuse inode 且 fuse_evict_inode() 尝试删除与页面缓存 (truncate_inode_pages_range()) 中的 inode 关联的所有 folio时回收将永远阻止等待锁定因为 readahead 无法放弃由于其本身在回收中被阻断而被锁定: >>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate. c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache. c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c: 221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195) 3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.htm) c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/ x86/mm/fault.c:1481:3exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27 通过在准备文件的发布即使服务器未实现 open。丢弃 fuse 文件上的最后一个引用时将丢弃 inode 引用请参阅 fuse_file_put() -> fuse_release_end()。 (CVE-2025-68821)

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

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

  - net/schedets从 ets_qdisc_change 中删除之前始终从活动列表中删除类 zdi-disclosures@trendmicro.com 称此漏洞为 `ets_qdisc_dequeue` 和 `ets_qdisc_change` 之间的争用条件。它会导致“struct Qdisc”对象上的 UAF。攻击者需要能够创建新用户和网络命名空间才能触发该缺陷。请参阅我在分析末尾的补充评论。Analysis static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack) { ... // (1) 此锁定阻止 .change 处理程序 (`ets_qdisc_change`) //与 .dequeue 处理程序争用(`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) {if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist) ;
    qdisc_purge_queue(q->classes[i].qdisc); WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict;
    i++) { if (q->classes[i].qdisc->q.qlen) { // (2) 已将类添加到 q->active list_add_tail(&q->classes[i].alist, &q- >active); q->classes[i].deficit = quantuma[i]; } } WRITE_ONCE(q->nstrict, nstrict) memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quantuma[i]); for (i = oldbands; i < q->nbands; i++) {q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) qdisc 已解锁现在可与 // 与 .change 处理程序的其余部分并行调用出列 sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { //(4) 减少了类的 qdisc 的引用计数并 // 将其释放 qdisc_put(q->classes[i].qdisc); // (5) 如果在 (4) 和 (5) 之间调用 .dequeue // 将拥有强 UAF 并且可以控制 RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0);
    q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats);
    memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); return 0 } 注释：发生这种情况的原因是，某些类的 qdiscs 被分配为 NULL，但仍保留在活动列表中。此提交修复了此问题方法是始终将类从活动列表中删除然后再删除和释放其相关的 qdisc 复制程序步骤zdi-disclosures@trendmicro.com 发送的内容的修整版本`DEV=${DEV:-lo } ROOT_HANDLE=${ROOT_HANDLE:-1:} BAND2_HANDLE=${BAND2_HANDLE:-20:} 下的 # 1:2 PING_BYTES=${PING_BYTES:-48} PING_COUNT=${PING_COUNT:-200000} PING_DST=${PING_DST:-127.0.0.1} SLOW_TBF_RATE=${SLOW_TBF_RATE:-8bit} SLOW_TBF_BURST=${SLOW_TBF_BURST:-100b} SLOW_TBF_LAT= ${SLOW_TBF_LAT:-1s} cleanup() { tc qdisc del dev $DEV root 2>/dev/null } 陷阱清理 EXIT ip 链接设置 $DEV up tc qdisc del dev $DEV root 2>/dev/null || true tc qdisc add dev $DEV root handle $ROOT_HANDLE etsbands 2 strict 2 tc qdisc add dev $DEV parent 1:2 handle $BAND2_HANDLE \ tbf rate $SLOW_TBF_RATE burst $SLOW_TBF_BURST latency $SLOW_TBF_LAT tc filter add dev $DEV parent 1
    协议所有 prio 1 u32 匹配 u32 0 0 flowid 1:2 tc -s qdisc ls dev $DEV ping -I $DEV -f -c $PING_COUNT -s $PING_BYTES -W 0.001 $PING_DST \ >/dev/null 2>&1 & tc qdisc 更改 dev $DEV 根句柄 $ROOT_HANDLE etsbands 2 strict 0 tc qdisc 更改 dev $DEV 根句柄 $ROOT_HANDLE etsbands 2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev $DEV parent ---truncated--- (CVE-2025-71066)

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

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

  - fsnotify不在子项上生成特殊文件的 ACCESS/MODIFY 事件 inotify/fanotify 不允许对文件没有读取访问权限的用户订阅事件例如 IN_ACCESS/IN_MODIFY但允许同一用户订阅当用户具有父目录例如 /dev的访问权限时监视子进程上的事件。对文件没有读取访问权限但对其父目录具有读取访问权限的用户仍可以统计文件状态并查看是否通过 atime/mtime 更改访问/修改了该文件。特殊文件如 /dev/null则不存在同样的情况。当其他用户读取/写入特殊文件时用户通常不会观察到 atime/mtime 变更仅当有人通过 utimensat() 设置 atime/mtime 时才会观察到。使 fsnotify 事件与此 stat 行为一致这样在特殊文件的读取/写入时不生成父观察程序的 ACCESS/MODIFY 事件。仍会为 utimensat() 上的父观察程序生成事件。这样会关闭一些可能用于信息外泄的边信道 [1]。 [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf (CVE-2025-68788)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats() Commit ef56081d1864 (RDMA/bnxt_re: RoCE related hardware counters update) added three new counters and placed them after BNXT_RE_OUT_OF_SEQ_ERR. BNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware statistics with different num_counters values on chip_gen_p5_p7 devices. As a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating hw_stats, which leads to an out-of-bounds write in bnxt_re_copy_err_stats(). The counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and BNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not only p5/p7 devices. Fix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they are included in the generic counter set.
    (CVE-2025-71092)

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

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

  - platform/x86hp-bioscfg修复 ACPI 程序包解析时的越界数组访问 hp-bioscfg 驱动程序中的 hp_populate_*_elements_from_package() 函数包含越界数组访问漏洞。这些函数使用具有索引变量“elem”的 for 循环将 ACPI 程序包解析为可迭代 enum_obj/integer_obj/order_obj/password_obj/string_obj 数组的 for 循环。当处理 PREREQUISITES 和 ENUM_POSSIBLE_VALUES 等多元素字段时这些函数会在嵌套循环内使用“enum_obj[elem + reqs]”和“enum_obj[elem + pos_values]”等表达式来读取多个连续的数组元素。此缺陷在于边界检查仅验证了 elem但在访问 elem + reqs 或 elem + pos_values 时未考虑额外的偏移。补丁更改了边界检查以验证实际访问的索引。 (CVE-2025-71101)

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

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

  - ntfs挂载时设置虚拟的块大小以读取 boot_block挂载时sb->s_blocksize 用于读取未经定义或验证的 boot_block。在尝试读取 boot_block 之前设置一个虚拟的块大小。可使用以下 syz 重现程序触发此问题mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGSr4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x220804) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) 此处ioctl 将 bdev 块大小设置为 16384。在挂载期间get_tree_bdev_flags() 调用 sb_set_blocksize(sb, block_size(bdev))但由于 block_size(bdev) > PAGE_SIZEsb_set_blocksize() 将 sb->s_blocksize 保留为零。随后ntfs_init_from_boot() 会在 sb->s_blocksize 仍为零时尝试读取 boot_block这会触发该缺陷。
    [almaz.alexandrovich@paragon-software.com已更改注释样式添加返回值处理] (CVE-2025-71067)

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

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

  - f2fs造成失败 whiteout 创建时的 dentry 缓存 F2FS 可挂载具有经损坏目录深度值在运行时钳位为 MAX_DIR_HASH_DEPTH 的文件系统。在此类目录上执行 RENAME_WHITEOUT 操作时f2fs_rename 会在尝试通过 f2fs_add_link 添加 whiteout 条目之前执行目录修改更新目标条目并删除源条目。如果 f2fs_add_link 由于目录结构损坏而失败该函数会向 VFS 返回错误但部分目录修改已提交到磁盘。VFS 假设整个重命名操作失败并且不会更新 dentry 缓存从而导致过时映射。在错误路径中VFS 不调用 d_move() 来更新 dentry 缓存。这会导致 new_dentry 仍指向其 i_nlink 减少至零的旧 inode (new_inode)。过时的缓存会导致后续操作错误地引用已释放的 inode。这会导致后续操作使用不再与磁盘状态匹配的缓存目录项信息。当第二次重命名同一条目时VFS 尝试减少过时 inode 上的 i_nlink可能已经 i_nlink=0触发 drop_nlink() 中的警告。序列示例1. 首次重命名 (RENAME_WHITEOUT)file2 file1 - f2fs 更新磁盘上的 file1 条目指向 inode 8 - f2fs 删除磁盘上的 file2 条目 - f2fs_add_link(whiteout) 失败损坏的目录 - 将错误返回 VFS - VFS因错误而未调用 d_move() - VFS 缓存仍有过时缓存file1 inode 7过时- inode 7 具有 i_nlink=0已递减2. 第二次重命名file3 file1 - VFS 使用过时缓存file1 inode 7 -尝试在 inode 7 上 drop_nlinki_nlink 已为 0 - drop_nlink() 中存在警告通过在 whiteout 创建期间 f2fs_add_link 失败时当 f2fs_add_link 失败时明确使 old_dentry 和 new_dentry 无效来修复此问题。这会强制 VFS 在后续操作中从磁盘刷新从而即使在部分重命名部分成功时也可确保缓存的一致性。Re Producer1. 挂载 i_current_depth 已损坏的 F2FS 图像 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. drop_nlink() 中的系统触发警告 (CVE-2025-71069)

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

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

  - f2fs修复 f2fs_recover_fsync_data() 的返回值使用以下脚本将在 f2fs 中触发错误
    mkfs.f2fs -f /dev/vdd mount /dev/vdd /mnt/f2fs touch /mnt/f2fs/foo sync echo 111 >> /mnt/f2fs/foo f2fs_io fsync /mnt/f2fs/foo f2fs_io shutdown 2 /mnt/ f2fs umount /mnt/f2fs mount -o ro,norecovery /dev/vdd /mnt/f2fs 或 mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs F2FS-fs (vdd)f2fs_recover_fsync_data
    Recovery fsync 数据check_only0 F2FS-fs (vdd)挂载的检查点版本 = 7f5c361f F2FS-fs (vdd)由于原因导致文件系统停止0 F2FS-fs (vdd)f2fs_recover_fsync_data恢复 fsync 数据check_only1文件系统 f2fs get_tree() 未设置 fc->root返回 1 ------------[此处剪切]------------ fs/super 的内核缺陷.c:1761! 错误操作码无效 0000 [#1] SMP PTI CPU3 UID0 PID
    722 Comm: mount 未受感染 6.18.0-rc2+ #721 PREEMPT主动硬件名称QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP 0010:vfs_get_tree.cold+0x18/0x1a 调用跟踪
    <TASK> fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP0033:0x7fa6cc126cfe 根本原因是我们错过了处理从 f2f2f2f2f2f2f2f26b6e6b6e59b9ee7ad9431333333643364CALL_64_after_hwframe+0x76/0x7e RIP0033:0x7fa6cc126cfe 返回的错误编号mounting imagerecover__when 的错误编号的缺陷。 w/ ro,norecovery 或 ro,disable_roll_forward 挂载选项会导致将正错误编号返回至 vfs_get_tree()修复该问题。 (CVE-2025-68769)

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

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

  - shmem修复内存严重不足时重命名失败时的恢复maple_tree 插入可能会失败
    simple_offset_rename() 在遇到此情况时不会很好地恢复。这同样适用于 simple_offset_rename_exchange()。此外shmem_whiteout() 预计如果调用成功调用程序将进行到 d_move()即 shmem_rename2() 在成功调用 shmem_whiteout() 后不会失败。
    不难修复但幸运的是 - 如果我们尝试存储信息的索引已作为单一实例存在于树中则 mtree_store() 不会失败。对于 simple_offset_rename_exchange() 以上就足够了 - 我们只需要注意操作顺序即可。对于 simple_offset_rename() 解决方案是将目标预先插入到 new_dir 的树中在不进行任何可能失败的操作的情况下即可完成其余操作。该预插入必须在 shmem_rename2() 中完成而非在 simple_offset_rename() 本身中完成 - 否则我们需要在 shmem_whiteout() 成功后处理失败的可能性。 (CVE-2025-71072)

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

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

  - mediairis添加停止流的健全性检查 在 iris_vb2_stop_streaming 中添加健全性检查。如果 inst->state 已是 IRIS_INST_ERROR则应跳过 stream_off 操作因为它仍会向固件发送数据包。在 iris_kill_session 中inst->state 设置为 IRIS_INST_ERROR 且 session_close 执行将会导致 kfree(inst_hfi_gen2->packet)。如果之后调用 stop_streaming将导致崩溃。 [bod从修补程序标题中删除 qcom] (CVE-2025-68812)

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

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

  - ipv4修复使用具有 nexthop 对象的错误路由时引用计数泄漏。删除 nexthop 对象时会将其标记为失效然后调用 fib_table_flush() 以刷新使用失效 nexthop 的所有路由。fib_table_flush() 当前逻辑仅在其作为网络命名空间拆卸的一部分被调用时（即 flush_all=true 时）刷新错误路由如blackhole。因此当删除错误路由的 nexthop 对象时不会刷新错误路由 # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add Blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show Blackhole 198.51.100.2 nhid 1 dev dummy1 因此它们持续在 nexthop 对象上持有引用进而在 nexthop 设备上持有引用从而导致引用计数泄漏# ip link del dev dummy1 [ 70.516258] unregister_netdevice等待 dummy1 释放。使用计数 = 2 通过在下一跳被标记为无效时刷新错误路由来修复。IPv6 不受此问题的影响。 (CVE-2025-71097)

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

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

  - netrose修复 rose_kill_by_device() 中无效的数组索引 rose_kill_by_device() 将套接字收集到本地数组[]中然后对其进行迭代以断开绑定到正在运行的设备的套接字。循环错误地为 array[cnt] 而非 array[i] 建立索引。若 cnt < ARRAY_SIZE(array) 则此操作读取未初始化的条目cnt == ARRAY_SIZE(array) 时为越界读取。这两种情况均可导致无效的套接字指针取消引用并且还会泄漏通过 sock_hold() 取得的引用。修复索引以使用 i。 (CVE-2025-71086)

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

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

  - ksmbdvfs修复 vfs_cache 中 m_flags 上的争用 ksmbd 维护 ksmbd_inode->m_flags 中的 delete-on-close 和待删除状态。在 vfs_cache.c 中此字段在不一致的锁定下被访问一些路径读取和修改 ci->m_lock 下的 m_flags而另一些则在不锁定的情况下完成此操作。示例 - ksmbd_query_inode_status() 和 __ksmbd_inode_close() 在检查或更新 m_flags 时使用 ci->m_lock。 - ksmbd_inode_pending_delete()、ksmbd_set_inode_pending_delete()、ksmbd_clear_inode_pending_delete() 和 ksmbd_fd_set_delete_on_close()均用于在无 ci->m_lock 的情况下读取和修改 m_flags。当多个线程同时打开、关闭和删除同一个文件时这会在 m_flags 上造成潜在的数据争用。在最坏的情况下delete-on-close 和 pending-delete 位可能丢失或处于不一致的状态导致混淆删除语义文件在 delete-on-close 后留在磁盘上或者文件在仍在使用时消失。通过以下方式修复此问题- 在放置 inode_hash_lock 之后使 ksmbd_query_inode_status() 查看 ci->m_lock 下的 m_flags。- 为读取或修改 m_flags 的所有帮助程序添加 ci->m_lock 保护 (ksmbd_inode_pending_delete()、ksmbd_set_inode_pending_delete()、ksmbd_clear_inode_pending_delete()、ksmbd_fd_set_delete_on_close())。- 保留 __ksmbd_inode_close() 中现有的 ci->m_lock 保护并将实际的 unlink/xattr 删除移到锁定之外。这统一了 m_flags 周围的锁定并删除了数据争用，同时保留了现有的 delete-on-close 行为。 (CVE-2025-68809)

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

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

  - io_uring修复 __io_openat_prep() 中的文件名泄漏 __io_openat_prep() 使用 getname() 分配 struct 文件名。但是对于文件被安装在修复文件表中并且设置了 O_CLOEXEC 标记的情况该函数提前返回。此时请求还没有设置 REQ_F_NEED_CLEANUP 标记。因此没有清理为新分配的 struct filename 分配的内存从而导致内存泄漏。通过在成功调用 getname() 之后立即为请求设置 REQ_F_NEED_CLEANUP以便修复请求时文件名将连同其他需要清理的资源一起清除从而修复此问题。 (CVE-2025-68814)

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

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

  - Inputalps - 修复 dev3_register_work 引起的释放后使用缺陷dev3_register_work 延迟的工作项目在 alps_reconnect() 内初始化并在从连接到 ALPS 触摸板的外部 PS/2 设备收到第一个裸 PS/2 数据包时进行计划。在设备分离期间原始实现会调用 psmouse_disconnect() 中的 flush_workqueue() 以确保完成 dev3_register_work。
    但是psmouse_disconnect() 中的 flush_workqueue() 仅阻断和等待在其调用之前已加入工作队列的工作项目。调用 flush_workqueue() 之后提交的任何工作项目不包含在刷新操作等待的任务集中。这意味着在 flush_workqueue() 执行完成后仍可计划 dev3_register_work。尽管在 psmouse_disconnect() 中已将 psmouse 状态设置为 PSMOUSE_CMD_MODE但 dev3_register_work 的计划仍然不受影响。可能发生争用条件的原因如下：CPU 0清理路径| CPU 1延迟工作 psmouse_disconnect() | psmouse_set_state() | psmouse_set_state() flush_workqueue() | flush_workqueue() | flush_workqueue() | flush_workqueue() alps_report_bare_ps2_packet() alps_disconnect() | alps_report_bare_ps2_packet() psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // 使用 | priv->dev3 // 使用 在 alps_disconnect() 中添加 disable_delayed_work_sync() 以确保正确取消 dev3_register_work 并在 alps_data 结构解除分配后防止执行。此缺陷是通过静态分析识别的。 (CVE-2025-68822)

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

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

  - mediavidtv传输内存所有权 vidtv_channel_si_init() 时初始化本地指针会创建临时列表程序、服务、事件内存本身的所有权通过 vidtv_psi_pat_program_assign() 传输到 PAT/SDT/EIT 表vidtv_psi_sdt_service_assign 、vidtv_psi_eit_event_assign()。此处的问题在于完成内存所有权转移的本地指针未初始化为 NULL。这会造成 vidtv_psi_pmt_create_sec_for_each_pat_entry() 函数失败而且在跳转到 free_eit 的流中由于未初始化的本地指针vidtv_psi_*_table_destroy() 可以再次访问由 vidtv_psi_*_table_destroy() 释放的内存因此再次释放。因此为防止释放后使用和双重释放漏洞当传输内存所有权时本地指针必须初始化为 NULL。 (CVE-2025-68808)

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

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

  -作出反应路由器是反应的路由器。在版本 6.0.0 到 6.30.1 和 7.0.0 到 7.9.5中可以构建攻击者提供的路径以便当React Router 应用程序通过 navigate()、 <Link>或 redirect() 导航到该路径时该应用程序会执行导航/重定向到外部 URL。仅当您将不受信任的内容传递到应用程序代码中的导航路径时这才成为问题。已在版本 6.30.2 和 7.9.6 中修补此问题。(CVE-2025-68470)

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

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

  - netusbasix使用前验证 PHY 地址 ASIX 驱动程序通过 asix_read_phy_addr() 从 USB 设备读取 PHY 地址。恶意或错误设备可返回无效地址 (>= PHY_MAX_ADDR)这会在 mdiobus_get_phy() 中造成警告：addr 207 超出范围警告：drivers/net/phy/mdio_bus.c:76 验证 asix_read_phy_addr 中的 PHY 地址)并删除 ax88172a.c 中现已冗余的检查。
    (CVE-2025-71094)

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

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

  - ipv6修复 PREEMPT_RT 下 rt6_get_pcpu_route() 中的一个缺陷在 PREEMPT_RT 内核上当前任务可在 rt6_get_pcpu_route() 返回 NULL 之后被抢占。然后在同一 CPU 上运行的另一个任务可能执行 rt6_make_pcpu_route() 并成功安装 pcpu_rt 条目。当第一个任务恢复执行时rt6_make_pcpu_route() 中其 cmpxchg() 将失败因为 rt6i_pcpu 不再是 NULL从而触发 BUG_ON(prev)。通过在 rt6_get_pcpu_route() 之后添加 mdelay()可以轻松重现此问题。此处不适合使用 preempt_disable/enable因为 ip6_rt_pcpu_alloc() 可能会休眠。通过在 PREEMPT_RT 上妥善处理 cmpxchg() 失败来修复此问题释放我们的分配并返回由其他任务安装的现有 pcpu_rt。针对非 PREEMPT_RT 内核已由 WARN_ON_ONCE 替换不应发生此类争用的 BUG_ON。 (CVE-2025-71080)

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

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

  - 输入lkkbd - 在释放设备 lkkbd_interrupt() 通过 schedule_work() 计划 lk->tq 之前禁用待定工作且工作处理程序 lkkbd_reinit() 会取消引用 lkkbd 结构及其 serio/input_dev 字段。 lkKBd_disconnect() 和 lkKBd_connect() 中的错误路径会释放 lkKBd 结构但不会阻止 reinit 工作再次排队直到 serio_close() 返回。这可允许工作处理程序在结构释放后运行从而导致潜在的释放后使用。使用 disable_work_sync() 代替 cancel_work_sync() 以确保重新初始化工作无法重新排队并在 serio_open() 后的 lkkbd_disconnect() 和 lkkkd_connect() 错误路径中进行调用。 (CVE-2025-71073)

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

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

  - drm/amdgpu修复 gpu 恢复中的 job->pasid 访问争用 避免 GPU 恢复中因 sched 超时回调和 tdr 工作队列之间的争用而造成的 UAF。gpu 恢复函数调用 drm_sched_stop() 及稍后的 drm_sched_start()。 drm_sched_start() 重新启动最终将释放作业的 tdr 队列。如果 tdr 队列在超时回调完成之前释放了作业则作业将被释放并且我们将在访问 pasid 时获得 UAF。及早缓存以避免 UAF。KASAN 跟踪示例[ 493.058141] BUGKASANamdgpu_device_gpu_recover+0x968/0x990 中的 slab 释放后使用 [amdgpu] [493.067530] 由任务 kworker/u128:1/323 读取地址 ffff88b0ce3f794c 处大小 4 的值 [ 493.074892[ 493.076485] CPU9 UID: 0 PID: 323 Comm: kworker/u128:1 受感染的 GE 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(liberty) [ 493.076493] 受感染
    [E]=UNSIGNED_MODULE [ 493.076495] 硬件名称TYAN B8021G88V2HR-2T/S8021GM2NR-2TBIOS V1.03。B10 2019 年 04 月 1 日 [ 493.076500] Workqueueamdgpu-reset-dev drm_sched_job_timedout [gpu_sched] [ 493.076512] 调用跟踪[ 493.076515] <TASK> [ 493.076518] dump_stack_lvl+0x64/0x80 [ 493.076529] print_report+ 0xce/0x630 [493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0 [ 493.076541] __pfx__raw_spin_lock_irqsave+0x10/0x10 [493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077253] kasan_report+0xb8/0xf0 [493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu] [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu] [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu] [ 493.080903] ? pick_task_fair+0x24e/0x330 [ 493.080910] ?
    __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu] [ 493.081702] ? _raw_spin_lock+0x75/0xc0 [ 493.081708] ?
    __pfx__raw_spin_lock+0x10/0x10 [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched] [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081725] process_one_work+0x679/0xff0 [ 493.081732] worker_thread+0x6ce/0xfd0 [ 493.081736] ? __pfx_worker_thread+0x10/0x10 [ 493.081739] kthread+0x376/0x730 [ 493.081744] ? __pfx_kthread+0x10/0x10 [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081751] ?
    __pfx_kthread+0x10/0x10 [ 493.081755] ret_from_fork+0x247/0x330 [ 493.081761] ? __pfx_kthread+0x10/0x10 [493.081764] ret_from_fork_asm+0x1a/0x30 [ 493.081771] </TASK> 从提交 20880a3fd5dd7bca1a079534cf6596bda92e107d 中精选出的内容(CVE-2025-68793)

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

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

  - ext4xattr如果 ext4_get_inode_loc() 失败例如如果其返回
    -EFSCORRUPTED)iloc.bh 将保持为 NULL 设置。由于 ext4_xattr_inode_dec_ref_all() 缺少错误检查这将导致在紧随 ext4_get_inode_loc() 之后调用的 ext4_raw_inode() 中发生空指针取消引用。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2025-68820)

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

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

  - charapplicom修复由 Atuin - 自动化漏洞发现引擎发现的 ac_ioctl 中的空指针取消引用。在 ac_ioctl 中当 cmd 为 6 时IndexCard 的验证以及有效 RamIO 指针的检查都被跳过。然而该函数会在结束时无条件执行 readb(apbs[IndexCard].RamIO + VERS)。如果 cmd 为 6IndexCard 可能引用不存在的板其中 RamIO 为空从而导致空指针取消引用。通过在 cmd 为 6 时跳过 readb 访问来修复此命令因为此命令为全局信息查询且不针对特定的板环境。 (CVE-2025-68797)

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

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

  - mptcp更早回退同时连接 Syzkaller 报告一个同时连接争用导致不一致的回退状态警告CPU3 PID 33 (net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow)。链接在一起的 c:1515 模块CPU: 3 UID: 0 PID: 33 Comm
    ksoftirqd/3 未受感染 syzkaller #0 PREEMPT(full) 硬件名称QEMU Standard PCQ35 + ICH92009，BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 代码89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX:
    ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12:
    ffff88802ba69900 R131ffff920000d9e67 R14ffff888046f81800 R150000000000000004 FS
    0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 tcp_v6_do_rcv+0x492/0x1740 net/ ipv6/tcp_ipv6.c:1672 tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1e4/0x4b0ok_ipv6c.input include/linux/netfilter.h:318 [内联] NF_HOOK include/linux/netfilter.h:312 [内联] ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 dst_input include/net/dst.h:471 [ inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x264/0x650 net/ipv6/ ip6_input.c:311 __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979
    __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 process_backlog+0x442/0x15e0 net/core/dev.c:6444
    __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 napi_poll net/core/dev.c:7557 [内联] net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 run_ksoftirqd kernel/softirq.c:968 [inline] run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread .c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> TCP 子流可处理 simult-connect syn-ack数据包在转换到 TCP_FIN1 状态后绕过 MPTCP 回退检查因为 * -> FIN_WAIT1 转换不会调用 sk_state_change() 回调。这会将 msk 套接字移至不一致状态且下一个传入数据将命中报告的 splat。关闭在尽早移动 simult-fallback 检查的争用阶段即在 syn-ack 生成时。关于补丁标签 [2] 应该也修复 [3] 引入的此问题。需要 [1] 作为依存关系没有明确将其标记为补丁但实际是一个补丁并且在 [3] 之前已向后移植。换言之此提交应向后移植到 [3] 包括 [2] 和 [1]如果尚不存在。 (CVE-2025-71088)

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

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

  - iommu设置 CONFIG_X86 时禁用 SVA 修补程序系列修复内核地址空间 v7 的过时 IOTLB 条目。此更新提议针对一个与 IOMMU 共享虚拟寻址 (SVA) 有关的安全漏洞的补丁。在 SVA 上下文中，IOMMU 可以缓存内核页表条目。当出于其他目的释放并重新分配内核页表页面时IOMMU 可能仍包含过时的错误条目。这可被利用于造成释放后使用或释放后写入情况从而可能导致权限升级或数据损坏。此解决方案引入了内核页表页面的延迟释放机制该机制提供了一个安全窗口通知 IOMMU 在重新使用页面之前使其缓存无效。此修补程序共 8个修补程序修复了在 IOMMU 共享虚拟寻址 (SVA) 环境中IOMMU 硬件共享并遍历 CPU 的页表。x86 架构将内核的虚拟地址空间映射到每个进程页表的上位部分。因此在 SVA 环境中IOMMU 硬件可以遍历和缓存内核页表条目。Linux 内核当前缺少针对内核页表变更的通知机制尤其是在释放并重用页表页面时。IOMMU 驱动程序只会收到用户虚拟地址映射发生更改的通知。这可造成 IOMMU 的内部缓存保留内核 VA 的过时条目。释放后重新分配内核页表页面时会出现释放后使用 (UAF) 和释放后写入 (WAF) 情况。IOMMU 可能将新数据错误解释为有效页表条目。然后IOMMU 可能会进入攻击者控制的内存从而导致任意物理内存 DMA 访问或权限升级。这也是释放后写入问题因为 IOMMU 在尝试遍历过时页表时可能会继续将已访问和脏位写入已释放的内存。目前SVA 上下文没有权限因此无法访问内核映射。但是，IOMMU 仍会遍历仅内核页表一直到叶条目，并在叶条目中意识到映射用于内核并输出错误。这意味着 IOMMU 仍会缓存这些中间页表条目从而使所述漏洞真正引起关注。在释放 CPU 内核页表页面之前禁用 x86 架构上的 SVA 直到 IOMMU 可以收到通知刷新分页缓存。 (CVE-2025-71089)

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

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

  - Fulcio 是为 OpenID Connect (OIDC) 身份颁发代码签名证书的证书颁发机构。在在 1.8.5版本中Fulcio 的 metaRegex() 函数使用未锚定的 regex允许攻击者绕过 MetaIssuer URL 验证并触发前往任意内部服务的 SSRF。由于 SSRF 只能触发 GET 请求因此该请求无法改变状态。来自 GET 请求的响应不会返回给调用程序因此无法发生数据外泄。恶意执行者可尝试通过 Blind SSRF 探测内部网络。此漏洞已在 1.8.5 中修复。(CVE-2026-22772)

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

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

  - functionfs修复打开/删除争用 ffs_epfile_open() 可能与删除争用导致 file->private_data 指向已释放对象。functionfs 上存在一个打开的文件总数ep0 和动态文件当总数为零时动态文件会被删除。遗憾的是当另一个线程处于 ffs_epfile_open() 状态但尚未增加计数时可能会发生该删除操作。在这种情况下打开将成功导致我们在任何后续的 read() 或 write() 中遇到 UAF。根本原因是ffs->opened 被误用当对象始终保持可见时，atomic_dec_and_test() 与 atomic_add_return() 不是一个好想法。若要解开 * 序列化 ffs->mutex 上的开启程序针对 ep0 和动态文件 * 动态的开启程序请使用 atomic_inc_not_zero()并且会在我们进行 zero ->opened 时失败在这种情况下，我们打开的文件就会失败。 * 在删除时标记了动态文件的 inode来自 simple_recursive_removal() 的回调 - 此处清除 ->i_private。 * 打开动态条目验证其未被删除并检查状态是否为 FFS_ACTIVE。 (CVE-2025-71074)

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

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

  - iavf修复 iavf_config_rss_reg() 中的大小差一问题 配置 RSS 哈希密钥和查找表时存在大小差一缺陷导致内存越界读取 [1] 和写入设备寄存器的作用域。在提交 43a3d9ba34c9 i40evf允许 PF 驱动程序配置 RSS之前循环上限为该提交将边界更改为i <= adapter->rss_{key,lut}_size / 4其中“rss_{key,lut}_size / 4”为 dword 的数量因此上一个有效索引为“(rss_{ key,lut}_size / 4) - 1`。因此使用“<=”会访问超出末尾的一个元素。使用“<”而不是“<=”修复问题确保不超出边界。 [1] 关于 rss_key_size 差一缺陷的 KASAN splat“KASAN: iavf_config_rss+0x619/0x800 中在地址 ffff888102c50134 的大小为 4 的读取中由任务 kworker/u8:6/63 CPU: 0 UID 执行的 slab 越界读取” 0 PID63 Commkworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT自主）硬件名称QEMU Standard PCQ35 + ICH9、2009、BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作队列iavf iavf_watchdog_task 调用跟踪 <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchbe20x30x3237/task process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK> 由任务 63 分配
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90
    __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc -64 大小的 64 有缺陷的地址位于已分配 52 字节区域右侧 0 字节处 [ffff888102c50100、ffff888102c50134有缺陷的地址属于物理页page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn 0x102c50 标记 0x200000000000000(node=0|zone=2) page_type
    f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc (CVE-2025-71087)

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

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

  - team修复对 team_queue_override_port_prio_changed() 中启用的端口的检查 最近报告一个带有以下跟踪的 syzkaller 缺陷list_del 损坏ffff888058bea080->prev 是 LIST_POISON2 (dead000000000122) ------------[在此处切换 ]------------ lib/list_debug.c:59! 的内核缺陷Oops无效的 opcode0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) 硬件名称QEMU Standard PC（Q35 + ICH9、2009） BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 代码48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09:
     R100000000000000000  : 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 : 0000000080050033 CR2:000000110c3afcb0 CR3:
    00000000382c7000 CR40000000000352ef0 调用跟踪 <TASK> __list_del_entry_valid include/linux/list.h:132 [内联] __list_del_entry include/linux/list.h:223 [内联] list_del_rcu include/linux/rculist.h:178 [内联] __team_queue_override_port_del 驱动程序/net/team/team_core.c:826 [内联]
    __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net /team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c 1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink /af_netlink.c:1320 [内联] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [内联] __sock_sendmsg net /socket.c:742 [内联]____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684
    __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 问题在此流中: 1) 端口已启用queue_id != 0在 qom_list 2) 端口被禁用 -> team_port_disable() -> team_queue_override_port_del() -> del从列表中删除3) 端口已禁用 queue_id != 0、 不在任何列表中 4) 优先级变更 -> team_queue_override_port_prio_changed() -> 检查
    port enabled && queue_id != 0 -> 调用 del - 命中缺陷因为其已被删除。要修复此问题请在 team_queue_override_port_prio_changed() 中更改检查使其在未启用端口时提早返回。
    (CVE-2025-71091)

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

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

  - powerpc/64s/slb在 SLB 预加载期间修复了 SLB 多重命中问题使用哈希 MMU 的系统中存在一个软件 SLB 预加载缓存它会镜像加载到硬件 SLB 缓冲区中的条目。第 256 章：
    为优化性能当上一个和下一个 mm_struct 相同时内核会在 switch_mm_irqs_off() 中跳过 switch_mmu_context()。但是在哈希 MMU 系统上这可能导致硬件 SLB 和软件预加载缓存之间出现不一致。如果进程的 SLB 条目在一个 CPU 上被从软件缓存逐出而后在另一个 CPU 上运行相同的进程而没有执行 switch_mmu_context()则硬件 SLB 可能会保留过时的条目。如果内核此后尝试重新加载该条目则可触发 SLB 多次命中错误。以下时间线显示了过时的 SLB 条目是如何创建的以及如何在进程在无 MMU 上下文切换的 CPU 之间移动时导致多重命中错误。CPU 0 CPU 1 -----
    ----- Process P exec swapper/1 load_elf_binarybegin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * 此操作会使 HW 中的所有条目无效 * 并根据 * 预加载缓存设置新的 HW * SLB 条目。 */ context_switch sched_migrate_task 将进程 P 迁移到 cpu-1 进程 swapper/0 上下文切换到进程 P使用进程 P 的 mm_struct switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb 在此变为 0 *我们从 * 中逐出一个条目通过 * preload_age() 预加载缓存。我们仍然 * 保持 HW SLB 和预加载 * 缓存同步这是因为 * 在 SLBIA 期间所有 HW SLB 条目 * 无论如何都会在 switch_slb 中逐出。 * 然后我们仅将这些条目添加回 HW SLB 中 * 当前 * 存在于 preload_cache * 中的条目 * 驱逐后。 */ load_elf_binary continue...
    setup_new_exec() slb_setup_new_exec() sched_switch 事件 sched_migrate_task 将进程 P 迁移到 cpu-0 context_switch 从 swapper/0 到进程 P switch_mm_irqs_off() /* * 由于上一个和下一个 mm struct 相同我们不会调用 * switch_mmu_context()。这会造成 HW SLB 和软件预加载 * 缓存在 preload_new_slb_context 中不同步。因为 * cpu-1 上的 *一个 SLB 条目已从 HW 和预加载缓存中逐出。* 之后在 preload_new_slb_context() 中我们将再次尝试添加相同的预加载条目时* 会将其添加至 SW 预加载缓存然后将其添加至 HW SLB。由于在 cpu-0 上此条目从未失效因此将此条目添加到 HW * SLB 将导致 SLB 多重命中错误。 */ load_elf_binary cont ---truncated--- (CVE-2025-71078)

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

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

  - RDMA/core正确检查是否存在 LS_NLA_TYPE_DGID RDMA_NL_LS_OP_IP_RESOLVE 的 netlink 响应应始终具有 LS_NLA_TYPE_DGID 属性否则无效。
    正确使用 nl 解析逻辑并调用 nla_parse_deprecated() 以填充 nlattrs 数组然后直接为该数组编制索引以获取 DGID 的数据。为空时仅失败。删除搜索 nla 的 for 循环并将验证和解析压缩为一个函数。修复如果用户空间未向内核发起的 RDMA_NL_LS_OP_IP_RESOLVE 查询提供 DGID 则会触发由用户空间触发的来自堆栈的未初始化读取。BUGKMSANhex_byte_pack include/linux/hex.h:13 中的 uninit-value [内联] BUGKMSANip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h 中的 uninit-value 13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633pointer+0xc09/0x1bd0 lib/vsprintf.c 2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk /printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [内联] ib_nl_handle_ip_res_resp +0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [内联] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [内联] rdma_nl_rcv+0xefa/ 0x11c0 drivers/infiniband/core/netlink.c :259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c 714 [内联]
    __sock_sendmsg+0x333/0x3d0 net/socket.c:729____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
    ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703
    __compat_sys_sendmsg net/compat.c:346 [内联] __do_compat_sys_sendmsg net/compat.c:353 [内联]
    __se_compat_sys_sendmsg net/compat.c:350 [内联] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry syscall_32.c:83 [内联] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry /syscall_32.c:3 (CVE-2025-71096)

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

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

  - iommu/mediatek修复探测延迟时的释放后使用 驱动程序正在删除在成功查找后的探测期间以及出错时对 larb 设备的引用。这可能会导致释放后使用以防 larb 设备尚未绑定至其驱动程序使得 iommu 驱动程序探测延迟。通过在绑定 iommu 驱动程序时按预期保持引用来修复此问题。 (CVE-2025-71071)

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

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

  - ksmbd在相等大小上跳过 lock-range 检查以避免 size==0 下溢当大小等于当前 i_size包括 0时此代码用于调用 check_lock_range(filp, i_size, size - 1, WRITE)该代码计算 `大小
    - 1`并且可在大小== 0 时下溢。跳过相等情况。 (CVE-2025-68786)

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

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

  - ip6_gre使 ip6gre_header() 健全 多年以来syzbot 在 ip6gre_header() 中发现许多造成内核崩溃的方式 [1]。这涉及团队或绑定驱动程序动态更改其 dev->needed_headroom 和/或 dev->hard_header_len 的能力。在此特定崩溃中mld_newpack() 为 skb 分配了预留空间/余量过小的 skb在调用 mld_sendpack() 时syzbot 已成功附加 ip6gre 设备。 [1] skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[在此剪切 ]--- --------- net/core/skbuff.c:213 的内核缺陷 <TASK> skb_under_panic net/core/skbuff.c:223 [内联] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice。 h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ ipv6/ip6_output.c:-1 [内联] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [内联] ip6_output+0x340/0x550 net/ipv6/ip6_output.c :247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [内联] mld_ifc_work+0x83e/0xd60 net/ ipv6/mcast.c:2693 (CVE-2025-71098)

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

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

  - svcrdma将 rc_pageoff 用于 memcpy 字节偏移 svc_rdma_copy_inline_range 将 rc_curpage页面索引而不是字节偏移 rc_pageoff 添加到页库。使用 rc_pageoff以便副本落在当前页面中。由 ZeroPath 发现 (https://zeropath.com) (CVE-2025-68811)

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

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

  - btrfs如果是在当前事务中移动的目录则不记录冲突的 inode 如果是目录且已在当前事务中从一个父目录移动到另一个父目录则无法记录冲突的 inode 因为这会结果在日志重播期间尝试获得包含两个硬链接的目录一个用于旧的父目录另一个用于新的父目录。以下情况会触发该问题1) 存在在过去的事务中创建的目录 dir1 和 dir2。目录 dir1 将 inode A 作为其父目录2) 将 dir1 移动到其他某个目录3) 在目录 inode A 中创建一个名为 dir1 的文件4) 对新文件进行 fsync。这会导致记录新文件的 inode 以及之前在当前事务中移动的目录 dir1 的 inode。因此日志树中的 INODE_REF 项目对应于 dir1 的新位置
    5) 我们将新文件移动到其他某个目录。这会导致更新日志树以包括文件新位置的新 INODE_REF并删除旧位置的 INODE_REF。当我们调用 btrfs_log_new_name() 时在重命名期间会发生这种情况6) 我们对文件进行 fsync，以便持久保存上步骤中完成的日志树更改btrfs_log_new_name() 仅更新内存中的日志树7) 停电了8) 下次挂载 fs 时会发生日志重播并且在处理目录 dir1 的 inode 时会发现新的 INODE_REF 并添加该链接但不会删除 inode 的旧链接因为尚未记录旧父项目录 inode dir1 的目录。因此在日志重播完成后我们触发子卷树的范围缓冲区的回写时树检查将检测到硬链接计数为 2 的目录即挂载失败。dmesg/syslog 中报告的错误和堆栈跟踪如下所示[ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags
    0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw
    017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino =257无效的 nlink有 2 个预期不超过 1 个用于 dir [ 3845.737786] BTRFS info设备 dm-0叶 30408704 gen 10 总指针 17 可用空间 14881 所有者 5 [ 3845.737789] BTRFS 信息设备 dm- 0)refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [3845.737803] 项目 1 密钥 (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] 项目 3 k ey (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [3845.737816] 位置密钥 (257 1 0) 类型 2 [ ---truncated--- (CVE-2025-68778)

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

ID	名称	严重性
283662	Linux Distros 未修补的漏洞：CVE-2025-68774	medium
283661	Linux Distros 未修补的漏洞：CVE-2025-68823	high
283660	Linux Distros 未修补的漏洞：CVE-2025-68781	high
283659	Linux Distros 未修补的漏洞：CVE-2025-68798	high
283658	Linux Distros 未修补的漏洞：CVE-2025-71084	medium
283657	Linux Distros 未修补的漏洞：CVE-2025-68768	medium
283656	Linux Distros 未修补的漏洞：CVE-2025-71085	high
283655	Linux Distros 未修补的漏洞：CVE-2025-68785	medium
283654	Linux Distros 未修补的漏洞：CVE-2025-68770	medium
283653	Linux Distros 未修补的漏洞：CVE-2025-68813	medium
283652	Linux Distros 未修补的漏洞：CVE-2025-71090	medium
283651	Linux Distros 未修补的漏洞：CVE-2025-68819	medium
283650	Linux Distros 未修补的漏洞：CVE-2025-68801	high
283649	Linux Distros 未修补的漏洞：CVE-2025-68777	medium
283648	Linux Distros 未修补的漏洞：CVE-2025-68821	medium
283647	Linux Distros 未修补的漏洞：CVE-2025-71066	medium
283646	Linux Distros 未修补的漏洞：CVE-2025-68788	medium
283645	Linux Distros 未修补的漏洞：CVE-2025-71092	high
283644	Linux Distros 未修补的漏洞：CVE-2025-71101	high
283643	Linux Distros 未修补的漏洞：CVE-2025-71067	high
283642	Linux Distros 未修补的漏洞：CVE-2025-71069	medium
283641	Linux Distros 未修补的漏洞：CVE-2025-68769	medium
283640	Linux Distros 未修补的漏洞：CVE-2025-71072	medium
283639	Linux Distros 未修补的漏洞：CVE-2025-68812	medium
283638	Linux Distros 未修补的漏洞：CVE-2025-71097	medium
283637	Linux Distros 未修补的漏洞：CVE-2025-71086	medium
283636	Linux Distros 未修补的漏洞：CVE-2025-68809	medium
283635	Linux Distros 未修补的漏洞：CVE-2025-68814	medium
283634	Linux Distros 未修补的漏洞：CVE-2025-68822	medium
283633	Linux Distros 未修补的漏洞：CVE-2025-68808	high
283632	Linux Distros 未修补的漏洞：CVE-2025-68470	medium
283631	Linux Distros 未修补的漏洞：CVE-2025-71094	medium
283630	Linux Distros 未修补的漏洞：CVE-2025-71080	high
283629	Linux Distros 未修补的漏洞：CVE-2025-71073	high
283628	Linux Distros 未修补的漏洞：CVE-2025-68793	medium
283627	Linux Distros 未修补的漏洞：CVE-2025-68820	medium
283626	Linux Distros 未修补的漏洞：CVE-2025-68797	medium
283625	Linux Distros 未修补的漏洞：CVE-2025-71088	medium
283624	Linux Distros 未修补的漏洞：CVE-2025-71089	high
283623	Linux Distros 未修补的漏洞：CVE-2026-22772	medium
283622	Linux Distros 未修补的漏洞：CVE-2025-71074	medium
283621	Linux Distros 未修补的漏洞：CVE-2025-71087	high
283620	Linux Distros 未修补的漏洞：CVE-2025-71091	medium
283619	Linux Distros 未修补的漏洞：CVE-2025-71078	medium
283618	Linux Distros 未修补的漏洞：CVE-2025-71096	high
283617	Linux Distros 未修补的漏洞：CVE-2025-71071	high
283616	Linux Distros 未修补的漏洞：CVE-2025-68786	high
283615	Linux Distros 未修补的漏洞：CVE-2025-71098	medium
283614	Linux Distros 未修补的漏洞：CVE-2025-68811	high
283613	Linux Distros 未修补的漏洞：CVE-2025-68778	low

检测

Nessus 的 Misc. 系列

medium

high

high

high

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

high

medium

high

low