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

  - WordPress 6.9.x 之前 6.9.5 和 7.0.x 之前 7.0.2 版本受到 REST API 批次端点路由混淆问题的影响，该问题与 SQL 注入 （）CVE-2026-60137 author__not_in WP_Query相结合，可允许攻击者执行 SQL 注入并实现远程代码执行。（CVE-2026-63030）

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

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

  - i2c：i801：修复错误路径中的硬件状态机损坏 在并发模糊测试期间，在 i2c-i801 驱动程序中发现严重的活锁和后续的挂起任务错误。崩溃是由 i801_access（） 的错误处理路径中无条件的硬件寄存器清理所造成。当 i801_check_pre（） 失败时（例如，由于 BIOS/ACPI 主动使用 SMBus 控制器而返回 -EBUSY），内核实际上不会获得硬件所有权。不过，代码会跳转到“out”标签并执行：
    iowrite8（SMBHSTSTS_INUSE_STS |STATUS_FLAGS， SMBHSTSTS（priv））;这将在不拥有控制器的情况下强制清除INUSE_STS锁定并重置硬件状态标记。这样做会中断正在进行的 BIOS/ACPI 事务并完全损坏 SMBus 硬件状态机。因此，所有后续的 i801_access（） 调用都会在预检查阶段失败，从而触发源源不断的 SMBus 繁忙，无法使用！错误日志。在缓慢的串行控制台上，此 printk 洪流会独占 CPU（控制台活锁），使尝试获取 mmap_lock down_read 信号量的其他进程匮乏，最终触发挂起任务监视程序。通过将“out”标签移动到硬件寄存器清理下方来修复此问题。如果 i801_check_pre（） 失败，我们将安全地绕过 iowrite8（） 并仅释放软件锁（pm_runtime 和互斥），严格遵守不释放从未获取的资源的规则。
    (CVE-2026-64205)

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

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

  - netfilter：ipset：修复转储与ip_set_list大小调整之间的争用 ip_set_dump_do（） 和 ip_set_dump_done（） 的释放路径通过数组指针的普通 rcu_dereference_raw（）ip_set_ref_netlink（） 读取 inst->ip_set_list。这些程序包从 netlink_recvmsg（） 运行，不具备 nfnl 互斥体且无 RCU 读取端关键部分。并发 ip_set_create（） 可以增加数组：它发布新数组，调用 synchronize_net（），然后 kvfree（） 旧数组。由于转储路径读取任何 RCU 读取器外部的数组，synchronize_net（） 不会等待它们，并且可以在旧数组仍编制索引时释放旧数组，从而造成释放后使用。转储的集合本身会通过 set->ref_netlink 保持固定，因此只有数组加载需要保护。取 rcu_read_lock（），匹配 ip_set_get_byname（） 和
    __ip_set_put_byindex（）。缺陷：KASAN：ip_set_dump_do 中的 slab-use-after-free （net/netfilter/ipset/ip_set_core.c：1697） 任务 exploit/150 在地址 ffff88800b5c4018 读取大小为 8 调用跟踪：...kasan_report （mm/kasan/report.c：595） ip_set_dump_do （net/netfilter/ipset/ip_set_core.c：1697） netlink_dump （net/netlink/af_netlink.c：2325） netlink_recvmsg （net/netlink/af_netlink.c：1976） sock_recvmsg （net/socket.c：1159） __sys_recvfrom （net/socket.c：2315） ... 哎呀：一般保护错误，可能针对非规范地址... KASAN NOPTI KASAN：可能是范围中的失控内存访问 [0x02d6...d0-0x02d6...d7] RIP：0010：ip_set_dump_do （net/netfilter/ipset/ip_set_core.c：1698） 内核错误 - 不同步：致命异常 （CVE-2026-64189）

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

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

  - xfs：无法在无区域的已提交日志项上恢复 如果事务的第一个 op 是裸事务标头 （len == sizeof（struct xfs_trans_header）），则 xlog_recover_add_to_trans（） 会添加一个项目但不添加任何区域，从而将其保留在 ri_cnt == 0 且 ri_buf == NULL 的r_itemq上。标头可以在 op 记录之间拆分，因此以后的 ops 仍可能添加区域;仅当事务以 None 提交时，该项目才无效。运行时提交路径从不发出此类事务，因此这只会在构建的日志上发生。它来自对恢复解析器的人工智能辅助代码审计。xlog_recover_reorder_trans（） 在该项目上调用 ITEM_TYPE（），该项目读取 *（unsigned short *）item->ri_buf[0].iov_base 并在 NULL ri_buf上发生错误。在同样读取 ri_buf[0] 的提交处理程序之前将其拒绝。KASAN：范围内的 null-ptr-deref [0x0000000000000000-0x0000000000000007] RIP：0010：xlog_recover_reorder_trans （fs/xfs/xfs_log_recover.c：1836） xlog_recover_commit_trans （fs/xfs/xfs_log_recover.c：2043） xlog_recover_process_data （fs/xfs/xfs_log_recover.c：2501） xlog_do_recovery_pass （fs/xfs/xfs_log_recover.c：3244） xlog_recover （fs/xfs/xfs_log_recover.c：3493） xfs_log_mount （fs/xfs/xfs_log.c：618） xfs_mountfs （fs/xfs/xfs_mount.c：1034） xfs_fs_fill_super （fs/xfs/xfs_super.c：1938） vfs_get_tree （fs/super.c：1695） path_mount （fs/namespace.c：4161） __x64_sys_mount （fs/namespace.c：4367） （CVE-2026-64187）

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

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

  - i2c：stub：拒绝具有无效长度的 I2C 区块传输。stub_xfer（） 中的I2C_SMBUS_I2C_BLOCK_DATA情况使用 data->block[0] 作为传输长度。现有检查仅限制它以避免 chip->words[256] 寄存器数组溢出，但未依据 I2C_SMBUS_BLOCK_MAX （32） 进行验证，后者是 union i2c_smbus_data.block 缓冲区的限制（总共 34 字节）。驱动程序是必须通过 chip_addr= 参数加载的开发/测试工具（CONFIG_I2C_STUB=m，默认情况下未构建）。具有 /dev/i2c-* 访问权限的本地用户可发出带有 I2C_SMBUS_I2C_BLOCK_DATA 和 data->block[0] > 32 的I2C_SMBUS ioctl，从而导致 stub_xfer（） 读取或写入超过 union i2c_smbus_data.block 缓冲区的末尾： 缺陷：
    KASAN：stub_xfer 中的堆栈越界 （drivers/i2c/i2c-stub.c：223） 任务 exploit/81 在地址 ffff88800abcfd92 处读取大小为 1 调用跟踪： <TASK> stub_xfer （drivers/i2c/i2c-stub.c：223）
    __i2c_smbus_xfer （drivers/i2c/i2c-core-smbus.c：593） i2c_smbus_xfer （drivers/i2c/i2c-core-smbus.c：536） i2cdev_ioctl_smbus （drivers/i2c/i2c-dev.c：391） i2cdev_ioctl （drivers/i2c/i2c-dev.c：478） __x64_sys_ioctl （fs/ioctl.c：583） do_syscall_64 （arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：130） </TASK> 此缺陷之所以存在，是因为 i2c-stub 直接实现了 .smbus_xfer 绕过 i2c_smbus_xfer_emulated（） 中的I2C_SMBUS_BLOCK_MAX验证。同一函数中的 I2C_SMBUS_BLOCK_DATA 案例会正确验证I2C_SMBUS_BLOCK_MAX，但I2C_SMBUS_I2C_BLOCK_DATA情况不会。通过拒绝带有 data->block[0] == 0 的传输或带有 -EINVAL 的 data->block[0] > I2C_SMBUS_BLOCK_MAX进行修复，这与同一函数中的I2C_SMBUS_BLOCK_DATA情况和 i2c_smbus_xfer_emulated（） 中的I2C_SMBUS_I2C_BLOCK_DATA验证一致。（CVE-2026-64191）

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

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

  - libvips 是一个快速的图像处理库，对内存的需求很低。libvips 之前和之前 8.18.1 版本中的“tiffload”操作可能错误地确定 TIFF 图像内 JPEG 或 JPEG2000编码平铺中的通道数量，从而可能导致缓冲区溢出。已在版本 8.18.2.（CVE-2026-35591）

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

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

  - bpf：如果 BPF LSM 未初始化，则拒绝BPF_MAP_TYPE_INODE_STORAGE创建 设置 CONFIG_BPF_LSM=y 时，BPF inode 存储映射 （BPF_MAP_TYPE_INODE_STORAGE） 被编译到内核中。但是，如果在引导时未显式启用 BPF LSM（如从 lsm= boot 参数中忽略），则绝不会为 BPF LSM 执行 lsm_prepare（）。因此，从不初始化 BPF inode 安全 blob 偏移 （bpf_lsm_blob_sizes.lbs_inode） 并保持其默认编译大小 8 字节，而不是更新为超过预留结构rcu_head（通常为 16 字节或更大）的有效偏移。
    当特权用户创建并更新BPF_MAP_TYPE_INODE_STORAGE映射时，bpf_inode（） 评估 inode->i_security + 8。这会错误地将 struct rcu_head.func 回调指针放在 inode >i_security blob 的开头。在后续映射元素清理或 inode 销毁期间，将 NULL 写入 owner_storage 会清除排队的 RCU 回调指针。当 rcu_do_batch（） 稍后执行已排队的回调时，它会在地址0x0尝试指令提取，从而立即触发内核错误。通过引入标有 __ro_after_init 的全局bpf_lsm_initialized布尔标记来修复此问题。当 LSM 框架成功注册 BPF LSM 时，在 bpf_lsm_init（） 中将此标记设置为 true。此标记的 inode_storage_map_alloc（） 中的门映射分配，如果 BPF LSM 反过来未初始化，则返回 -EOPNOTSUPP。
    此 fail-fast 方法可防止用户空间在缺少支持 BPF LSM 基础架构时分配 inode 存储映射，避免僵尸映射状态。（CVE-2026-64192）

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

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

  - net/sched：dualpi2：修复 GSO 积压计数 当 DualPI2 将 GSO skb 拆分为 N 个段时，它会在返回 NET_XMIT_SUCCESS 之前将另外 N 个数据包传播到其父段。然后，父项再次考虑原始 skb，留下比实际排队的数据包数大的 qlen 1。
    将 QFQ 作为父项，在所有实际数据包出列后，QFQ 仍具有非零 qlen，而其服务聚合没有活动类。qfq_choose_next_agg（） 返回 NULL，qfq_dequeue（） 将结果传递给 qfq_peek_skb（），从而导致空指针取消引用。遵循 tbf_segment（） 和 taprio 使用的相同模式：仅计数成功排队的段，传播原始 skb 和这些段之间的差异，并在至少有一个段排队时返回NET_XMIT_SUCCESS。
    (CVE-2026-64207)

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

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

  - （受影响的 <=3.27.1） 之前3.28.0的 FreeRDP 在 crypto_rsa_common（） （libfreerdp/crypto/crypto.c） 中包含基于堆的缓冲区溢出。该函数通过 BN_bn2bin（） 将模块化取幂结果写入调用方的输出缓冲区，并且仅在之后检查output_length > out_length，因此会在边界检查之前写入越界字节。在服务器端，当客户端选择 RDP 标准安全性时，加密的客户端随机数将被解密为固定的 32 字节缓冲区。由于服务器发布其 RSA 公钥，未经认证的攻击者可伪造解密值达到完整模数长度（例如 RSA-2048 为 256 字节）的密文，使 32 字节堆缓冲区溢出多达 ~224 个由攻击者控制的字节预认证，从而导致拒绝服务。（CVE-2026-64620）

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

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

  - libvips 是一个快速的图像处理库，对内存的需求很低。以前和包含 8.18.0 版本中的“vipsload”操作可能错误地确定图像尺寸，从而导致整数溢出和后续的基于堆的缓冲区溢出。已在版本 8.18.1.（CVE-2026-33327）

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

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

  - libvips 是一个快速的图像处理库，对内存的需求很低。在 的 和之前 8.18.0版本的 32 位系统中，“gifload”操作可错误地确定尺寸，从而导致整数溢出。已在版本 8.18.1.（CVE-2026-33328）

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

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

  - net：team：修复模式变更期间 team_xmit 中的空指针取消引用 __team_change_mode（） 通过 team_adjust_ops（） 还原安全的虚拟处理程序前，先清除含有 memset（） 的 team->ops。另一个 CPU 上的 RCU 下并行运行的 team_xmit（） 可能会在此窗口期间读取 team->ops.transmit 并调用空函数指针，从而造成内核崩溃。比赛需要在团队设备上同时进行模式变更 （CAP_NET_ADMIN） 和传输。缺陷：内核空指针取消引用，地址：0000000000000000 哎呀：
    0010 [#1] SMP KASAN NOPTI RIP：0010：0x0 调用跟踪：team_xmit （drivers/net/team/team_core.c：1853） dev_hard_start_xmit （net/core/dev.c：3904） __dev_queue_xmit （net/core/dev.c：4871） packet_sendmsg （net/packet/af_packet.c：3109） __sys_sendto （net/socket.c：2265） 原始代码假设没有端口意味着没有流量，因此模式更改可以随意 memset（）/memcpy（） ops。带有强制载波的AF_PACKET打破了这一假设。防止争用而不是使其安全：将 memset（）/memcpy（） 替换为从不接触传输或接收的每字段更新。这两个处理程序仅由 team_adjust_ops（） 管理，后者会在 tx_en_port_count == 0 时（模式变更期间始终为真，因为不存在端口）时已安装虚拟程序。WRITE_ONCE/READ_ONCE 阻止处理程序指针上的存储/加载撕裂。exit_op（） 之前的 synchronize_net（） 耗尽正在传输的读取器，这些读取器可能仍然引用端口删除前的旧模式状态，将处理程序切换为虚拟程序。（CVE-2026-64190）

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

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

  - Bluetooth：L2CAP：在执行 conn->lock 之前取消pending_rx_work l2cap_conn_del（） 采用 conn->lock 然后调用 cancel_work_sync（） 进行pending_rx_work。process_pending_rx（） 采用相同的互斥体，因此 teardown 可针对它要刷新的工作线程进行死锁。此问题是我们的静态分析工具发现的，然后对照当前树手动查看。接地的 PoC 保留了 l2cap_conn_ready（） -> queue_work（...， &conn->pending_rx_work） 提交路径、l2cap_conn_del（） -> cancel_work_sync（&conn->pending_rx_work） 拆卸路径和 process_pending_rx（） -> mutex_lock（&conn->lock） 工作边缘。Lockdep 警告：检测到可能的循环锁定依赖关系 process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** 死锁 *** 在进行 conn->lock 之前取消pending_rx_work，以匹配用于同一拆卸路径中两个延迟工作的现有 lock-before-drain 顺序。在取消工作并获得 conn->lock 之后，仍会清除pending_rx队列。（CVE-2026-64206）

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

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

  - Perl 的 Net：:D NS 版本 1.55 允许通过 EDNS 扩展错误进行远程执行注入。
    Net：:D NS：：RR：：OPT：：EXTENDED_ERROR：：_decompose 通过标记原始字节并将结果传递至 Perl 的 eval 来解析 EDNS EXTENDED-ERROR 选项 （RFC 8914） 的 EXTRA-TEXT 字段。对 $ 和 @ 进行了一些转义，但不对反撇号进行了转义。如果在数组上下文中调用 ->edns->option（'EXTENDED-ERROR'），例如在 EXTRA-TEXT 中负载 {0：'<command>'}，则$pkt可利用此漏洞来执行命令。（CVE-2026-64193）

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

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

  - 由于 ['afsql_dd_run_query']（）https://github.com/syslog-ng/syslog-ng/blob/649e6e18e3459fb4467000a88dfb12fa97f9719c/modules/afsql/afsql.c#L219 中缺少审查调用，syslog-ng 之前 4.12 容易遭受来自不受信任来源的 SQL 注入攻击。这不是默认配置的一部分，SQL 驱动程序必须手动配置。syslog-ng 4.12、syslog-ng Premium Edition 8.2 和 syslog-ng Store Box 7.8 （CVE-2026-39879） 中包含补丁

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

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

  - Perl 的 1.55 Net：:D NS 版本允许通过深层 DNS 压缩指针链造成拒绝服务。
    Net：:D NS：:D omainName：:d ecode 通过递归到自身来遵循 RFC 1035 压缩指针，无深度限制。可能构造使调用堆栈饱和的名称（至少需要更大的 TCP 响应），从而导致潜在的拒绝服务。防护“$link < $offset”阻止向前和循环链，但是仍然允许任意长的向后链。每个偏移量缓存 （'$cache'） 在每次调用开始时填充，并且短路仅会重新遍历同一偏移 - 通过新链的初始下降仍会以完整深度递归。构建的数据包可链接双字节压缩指针，使每个压缩指针比前一个压缩指针早指向两个字节，从而生成“offset / 2”的链长度。对于 14 位指针字段（最大偏移 16383），这会造成多达 ~8191 个递归帧。
    对于 TCP DNS 消息，该限制为 16 位长度字段（~32767 帧）。Perl 的默认 C 堆栈仅处理几千帧;超出此范围，进程会收到 SIGSEGV 或类似消息，这对任何解析不受信任的 DNS 数据的应用程序都会造成拒绝服务。“Net：:D NS：:P acket->new（\$wire）”会触发该漏洞，即库从网络解码 DNS 消息的任何点。
    (CVE-2026-64194)

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

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

  - net：qualcomm：rmnet：修复 rmnet_dellink（） 中的端点释放后使用 rmnet_dellink（） 使用 hlist_del_init_rcu（） 从哈希表中删除端点，然后立即使用 kfree（） 将其释放。但是，接收路径 （rmnet_rx_handler -> __rmnet_map_ingress_handler） 上的 RCU 读取器可能仍会保留对端点的引用，并在内存释放后取消引用 ep->egress_dev。端点为 kmalloc-32 对象，偏移 8 处的过时读取对应于egress_dev指针。缺陷：无法处理地址的页面错误：ffffffffde942eef 错误：0002 [#1] SMP NOPTI CPU：1 UID：0 PID：137 通信：
    poc_write 未受感染 7.0.0+ #4 PREEMPTLAZY RIP：0010：rmnet_vnd_rx_fixup （rmnet_vnd.c：27） 调用跟踪：
    <TASK> __rmnet_map_ingress_handler （rmnet_handlers.c：48 rmnet_handlers.c：101） rmnet_rx_handler （rmnet_handlers.c：129 rmnet_handlers.c：235） __netif_receive_skb_core.constprop.0 （net/core/dev.c：6096）
    __netif_receive_skb_one_core （net/core/dev.c：6208） netif_receive_skb （net/core/dev.c：6467） tun_get_user （drivers/net/tun.c：1955） tun_chr_write_iter （drivers/net/tun.c：2003） vfs_write （fs/read_write.c：688） ksys_write （fs/read_write.c：740） </TASK> 添加 struct rmnet_endpoint 的 rcu_head 字段，并将 kfree（） 替换为 kfree_rcu（），以使端点内存在 RCU 宽限期内保持有效。同时删除 rmnet_vnd_dellink（） 调用并仅内联 nr_rmnet_devs 递减，因为 rmnet_vnd_dellink（） 会在宽限期内将 ep->egress_dev 设置为 NULL，从而造成无锁阅读器的数据争用。
    (CVE-2026-64188)

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

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

  - libvips 是一个快速的图像处理库，对内存的需求很低。libvips 以前和以前 8.18.1 版本中的 EXIF 解码器在将数据传递到 libexif 之前未验证 EXIF 标签群组的范围，从而可能导致空指针取消引用和崩溃。已在版本 8.18.2.
    (CVE-2026-35590)

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

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

  - platform/x86：lenovo-wmi-helpers：修复 lwmi_dev_evaluate_int（） 中的内存泄漏 lwmi_dev_evaluate_int（） 当 retval == NULL 时泄漏 output.pointer （由 sashiko.dev [1] 发现）。通过将“ret_obj = output.pointer”移到“if （retval）”块之外来修复该问题，以便始终由__free清除回调将其释放。无功能更改意图。（CVE-2026-63839）

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

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

  - mm/rmap：在 try_to_unmap_one 中的循环开始时将 nr_pages 初始化为 1 像 folio_referenced_one（） 一样，在每个循环迭代开始时将 nr_pages 初始化为 1。如果没有此操作，则由之前的 folio_unmap_pte_batch（） 调用计算的nr_pages可以在不会再次运行 folio_unmap_pte_batch（） 的后续迭代中重用。mmap 64K 大对开本，带MAP_ANONYMOUS |MAP_DROPPABLE，然后调用 madvise（MADV_FREE），然后通过 HMM_DMIRROR_EXCLUSIVE 将最后一页设为设备独占。通过 sysfs 触发节点回收。现在，在 try_to_unmap_one（） 中，我们将首先清除映射 lazyfree 作品集的 16 个条目中的前 15 个。这会将 nr_pages 设置为 15。在下一个 pvmw walk 中，此nr_pages将在设备专属 pte 上重用，从而可能损坏 folio refcount/mapcount。目前，我有一个可以使内核吐出跟踪的用户空间程序，但爆炸发生在 folio_referenced_one（） 中，因为 device-private 和 rmap 之间的交互中存在现有错误（我也在调查）。我做了一个单行内核更改以避免进入 folio_referenced_one（），并且内核在 try_to_unmap_one folio_remove_rmap_ptes时爆炸，这正是我想要的。请注意，此缺陷不是自文件作品集批处理之后出现的，而是lazyfree 作品集批处理，因为设备独占仅适用于匿名作品集。
    由于 refcount/mapcount 损坏，用户空间可见的效果只是内核在某处崩溃。
    (CVE-2026-63950)

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

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

  - batman-adv：tt：避免空 VLAN 响应 提交 16116dac2339（batman-adv：通过不发送不一致的 TT TLVL 来防止 TT 请求风暴）已添加对本地（直接）TT 响应代码的检查。但是响应也可以由另一个节点使用全局 TT 状态间接完成。为避免原始补丁中报告的这种不一致状态，还避免发送空 VLAN 以从全局 TT 状态进行回复。（CVE-2026-64090）

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

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

  - ipv6：exthdrs：在 ipv6_hop_jumbo（） ipv6_hop_jumbo（） 调用 pskb_trim_rcsum（） 后刷新 nh 指针，这可更改 skb 指针。让我们重新计算 nh 指针以确保任何更改都不会把事情搞砸。
    (CVE-2026-63924)

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

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

  - ovpn：tcp - 在 ovpn_tcp_close（） 中使用缓存的对等机指针 ovpn_tcp_close（） 通过 rcu_read_lock（） 下的 rcu_dereference_sk_user_data（） 加载ovpn_socket，在 sock->peer 上获取引用，在本地缓存对等机指针，然后放置读取锁定。然后将 sock->peer（而非缓存的本地）传递到 ovpn_peer_del（），在 RCU 读取部分结束后重新取消引用ovpn_socket。与 ovpn_tcp_sendmsg（） 不同，（） 在 RCU 下使用相同的负载，解锁后使用模式，但受到跨函数的 lock_sock（） 保护，ovpn_tcp_close（） 运行时没有套接字锁定：inet_release（） 调用 sk_prot->close（），而无需先进行lock_sock。因此，ovpn_socket_release（） 可在 ovpn_tcp_close（） 丢弃 rcu_read_lock（） 之后但在取消引用 sock->peer 之前的窗口中并发完成其kref_put -> detach -> synchronize_rcu -> kfree（sock） 序列。ovpn_socket_release（） 中的 synchronize_rcu（） 保护在 RCU 读取区段内使用取消引用指针的读取器，而非保护将指针转义到本地并随后使用的读取器。复制程序遵循提交 94560267d6c4 的模式（ovpn：tcp - 不在 tcp_close（）） 之后取消引用 NULL sk_socket成员）：在用户空间关闭 TCP fd 的同时触发对等删除（keepalive 到期或 netlink OVPN_CMD_DEL_PEER）。该提交修复了同一争用窗口的分离端;这修复了另一个受害者的关闭侧。
    收紧条目块以便将 sock->peer 只读入一次缓存的对等机本地，并通过该本地路由所有后续使用（保持检查、ovpn_peer_del（） 调用和 prot->close（） 调用）。在 rcu_assign_sk_user_data（） 发布ovpn_socket之前，sock->peer 只在 lock_sock（） 下的 ovpn_socket_new（） 中写入一次，之后再也不会重新分配，但之前的多重读取模式使这种不变性变得隐式而非显式。ovpn_tcp_recvmsg（）、ovpn_tcp_sendmsg（）、ovpn_tcp_data_ready（） 和 ovpn_tcp_write_space（） 中存在相同的多读形状;这些将在后续的 Net-Next 系列中通过专门的帮助程序进行清理。（CVE-2026-64045）

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

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

  - nfsd：避免在未经确认的重试争用中泄漏预分配的 openowner find_or_alloc_open_stateowner（） 遇到未经确认的所有者时，会调用 release_openowner（） 并将 oo = NULL 设置为 oo = NULL。然后控制权越过“if （oo）”防护（这将释放任何预分配的“new”），并无条件执行“new = alloc_stateowner（...）`. 如果在之前的迭代中已分配了“new”，则指针将以静默方式被覆盖，并且之前的分配（slab 对象 + 所有者名称缓冲区）被泄漏。这需要争用：两个具有相同所有者字符串的 NFSv4.0 OPEN 线程，其中并发线程在重试迭代之间将新的未经确认所有者插入到哈希中。窗口很窄，但在对抗条件下可以重复。通过在“oo = NULL”之后添加“goto retry”进行修复，以便在下一次迭代时重用已分配的“new”，而不是被覆盖。（CVE-2026-53394）

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

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

  - Meshtastic 是一个开源网状网络解决方案。在低于 2.7.23.b246bcd 的版本中，通过 iOS 应用程序管理时，播发包含畸形字符编码的User.long_name的单节点可使其他无线电无法通过 BLE 使用。畸形名称不需要经过恶意特制，它可以由普通的缓冲区截断产生，并且已经观察到在通常环境中自然发生。至少有一个代码路径可将 NULL 终止符放在多字节序列中间，从而在节点数据库中留下畸形User.long_name。该问题在下游浮出水面：iOS 应用程序强制执行编码验证，因此一旦节点数据库包含中毒条目，就无法对其进行解析。这导致 BLE 同步进入失败/重试循环，从而导致失去对受影响设备的控制。对于使用 iOS 应用程序管理其无线电的典型用户，在中毒节点老化之前，或者除非他们有备用管理路径（例如，Python CLI，可用于手动识别和删除有问题的条目），否则设备实际上将无法使用。由于畸形名称通过网格传播，因此单个受影响节点的临时存在可能会在很长一段时间内降低 iOS 用户在广泛地理区域的 BLE 管理。技术水平较低的用户没有直接的恢复路径。从 2.7.23.b246bcd 版开始，该固件添加了输入清理和回归测试，演示了对已经中毒的设备的恢复。这些应用程序还采取措施确保更从容地处理畸形编码序列。（CVE-2026-42566）

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

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

  - usb：dwc2：修复调试代码中的释放后使用 调用 usb_hcd_giveback_urb（） 后不允许取消引用 urb，因此请提前保存 urb->status。（CVE-2026-63927）

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

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

  - ipv4：raw：拒绝含有 IHL < 5 的 IP_HDRINCL 数据包 raw_send_hdrinc（） 验证调用程序提供的 IPv4 标头是否适合消息长度： iphlen = iph->ihl * 4;错误 = -EINVAL;if （iphlen > length） goto error_free;if （iphlen >= sizeof（*iph）） { /* 修复 saddr， tot_len， id， csum， transport_header */ } 但是，它不会拒绝 ihl < 5。对于此类数据包，会跳过 if （iphlen >= sizeof（*iph）） 分支，从而不影响构建的 iphdr，但数据包仍会传递给 __ip_local_out（） 以及后续版本。读取 iph->ihl 的下游使用者会假设一个合理的值：net/ipv4/ah4.c：ah_output（） 会特别从 top_iph->ihl * 4 减去 sizeof（struct iphdr），并将（signed-int-negative，然后转换为 size_t）结果传递到 memcpy（），进而产生长度接近 SIZE_MAX 的 OOB 访问和主机内核错误。根据定义，具有 ihl < 5 的 IPv4 标头格式错误（RFC 791：Internet 标头长度是 Internet 标头以 32 位字表示的长度...... 请注意，正确标头的最小值为 5。）内核不应愿意将此类数据包注入其自己的输出路径。拒绝 iphlen < sizeof（*iph） 及现有 iphlen >长度检查。这符合重新进入 IP 堆栈的本地构建数据包必须通过与外部数据包相同的基本健全性测试的原则。一旦它落地，修复分支周围的 if （iphlen >= sizeof（*iph）） 封装程序就变得多余;保留原处以保持修补程序最少且便于向后移植。后续行动可以解开它。请注意，提交 86f4c90a1c5c（ipv4、ipv6：确保原始套接字消息大小足以容纳 IP 标头）确保消息缓冲区大小足以容纳 iphdr，但不会限制自我报告的 iph->ihl。可达性：畸形数据包源是具有CAP_NET_RAW的任何调用程序，包括内核中 CONFIG_USER_NS=y 的 user+net 命名空间中的非特权进程。再现的 AH 崩溃还要求在传出路由上匹配 xfrm AH 策略;被授予CAP_NET_ADMIN的容器可以在其 netns 中安装该状态和策略。环回绕过xfrm_output，因此触发器使用真正的 netdev。在 UML 上重现 + KASAN：地址0x0的内核模式错误，memcpy_orig在崩溃位置。在无根 Docker 容器内重现相同的形状，并在 --cap-add 库存 distro 内核上具有NET_ADMIN。
    (CVE-2026-64114)

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

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

  - net/sched：sch_sfb：将直接出列调用替换为 peek 和 qdisc_dequeue_peeked 当 sfb 具有 peek（） 回调为 qdisc_peek_dequeued（） 的子进程（例如 qfq qdisc）时，我们可能遇到内核错误。当此类 qdiscs 的父项（如 tbf 等修补程序 #3 所示）想要从其子项（本例中为 sfb）检索 skb 时，它将执行以下操作：1a. 执行 peek（） - 当感应到子进程可以提供的 skb 时，则 - 在这种情况下，子进程 （sfb） 会调用其子进程 （qfq） 的 peek。qfq 执行正确的操作，将返回gso_skb队列数据包。注意：如果没有gso_skb条目，则 qfq 会将其存储在那里。1b.
    对子进程 （sfb） 调用 dequeue（）。问题就在这里。- sfb 将调用子进程的 dequeue（），其实质上只是尝试获取 qfq 队列中的内容。[ 127.594489][ T453] KASAN：范围 [0x0000000000000048-0x000000000000004f] 中的 null-ptr-deref [ 127.594741][ T453] CPU：2 UID：0 PID：453 通信：
    ping 未受感染 7.ping 1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT（full） [ 127.595059][ T453] 硬件名称：Bochs Bochs， BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP：0010：qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] 代码：00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 76 0c 00 00 48b8 00 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP： 0018：ffff88810e5af440 EFLAGS： 00010216 [ 127.596337][ T453] RAX：
    dffffc0000000000 RBX： 0000000000000000 RCX： dffffc00000000000 [ ][ T453] RDX： 0000000000000009 RSI： 0000001880000000 RDI： ffff888104fd82b0 [ 127.596917][ T453] RBP： ffff888104fd8000R08： 127.596623
    ffff888104fd8280 ： 1ffff110211893a3 [ 127.597165][ T453] R10： 1ffff110211893a6 R11： 1ffff110211893a7 R12： 0000001880000000 [ 127.597404][ T453] R13： ffff888104fd82b8R14： 0000000000000048R15：R09
    0000000040000000 [ ][ T453] FS：00007fc380cbfc40（0000） GS：ffff88816f2a8000（0000） knlGS：00000000000000000 [ 127.597956][ T453] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [127.598160][ T453] CR2：00005610aa9890a8 CR3：0000000010369e000 CR4：0000000000750ef0 [ 127.598390][ T453] PKRU：55555554 [ 127.598509][ T453] 调用跟踪：[ 127.598629][ T453] <TASK>127.598718[ ][ T453] ？ mark_held_locks+0x40/0x70 [ 127.598890][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053T453][ ] sfb_dequeue+0x88/0x4d0 [ 127.599174127.597644][ T453] ？ ktime_get+0x137/0x230 [ 127.599328][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ？ qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [127.599670][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831]T453[ ] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 在 b 中的#1正确做法是将 skb 从队列中抓取gso_skb。此修补程序集通过将 b 更改 #1为使用 qdisc_dequeue_peeked（） 方法来修复该问题。（CVE-2026-64012）

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

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

  - cifs：修复卸载后使用的忙碌的 dentry 自提交 340cea84f691c 后（cifs：打开的文件不应在超级块上保留 ref），cifs 文件仅保留 dentry ref_cnt，卸载后可执行 cifs 文件关闭工作（cfile->deferred），这将在 generic_shutdown_super 中触发警告： 缺陷：Dentry 00000000a14a6845{i=c，n=file} 仍在使用 （1） [卸载 cifs cifs] 详细进程为： 进程 A 进程 B kworker fd = open（PATH） vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_fileinfo cfile->dentry = dget（dentry） // dentry->d_lockref.count = 2 close（fd） __fput cifs_close queue_delayed_work（deferredclose_wq， cfile->deferred） dput（dentry） // dentry->d_lockref.count = 1 smb2_deferred_work_close _cifsFileInfo_put list_del（&cifs_file->flist） 卸载cleanup_mnt deactivate_super cifs_kill_sb cifs_close_all_deferred_files_sbcifs_close_all_deferred_files // 找不到 cfile，跳过
    _cifsFileInfo_put kill_anon_super generic_shutdown_super shrink_dcache_for_umount umount_check WARN ！dentry->d_lockref.count = 1 cifsFileInfo_put_final dput（cifs_file->dentry） // dentry->d_lockref.count = 0 调用 kill_anon_super 之前通过刷新“deferredclose_wq”修复此问题。在 中 https://bugzilla.kernel.org/show_bug.cgi?id=221548获取复制器。（CVE-2026-64108）

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

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

  - firmware：arm_ffa：驱动程序注册时检查 NULL FF-A ID 表 总线匹配回调假设每个 FF-A 驱动程序都会提供一个id_table，并且会无条件取消引用该。在注册时强制执行该合同时，让有缺陷的客户端驱动程序无法在比赛期间造成总线崩溃。（CVE-2026-64166）

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

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

  - nfsd：修复 nfsd4_create nfsd4_create（） 中的无作用 ACL 冲突防护，通过指定的初始值设定项将 create->cr_dpacl/cr_pacl 窃取到本地nfsd_attrs，然后立即将源指针设置为 NULL。后续冲突防护会测试已经 nilled 的源字段，使其成为永久死代码： if （create->cr_acl） { if （create->cr_dpacl || create->cr_pacl） /* 始终为 false */ 当客户端在同一个 CREATE fattr 位图中同时编码 FATTR4_WORD0_ACL 和 FATTR4_WORD2_POSIX_{DEFAULT，ACCESS}_ACL 时，nfsd4_acl_to_attr（） 会覆盖 attrs.na_pacl/na_dpacl而不释放原始值， 每个请求泄漏两个posix_acl slab 对象。重复的请求会导致无限的 slab 耗尽。通过检查 attrs.na_dpacl/na_pacl（失窃值）而非空 create->cr_dpacl/cr_pacl 修复，从而匹配 nfsd4_setattr（） 中已使用的正确模式。（CVE-2026-53395）

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

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

  - gpio：aggregator：修复潜在的释放后使用 发生错误时，我们会在从查找表中删除条目之前释放 aggr->lookups->dev_id。如果并行线程在我们删除该条目之前调用 gpiod_find（），则它可迭代列表并调用 gpiod_match_lookup_table（），从而在调用 strcmp（） 时无条件取消引用dev_id。反转清理顺序。（CVE-2026-64023）

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

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

  - macsec：修复 XPN lower-PN wrap 时的重放保护 在 macsec_post_decrypt（） 中，当 pn U32_MAX时，pn + 1 会将 u32 溢出到 0，并且从不触发第一个分支。如果 next_pn_halves.lower 也在上半部分，则 pn_same_half（pn， lower） 为 true，XPN else-if 也不会触发，next_pn_halves 保持不变。捕获到 XPN 关联上携带 pn == 0xFFFFFFFF 的合法帧的攻击者随后可以无限重播该帧，因为 lowest_pn 永远不会高于捕获的 pn 并且 macsec_decrypt（） 重建相同的 IV。扩展 XPN else-if 以在 pn + 1 封装为 0 时也触发，这样接收 pn == U32_MAX 会next_pn_halves （upper + 1， 0）。（CVE-2026-63925）

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

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

  - wifi：mac80211：限制 ieee80211_parse_tx_radiotap 中注入的天线索引 当解析注入帧的 radiotap 标头时，ieee80211_parse_tx_radiotap（） 直接将IEEE80211_RADIOTAP_ANTENNA值用作位移计数： info->control.antennas |= BIT（*iterator.this_arg）;*iterator.this_arg 是直接取自用户空间提供的帧的 8 位值，因此最多可要求 BIT（） 移动 255 位。这是未签名长整型的未定义行为，由 UBSAN 报告： UBSAN：net/mac80211/tx.c：2174：30 中的移位越界 位移指数 235 对 64 位类型“无符号长整形”过大 调用跟踪：
    ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c：2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c：2451 ...packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c：3109 info->control.antennas 是一个 2 位位图（u8 天线：2），因此只能表示天线索引 0 和 1。忽略任何较大的值，而不是越界移动。（CVE-2026-63869）

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

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

  - pds_core：修复 debugfs_lookup 目录项泄漏和错误处理 debugfs_lookup（） 返回具有必须通过 dput（） 释放的引用计数提升的目录项。当前代码在不调用 dput（） 的情况下丢弃返回的 dentry，从而在每次固件重置恢复时造成引用泄漏。此外，当禁用CONFIG_DEBUG_FS时，debugfs_lookup（） 会返回 ERR_PTR（-ENODEV），而不是 NULL。当前检查传递错误指针并会在无效指针上调用 dput（），进而造成崩溃。（CVE-2026-64147）

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

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

  - iio：buffer：hw-consumer：修复错误路径中的释放后使用 在 iio_hw_consumer_alloc（） 的 err_put_buffers 清理路径中，代码在调用 iio_buffer_put（） 时使用 list_for_each_entry（） 遍历缓冲区，这可在 refcount 降至 0 时释放当前缓冲区。然后 list_for_each_entry（） 循环宏评估 buf->head.next 以继续迭代，访问释放的缓冲区。使用 list_for_each_entry_safe（） 修复此问题。（CVE-2026-63930）

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

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

  - mm/damon/sysfs-schemes：调用缺少的 mem_cgroup_iter_break（） damon_sysfs_memcg_path_to_id（） 会在不调用 mem_cgroup_iter_break（） 的情况下中断 mem_cgroup_iter（） 循环。这会泄露 cgroup 引用。通过在中断前调用 mem_cgroup_iter_break（） 来修复此问题。此问题由 Sashiko 发现 [1]。
    (CVE-2026-64184)

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

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

  - USB：serial：digi_acceleport：修复小端点的内存损坏 添加缺少的大量输出缓冲区大小健全性检查，以便在恶意设备报告的缓冲区小于预期时避免越界内存访问或碎片损坏。（CVE-2026-63901）

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

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

  - usb：typec：wcove：不在 wcove_read_rx_buffer（） 中写入过去的结构pd_message wcove_read_rx_buffer（） 使用 for （i = 0; i < USBC_RXINFO_RXBYTES（info） 将 PD RX FIFO 复制到调用方的结构pd_message中;
    i++） regmap_read（wcove->regmap， USBC_RX_DATA + i， msg + i）;它有两个问题：USBC_RXINFO_RXBYTES（） 是一个 5 位字段（最多 31 位），而结构pd_message是 30 字节（__le16 标头 + __le32 有效负载 [PD_MAX_PAYLOAD]，打包）。RXINFO 中锁存的字节计数是端口伙伴在线路上放置的字节数，因此，如果 WCOVE BMC 接收方未在硬件中强制执行 PD 对象计数限制，传输 31 字节帧的恶意伙伴可将循环驱动到目的地之外一个字节。现有 FIXME 将此标记为未经验证。独立地，regmap_read（） 采用未签名的 int * 并在目标存储完整的未签名 int。传递字节指针 msg + i 意味着每次迭代写入四个字节;高 3 是零（val_bits是 8），通常会被下一次迭代覆盖，但最终迭代的高字节不会。当 RXBYTES == 30 时，i == 29 迭代已经在 msg 之外写入三个零字节，消息位于 IRQ 线程的 wcove_typec_irq（） 堆栈上。将循环限制到 sizeof（struct pd_message），并在仅存储每个寄存器的低字节之前读入本地寄存器，这样无论 RXINFO 报告什么内容，副本都不会超过目的地。（CVE-2026-63960）

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

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

  - HID：wacom：修复 wacom_hid_set_device_mode（） 中的越界写入 wacom_hid_set_device_mode（） 目前假设HID_DG_INPUTMODE使用情况始终位于功能报告的第一个字段 （field[0]） 中。
    但是，设备可以在其他字段中指定HID_DG_INPUTMODE。如果HID_DG_INPUTMODE在第一个字段以外的字段中，并且第一个字段的report_count小于HID_DG_INPUTMODE的usage_index，这会导致对 r->field[0]->value 的越界写入。通过在功能映射期间将 HID_DG_INPUTMODE 的字段索引存储在“struct hid_data”中来修复此问题。在 wacom_hid_set_device_mode（） 中，使用此存储的字段索引来访问正确的字段并添加边界检查以确保字段索引和值索引在写入之前都在有效范围内。
    (CVE-2026-63916)

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

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

  - USB：serial：safe_serial：通过小端点修复内存损坏 确保大量输出缓冲区大小至少为 8 字节，以避免在恶意设备报告较小大小时在安全模式下用户控制的 slab 损坏。（CVE-2026-63957）

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

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

  - iio：chemical：scd30：修复 write_raw 中的除以零错误 设置采样频率时，val2 用作除数之前，先对其添加零检查。用户将零小数部分写入 sampling_frequency sysfs 属性会在内核中触发除零操作。（CVE-2026-63931）

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

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

  - USB：serial： cypress_m8： 验证中断数据包标头 cypress_read_int_callback（） 根据所选的 Cypress 数据包格式解析中断输入缓冲区。格式 1 具有两个字节的状态/计数标头，格式 2 具有一个字节的状态/计数组合标头。usb 串行核心根据端点描述符的 wMaxPacketSize 调整中断输入缓冲区的大小，并且当未设置URB_SHORT_NOT_OK时，成功的中断传输可以完成短时间。在读取完整的数据包之前，请检查其是否包含所选标头。畸形短报告将被忽略，并通过现有重试路径重新提交中断 URB，从而阻止越界标头字节读取。KASAN 报告如下：大小为 1 的 cypress_read_int_callback+0x240/0x7f0 中的 KASAN slab-out-of-bound 调用跟踪：cypress_read_int_callback（） （drivers/usb/serial/cypress_m8.c：1009） __usb_hcd_giveback_urb（） dummy_timer（） [ johan：在标头长度健全性检查中使用常量 ] （CVE-2026-63902）

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

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

  - netfs：修复 netfs_perform_write（） 中的 folio->private 处理 在某些情况下，netfs_perform_write（） 未正确在 NULL、NETFS_FOLIO_COPY_TO_CACHE、指向群组和指向netfs_folio结构之间操纵 folio->private，从而导致具有相关 folio ref 泄漏的隐私数据的潜在多个附件，以及泄漏 netfs_folio struct 或 netfs_group ref。
    通过将作品集标记为最新的位置合并到一个位置并查看附加到 folio->private 的内容并决定如何清理它，然后设置新组来修复此问题。此外，如果群组为 NULL，即使在 netfs_group 参数中指定了群组，也不应刷新内容，因为新作品集就是这种情况。文件系统应始终指定netfs_group或永远不要指定netfs_group。Sashiko 自动检查工具指出，理论上如果 fpos >= ctx->zero_point 部分修改流写入作品集，则该部分可能会泄漏。这不太可能发生，但使用网络文件系统时，可能会发生第三方更改。它还指出，如果从整个作品集修改部分对同一作品集进行多次调用，则 __netfs_set_group（） 将会泄漏。（CVE-2026-64059）

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

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

  - fs/statmount：修复 statmount_mnt_idmap statmount_mnt_idmap（） 中的 slab 越界写入，写入一个与 seq_printf（） 的映射，然后手动推进 seq->count 以包含 NUL 分隔符。如果 seq_printf（） 溢出，seq_set_overflow（） 会将 seq->count 设置为 seq->size。手动 seq->count++ 将此更改为 seq->size + 1。然后 seq_has_overflowed（） 不再检测溢出。损坏的计数返回到 statmount_string（），稍后执行：seq->buf[seq->count++] = '\0';这会在动态分配的 seq 缓冲区上造成 1 字节空越界写入。通过在 seq_printf（） 之后立即检查溢出修复此问题。（CVE-2026-64074）

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

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

  - IIO：IMU：adis16550：修复触发器处理程序中的堆栈泄漏 adis16550_trigger_handler（） 声明堆栈上的扫描数据数组，但未对其进行初始化。底部的 memcpy（） 仅填充前 28 个字节（TEMP + 6 个 GYRO/ACCEL 数据通道），iio_push_to_buffers_with_timestamp（） 将 s64 时间戳写入 8 字节对齐的偏移 32。字节 28-31 仍然是未初始化的堆栈数据，一旦触发就会泄漏到用户空间。只需对堆栈上的结构进行零初始化即可修复这一切。（CVE-2026-63966）

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

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

  - dma-buf：修复 dma_buf_fd（） 跟踪点中的 UAF FD_ADD（） 返回后，fd 在文件描述符表中处于活动状态，共享该表的线程可在 DMA_BUF_TRACE（） 运行前对其进行关闭。关闭会终止最后一个引用，__fput（） 会释放dma_buf，而跟踪点随后会取消引用 dmabuf 以进行 dmabuf->name_lock -- slab-use-after-free。将 FD_ADD（） 拆分回 get_unused_fd_flags（） + fd_install（），并发出它们之间的跟踪点。如果以空文件指针保留 fdtable 插槽，但争用 close（） 会在不输入 __fput（） 的情况下返回 -EBADF，因此dma_buf在整个跟踪中保持活动状态。与提交 2d76319c4cbb 相同的方法（dma-buf：修复 dma_buf_put（） 跟踪点中的 UAF）。这会撤销提交 34dfce523c90 中完成的 FD_ADD（） 转换（dma：将 dma_buf_fd（） 转换为 FD_ADD（））;FD_ADD（） 没有位置可以安全地钩住跟踪点。（CVE-2026-63910）

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

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

  - USB：serial：mct_u232：修复缺少的中断输入传输健全性检查 添加缺少的对中断输入传输大小的健全性检查，以避免解析过时或未初始化的 slab 数据（并将其泄漏到用户空间）。（CVE-2026-63897）

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

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

  - usbip：vudc：修复 vudc_remove 中因争用条件导致的释放后使用缺陷 此修补程序是对 Zheng Wang 2023 年关于 vudc_remove（） 中释放后使用报告的后续作业。原始线程在 Shuah Khan 的请求中停止，要求对拔出/取消绑定路径进行运行时测试。此修补程序提供该测试并保留 Zheng 的原始补丁形状。在 vudc_probe（） 中，v_init_timer（） 将 udc->tr_timer.timer 绑定到 v_timer（）。
    usbip_sockfd_store（） 通过 v_start_timer（）/v_kick_timer（） 启动定时器。然后，vudc_remove（） 可在计时器仍处于待定或执行状态时释放包含的 struct vudc。KASAN 确认具有 CONFIG_KASAN=y、CONFIG_USBIP_VUDC=y、CONFIG_USB_ZERO=y 和重复将套接字 fd 写入 usbip_sockfd、关闭套接字对并取消绑定/重新绑定 usbip-vudc 的紧凑循环的未修补 x86_64 QEMU 客户机上的争用：缺陷：KASAN：在 __run_timer_base.part.0+0x8ba/0x8e0 中的释放后使用 在地址 ffff888001b80740 处大小为 8 的写入 按任务 trigger_and_unb/239 分配： vudc_probe+0x4d/0xaa0 由任务 239 释放：kfree+0x18f/0x520 device_release_driver_internal+0x388/0x540 unbind_store+0xd9/0x100 这会落在定时器核心中，而不是 v_timer（） 本身，因为在已经释放包含嵌入的 timer_list struct vudc 之后对其进行遍历。潜在的生命周期缺陷与 Zheng 报告的缺陷相同。
    通过从 vudc_remove（） 调用 v_stop_timer（） 且同步删除计时器，同一工具在没有 KASAN 报告的情况下完成了 5000 次绑定/取消绑定迭代。（CVE-2026-63905）

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

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

  - firmware：arm_ffa：锁定下的快照通知程序回调 两个通知处理程序当前都在 notify_lock 下查找通知程序回调，终止锁定，然后取消引用返回的通知程序条目。并发取消注册可以删除和释放间隙中的该条目，从而使处理程序取消引用过时内存。在仍保留notify_lock时复制回调指针和回调数据，并仅在锁定终止后调用回调。这保留了现有的回调执行模型，同时删除了框架和非框架通知路径中的释放后使用窗口。（CVE-2026-64080）

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

ID	名称	严重性
328672	Linux Distros 未修补的漏洞：CVE-2026-63030	high
328349	Linux Distros 未修补的漏洞：CVE-2026-64205	medium
328348	Linux Distros 未修补的漏洞：CVE-2026-64189	high
328347	Linux Distros 未修补的漏洞：CVE-2026-64187	critical
328346	Linux Distros 未修补的漏洞：CVE-2026-64191	high
328345	Linux Distros 未修补的漏洞：CVE-2026-35591	high
328344	Linux Distros 未修补的漏洞：CVE-2026-64192	high
328343	Linux Distros 未修补的漏洞：CVE-2026-64207	critical
328342	Linux Distros 未修补的漏洞：CVE-2026-64620	critical
328341	Linux Distros 未修补的漏洞：CVE-2026-33327	high
328340	Linux Distros 未修补的漏洞：CVE-2026-33328	medium
328339	Linux Distros 未修补的漏洞：CVE-2026-64190	medium
328338	Linux Distros 未修补的漏洞：CVE-2026-64206	medium
328337	Linux Distros 未修补的漏洞：CVE-2026-64193	critical
328336	Linux Distros 未修补的漏洞：CVE-2026-39879	high
328335	Linux Distros 未修补的漏洞：CVE-2026-64194	high
328334	Linux Distros 未修补的漏洞：CVE-2026-64188	critical
328333	Linux Distros 未修补的漏洞：CVE-2026-35590	medium
328330	Linux Distros 未修补的漏洞：CVE-2026-63839	medium
328329	Linux Distros 未修补的漏洞：CVE-2026-63950	high
328328	Linux Distros 未修补的漏洞：CVE-2026-64090	medium
328327	Linux Distros 未修补的漏洞：CVE-2026-63924	critical
328326	Linux Distros 未修补的漏洞：CVE-2026-64045	high
328325	Linux Distros 未修补的漏洞：CVE-2026-53394	high
328324	Linux Distros 未修补的漏洞：CVE-2026-42566	high
328323	Linux Distros 未修补的漏洞：CVE-2026-63927	high
328322	Linux Distros 未修补的漏洞：CVE-2026-64114	high
328321	Linux Distros 未修补的漏洞：CVE-2026-64012	medium
328320	Linux Distros 未修补的漏洞：CVE-2026-64108	high
328319	Linux Distros 未修补的漏洞：CVE-2026-64166	medium
328318	Linux Distros 未修补的漏洞：CVE-2026-53395	high
328317	Linux Distros 未修补的漏洞：CVE-2026-64023	high
328316	Linux Distros 未修补的漏洞：CVE-2026-63925	high
328315	Linux Distros 未修补的漏洞：CVE-2026-63869	high
328314	Linux Distros 未修补的漏洞：CVE-2026-64147	medium
328313	Linux Distros 未修补的漏洞：CVE-2026-63930	high
328312	Linux Distros 未修补的漏洞：CVE-2026-64184	high
328311	Linux Distros 未修补的漏洞：CVE-2026-63901	medium
328310	Linux Distros 未修补的漏洞：CVE-2026-63960	medium
328309	Linux Distros 未修补的漏洞：CVE-2026-63916	high
328308	Linux Distros 未修补的漏洞：CVE-2026-63957	medium
328307	Linux Distros 未修补的漏洞：CVE-2026-63931	medium
328306	Linux Distros 未修补的漏洞：CVE-2026-63902	medium
328305	Linux Distros 未修补的漏洞：CVE-2026-64059	medium
328304	Linux Distros 未修补的漏洞：CVE-2026-64074	high
328303	Linux Distros 未修补的漏洞：CVE-2026-63966	medium
328302	Linux Distros 未修补的漏洞：CVE-2026-63910	high
328301	Linux Distros 未修补的漏洞：CVE-2026-63897	medium
328300	Linux Distros 未修补的漏洞：CVE-2026-63905	medium
328299	Linux Distros 未修补的漏洞：CVE-2026-64080	critical

检测

Nessus 的 Misc. 系列

high

medium

high

critical

high

high

high

critical

critical

high

medium

medium

medium

critical

high

high

critical

medium

medium

high

medium

critical

high

high

high

high

high

medium

high

medium

high

high

high

high

medium

high

high

medium

medium

high

medium

medium

medium

medium

high

medium

high

medium

medium

critical