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

  - Bluetooth：hci_sync：修复暂停期间的接受列表 UAF hci_update_event_filter_sync（） 在为每个远程唤醒设备发送同步 HCI 命令时遍历 hdev->accept_list。暂停路径保留 hdev->req_lock，但接受列表更新由 hdev->lock 进行序列化。因此，remove_device（） 可在控制器等待期间释放当前列表条目。以下交错导致释放后使用：hci_update_event_filter_sync（） remove_device（） 获取接受列表条目 hci_set_event_filter_sync（） 等待控制器响应 hci_dev_lock（） list_del（） kfree（） hci_dev_unlock（） 读取释放的列表。下一页 KASAN 报告： 缺陷：KASAN：hci_suspend_sync+0x835/0x910 中的释放后使用 任务 kworker//10 在地址处读取的大小为 8 的工作 kworker/0:1/10 工作队列：
    事件vhci_suspend_work调用跟踪：hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 按任务 86 分配：
    hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 由任务 91 释放：kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 对 hdev->lock 下的远程唤醒地址进行快照。发送 HCI 命令之前释放锁定。在生成快照之前清除控制器事件筛选器，当没有匹配的条目时，请跳过分配和第二次列表遍历。这会保留原始筛选器和扫描状态更新，而不会在控制器等待期间保留接受列表节点。（CVE-2026-80762）

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

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

  - ALSA：usb-audio：修复 snd_usbmidi_novation_output（） 中的越界写入 snd_usbmidi_novation_output（） 在 transfer_buffer[0..1] 处布局双字节标头，并将 &transfer_buffer[2] 连同长度 ep->max_transfer - 2 一起传递给 snd_rawmidi_transmit（）：count = snd_rawmidi_transmit（ep->ports[0].substream， &transfer_buffer[2]， ep->max_transfer - 2）;ep->max_transfer 通过 usb_maxpacket（） 来自输出端点的 wMaxPacketSize。畸形或恶意设备可公告 wMaxPacketSize 为 1 的大量 OUT 端点 - USB 核心仅仅向下限制此值 - 因此 ep->max_transfer 变为 1，计数参数变为 -1。snd_rawmidi_transmit（） 将负计数传递至
    __snd_rawmidi_transmit_peek（），其中 if （count1 > count） count1 = count 使 count1 为负;
    get_aligned_size（） 对字节流子流保持负值，因此以下 memcpy（buffer， ...， count1） 以 （size_t）-1 长度运行，并且写入远远超出使用 usb_alloc_coherent（ep->max_transfer） 分配的传输缓冲区。这与提交 0970274613fb 中的 snd_usbmidi_akai_output（） 修复的缺陷类型相同（ALSA：usb-audio：修复 snd_usbmidi_akai_output（）） 中的 OOB 写入）;novation 输出例程处于无人保护状态。当端点无法容纳双字节标头和至少一个负载字节时退出。（CVE-2026-80829）

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

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

  - nfc：pn533：清除期间清除拆分的 skbs pn53x_common_clean（） 在释放通用 PN533 状态之前resp_q清除，但不影响fragment_skb。片段帮助程序在发送大型发起程序或目标模式帧时将片段排队到该处，并且这些 skb 在发送或丢弃之前仍归驱动程序所有。如果在碎片仍处于排队状态时删除设备，通用清除路径将释放状态， PN533 而不释放排队的碎片 skb，从而泄露它们。与 resp_q 一起清理期间清除 fragment_skb。（CVE-2026-80797）

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

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

  - selinux：要求定义每个布尔值，p_bools.nprim 来自策略图像，与随后有多少布尔值无关，且 cond_index_bool（） 填充 bool_val_to_struct[] 值 - 1，因此大于存在值的计数会留下 NULL 条目。然后，该数组的每位用户都按索引遍历它，并取消引用每个条目：访问矢量路径上的 cond_evaluate_expr（）、selinuxfs 后的 security_get_bools（） 和 security_get_bool_value（），以及 security_set_bools（）。稀疏类值被 policydb_class_isvalid（） 及其同级吸收;布尔没有这样的谓词，也没有可以使用它的消费者。拒绝一次未定义任何布尔值的布尔值，用于构建数组。合规策略定义其声明的每个布尔值，并且不受影响。（CVE-2026-80913）

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

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

  - drm/vmwgfx：终止 foreign-fd prime 导入中的 dma_buf 引用 ttm_prime_fd_to_handle（） 当导入的 fd 的 dma_buf->ops 与ttm_object_device的 ops 不匹配时返回 -ENOSYS，但会在不释放 dma_buf_get（） 获取的引用的情况下返回 -ENOSYS。任何非特权 renderD 客户端通过 DRM_VMW_GB_SURFACE_REF{，_EXT} 路径传递非 vmwgfx prime fd，每个调用都会泄漏一个 dma_buf 引用，并无限期地固定外部导出器的 GEM 资源。通过现有 dma_buf_put（） 漏斗错误路径，以便始终丢弃引用。（CVE-2026-80888）

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

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

  - 当远程对等机在没有 WebSocket 关闭握手的情况下关闭 TCP 连接时，undici 的实验性 WebSocketStream 客户端会使整个 Node.js 进程崩溃。不干净关闭时，内部套接字关闭处理程序会无条件调用可写入流中止并丢弃返回的 promise，但根据 WHATWG 流标准中止锁定的可写入内容会返回 Promise，并因 TypeError 而拒绝。
    由于应用程序在该可写入物上保留了一个写入器，这是唯一的写入方式，因此永远不会观察到拒绝，并且 Node 的默认未处理拒绝行为会终止该进程。因此，不受信任的服务器可通过一次突然断开连接造成客户端崩溃，无需认证，也不会发生应用程序错误。这会影响最高和7.29.18.0.0最高到 8.10.2的 undici 版本。7.0.0 用户应升级到 undici 7.29.1 或 8.10.2.（CVE-2026-85014）

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

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

  - HID：sensor：custom：修复 enable_sensor enable_sensor_store（） 可调用 set_power_report_state（） 中的释放后使用，从而取消引用 sensor_inst->power_state 和 sensor_inst->report_state。这些指针引用 sensor_inst-> 字段中的条目。在暴露enable_sensor sysfs 属性之前创建字段属性，以便在初始化它依赖的状态之前无法访问enable_sensor。删除时，删除enable_sensor后再释放字段属性，这样并发 sysfs 写入就无法通过power_state或report_state取消引用已释放内存。（CVE-2026-80767）

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

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

  - nvmet-tcp：不警告远程控制的过大 SGL 分配 当模糊处理 nvme 目标代码时，我在 nvmet_tcp_map_data（） 中跳脱了内核警告，因为传递到分配器的长度由远程发起程序控制。发送含有声明巨大数字的 SGL 的命令的远程发起程序可创建超过 100 万个条目的 scatterlist 和 iovec 分配，这造成后备 kmalloc 调用超过 MAX_PAGE_ORDER，然后页面分配器将在 WARN_ON_ONCE_GFP（） 消息上跳闸： 警告：mm/page_alloc.c：5280 __alloc_frozen_pages_noprof 工作队列： nvmet_tcp_wq nvmet_tcp_io_work ...sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu 由于许多系统都启用了 panic-on-warn，远程触发内核警告可从不好，我们仅通过将 GFP_NOWARN 添加到分配标记来使其静默。（CVE-2026-80788）

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

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

  - erofs：完全删除 fscache 后端 引入 FSCACHE 上的 EROFS 以提供镜像惰性拉取功能。功能上陆后，fscache 子系统使 netfs 成为新的硬依赖关系，这对于本地文件系统来说是意外的，并且具有内核定义的缓存层次结构，与 fanotify 内容前挂钩相比可能不灵活。因此，此功能已经弃用了将近两年。由于 EROFS 文件支持挂载和 fanotify 预内容挂钩在上游一段时间并且已经提供同等功能（erofs-utils 支持 fanotify 预内容挂钩），因此我们现在删除 fscache 后端。此功能的主要应用是 Nydus [1]，他们也计划在不久的将来转向使用 fanotify 预内容挂钩。我希望此修补程序可以合并到 Linux 7.2中，Linux 也是由新发现的实现问题 [2] [3] 驱动的，鉴于弃用和有限的开发资源，这些问题不值得调查。相关 fscache/cachefiles 清理修补程序稍后将单独完成 vfs 树 （netfs）：看起来没问题，因为代码库被 CONFIG_CACHEFILES_ONDEMAND 隔离。[1] https://github.com/dragonflyoss/nydus/blob/v2.1.0/docs/nydus-fscache.md[2] https://github.com/dragonflyoss/nydus/pull/1824 [3] https://lore.kernel.org/r/20260619135800.1594811-1-michael.bommarito@gmail.com （CVE-2026-80899）

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

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

  - tls：device：修复 tls_append_frag（） 中的越界写入 在 netdevsim TLS 卸载仿真之上运行的 syzkaller 和本地 syzbot 实例中发现;否则，只有在具有实现卸载的 NIC 的机器上才能访问 tls_device.c。tls_push_data（） 仅检查打开记录在其循环底部是否仍有空间容纳另一个碎片，而MSG_MORE早期中断会跳过该检查。该记录会保留到下一个具有已具有的 frag 计数的 syscall，而 tls_append_frag（） 不会检查，因此TLS_TX_ZEROCOPY_RO一两个字节的每个 splice（SPLICE_F_MORE） 都会添加一个非合并管道页，并且num_frags从 tls_record_info.frags[MAX_SKB_FRAGS] 的末尾离开。一旦记录被推送，tls_push_record（） 会在 sg_tx_data[MAX_SKB_FRAGS] 上运行相同的索引，并且 sg_set_page（） 写入到它后面的destruct_work上，然后工作队列调用该索引。字节限制没有问题，因为副本降至 0 并且循环会落入相同的检查;碎片计数没有此类反馈。推送记录而不是让完整记录保持打开状态，这是普通 TCP 套接字的作用 - tcp_sendmsg_locked（） 在复制和MSG_SPLICE_PAGES路径中使用 tcp_mark_push（） 和 new_segment，并且 tls_sw 已在sk_msg环填满时设置full_record，无论MSG_MORE与否。缺陷：KASAN：tls_append_frag 中的 slab-out-of-bound （ net/tls/tls_device.c：269） 在 addr ffff8881104d1530 处按任务写入大小为 8 tls_oob/450 CPU：2 UID：0 PID：450 通信：tls_oob 未受感染 7.2.0-rc7+ #329 PREEMPT 调用跟踪： <TASK> dump_stack_lvl （lib/dump_stack.c：94 lib/dump_stack.c：120） print_report （mm/kasan/report.c：378 mm/kasan/report.c：482） kasan_report （mm/kasan/report.c：595） tls_append_frag （net/tls/tls_device.c：269）tls_push_data （net/tls/tls_device.c：518） tls_device_sendmsg （net/tls/tls_device.c：583） inet_sendmsg （net/ipv4/af_inet.c：865） sock_sendmsg （net/socket.c：775 net/socket.c：790 net/socket.c：813） splice_to_socket （fs/splice.c：884） do_splice （fs/splice.c：936 fs/splice.c：1349） __do_splice （fs/splice.c：1431） __x64_sys_splice （fs/splice.c：1634 fs/splice.c：1616） do_syscall_64 （arch/x86/entry/syscall_64.c：63 arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） </TASK> 并且，一旦推送记录： UBSAN： array-index-out-of-boundsin net/tls/tls_device.c：300：24 索引 18 超出“skb_frag_t [17]”类型的范围 UBSAN： array-index-out-of-bounds net/tls/tls_device.c：301：41 中，索引 18 超出“scatterlist [17]”类型的范围 UBSAN：
    array-index-out-of-bounds 在 net/tls/tls_device.c：302：39 中，索引 18 超出“scatterlist [17]”类型的范围 UBSAN： array-index-out-of-bounds 在 net/tls/tls_device.c：307：38 中，索引 26 超出“scatterlist [17]”类型的范围 内核尝试执行受 NX 保护的页面 - 尝试利用？（uid：0） 缺陷：无法处理地址的页面错误：ffffea000411a680 #PF：内核模式下的监督程序指令提取 #PF：
    error_code（0x0011） - 权限违规 Oops： Oops： 0011 [#1] SMP KASAN PTI 工作队列：
    ktls_device_destruct 0xffffea000411a680 RIP：0010：0xffffea000411a680 调用跟踪： <TASK> worker_thread （kernel/workqueue.c：3405 kernel/workqueue.c：3486） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） </TASK> （CVE-2026-80852）

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

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

  - HID：asus：修复缺少的 hid_is_usb（） 检查 to_usb_interface（） 只能在父项真正为 USB 的hid_device上使用;uhid 可创建识别为正在BUS_USB但实际上没有 USB 父级的设备。修复在未进行 hid_is_usb（） 检查的情况下使用 to_usb_interface（） 的问题。我已验证由于 ASAN 版本中的此缺陷目前可以触发内核崩溃，并且此提交修复了该问题。（CVE-2026-80774）

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

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

  - ipv6：修复 ip6_finish_output2（） 中的释放后使用 ip6_finish_output2（） 在调用 lwtunnel_xmit（） 之前缓存指向 IPv6 目标地址 （daddr） 的指针。lwtunnel_xmit（） 中的 LWT-BPF 传输路径或其他封装操作可重新分配 skb 头，从而释放 daddr 指向的内存。当 lwtunnel_xmit（） 返回LWTUNNEL_XMIT_CONTINUE时，该函数将继续使用过时的 daddr 指针计算下一个跃点并查找或创建相邻条目。这可导致释放后使用读取，从而泄露敏感内核数据、用任意值污染相邻表、误导流量或造成系统崩溃。通过在 lwtunnel_xmit（） 返回 LWTUNNEL_XMIT_CONTINUE 后重新获取 IPv6 标头和目标地址指针来修复此问题，从而确保后续的 nexthop 计算和邻居查找在有效内存上运行。（CVE-2026-80792）

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

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

  - nvmet-tcp：在分配命令缓冲区之前限制 SGL 数据长度 nvmet_tcp_map_data（） 读取主机控制的 32 位 sgl->length，并且对于胶囊内偏移描述符（类型 0x01）在使用前根据端口>inline_data_size进行检查。任何其他 SGL 描述符类型 -- 包括非内联传输 SGL 数据块描述符（类型 （NVME_TRANSPORT_SGL_DATA_DESC << 4） |NVME_SGL_FMT_TRANSPORT_A，真实主机用于胶囊外写入的类型）会完全跳过该检查并直接转到：
    cmd->req.sg = sgl_alloc（len， GFP_KERNEL， &cmd->req.sg_cnt）;len 直接从线路获取，不限制高达 4 GiB。nvmet_req_init（） 仅解析命令，从不检查 sgl->length，而 nvmet_check_transfer_len（） -- 唯一验证transfer_len的其他位置 -- 稍后在分配发生后从 req->execute（） 运行。对于写入命令，目标使用 R2T 响应并停放命令等待主机发送数据;如果主机（或从不跟进的未经身份验证的对等方）从未执行此操作，则 sgl_alloc（） 缓冲区会在命令的生命期限内保持驻留状态。NVMe/TCP 在默认配置中没有强制身份验证，因此任何能够访问目标门户并完成 Fabrics 连接的对等机都可以通过单个构建的命令来驱动此过程，该命令可在队列和连接之间重复进行放大。这是由实际上未经身份验证的远程对等机触发的不受限制的内核内存分配。在执行任何分配之前，根据此文件已用于绑定每个 PDU H2C 数据的相同NVMET_TCP_MAXH2CDATA上限来验证 len，适用于每个 SGL 描述符类型。
    这缩小了非内联描述符的间隙，同时针对胶囊内情况保留了现有的、更严格的inline_data_size检查。在 v6.19 KASAN 支架上进行运行时验证：建立此绑定后，会在运行 sgl_alloc（） 之前拒绝带有超大非内联 SGL 长度的构建写入命令，在这种情况下，同一请求之前驱动不受限制的 ~256 MiB 内核分配（高达 4 GiB），该分配会常驻待主机永远不满足的 R2T 待定状态。(CVE-2026-80789)

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

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

  - HID：nintendo：修复 joycon_ctlr_read_handler（） 中的越界读取 joycon_ctlr_read_handler（） 将传入的 HID 输入报告转换为 struct joycon_input_report 并对其进行解析，仅通过 12 字节长度检查保护转换：if （size >= 12） /* 确保其包含输入报告 */ joycon_parse_report（ctlr， （struct joycon_input_report *）data）;结构joycon_input_report为 49 个字节：一个 13 字节的标头，后跟一个 IMU arm 为 36 字节的并集。对于 IMU 报告 joycon_parse_report（） -> joycon_parse_imu_report（） 遍历该并集（结构偏移 13..48），因此恰好包含 data[0] == JC_INPUT_IMU_DATA 的 12 字节的报告通过了防护，但读取到超过其声明长度的 37 字节。过度读取字节被解码为加速度计/陀螺仪值，并通过 （IMU） 输入设备转发到用户空间，从而泄露驱动程序内部存储器。数据[0] 和大小完全由恶意或假冒的 Joy-Con/Pro 控制器控制。接收缓冲区的大小取决于最大报告长度，因此这是分配内的过度读取，而不是 slab OOB，但解码的字节仍会到达用户空间。joycon_ctlr_handle_event（） 中的同级 subcmd 路径已正确限制相同的转换：if （size < sizeof（struct joycon_input_report） || data[0] ！= JC_INPUT_SUBCMD_REPLY） break;在此处使用相同的 sizeof（struct joycon_input_report） 边界。（CVE-2026-80772）

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

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

  - nilfs2：拒绝 GC ioctl 中无效的区块索引 Syzbot 报告 nilfs_lookup_dirty_data_buffers（） 中对 bh->b_assoc_buffers 的双重 list_add_tail（） 调用造成的列表损坏。分析显示，根本原因是将页面索引为 ULONG_MAX 的 page/folio 通过 GC ioctl 插入页面缓存。由于索引回绕，nilfs_lookup_dirty_data_buffers（） 调用的 filemap_get_folios_tag（） 重复检测页面索引为 ULONG_MAX 的脏作品集，从而导致脏缓冲区的重复处理。作为准备步骤，GC ioctl 加载要在 GC 期间移动的区块的页面/作品集，并根据作为参数传递的 nilfs_vdesc 结构中的信息将其插入到页面缓存中。通常这不会造成问题，因为用户空间 GC 库正确配置了 nilfs_vdesc 结构。但是，由于没有对确定页面索引的参数进行范围检查，因此包含人工构建的参数（如 Syzbot 生成的参数）的请求可导致插入页面索引为 ULONG_MAX 的页面/作品集，从而触发上述问题。这通过检查 nilfs_vdesc 结构中确定页面索引的“vd_offset”和“vd_vblocknr”范围解决了此问题，从而防止无效的页面/作品集插入。（CVE-2026-80807）

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

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

  - 邮箱：mchp-ipc-sbi：为 devm_kasprintf（） 添加 null 检查 添加检查以查看 mchp_ipc_get_cluster_aggr_irq（） 中的 devm_kasprintf（） 是否为非 NULL，如果函数失败则返回 -ENOMEM。（CVE-2026-80822）

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

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

  - HID：nintendo：探测失败时在hid_hw_stop前停止设备 IO nintendo_hid_probe（） 在调用 joycon_init（） 和 joycon_leds_create（） 之前调用 hid_device_io_start（）。如果任一失败，错误路径将跳至调用 hid_hw_close（）/hid_hw_stop（） 而不先调用 hid_device_io_stop（） 的 err_close。
    hid_hw_stop（） 不会停止设备 IO，因此 hid_input_report（） 可能仍会运行并访问被拆散的驱动程序数据，进而导致释放后使用。添加一个在调用 hid_hw_close（） 之前调用 hid_device_io_stop（） 的err_io_stop标签，并将两个 post-io_start 错误路径指向该标签。（CVE-2026-80770）

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

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

  - usb：gadget：f_tcm：保持端口计数直到 LUN 拆卸完成 tcm_usbg_drop_nexus（） 允许在tpg_port_count达到零时删除会话。但是，usbg_port_unlink（） 当前会从 fabric_pre_unlink（） 回调减少其计数，然后 core_dev_del_lun（） 会等待活动se_lun引用耗尽。
    如果删除最后一个 LUN 与删除 nexus 争用，后者可观察到零端口计数并调用 target_remove_session（）。这将释放sess_cmd_map，同时仍然可以访问正在运行的 struct usbg_cmd，包括其工作项。通过删除 nexus 重叠最后一个 LUN 取消链接会将该生命周期违规再现为usbg_cmd_work的DEBUG_OBJECTS释放活动警告，随后跟随 target-core BUG/Oops。
    通用 target-core unlink 路径在 core_dev_del_lun（） 完成后没有回调。添加可选的 fabric_post_unlink（） 回调并将其用于f_tcm端口计数。在 core_dev_del_lun（） 耗尽活动 LUN 引用之前，计数现在保持为非零，从而阻止删除 nexus 在命令完成期间释放会话。（CVE-2026-80854）

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

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

  - fuse：使用发布语义发布 io-uring 队列 fuse_uring_create_queue（） 初始化fuse_ring_queue，然后使用 WRITE_ONCE（） 将指针发布到 fch->lock 下的 ring->queues[qid]。有多个阅读器可能同时以无锁方式获取该指针然后取消引用它。WRITE_ONCE（） 未确保 ring->queues[qid] 指针分配之前队列的字段初始化顺序。队列必须使用 smp_store_release（） 发布，这样才能保证在之前发生字段初始化。读取可能与存储同时发生的路径中的阅读器需要使用 READ_ONCE（），因为涉及普通访问的任何争用都是未定义的。
    (CVE-2026-80858)

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

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

  - crypto：mxs-dcp - 修复源 scatterlist 长度访问 mxs_dcp_aes_block_crypt（） 使用 sg_dma_len（），而不首先将源 scatterlist 与 dma_map_sg（） 映射。因此，sg_dma_len（） 无效且可返回零或过时的 DMA 长度，进而造成加密和解密在 CONFIG_NEED_SG_DMA_LENGTH=y 时处理错误的字节数。请改用原始 scatterlist 长度。（CVE-2026-80831）

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

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

  - xfrm：丢弃无入口设备的 ESP-in-TCP 数据包 ESP-in-TCP 通过 TCP strparser 接收记录。handle_esp（） 在将数据包传递到 XFRM 输入路径之前，将 skb->dev 从保存的skb_iif还原。排队的 TCP 数据可在删除原始入口设备之后（例如在 veth 或 net 命名空间拆卸期间）处理。在这种情况下，dev_get_by_index_rcu（） 返回 NULL。XFRM IPv4 和 IPv6 输入路径在构建路由查找时均要求 skb->dev 有效，因此排列的 ESP-in-TCP 数据可取消引用空设备。如果保存的入口设备无法再解析，则丢弃该数据包。此类数据包无法再通过正常 XFRM 接收路径进行路由，而这会为仍然存在入口设备的数据包保留现有行为。（CVE-2026-80846）

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

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

  - nfc：nci：向激活参数提取器添加data_len边界检查 nci_extract_activation_params_iso_dep） 和 nci_extract_activation_params_nfc_dep（） 从 NCI RF_INTF_ACTIVATED_NTF负载读取内部长度字节并将其用于固定内核缓冲区的 memcpy（），但这两个函数都无法接收调用程序验证的activation_params_len。activation_params_len=1 且内部长度字节最多为 20 （NFC-A） 或 50 （NFC-B） 的构建的 NCI 通知会导致 memcpy（） 读取超出激活参数区域中一个有效字节的字节数，即与 NCI skb 相邻的内核内存的 slab 越界读取。通过提交 571dcbeb8e63，为同级 nci_extract_rf_params_*（） 系列提供了同等保护（net：nfc：nci：修复了数据包数据的参数验证），但这两个激活参数提取器当时未更新。将 data_len 参数添加到这两个函数，在消耗内部长度字节之前防止空白区域，在消耗剩余计数后将其递减，并将复制长度限制为实际可用的长度。更新两个调用站点以传递 ntf.activation_params_len，它已经针对位于 ntf.c：801 的 skb 进行了验证。（CVE-2026-80796）

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

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

  - crypto：sun8i-ss - 删除crypto_rng接口 由于硬件 PRNG 的crypto_rng接口未使用，并且与 hwrng 和实际的 Linux RNG 冗余，因此该接口将逐步淘汰。它的大多数驱动程序已经被删除。继续删除 sun8i-ss 支持，这是仅存的 sun8i-ss 支持之一。和 crypto_rng 一样，此驱动程序也存在缺陷：其 ->generate（） 函数存在一个释放后使用漏洞，这是因为在发送信号时未处理关闭 DMA 操作而使用 wait_for_completion_interruptible_timeout（） 所致。此外，它在行“memcpy（ctx->seed， d + dlen， ctx->slen）;”中存在缓冲区过度读取缺陷。单独修复这些缺陷只是为了删除代码是没有意义的，因此此提交被标记为修复和 Cc 稳定。（CVE-2026-80833）

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

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

  - crypto：qce - 修复 CCM AAD 缓冲区分配不足 在 qce_aead_ccm_prepare_buf_assoclen（） 中分配的 AAD 缓冲区可以小于稍后编程到 DMA scatterlist 中的长度。分配大小当前计算为：ALIGN（assoclen， 16） + MAX_CCM_ADATA_HEADER_LEN 而 DMA 长度设置为：ALIGN（assoclen + adata_header_len， 16） 由于 ALIGN（） 不按加法进行分配，因此分配可以小于 DMA 长度。例如，当 assoclen = 32 且 adata_header_len = 2 时：分配 = ALIGN（32， 16） + 6 = 38 DMA 长度 = ALIGN（32 + 2， 16） = 48 因此，在通过相关数据计算 CBC-MAC 时，QCE 硬件可以超出分配的缓冲区进行读取。额外字节被折叠到认证标签中，从而导致错误的标签并造成 CCM 自检失败，例如：alg：aead：对测试矢量 8 的 ccm-aes-qce 加密测试失败（错误结果） 通过在对齐之前添加最大可能的 AAD 标头长度来修复分配：ALIGN（assoclen + MAX_CCM_ADATA_HEADER_LEN， 16） 这保证了分配的缓冲区大小足够大，可容纳针对所有支持的标头大小的完全填充 AAD 数据。（CVE-2026-80832）

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

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

  - erofs：上限 LZMA 流池大小 未设置 lzma_streams 模块参数时，fs/erofs/decompressor_lzma.c 会从 num_possible_cpus（） 调整模块全局 MicroLZMA 流池的大小，然后 z_erofs_load_lzma_config（） 为每个流预分配一个图像提供的字典，最多可接受 8 MiB 的字典。在高 CPU 系统上，小型 EROFS 图像可以固定数百 MiB 的 vmalloc 支持的解码器状态，直到卸载 erofs 模块为止。影响：系统挂载的 EROFS 图像可按 LZMA 流固定最多 8 MiB 的 vmalloc 内存，不论是预期或意外。通过新的CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS选项（默认为 16）限制默认流计数，因此，如果 CPU 数不少于 16，同时保留现有的每图像字典限制，最坏情况下的默认预分配为 128 MiB。仍会按原样遵从明确的 lzma_streams 模块参数，因此故意调整池大小的管理员不会受到影响。（CVE-2026-80892）

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

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

  - net/tls：异步解密失败后的 tls_sw_splice_read（） 失败 异步解密失败时，tls_decrypt_done（） 会在 ctx->async_wait.err 中记录错误并调用 tls_err_abort（），后者会将其存储在 sk_err 中。tls_sw_recvmsg（） 和 tls_sw_read_sock（） 各自在保持读卡器锁定后分别读取 async_wait.err，并且调用失败：未经身份验证的记录使连接中断。tls_sw_splice_read（） 没有此类检查，sk_err 也不代表该检查。tls_rx_rec_wait（） 仅在已解析记录并且第一个到达 sock_error（） 的阅读器将清除记录而async_wait保留的记录时所跳过的循环内部测试sk_err。因此，splice 会在 recvmsg（） 和 read_sock（） 拒绝读取的连接上不断发送记录。像其他两个阅读器一样读取 tls_sw_splice_read（） 中的 async_wait.err。
    (CVE-2026-80904)

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

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

  - USB：serial：选项：修复中断 URB 回调中的 slab OOB 读取 中断 URB 缓冲区根据端点的 wMaxPacketSize 在 setup_port_interrupt_in（） 中分配中断 URB 缓冲区：buffer_size = usb_endpoint_maxp（epd）;
    port->interrupt_in_buffer = kmalloc（buffer_size， GFP_KERNEL）;USB 设备在其中断 IN 端点上声明 wMaxPacketSize = 8 时，从 kmalloc-8 缓存（正好 8 字节）分配缓冲区。如果设备发送短数据包（actual_length < wMaxPacketSize），则 URB 以状态 == 0 完成，回调继续读取：data[sizeof（struct usb_ctrlrequest），评估为 data[8]，访问分配的 8 字节缓冲区之外的 1 个字节。这会导致 slab 越界读取。通过添加缺少的边界检查修复此问题：在访问 req_pkt->bRequestType 和 req_pkt->bRequest 之前，首先验证实际长度是否足以包含 struct usb_ctrlrequest 标头，然后在读取条件中的 data[sizeof（struct usb_ctrlrequest）] 之前验证调制解调器信号状态是否有额外的字节。为 一致性，使用 sizeof（*req_pkt） 而不是 sizeof（struct usb_ctrlrequest）。[johan：使用 dev_err（）;拆分信号声明和初始化]（CVE-2026-80827）

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

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

  - ntb：存储原始 DMA 地址以供将来发布 DMA API 要求dma_free_attrs接收分配函数最初返回的确切dma_handle。请勿修改它。（CVE-2026-80884）

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

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

  - fbdev：通过 lock_fb_info（） show_mode（）、show_modes（） 和 store_mode（） 访问 fb_info->-modelist 和 fb_info->mode，而不按住 lock_fb_info（） 的序列化模式 sysf。store_modes（） 在替换 modelist 和释放旧 modelist 时采用 lock_fb_info（）。并行读取器或写入器可在 store_modes（） 释放旧 modelist 条目之前加载指向该条目的指针，然后取消引用释放的内存或以 fb_info-> 模式存储过时的已释放指针。采用 show_mode（）、show_modes（） 和 store_mode（） 中的 lock_fb_info（） 以 store_modes（） 进行序列化。在 show_mode（） 中，将模式复制到堆栈中，并在放置锁定后进行格式化。在 store_mode（） 中，将 activate（） 拆分为一个_locked变体以避免双重锁定，并将 modelist walk、模式转换、激活和fb_info>模式分配的锁定一起保留。（CVE-2026-80785）

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

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

  - xfs：不活锁在循环的未链接列表上的 scrub 中 LOLLM 指出，如果未链接的 inode 列表包含循环，则在线 fsck 可活锁。使用位图检测周期。（CVE-2026-80820）

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

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

  - usb：core：向 usb_wakeup_notification（） 添加锁 向通知添加旋转锁usb_wakeup以防止取消引用已释放内存时出现争用条件。xHCI 驱动程序从 IRQ 调用此函数时可能会遇到此问题，并且可能与 hub_disconnect（） 函数争用，后者会正确获取此锁定以保护设备状态。（CVE-2026-80830）

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

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

  - Bluetooth：ISO：在 getname 中返回 sockaddr 之前将其归零 iso_sock_getname（） 填充适当的结构sockaddr_iso并在未首先清除的情况下返回其大小，以便其未写入的字节从内核堆栈复制到用户空间。getsockname（2） 和 getpeername（2） 路径均经过 do_getsockname（），后者会将未初始化的sockaddr_storage交给 getname（） 堆栈并复制回 getname（） 返回的字节数，因此驱动程序必须初始化它所解释的每个字节。有两个范围处于未初始化状态：- struct sockaddr_iso为 10 个字节，但只写入了 9 个字节（family、iso_bdaddr、iso_bdaddr_type），导致每次调用都会泄露末尾填充字节。- 对于广播对等机（BIS_LINK或 PA_LINK），返回的长度会增加 sizeof（struct sockaddr_iso_bc），但只填充 bc_sid、bc_num_bis 和 bc_bis;从不写入该结构的前 7 个字节 bc_bdaddr 和 bc_bdaddr_type。非特权进程可打开BTPROTO_ISO套接字并使用 getsockname（） 访问填充泄漏;广播泄漏需要建立的 BIS/PA 连接。出于相同原因，l2cap 和 rfcomm 已在 getname 中 memset 其 sockaddr;在这里做同样的事情。（CVE-2026-80761）

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

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

  - ext4：不对新的加密文件启用 DAX 当前，创建新的加密常规文件时，会在设置EXT4_INODE_ENCRYPT之前对 __ext4_new_inode（） 中的 ext4_set_inode_flags（inode， init=true） 进行调用。因此，它可以设置文件系统是否使用 -o dax=always挂载S_DAX。随后，当它调用调用 ext4_set_context（） 的 fscrypt_set_context（） 时，在 __ext4_new_inode（） 中稍后实际会设置EXT4_INODE_ENCRYPT。ext4_set_context（） 设置 EXT4_INODE_ENCRYPT 并调用 ext4_set_inode_flags（inode， init=false） 也设置S_ENCRYPTED。这也是为了清除S_DAX。但是，这被提交 043546e46dc7 打破（fs/ext4：仅更改 inode 加载中的S_DAX）。这会导致写入文件的数据绕过加密，同时造成 xfstests 失败，例如 generic/548（使用 -o dax=always 时）。通过使 __ext4_new_inode（） 设置更早EXT4_INODE_ENCRYPT来简化流程，从而修复此问题。这会使其在 ext4_set_inode_flags（inode，init=true） 中生效，从而永远不会设置S_DAX。同样，在新的加密 inode 上从一开始就设置 EXT4_STATE_MAY_INLINE_DATA。然后就不需要清除了。由于进行了这些简化操作，ext4_set_context（） 在“handle ！= NULL”时不再需要更改 inode 标记或状态。也删除它。（CVE-2026-80806）

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

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

  - net：tap：修复发送 VLAN 标记帧时错误的transport_header 在 tap_get_user_xdp（） 中，处理 VLAN 标记帧（例如 ETH_P_8021Q）时，首先调用 skb_set_network_header（） 以network_header越过 VLAN 标记进入内部协议标头。然后在 skb->protocol 仍设置为 ETH_P_8021Q 的情况下调用 skb_probe_transport_header（），而 nhoff（派生自 skb_network_offset（））已指向越过 VLAN 标签指向内部协议标头。在 __skb_flow_dissect（） 中，proto 被初始化为 ETH_P_8021Q 点，nhoff 点经过 VLAN 标签。当分析器达到大小写ETH_P_8021Q时，它通过 __skb_header_pointer（） 读取当前 nhoff 处的结构vlan_hdr，但该偏移包含内部协议标头（例如 IP 标头）。这些字节被误解释为 VLAN 标头，从而生成与未知协议不匹配的垃圾封装 EtherType。分析器返回 false，因此 skb_probe_transport_header（） 从不调用 skb_set_transport_header（），transport_header保留其未初始化的 sentinel 值 （~0U）。将 skb_set_network_header（） 移动到 skb_probe_transport_header（） 之后。
    在调用 skb_probe_transport_header（） 时，network_header 仍然指向 VLAN 标头（偏移 ETH_HLEN），因此 nhoff 是正确的，并且流分析器可以解析 VLAN 标头，提取内部 EtherType，并将 nhoff 推进到内部协议标头，从而允许正确设置transport_header。
    (CVE-2026-80905)

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

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

  - fuse：修复打开时 DAX 失败时的无效锁定泄漏 fuse_open（） 采用 DAX 截断 （O_TRUNC dax_truncate = true） 的 filemap_invalidate_lock（），并在out_inode_unlock标签之前释放。但当 fuse_dax_break_layouts（） 失败时，goto out_inode_unlock会跳过解锁并泄露 rwsem，因此文件上任何以后的错误或截断都会在过时锁上停止。fuse_dax_break_layouts（） 可因
    -ERESTARTSYS 当信号中断等待繁忙的 DAX 页面耗尽时：open（file， O_RDWR |O_TRUNC） fuse_open（） filemap_invalidate_lock（） # dax_truncate fuse_dax_break_layouts（） dax_break_layout（） wait_page_idle（） # TASK_INTERRUPTIBLE fuse_wait_dax_page（） # 解锁、计划、重新锁定信号 -ERESTARTSYS goto out_inode_unlock # <- 泄漏了锁 通过将 filemap_invalidate_unlock（） 移动到标签下方以使所有错误路径释放锁定来修复此问题，并将标签重命名为 out_unlock，因为它现在不仅仅涵盖 inode 锁定。（CVE-2026-80855）

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

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

  - nfc：st21nfca：针对接收到的帧验证ATR_REQ长度 st21nfca_tm_recv_atr_req（） 检查接收到的ATR_REQ帧是否至少为 ST21NFCA_ATR_REQ_MIN_SIZE，以及自我声明的 atr_req->length 是否至少为 sizeof（struct st21nfca_atr_req），但从不检查 atr_req->length 是否超过实际接收长度 （skb->len）。然后st21nfca_tm_send_atr_res（） 信任声明的长度：gb_len = atr_req->length - sizeof（struct st21nfca_atr_req）;...memcpy（atr_res->gbi、atr_req->gbi、gb_len）;因此，发送短帧但设置大于帧的 atr_req-> 长度的 RF 对等体使gb_len超出实际存在的一般字节，并且 memcpy 越界读取超出接收的 skb。这些字节被放置在ATR_RES中并发送回对等机（向邻近攻击者泄露内核内存）;较大的声明长度是越界读取 （DoS）。拒绝声明的长度超过接收长度的帧。同一函数中的相邻 nfc_tm_activated（） 路径已从 skb->len 而非声明的字段派生其通用字节长度。使用自动源分析由 0sec （https://0sec.ai） 发现;从源可明显发现缺失边界。经过编译测试。（CVE-2026-80823）

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

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

  - Bluetooth： RFCOMM： take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg（） 通过调用 rfcomm_dlc_accept（） 完成延迟设置而不保留任何 RFCOMM 锁： if （test_and_clear_bit（RFCOMM_DEFER_SETUP， &d->flags）） { rfcomm_dlc_accept（d）; return 0; } and rfcomm_dlc_accept（） 在其第一行取消引用会话： struct sock *sk = d->session->sock->sk;
    接触 d->session 的所有其他路径都在 rfcomm_mutex 下运行：rfcomm_dlc_open（）、rfcomm_dlc_close（）、rfcomm_dlc_exists（）、rfcomm_dlc_send_rpn（） 以及通过 rfcomm_process_sessions（） 的 RFCOMM 线程。
    rfcomm_connect_ind（） 甚至被记录为在 rfcomm_lock（） 下调用。此呼叫站点是唯一跳过它的站点。RFCOMM_DEFER_SETUP位看起来像是针对拆卸序列化 accept，因为
    __rfcomm_dlc_close（） 在赢得test_and_clear时提早返回。但是 rfcomm_recv_disc（） 首先强制状态：d->state = BT_CLOSED;__rfcomm_dlc_close（d，错误）;提前返还仅涵盖BT_CONNECT、BT_CONFIG、BT_OPEN和BT_CONNECT2。已BT_CLOSED开关不匹配的状态时，从不查阅该位，并且 __rfcomm_dlc_close（） 跌破到 rfcomm_dlc_unlink（），这将设置 d->session = NULL。因此，延迟的 dlc 上的远程 DISC 会清除会话，同时保留RFCOMM_DEFER_SETUP集。然后，下一个 recvmsg（） 传递test_and_clear并取消引用 NULL 会话。
    不需要定时窗口：一旦处理了 DISC，取消引用是无条件的。为 rfcomm_dlc_accept（） 提供与 rfcomm_dlc_open（） 和 rfcomm_dlc_close（） 相同的形状：一个导出的封装程序，它接受rfcomm_mutex并重新检查会话，围绕两个已经保留互斥体的核心调用程序继续使用的 __rfcomm_dlc_accept（） 进行会话。在具有通过 /dev/vhci 仿真的 BR/EDR 对等机的 KASAN + PROVE_LOCKING 内核上重现：对等机提出 ACL 链接、在 RFCOMM PSM 上打开 L2CAP、开始会话、在与 BT_DEFER_SETUP 绑定的通道上打开 dlc，并在接受套接字后发送 DISC。然后，已接受套接字上的 recv（） 发生： 错误：一般保护错误 KASAN：范围内的 null-ptr-deref [0x0000000000000010-0x0000000000000017] RIP：0010：rfcomm_dlc_accept+0x54/0x350 调用跟踪：
    rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 是结构rfcomm_session中 sock 的偏移量。通过此修补程序，同一个运行完成，recv（） 返回 0 且无报告，并且 lockdep 保持静默，确认在此路径上lock_sock前仍然采用rfcomm_mutex，因为它在线程端。（CVE-2026-80819）

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

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

  - ipvs：修复校验和验证 ip_vs_in_icmp_v6（） 缺少来自客户端的 ICMPv6 数据包的校验和验证。事实上，至于 TCP/UDP，我们应该仅在 MASQ 上或隧道回复上破坏数据包时验证 ICMP 数据包的校验和。此外，Sashiko 指出，在验证来自真实服务器的 ICMPv6 消息时，IPv4 和 IPv6 通用的 handle_response_icmp（） 缺少伪标头计算，如果硬件未验证校验和，则会出现问题。通过创建 ip_vs_checksum_common_check（） 辅助函数并将其用于 IPv4 和 IPv6 的 TCP/UDP/ICMP，修复了这些问题。依赖 nf_checksum（） 来验证 ICMP 消息，但也将其用于 TCP 和 UDP。对 TCP/UDP/SCTP 的IP_VS_DBG_RL_PKT使用正确的 IP 偏移。IPVS 数据包 （TCP/UDP/SCTP/ICMP） 不需要在 LOCAL_OUT（本地客户端或本地真实服务器）和 FORWARD（来自 LAN 上服务器的流量）上进行校验和验证。如果PRE_ROUTING上未调用 nf_checksum（），则仅在 LOCAL_IN 上执行该操作。此外，ip_vs_checksum_complete（） 可标记为静态。（CVE-2026-80901）

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

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

  - xfs：在字段访问之前验证属性条目指针 xfs_attr3_leaf_verify_entry（） 访问 lentry/rentry 字段（namelen、valuelen），然后再检查条目指针本身是否在界内。如果 nameidx 被特制为指向缓冲区末尾附近，则这些字段访问可在执行name_end > buf_end处的边界检查之前读取越界。在访问条目指针的字段之前，添加明确的边界检查。使用 offsetof（） 检查灵活数组成员 （nameval/name） 的开头是否在边界内，以确保可以安全访问所有前面的字段。（CVE-2026-80805）

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

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

  - usb：xhci：若控制器不可访问，则退出设置 xhci_gen_setup（） 使用从第一个寄存器读取的功能长度找到操作寄存器： xhci->op_regs = hcd->regs + HC_LENGTH（readl（&xhci->cap_regs->hc_capbase））;如果控制器已死机或已脱离总线，则该读取返回 ~0，HC_LENGTH（） 将其截断为 0xff，op_regs 结束0xff字节超出页面对齐的 MMIO 基底，即未对齐。通过它进行的第一次访问，即读取 op_regs->status 的 xhci_halt（） -> xhci_handshake（），然后是设备内存上的未对齐 readl（）。arm64 在未对齐的设备访问中出错，因此不是xhci_handshake（）（） 捕获 all-one 值并返回 -ENODEV，而是设置 oopses：xhci-pci-renesas 0005：08：00.0：无法将电源状态从 D3cold 更改为 D0，设备不可访问 xhci-pci-renesas 0005：08：00.0：xHCI 主机控制器 xhci-pci-renesas 0005：08：00.0：已注册新的 USB 总线，已分配总线编号 1 无法处理虚拟地址 ffff80030a770103 上的内核分页请求 ESR = 0x0000000096000021 FSC = 0x21： 对齐错误 内部错误：错误：0000000096000021 [#1] SMP pc：
    xhci_halt [xhci_hcd] 调用跟踪：xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe 这是由无法启动（无法将电源状态从 D3cold 更改为 D0，设备不可访问）但仍到达 HCD 探测路径的 Renesas uPD720201 所触发的。读取功能寄存器一次，如果它读回 all-one 值（如 xhci_handshake（） 和 xhci_reset（） 已对其进行测试），则在从 -ENODEV 派生 op_regs 之前中止使用 -ENODEV 进行设置。读取一次还可避免重新读取在并发热删除下可能更改的寄存器。（CVE-2026-80861）

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

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

  - tcp：将路由 advmss 钳制为 TCP_MIN_MSS tcp_select_initial_window（） 假设调用方从不传递小于 1 的 MSS，但路由派生的 advmss 值可违反该假设。太小的明确RTAX_ADVMSS是实现这一目标的一种方法，但它不是唯一的方法。当 RTAX_ADVMSS 保留为 0 时，也可以通过默认 advmss 路径实现相同的除以零，并且随后路由 MTU 和 min_adv_mss 将有效 advmss 向下驱动。引入 tcp_dst_advmss（） 帮助程序，在 TCP 消耗路由 advmss 之前将其限制为 TCP_MIN_MSS，并在从 dst 指标派生 advmss 的 TCP 路径中使用它。这可防止有效 MSS 在 tcp_select_initial_window（） 舍入接收窗口之前降至零。（CVE-2026-80847）

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

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

  - ALSA：dummy：在探测时检查卡索引有效性 snd_dummy_probe（） 盲目地相信给定的 devptr->id 值在正确的卡索引范围内。对于驱动程序本身在模块探测时创建的设备来说没有问题，但如果设备通过 sysfs 接口手动绑定，则此情况可能为 -1 为无，这会导致对 index[] 和其他参数的 OOB 访问。添加卡片索引的健全性检查，如果其值超出范围则警告/更正。（CVE-2026-80812）

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

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

  - sctp：拒绝带有不匹配验证标记的过时 Cookie sctp_unpack_cookie（） 只要已存在关联，就跳过 Cookie 过期检查。这比 RFC 9260 部分 5.2.4中的例外更广泛。对于现有关联，仅当 Cookie 中的两个验证标记都与当前关联匹配时，Section 5.2.4 才允许过期状态 Cookie。否则，数据包应该被丢弃，并且必须发送过时的 Cookie 错误。广泛检查可让过期的操作 A 重新启动 cookie 到达 sctp_sf_do_dupcook_a（）。在默认 60 秒 cookie 生存期的运行时测试中，在 65 秒后重播此类 cookie 会返回 COOKIE-ACK 并重新启动关联。除非两个验证标记都匹配，否则检查 cookie 过期。这将为丢失的 COOKIE ACK 保留操作 D 异常，同时在所有其他情况下拒绝过期的 Cookie。（CVE-2026-80890）

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

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

  - afs：修复 ungot 卷的泄漏 修复 afs_lookup_volume_rcu（），以便在 afs_try_get_volume（） 失败时不泄漏垂死的卷。（CVE-2026-80878）

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

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

  - fuse：等待 abort_on_kill 上的FR_FINISHED以防止释放后使用 request_wait_answer（） 中的 abort_on_kill 路径会调用 fuse_abort_conn（），并且返回而不等待FR_FINISHED。如果 fuse_dev_do_write（） 同时处理相同的请求（FR_LOCKED集），则调用程序会在仍处于访问状态时释放 req->args，从而造成释放后使用。通过跳到现有 wait_event（FR_FINISHED） 修复此问题，而不是提前返回。等待不会挂起，因为 fuse_abort_conn（） 确保所有请求都结束。（CVE-2026-80857）

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

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

  - ASoC：编解码器：lpass-wsa-macro：修复枚举 kcontrol 访问 EAR SPKR PA Gain 和四个 WSA RX* Mux 控件已枚举，但其 get 和 put 回调通过 ucontrol->value.integer.value[0]（长）而非 ucontrol->value.enumerated.item[0]（无符号 int）访问值。
    通过提交 bcfe5f76cc40（ASoC：编解码器：rx-macro：修复枚举类型的越界访问数组）和提交 0ea5eff7c606（ASoC：编解码器：va-macro：修复枚举类型的越界访问数组），但缺少 wsa-macro，已修复同级驱动程序中的相同模式。在具有 CONFIG_SND_CTL_DEBUG 的 64 位内核上这会触发 elem 值的健全性检查，并且每次读取这些控件都会失败，并出现
    -EINVAL。（CVE-2026-80910）

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

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

  - ipv6：seg6：清除 IPIP 解封装上的 IPv4 控制块 End.DX4 和 End.DT4 通过 decap_and_validate（） 解封装 IPv4 数据包，并将其直接发送到 IPv4 路由。因此，内部数据包绕过 ip_rcv_core（），通常会在 IPv4 解释 skb->cb 之前清除 IPCB。skb 反而会保留来自外部数据包的 IP6CB 数据。IP6CB 和 IPCB 使用相同的 skb->cb 存储，因此 IP6CB（skb）->lastopt 与 IPCB（skb）->opt.optlen 和 srr 重叠，而 IP6CB（skb）->nhoff 重叠 rr 和 ts。发送方可以通过有效的外部扩展标头链使过时的 optlen 字节变为非零。复制器将一个 8 字节的 Destination Options 标头紧接在 40 字节的 IPv6 标头之后和 Segment Routing 标头之前。ipv6_destopt_rcv（） 在 lastopt 和 nhoff 中记录发件人控制的目标选项偏移量，将其设置为 40。因此，在重现的小端 x86-64 内核上，IPv4 会看到 optlen = 40 且 rr = 40。optlen 为零时，tcp_v4_save_options（） 和 __ip_options_echo（） 跳过选项复制。
    此处optlen为40，因此TCP SYN路径为40字节的选项数据和调用分配空间
    __ip_options_echo（）。过时的 rr 值使该函数将内部数据包字节 41 作为记录路由选项长度进行读取。复制器将该发送者控制的字节设为 255，因此 __ip_options_echo（） 将 255 字节复制到 40 字节的选项数据区域。未安装修补程序的 v7.2-rc5 内核上的独立 End.DX4 和 End.DT4 复制程序均产生：缺陷：KASAN：大小为 255 的 __ip_options_echo（） 写入中的 slab-out-of-bound 相关的 End.DX4 调用路径为：__ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4相关的 End.DT4 调用路径为：
    __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options（） 内联到 tcp_v4_route_req（） 路径中，因此不会显示为单独的帧。当 decap_and_validate（） 处理IPPROTO_IPIP时，保存 IP6CB 的入口接口，清除 IPCB，并恢复保存的值。在通用解封装路径中执行此操作涵盖 End.DX4、End.DT4 和 End。”DT46的 IPv4 arm。使用 IP6CB（skb）->iif 而非 skb->skb_iif。这些操作在 l3mdev 处理之后运行，可将skb_iif替换为 L3 主控端;IP6CB iif 仍会记录在 IPv6 入口处设置的接收接口。（CVE-2026-80840）

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

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

  - HID：magicmouse：防止 magicmouse_raw_event（） magicmouse_raw_event（） 处理DOUBLE_REPORT_ID （0xf7） 数据包中无限制的递归，其通过拆分数据包并在每一半调用自身的方式将两个触摸报告打包为一个。防止失控递归的唯一方法是大小 < 1 检查，它可以停止零大小的调用，但不会限制递归深度。与此驱动程序匹配的恶意 HID 设备可发送以 DOUBLE_REPORT_ID 开头并填入序列 [0xf7、0x00] 的报告。每个级别消耗两个字节并对剩余部分递归，因此多达 HID_MAX_BUFFER_SIZE （16 KiB） 的传入报告会驱动大约 8000 个嵌套调用。这很容易耗尽 16 KiB 的内核堆栈，导致堆栈溢出：CONFIG_VMAP_STACK 时发生错误，或没有时发生内存损坏。双重报告只包装两份普通报告;它永远不会合法嵌套。拒绝从递归调用重新输入DOUBLE_REPORT_ID情况，因此递归深度限制为二，同时继续像以前一样解析所有有效数据包。（CVE-2026-80783）

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

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

  - fuse：修复中断与重新发送之间的争用 提交 f8fce75fedf7 后（fuse：清除 fuse_resend 和 fuse_remove_pending_req 中的intr_entry），fuse_request_free（） 中的 WARN_ON（！list_empty（&req->intr_entry）） 仍会由于下列争用而触发： 在 request_wait_answer（） 中 if （test_bit（FR_SENT， &req->flags）） -> 返回 true 在 fuse_chan_resend（） clear_bit（FR_SENT） 中， request_wait_answer（） 中的 &req->flags queue_interrupt（req） 修复方式： - 移动 fpq->lock 内的清除FR_SENT - 移动 fiq->lock 内的设置FR_PENDING - 在 fuse_dev_queue_interrupt（） （CVE-2026-80860） 中获取 fiq->lock 后重新检查FR_SENT

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

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

  - mptcp：pm：修复 alloc-during-teardown 争用造成的内存泄漏 mptcp_pm_destroy（） 在套接字拆卸期间清空 msk->pm.lock 下的 msk->pm.anno_list 和 msk->pm.userspace_pm_local_addr_list，从而终止两者之间的锁定。同一 msk 上的并行用户空间 PM genl ANNOUNCE 通过 mptcp_token_get_sock（） 保留一个 sock 引用，并在 mptcp_pm_nl_announce_doit（） 中调用 mptcp_userspace_pm_append_new_local_addr（） 和 mptcp_pm_announced_alloc（）。两者都简要采用 msk->pm.lock 以添加到各自的列表中。由于 genl 处理程序保留 sock 引用，因此在处理程序完成之前，mptcp_pm_destroy（） 可通过 mptcp_disconnect（） 在相同 msk 上运行，从而调用 mptcp_destroy_common（） 而不会丢弃 sock refcount。如果锁获取交错使得 mptcp_pm_destroy（） 首先清空列表，则后面的 alloc 会将其条目添加到此 msk 未迭代其他任何内容的列表头，并且该条目会泄漏。kmemleak 针对用户空间 PM 报告持续并发 ANNOUNCE + 关闭负载下的 mptcp_pm_add_addr 对象（来自 mptcp_pm_announced_alloc（）））和mptcp_pm_addr_entry对象（来自 mptcp_userspace_pm_append_new_local_addr（））。在 msk->pm.status 中添加一个MPTCP_PM_DESTROYING位，由 pm.lock 下的 mptcp_pm_destroy（） 设置，然后列表会被分配路径在 pm.lock 下检查。要么 alloc 首先获取 pm.lock，在这种情况下，当 mptcp_pm_destroy（） 释放它时，它的条目在列表中;或 mptcp_pm_destroy（） 首先采用 pm.lock，在这种情况下，后面的 alloc 会观察该位并拒绝。由扩展 BRF 的 MPTCP 协议流强度发现 （arXiv：2305.08782）。（CVE-2026-80784）

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

ID	名称	严重性
343013	Linux Distros 未修补的漏洞：CVE-2026-80762	high
343012	Linux Distros 未修补的漏洞：CVE-2026-80829	high
343011	Linux Distros 未修补的漏洞：CVE-2026-80797	medium
343010	Linux Distros 未修补的漏洞：CVE-2026-80913	medium
343009	Linux Distros 未修补的漏洞：CVE-2026-80888	medium
343008	Linux Distros 未修补的漏洞：CVE-2026-85014	high
343007	Linux Distros 未修补的漏洞：CVE-2026-80767	medium
343006	Linux Distros 未修补的漏洞：CVE-2026-80788	medium
343005	Linux Distros 未修补的漏洞：CVE-2026-80899	high
343004	Linux Distros 未修补的漏洞：CVE-2026-80852	high
343003	Linux Distros 未修补的漏洞：CVE-2026-80774	medium
343002	Linux Distros 未修补的漏洞：CVE-2026-80792	medium
343001	Linux Distros 未修补的漏洞：CVE-2026-80789	medium
343000	Linux Distros 未修补的漏洞：CVE-2026-80772	medium
342999	Linux Distros 未修补的漏洞：CVE-2026-80807	high
342998	Linux Distros 未修补的漏洞：CVE-2026-80822	medium
342997	Linux Distros 未修补的漏洞：CVE-2026-80770	medium
342996	Linux Distros 未修补的漏洞：CVE-2026-80854	high
342995	Linux Distros 未修补的漏洞：CVE-2026-80858	high
342994	Linux Distros 未修补的漏洞：CVE-2026-80831	medium
342993	Linux Distros 未修补的漏洞：CVE-2026-80846	medium
342992	Linux Distros 未修补的漏洞：CVE-2026-80796	high
342991	Linux Distros 未修补的漏洞：CVE-2026-80833	high
342990	Linux Distros 未修补的漏洞：CVE-2026-80832	medium
342989	Linux Distros 未修补的漏洞：CVE-2026-80892	medium
342988	Linux Distros 未修补的漏洞：CVE-2026-80904	medium
342987	Linux Distros 未修补的漏洞：CVE-2026-80827	high
342986	Linux Distros 未修补的漏洞：CVE-2026-80884	high
342985	Linux Distros 未修补的漏洞：CVE-2026-80785	high
342984	Linux Distros 未修补的漏洞：CVE-2026-80820	medium
342983	Linux Distros 未修补的漏洞：CVE-2026-80830	medium
342982	Linux Distros 未修补的漏洞：CVE-2026-80761	low
342981	Linux Distros 未修补的漏洞：CVE-2026-80806	high
342980	Linux Distros 未修补的漏洞：CVE-2026-80905	medium
342979	Linux Distros 未修补的漏洞：CVE-2026-80855	medium
342978	Linux Distros 未修补的漏洞：CVE-2026-80823	medium
342977	Linux Distros 未修补的漏洞：CVE-2026-80819	medium
342976	Linux Distros 未修补的漏洞：CVE-2026-80901	medium
342975	Linux Distros 未修补的漏洞：CVE-2026-80805	medium
342974	Linux Distros 未修补的漏洞：CVE-2026-80861	medium
342973	Linux Distros 未修补的漏洞：CVE-2026-80847	medium
342972	Linux Distros 未修补的漏洞：CVE-2026-80812	medium
342971	Linux Distros 未修补的漏洞：CVE-2026-80890	medium
342970	Linux Distros 未修补的漏洞：CVE-2026-80878	high
342969	Linux Distros 未修补的漏洞：CVE-2026-80857	high
342968	Linux Distros 未修补的漏洞：CVE-2026-80910	medium
342967	Linux Distros 未修补的漏洞：CVE-2026-80840	medium
342966	Linux Distros 未修补的漏洞：CVE-2026-80783	medium
342965	Linux Distros 未修补的漏洞：CVE-2026-80860	medium
342964	Linux Distros 未修补的漏洞：CVE-2026-80784	medium

检测

Nessus 的 Misc. 系列

high

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

high

high

medium

medium

medium

high

high

high

medium

medium

low

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

medium

medium