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

  - ALSA：mixer：oss：添加卡断开连接检查点 ALSA OSS 混合器层而非单独调用 kcontrol ops，且断开设备时可能并不总是捕获待定调用。为避免潜在的 UAF 情况，请在 OSS 混合器访问的每个入口点添加对卡断开连接的健全性检查。rwsem 是在该检查之前取得的，因此应正确涵盖其余上下文。（CVE-2026-43126）

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

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

  - vhost：将 vdpa 群组边界检查移至 vhost_vdpa 通过在此处合并这些内容删除重复。这降低了父驱动程序错过他们的可能性。同时修复 vdpa_sim 中的缺陷，其中可将有效的 ASID 分配给等于 ngroups 的群组，从而导致越界写入。（CVE-2026-43248）

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

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

  - drm/amdgpu：修复空指针问题缓冲区函数如果未启用 SDMA 区块，buffer_funcs 不会初始化，如果buffer_funcs未初始化，则修复空指针问题。（CVE-2025-71294）

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

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

  - misc：bcm_vk：修复 bcm_vk_read（） 中可能的空指针取消引用 在函数 bcm_vk_read（） 中，已检查指针条目，表明其可为空。如果 entry 为 NULL 且 rc 设置为 -EMSGSIZE，以下代码可导致空指针取消引用： struct vk_msg_blk tmp_msg = entry->to_h_msg[0];
    set_msg_id（&tmp_msg，entry->usr_msg_id）;tmp_msg.size = entry->to_h_blks - 1;若要避免这些可能的空指针取消引用，请将 iter 中的 to_h_msg、usr_msg_id 和 to_h_blks 复制到临时变量中，然后将这些临时变量返回至应用程序，而非通过可能的空条目访问它们。（CVE-2025-71291）

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

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

  - 具有本地访问权限 （Ring 0） 的特权攻击者未正确使用 AMD Platform Configuration Blob （APCB） SMM 驱动程序中的引导服务即可实现权限升级，从而可能导致任意代码执行。（CVE-2025-54502）

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

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

  - soc：ti：k3-socinfo：修复探查失败时的 regmap 泄漏 从不释放探测期间分配的 mmio regmap。切换为使用设备管理的分配器，以便在探测失败时释放 regmap（例如
    探测延迟）和驱动程序取消绑定时。（CVE-2026-43242）

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

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

  - drm/amdgpu：重构 amdgpu_gem_va_ioctl 以处理上次隔离更新和时间线管理 v4 此提交简化了 amdgpu_gem_va_ioctl 函数，主要更新包括：- 将用于管理上次更新隔离的逻辑直接移动到 amdgpu_gem_va_update_vm 中。- 引入了对时间线点的检查，以便有条件地替换或添加隔离。v2：处理了 Christian 的评论评论。v3：
    更新了评论（克里斯蒂安）。v4：之前的版本过早选择隔离并且未正确管理其引用，这样可导致使用过时或已释放的隔离。这导致 refcount 下溢，并且可能在更新 GPU 时间线时崩溃。现在只有在 VA 测绘工作完成并安全地获取其参考后，才能选择围栏。将其导出到 VM 时间线 syncobj 后，驱动程序始终会丢弃其本地隔离引用，从而确保平衡的引用计数并避免dma_fence的释放后使用。崩溃签名： [ 205.828135] refcount_t：下溢;释放后使用。[ 205.832963] 警告：
    CPU：30 PID：7274 at lib/refcount.c：28 refcount_warn_saturate+0xbe/0x110 ...[ 206.074014] 调用跟踪：[206.076488] <TASK> [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu] [ 206.084040] ？
    __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm] [ 206.094415] drm_ioctl+0x26e/0x520 [drm] [ 206.098424] ？ __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] [ 206.109387] __x64_sys_ioctl+0x96/0xe0 [ 206.113156] do_syscall_64+0x66/0x2d0 ...[ 206.553351] 缺陷：无法处理地址的页面错误：ffffffffc0dfde90 ...[ 206.553378] RIP：0010：dma_fence_signal_timestamp_locked+0x39/0xe0 ...[ 206.553405] 调用跟踪： [206.553409] <IRQ> [ 206.553415] ？ __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched] [ 206.553424] dma_fence_signal+0x30/0x60 [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched] [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0 [ 206.553437] dma_fence_signal+0x30/0x60 [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu] [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu] [206.554353] edac_mce_amd（E） ee1004（E） [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu] [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu] [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu] [ 206.555500]
    __handle_irq_event_percpu+0x4a/0x1c0 [ 206.555506] handle_irq_event+0x38/0x80 [ 206.555509] handle_edge_irq+0x92/0x1e0 [ 206.555513] __common_interrupt+0x3e/0xb0 [ 206.555519] common_interrupt+0x80/0xa0 [ 206.555527206.555525</IRQ> ] [ ] ... <TASK>[ 206.555650] RIP：
    0010：dma_fence_signal_timestamp_locked+0x39/0xe0 ...[ 206.555667] 内核恐慌 - 不同步：中断 （CVE-2026-43237） 中的致命异常

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

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

  - wifi：libertas：修复 usb_tx_block 中的警告 函数 usb_tx_block（） 在未确保已完成此 URB 上之前的任何传输的情况下提交 cardp->tx_urb。如果在 URB 仍处于活动状态时（例如在快速固件加载期间）发生第二次调用，则 usb_submit_urb（） 会检测活动状态并触发警告：“活动时提交了 URB”。通过强制执行序列化修复此问题：在提交新请求之前调用 usb_kill_urb（）。这可确保 URB 空闲且可以安全重用。（CVE-2026-43255）

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

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

  - media：pvrusb2：修复 pvr2_send_request_ex 中的 URB 泄漏 pvr2_send_request_ex（） 若成功提交写入 URB 但未能提交读取的 URB（如返回 -ENOMEM），系统会立即返回，而不会等待写入 URB 完成。由于驱动程序重复使用相同的 URB 结构，对 pvr2_send_request_ex（） 的后续调用会尝试提交仍然活动的写入 URB，从而在 usb_submit_urb（） 中触发“URB submitted while active”警告。通过确保断开写入 URB 链接并等待读取 URB 提交失败来修复此问题。（CVE-2026-43223）

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

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

  - ntb：ntb_hw_switchtec：修复访问权限 array-index-out-of-bounds MW LUT 的数量取决于 NTB 配置，并且可设置为 MAX_MWS，此修补程序可防止无效的索引越界访问 mw_sizes 当无效访问时，将配置无效打印给用户的消息。（CVE-2026-43241）

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

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

  - 邮箱：mchp-ipc-sbi：修复 mchp_ipc_get_cluster_aggr_irq（） 中的越界访问 cluster_cfg 数组会动态分配，以容纳每个 CPU 的配置结构，其大小基于在线 CPU 的数量。以前，此数组使用 hartid 编制索引，这可能是非连续的或超出数组的边界，从而导致越界访问。切换为使用 cpuid 作为索引，因为它保证在 for_each_online_cpu（） 提供的有效范围内。（CVE-2026-43274）

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

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

  - team：避免取消注册从属 syzbot 报告时发生NETDEV_CHANGEMTU事件 unregister_netdevice：
    等待 netdevsim0 释放。使用计数 = 3 ref_tracker：netdev@ffff88807dcf8618在 include/linux/netdevice.h：4400 [内联] netdev_hold include/linux/netdevice.h：4429 [内联] __netdev_tracker_alloc有 1/2 个用户 include/linux/netdevice.h：4429 [内联] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c：286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c：1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c：85 call_netdevice_notifiers_mtu net/core/dev.c：2318 [内联] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c：9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c：9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c：248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c：1333 team_del_slave drivers/net/team/team_core.c：1936 [内联] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c：2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c：85 call_netdevice_notifiers_extack net/core/dev.c：2281 [内联] call_netdevice_notifiers net/core/dev.c：2295 [内联] __dev_change_net_namespace+0xcb7/0x2050net/core/dev.c：12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c：3060 rtnl_changelink net/core/rtnetlink.c：3776 [内联] __rtnl_newlink net/core/rtnetlink.c：3935 [内联] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c：4072 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c：6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c：2550 netlink_unicast_kernel net/netlink/af_netlink.c：1318 [内联] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c：1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c：1894 问题。Ido Schimmel 发现重现 ip 链接添加名称 team1 类型团队 ip 链接添加名称 dummy1 mtu 1499 master team1 类型虚拟 ip netns 添加 ns1 ip 链接设置 dev dummy1 netns ns1 ip -n ns1 link del dev dummy1 的步骤，还发现提交 f51048c3e07b 中的绑定驱动程序中修复了相同的问题（bonding： 避免NETDEV_CHANGEMTU注销从属设备时发生的事件）。让我们对团队驱动程序做类似的事情，同时应用提交 ad7c7b2172c3（net：在 sysfs 操作期间保持 netdev 实例锁定）和提交 303a8487a657（net：s/__dev_set_mtu/__netif_set_mtu/）。（CVE-2026-43234）

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

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

  - dm-verity：正确处理 dm_bufio_client_create（） 失败 如果对 verity_fec_ctr（） 中的 dm_bufio_client_create（） 的任一调用失败，则稍后会使用 ERR_PTR（） 参数调用 dm_bufio_client_destroy（）。这会导致崩溃。修复此问题。（CVE-2026-43132）

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

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

  - atm：fore200e：修复设备删除期间 tasklet 中的释放后使用 当卸下 PCA-200E 或 SBA-200E 适配器时，fore200e 将释放。但是，tx_tasklet或rx_tasklet可能仍在运行或待定，从而导致在 fore200e_tx_tasklet（） 或 fore200e_rx_tasklet（） 中再次访问已释放的 fore200e 时出现释放后使用缺陷。其中一个争用条件可能发生，如下所示：CPU 0（清理）|CPU 1 （tasklet） fore200e_pca_remove_one（） |fore200e_interrupt（） fore200e_shutdown（） |tasklet_schedule（） kfree（FORE200E） |fore200e_tx_tasklet（） |fore200e-> // UAF 通过确保在释放 fore200e 之前正确取消tx_tasklet或 rx_tasklet 来修复此问题。在 fore200e_shutdown（） 中添加 tasklet_kill（） 以与任何待定或正在运行的 tasklet 同步。此外，由于 fore200e_reset（） 可阻止进一步的中断或数据传输，因此应将 tasklet_kill（） 放在 fore200e_reset（） 之后，以防止在 fore200e_interrupt（） 中重新计划 tasklet。最后，它只需要在 fore200e 状态大于或等于 FORE200E_STATE_IRQ 时执行 tasklet_kill（），因为 tasklet 在早期状态中是未初始化的。总之，tasklet_kill（）应该放在开关内的FORE200E_STATE_IRQ分支中......案例结构。此缺陷是通过静态分析发现的。（CVE-2026-43203）

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

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

  - rnbd-srv：使用 rsp 缓冲区之前将其归零 使用数据缓冲区发回响应消息之前，请将其完全归零。这可防止在不同协议版本之间交换消息时，客户端挑选任何杂散字节。（CVE-2026-43184）

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

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

  - EFI/CPER：不转储整个内存区域 cper_print_fw_err（） 的当前逻辑未检查错误记录长度是否足够大以处理偏移。在不良固件中，如果 ofset 高于实际记录，length -= offset 将下溢，从而转储整个内存。最终结果可能是：- 逻辑花费大量时间转储大区域内存;- 由于内存转储导致的数据泄露;
    - OOPS（如果它尝试转储未映射的内存区域）。通过在执行十六进制转储之前检查部分长度是否太小修复了此问题。[ rjw： 主题调整 ]（CVE-2026-43171）

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

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

  - KVM：nSVM：在 VMLOAD/VMSAVE 仿真提交 cc3ed80ae69f 中始终使用 vmcb01（KVM：nSVM：始终将 vmcb01 用于访客状态的 VMSAVE/VMLOAD）使 KVM 始终将 vmcb01 用于 VMSAVE/VMLOAD 控制的字段，但未能将 VMLOAD/VMSAVE 仿真代码更新为始终使用 vmcb01。因此，如果 VMSAVE/VMLOAD 由 L2 客户机执行且未被 L1 拦截，则 KVM 将错误地使用 vmcb02。
    始终使用 vmcb01 而非当前的 VMCB。（CVE-2026-43133）

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

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

  - fs/buffer：在 try_to_free_buffers（） 中为无缓冲区的作品集添加警报 try_to_free_buffers（） 在属于具有AS_RELEASE_ALWAYS集但未定义release_folio操作的映射的 folio 上调用 filemap_release_folio（） 时，可在未连接缓冲区的 Folios 上调用 。在这种情况下，由于 AS_RELEASE_ALWAYS 标记，folio_needs_release（） 返回 true，但 folio 没有专用缓冲区数据。这导致 try_to_free_buffers（） 在没有缓冲区的 folio 上调用 drop_buffers（），从而导致空指针取消引用。在 try_to_free_buffers（） 中添加检查以在作品集未附加缓冲区时提早返回，并通过 WARN_ON_ONCE（） 以针对错误配置发出警报。这提供了防御强化。（CVE-2025-71295）

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

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

  - net：cpsw_new：修复尚未注册的 netdev 可能的取消注册 如果在 cpsw_register_ports（） 中的第一个 MAC 的 register_netdev（） 期间发生错误，即使 cpsw->slaves[0].ndev 设置为 NULL，cpsw->slaves[1].ndev 也会保持不变。这可在以后造成 cpsw_unregister_ports（） 尝试取消注册第二个 MAC。若要解决此问题，请添加调用 unregister_netdev（） 之前的 ndev->reg_state 检查。通过此更改，将 cpsw->slaves[i].ndev 设置为空变得不必要，可以相应地删除。（CVE-2026-43219）

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

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

  - net：usb：pegasus：启用基本端点检查 pegasus_probe（） 在不验证端点描述符的情况下使用硬编码端点管道填充 URB： - usb_rcvbulkpipe（dev， 1） 用于 RX 数据 - usb_sndbulkpipe（dev， 2） 用于 TX 数据 - usb_rcvintpipe（dev， 3） 用于状态中断 畸形 USB 设备可通过与驱动程序假设的传输类型不同的传输类型呈现这些端点。为端点数字添加pegasus_usb_ep枚举，在整个过程中替换魔术常量。在任何资源分配前添加 usb_check_bulk_endpoints（） 和 usb_check_int_endpoints（） 调用，以在使用前验证端点类型，在探测时拒绝描述符不匹配的设备，并避免触发断言。类似的补丁 - 提交 90b7f2961798（net：usb：rtl8150：启用基本端点检查） - 提交 9e7021d2aeae（net：usb：catc：启用基本端点检查）（CVE-2026-43156）

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

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

  - tcp：修复 tcp_v6_syn_recv_sock（） 中潜在的争用 调用太晚完成 tcp_v4_syn_recv_sock（） 后 tcp_v6_syn_recv_sock（） 中的代码。tcp_v4_syn_recv_sock（） 之后，子套接字已从 TCP ehash 表可见，其他 cpu 可能会使用它。由于 newinet->pinet6 仍指向监听器ipv6_pinfo因此可能会发生 syzbot 发现的不好情况。在 tcp_v6_mapped_child_init（） 中移动有问题的代码并在插入 ehash 之前从 tcp_v4_syn_recv_sock（） 调用此新的帮助程序。这允许删除一个 tcp_sync_mss（），因为 tcp_v4_syn_recv_sock（） 将以正确的上下文调用它。
    (CVE-2026-43198)

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

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

  - RDMA/umem：修复故障路径中的双重dma_buf_unpin 在 ib_umem_dmabuf_get_pinned_with_dma_device（） 中，对 ib_umem_dmabuf_map_pages（） 的调用可能失败。如果发生这种情况，dmabuf 将立即取消固定，但仍会设置 umem_dmabuf->pinned 标记。然后，在调用 ib_umem_release（） 时，它会调用 ib_umem_dmabuf_revoke（），后者会再次调用 dma_buf_unpin（）。通过删除失败时立即取消固定来修复此问题，只需让ib_umem_release/撤销路径处理它。如果 dmabuf_map_pages 调用碰巧由于dma_resv_wait_timeout而失败（因此具有非 NULL umem_dmabuf->sgt），这也可确保正确的 unmap-unpin 展开顺序。（CVE-2026-43128）

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

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

  - staging：rtl8723bs：修复失败路径中的内存泄漏 cfg80211_inform_bss_frame（） 可能在失败时返回 NULL。在这种情况下，分配的缓冲区“buf”未释放，函数会提早返回，从而可能导致内存泄漏。通过确保在成功和失败路径中释放“buf”来修复此问题。
    (CVE-2026-43225)

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

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

  - net： ethernet： ec_bhf： 修复错误路径中的 dma_free_coherent（） dma 句柄 dma_free_coherent（） 采用 priv->rx_buf.alloc_len 作为 dma 句柄。这将导致缓冲区不正确的取消映射。将 dma 句柄更改为 priv->rx_buf.alloc_phys。 （CVE-2026-43283）

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

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

  - eventpoll：将结构 eventpoll 释放延迟至 RCU 宽限期 在某些情况下，eventpoll.c 中的 ep_free（） 会在另一个并发线程仍在使用 epi->ep eventpoll 结构时将其释放。将 kfree（） 延迟到 RCU 回调以防止 UAF。（CVE-2026-43074）

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

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

  - media：i2c/tw9906：修复 tw9906_probe（） 中可能发生的内存泄漏 在 tw9906_probe（） 的其中一个错误路径中，未释放 v4l2_ctrl_handler_init（） 和 v4l2_ctrl_new_std（） 中分配的内存。通过在该错误路径中的处理程序上调用 v4l2_ctrl_handler_free（） 来修复此问题。（CVE-2026-43246）

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

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

  - RedisBloom 是 Redis 的概率性数据结构模块。在之前的所有 RedisBloom 2.8.20版本中，该模块未正确验证通过 Redis RESTORE 命令处理的序列化值。如果经身份验证的攻击者具有权限，可在加载 RedisBloom 模块的服务器上执行 RESTORE，则可提供特制的序列化负载，触发无效的内存访问，并可能导致远程代码执行。变通方案是通过 ACL 规则限制对 RESTORE 命令的访问。此问题已在 2.8.20 版本中修复。(CVE-2026-25589)

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

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

  - netfilter：ctnetlink：确保对主控制追踪的安全访问仅对期望保持引用是不够的，主控制追踪对象可以直接消失，使exp->master无效。要安全访问 exp->master：- 抓住 nf_conntrack_expect_lock，该会被序列化为 clean_from_lists（），当主控制轨道消失时也能保持该锁。- 通过nf_conntrack_find_get（）保持主控制轨道的引用。这并不容易，因为现有有问题路径中无法查找主控制轨道的主元组。本次补丁是通过延长nf_conntrack_expect_lock段以简化问题，在下面描述的情况下，这只是稍微延长了锁段。add expectation 命令已经包含了来自 ctnetlink_create_expect（） 的主 conntrack 的引用。然而，删除期望命令需要先抓取自旋锁，然后才查找期望值。扩展现有的自旋锁部分以解决这个问题，以覆盖期望查找。注意，nf_ct_expect_iterate_net（）调用在遍历期望表时已经抓取了旋转锁，这是正确的。get expectation 命令需要抓住旋转锁，以确保主控制轨道不会消失。这也扩展了现有的旋转锁部分，以覆盖期望查找。我需要把网链SKB分配从spinlock中移出来，才能保持GFP_KERNEL。对于预期事件，IPEXP_DESTROY事件已经在旋转锁下传递，只需将IPEXP_NEW的传递也移到旋转锁下方，因为主控制追踪事件缓存是通过exp->master访问的。顺便加上锁链注释，帮助识别抓取自旋锁所需的码径。（CVE-2026-43116）

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

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

  - nfc：s3fwrn5：在消耗字节之前分配 rx skb s3fwrn82_uart_read（） 将接受的字节数报告给 serdev 核心。目前代码会消耗字节进入 recv_skb，并且可能在分配新的接收缓冲区之前就已传递完整帧。如果该 alloc_skb（） 失败，即使它已经消耗字节，回调也会返回 0，并将recv_skb留为空以用于下一个接收回调。这会破坏 receive_buf（） 会计合同，还可能导致下一个 skb_put_u8（） 的空取消引用。转而消耗下一个字节之前延迟分配接收 skb。如果分配失败，请返回已接受的字节数。（CVE-2026-43098）

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

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

  - btrfs：修复日志重播后大小为非零的 inode 在记录已存在的 inode 时，作为记录目录的新名称或记录新目录条目的一部分，我们始终将记录的 inode 项目的生成设置为 0。这是为了在日志重播期间（在 overwrite_item（） 中）发出信号，表明我们不应设置i_size，因为我们仅记录存在一个 inode，因此必须保留子卷树中 inode 的i_size（因为当我们记录新名称或存在 inode 时，我们不会记录盘区）。除非我们已经以完整模式记录了 inode，或者这是我们第一次记录在过去事务中创建的 inode，该 inode 的新i_size为 0，然后我们记录该 inode 的新名称（由于新的硬链接或重命名），否则这正常工作， 在这种情况下，我们为 inode 记录 0 的i_size和 0 的生成，这导致日志重播代码无法将 inode 的i_size更新为 0（在 overwrite_item（） 中）。示例场景：mkdir /mnt/dir xfs_io -f -c pwrite 0 64K /mnt/dir/foo sync xfs_io -c truncate 0 -c fsync /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c fsync /mnt/dir <power fail> 日志回放后，文件仍保持 64K 大小。这是因为当我们第一次记录 inode 时，当我们 fsync 文件 foo 时，我们记录其当前的i_size为 0，然后当我们创建硬链接时，我们会以存在模式 （LOG_INODE_EXISTS） 再次记录 inode，但我们为添加到日志树的 inode 项目设置了 0 的生成， 因此，在日志重播期间，overwrite_item（） 发现生成为 0，i_size 为 0，因此我们跳过将 inode 的i_size从 64K 更新到 0。通过确保在 fill_inode_item（） 我们始终记录 inode 的真实生成（如果它是使用之前记录的i_size记录在当前事务中）来修复此问题。此外，如果在之前的事务中创建的 inode 仅以存在模式登录，请确保我们记录存储在提交根的 inode 项目中的i_size，以便如果我们多次记录该 inode 存在，我们将获得正确的i_size。很快将推出针对 fstests 的测试用例。（CVE-2026-43118）

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

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

  - drm/vc4：修复挂起状态错误路径中的内存泄漏 当 vc4_save_hang_state（） 遇到提早返回条件时，它会在不释放之前分配的“kernel_state”的情况下返回，从而导致泄漏内存。通过将早期返回路径合并到一处，添加缺失的 kfree（） 调用。（CVE-2026-43104）

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

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

  - l2tp：丢弃包含 UDP encap 的大型数据包 syzbot 报告了关于我的修补程序系列的 WARN [1]。实际问题是 16 位 UDP 长度字段的溢出，它存在于上游代码中。我的系列添加了一个调试 WARN，其中包含暴露该问题的溢出检查，这就是 syzbot 在我的补丁上跳闸的原因，而不是在上游代码上跳闸的原因。syzbot 的重现：r0 = socket$pppl2tp（0x18， 0x1， 0x1） r1 = socket$inet6_udp（0xa， 0x2， 0x0） connect$inet6（r1， &（0x7f00000000c0）={0xa， 0x0， 0x0， @loopback， 0xfffffffc}， 0x1c） connect$pppl2tp（r0， &（0x7f0000000240）=@pppol2tpin6={0x18， 0x1， {0x0， r1， 0x4， 0x0， 0x0， 0x0， {0xa， 0x4e22， 0xffff， @ipv4={'\x00'， '\xff\xff'， @empty}}}}， 0x32） writev（r0， &（0x7f0000000080）=[{&（0x7f0000000000）=ee， 0x34000}]，0x1） 它基本上发送的是包含 UDP 封装的超大（0x34000字节）PPPoL2TP 数据包，分配 UDP 长度字段时 l2tp_xmit_core 不会检查溢出。该值被裁减为 16 咬。添加溢出检查，丢弃超大数据包并避免将具有修整后的 UDP 长度的数据包发送至线路。syzbot 的堆栈跟踪（应用了我的修补程序）：len >= 65536u 警告：
    ./include/linux/udp.h：38 at udp_set_len_short include/linux/udp.h：38 [inline]， CPU#1： syz.0.17/5957 WARNING： ./include/linux/udp.h：38 at l2tp_xmit_core net/l2tp/l2tp_core.c：1293 [inline]， CPU#1：
    syz.0.17/5957 WARNING： ./include/linux/udp.h：38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c：1327， CPU#1： syz.0.17/5957 链接的模块： CPU：1 UID：0 PID：5957 通信：syz.0.17 未受感染 syzkaller #0 PREEMPT（完整） 硬件名称： QEMU Standard PC （Q35 + ICH9， 2009）， BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP： 0010：udp_set_len_short include/linux/udp.h：38 [inline] RIP： 0010：l2tp_xmit_core net/l2tp/l2tp_core.c：1293 [内联] RIP：0010：l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c：1327 代码：
    0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP：
    0018：ffffc90003d67878 EFLAGS： 00010293 RAX： ffffffff8ad985e3 RBX： ffff8881a6400090 RCX： ffff8881697f0000 RDX： 0000000000000000 RSI： 0000000000034010 RDI： 000000000000ffff RBP： dffffc0000000000 R08：
    0000000000000003 R09： 0000000000000004 R10： dffffc0000000000 R11： ffffff520007acf00 R12： ffff8881baf20900 R13： 0000000000034010 R14： ffff8881a640008e R15： ffff8881760f7000 FS： 000055557e81f500（0000） GS：ffff8882a9467000（0000） knlGS：000000000000000 CS： 0010 DS： 0000 ES： 0000 CR0： 0000000080050033 CR2：
    0000200000033000 CR3：00000001612f4000 CR4：00000000000006f0 调用跟踪： <TASK> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c：302 sock_sendmsg_nosec net/socket.c：727 [内联]
    __sock_sendmsg net/socket.c：742 [内联] sock_write_iter+0x503/0x550 net/socket.c：1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c：-1 vfs_writev+0x33c/0x990 fs/read_write.c：1059 do_writev+0x154/0x2e0 fs/read_write.c：1105 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [内联] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7f636479c629 代码： ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007ffffd4241c8 EFLAGS： 00000246 ORIG_RAX： 0000000000000014 RAX： ffffffffffffffda RBX：
    00007f6364a15fa0 RCX： 00007f636479c629 RDX： 0000000000000001 RSI： 0000200000000080 RDI： 0000000000000003 RBP： 00007f6364832b39 R08： 00000000000000000 R09： 000000000000000000 R10： 000000000000000000 R11：
    0000000000000246 ： 0000000000000000 R13： 00007f6364a15fac R14： 00007f6364a15fa0 R15： 00007f6364a15fa0 </TASK> [1]： https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/(CVE-2026-43080）R12

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: Reset register ID for BPF_END value tracking When a register undergoes a BPF_END (byte swap) operation, its scalar value is mutated in-place. If this register previously shared a scalar ID with another register (e.g., after an `r1 = r0` assignment), this tie must be broken. Currently, the verifier misses resetting `dst_reg->id` to 0 for BPF_END. Consequently, if a conditional jump checks the swapped register, the verifier incorrectly propagates the learned bounds to the linked register, leading to false confidence in the linked register's value and potentially allowing out-of-bounds memory accesses. Fix this by explicitly resetting `dst_reg->id` to 0 in the BPF_END case to break the scalar tie, similar to how BPF_NEG handles it via `__mark_reg_known`. (CVE-2026-43070)

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

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

  - ipv4：icmp：修复 icmp_build_probe（） 中的 null-ptr-deref 当 IPv6 堆栈未活动时（CONFIG_IPV6=m 且未加载），ipv6_stub->ipv6_dev_find（） 可能会返回 ERR_PTR（-EAFNOSUPPORT），将此错误指针传递到 dev_hold（） 将造成内核因 null-ptr-deref 而崩溃。而是静默地丢弃该请求。RFC 8335 似乎并未针对以下情况定义特定响应：IPv6 接口标识符在语法上有效，但实现无法在运行时执行查找，并且静默终止请求可能比误报 No Such Interface 更安全。（CVE-2026-43099）

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

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

  - Bluetooth：hci_sync：注解 hdev->req_status __hci_cmd_sync_sk（） 周围的数据争用 在 hdev->req_lock 下设置 hdev->req_status：hdev->req_status = HCI_REQ_PEND;但是，其他几个函数在不保持任何锁定的情况下读取或写入 hdev->req_status：- hci_send_cmd_sync（） 读取 hci_cmd_work（工作队列）中的req_status - hci_cmd_sync_complete（） 从 HCI 事件完成读取/写入 - hci_cmd_sync_cancel（） / hci_cmd_sync_cancel_sync（） 读取/写入 - hci_abort_conn（） 在连接中读取中止路径
    __hci_cmd_sync_sk（） 在 hdev->req_workqueue 上运行，而 hci_send_cmd_sync（） 在 hdev->workqueue 上运行，这些是可以在不同 CPU 上并发执行的不同工作队列。普通 C 访问构成数据争用。对 hdev->req_status 的所有并发访问添加 READ_ONCE（）/WRITE_ONCE（） 批注，以防止可能影响正确性的潜在编译器优化（例如，wait_event条件下的加载融合或存储重新排序）。（CVE-2026-43119）

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

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

  - Redis 是内存内数据结构存储。在所有具有 Lua 脚本的 redis-server 版本中，经身份验证的攻击者可利用主本同步机制，在副本已禁用或可禁用（可导致远程代码执行）的副本上触发释放后使用。变通方案为阻止用户执行 Lua 脚本，或避免使用禁用了副本只读的副本。此问题已在版本 8.6.3 中得到修补。(CVE-2026-23631)

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

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

  - 在Paramiko中，直到 4.0.0 a448945，rsakey.py 允许SHA-1算法。（CVE-2026-44405）

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

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

  - ocfs2：修复 ocfs2_write_end_inline 中的越界写入 KASAN 报告了 ocfs2_write_end_inline 中 4086 字节的释放后使用写入，这些写入是在循环设备上挂载的损坏的 ocfs2 文件系统上进行copy_file_range splice 回退期间从 ocfs2_write_end_nolock 调用的。实际缺陷是越界写入超出 inode 区块缓冲区，而非真正的释放后使用。写入溢出到相邻的已释放页面，KASAN 将其报告为 UAF。根本原因是 ocfs2_try_to_write_inline_data 信任磁盘上的id_count字段来判断写入是否适合内联数据。在已损坏的文件系统上，id_count可超过物理最大内联数据容量，造成写入溢出 inode 区块缓冲区。调用跟踪（崩溃路径）：vfs_copy_file_range （fs/read_write.c：1634） do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock （fs/ocfs2/aops.c：1949） ocfs2_write_end_inline （fs/ocfs2/aops.c：1915） memcpy_from_folio <-- KASAN：写入 OOB 因此id_count在 ocfs2_validate_inode_block（） 中添加上限检查与现有i_size检查并列来修复它。（CVE-2026-43075）

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

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

  - Prometheus 是一个开源的监测系统和时间序列数据库。在版本和3.5.33.11.3之前，Azure AD 远程写入 OAuth 配置（storage/remote/azuread）中的 client_secret 字段是用字符串类型而非 Secret。Prometheus 在通过 /-/config HTTP API 端点提供配置时，会涂黑 Secret 类型的字段。由于字段是纯字符串，Azure OAuth 客户端秘密以明文形式暴露给任何有权限访问该端点的用户或进程。已在版本 3.5.3 和 3.11.3 中修补此问题。(CVE-2026-42151)

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

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

  - RDMA/irdma：修复与 rereg_user_mr 相关的双重释放 如果在rereg_user_mr期间设置了IB_MR_REREG_TRANS，则将释放 umem，并在 irdma_rereg_mr_trans 中分配新的 uum。如果分配新的 umem 后 irdma_rereg_mr_trans 的任何步骤失败，它将释放 umem，但不会将 iwmr->region 设置为 NULL。问题是该失败会传递给用户，然后用户将调用ibv_dereg_mr（按其应当的方式）。然后，dereg_mr路径会发现非空 umem，并尝试再次调用ib_umem_release。通过在ib_umem_release后将 iwmr->region 设置为 NULL 来修复此问题。已修复：5ac388db27c4（RDMA/irdma：添加支持以重新注册内存区域）（CVE-2026-43120）

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

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

  - ixgbevf：向 Hyper-V ops 表添加缺失的 negotiate_features op 提交 a7075f501bd3（ixgbevf：通过协商支持的功能修复邮箱 API 兼容性） 已将 .negotiate_features 回调添加到 ixgbe_mac_operations 并在 ixgbevf_mac_ops 中填充，但忘记将其添加到 ixgbevf_hv_mac_ops。这会使 Hyper-V VM 上的函数指针为 NULL。在探测期间，ixgbevf_negotiate_api（） 会调用 ixgbevf_set_features（），此函数会无条件取消引用 hw->mac.ops.negotiate_features（）。在 Hyper-V 上，这会导致空指针取消引用：缺陷：内核空指针取消引用，解决：
    0000000000000000 [...]硬件名称：Microsoft Corporation 虚拟机/虚拟机 [...]工作队列：事件work_for_cpu_fn RIP：0010：0x0 [...]调用跟踪：ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...]添加返回 -EOPNOTSUPP 的 ixgbevf_hv_negotiate_features_vf（） 并将其连接到 ixgbevf_hv_mac_ops。调用程序已妥善处理 -EOPNOTSUPP。（CVE-2026-43094）

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

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

  - xfrm_user：修复 build_mapping（） struct 中的信息泄漏，该xfrm_usersa_id在 proto 字段之后有一个字节填充孔，该漏洞在外复制到用户空间之前永远不会设为零。通过在设置各个变量之前将整个结构归零来修复此问题。（CVE-2026-43089）

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

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

  - 提交 42202bf 前的 BusyBox 包含 networking/udhcp/d6_dhcpc.c 中 DHCPv6 客户端（udhcpc6）DNS_SERVERS选项处理程序中的堆缓冲区溢出漏洞，允许网络邻近攻击者通过发送带有畸形 D6_OPT_DNS_SERVERS 选项的精心设计的 DHCPv6 响应来触发内存损坏。
    攻击者可以利用option_to_env（）函数中错误的堆缓冲区分配计算，导致拒绝服务，或在未进行堆硬化的情况下实现嵌入系统上的任意代码执行。
    (CVE-2026-29004)

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

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

  - Jupyter 服务器是 Jupyter 网页应用的后端。在版本 2.17.0 及更早版本中，用于签署认证 cookie 的秘密文件会持久化为 ~/.local/share/jupyter/runtime/jupyter_cookie_secret 的静态文件，用户更改密码时绝不会轮换。密码重置和服务器重启后，任何之前发出的认证 Cookie 在密码学上仍然有效，因为签名密钥未被更改。通过任何方式捕获会话Cookie的攻击者，无论后续密码如何更改，都保留对服务器的完整认证访问权限。这影响使用基于密码认证的部署，尤其是共享或面向公众的服务器，凭证轮换预计会撤销现有会话。此问题已在 2.18.0 版本中修复。(CVE-2026-40934)

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

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

  - netfilter：nft_set_pipapo_avx2：过期时不返回不匹配的条目 使用 avx2 匹配函数时，新的测试案例意外失败。该测试首先加载勒索生成的 pipapo 集，其中包含“ipv4 .
    port“密钥，即 nft -f foo。这有效。然后，它在刷新后重新加载该集合：（echo flush set t s; cat foo） |nft -f - 这有望奏效，因为它毕竟是同一套，而且已经加载过一次。但是对于 avx2，这失败了：nft 报告了一个冲突的元素。报告的冲突形式如下：
    我们成功地重新插入了一个 .b c .d 然后我们尝试插入一个 .D avx2 会发现已存在的 .d，其（由于“flush set”）在新一代中被标记为无效。它会跳过该元素并移到下一个元素。由于掩码不正确，跳过步骤会找到下一个匹配元素 *仅考虑第一个字段*，也就是说，我们返回已经重新插入的 .b，即使最后一个字段不同并且不应匹配条目。对于通用 c 实现（无 avx2）或当最后一个字段必须使用“nft_pipapo_avx2_lookup_slow”回退时，不会报告此类错误。Bisection 指向 7711f4bb4b36（netfilter：nft_set_pipapo：修复范围重叠检测），但该补丁仅发现此缺陷。在此提交之前，会返回错误的元素，但会错误地报告为完整、完全相同的重复。根本原因是 avx2 匹配函数中过早返回。当我们处理最后一个字段时，我们应该继续处理数据，直到消耗完整个输入大小，以确保映射中没有过时位。（CVE-2026-43114）

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

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

  - 在 ProFTPD 到 1.3.9a 之前的 7666224 中，contrib/mod_wrap2_sql.c sqltab_fetch_clients_cb（） 中的 SQL 注入漏洞允许远程攻击者通过反向 DNS 查找访问的自定义域名注入任意 SQL 命令。当启用 UseReverseDNS 时，攻击者提供的主机名会被无逃逸地传递到 SQL 查询中。DNS名称的字符限制可能影响可利用性。（CVE-2026-44331）

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 (ext4: always allocate blocks only from groups inode can use) restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().
    (CVE-2026-43067)

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

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

  - wifi：wl1251：编制索引前验证数据包 ID tx_frames wl1251_tx_packet_cb（） 直接使用固件完成 ID 为固定的 16 条目 wl->tx_frames[] 数组编制索引。ID 是来自完成块的原始 u8，回调当前未在取消引用数组之前验证其是否适合数组。拒绝超出 wl->tx_frames[] 范围的完成 ID 并保留同一防护中现有的 NULL 检查。这可使补丁保留在信任边界的本地位置，并避免涉及完成流的其余部分。
    (CVE-2026-43113)

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

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

  - FRRouting（FRR）MP_REACH_NLRI组件中缺少输入验证，stable/10.0 to stable/10.6 允许经过认证的攻击者通过提供精心设计的 UPDATE 消息来引发拒绝服务（DoS）。
    (CVE-2026-37458)

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

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

  - srcu：使用 irq_work 启动 tiny SRCU 中的 GP Tiny SRCU 的 srcu_gp_start_if_needed（） 直接调用 schedule_work（），从而获取工作队列 pool->lock。在保留计划程序锁定的情况下调用 call_srcu（） 时，这会导致 lockdep 崩溃，原因是：call_srcu（） [holding pi_lock] srcu_gp_start_if_needed（） schedule_work（） -> pool->lock workqueue_init（） / create_worker（） [holding pool->lock] wake_up_process（） -> try_to_wake_up（） -> pi_lock 此外，将 irq_work_sync（） 添加到 cleanup_srcu_struct（），如果清理开始后触发排队的irq_work，则防止释放后使用。使用 rcutorture SRCU-T 进行测试，无 lockdep 警告。[感谢 Boqun 在修补程序 rcu 中提供类似的修复：使用中间irq_work启动 process_srcu（） ]（CVE-2026-43115）

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

ID	名称	严重性
312712	Linux Distros 未修补的漏洞：CVE-2026-43126	high
312711	Linux Distros 未修补的漏洞：CVE-2026-43248	high
312710	Linux Distros 未修补的漏洞：CVE-2025-71294	medium
312709	Linux Distros 未修补的漏洞：CVE-2025-71291	medium
312708	Linux Distros 未修补的漏洞：CVE-2025-54502	high
312707	Linux Distros 未修补的漏洞：CVE-2026-43242	medium
312706	Linux Distros 未修补的漏洞：CVE-2026-43237	high
312705	Linux Distros 未修补的漏洞：CVE-2026-43255	medium
312704	Linux Distros 未修补的漏洞：CVE-2026-43223	medium
312703	Linux Distros 未修补的漏洞：CVE-2026-43241	high
312702	Linux Distros 未修补的漏洞：CVE-2026-43274	high
312701	Linux Distros 未修补的漏洞：CVE-2026-43234	medium
312700	Linux Distros 未修补的漏洞：CVE-2026-43132	medium
312699	Linux Distros 未修补的漏洞：CVE-2026-43203	high
312698	Linux Distros 未修补的漏洞：CVE-2026-43184	high
312697	Linux Distros 未修补的漏洞：CVE-2026-43171	medium
312696	Linux Distros 未修补的漏洞：CVE-2026-43133	high
312695	Linux Distros 未修补的漏洞：CVE-2025-71295	medium
312694	Linux Distros 未修补的漏洞：CVE-2026-43219	medium
312693	Linux Distros 未修补的漏洞：CVE-2026-43156	medium
312692	Linux Distros 未修补的漏洞：CVE-2026-43198	critical
312691	Linux Distros 未修补的漏洞：CVE-2026-43128	high
312690	Linux Distros 未修补的漏洞：CVE-2026-43225	medium
312689	Linux Distros 未修补的漏洞：CVE-2026-43283	high
312688	Linux Distros 未修补的漏洞：CVE-2026-43074	high
312687	Linux Distros 未修补的漏洞：CVE-2026-43246	medium
312644	Linux Distros 未修补的漏洞：CVE-2026-25589	high
312643	Linux Distros 未修补的漏洞：CVE-2026-43116	high
312642	Linux Distros 未修补的漏洞：CVE-2026-43098	medium
312641	Linux Distros 未修补的漏洞：CVE-2026-43118	medium
312640	Linux Distros 未修补的漏洞：CVE-2026-43104	medium
312639	Linux Distros 未修补的漏洞：CVE-2026-43080	high
312638	Linux Distros 未修补的漏洞：CVE-2026-43070	high
312637	Linux Distros 未修补的漏洞：CVE-2026-43099	high
312636	Linux Distros 未修补的漏洞：CVE-2026-43119	medium
312635	Linux Distros 未修补的漏洞：CVE-2026-23631	medium
312634	Linux Distros 未修补的漏洞：CVE-2026-44405	low
312633	Linux Distros 未修补的漏洞：CVE-2026-43075	high
312632	Linux Distros 未修补的漏洞：CVE-2026-42151	high
312631	Linux Distros 未修补的漏洞：CVE-2026-43120	high
312630	Linux Distros 未修补的漏洞：CVE-2026-43094	medium
312629	Linux Distros 未修补的漏洞：CVE-2026-43089	high
312628	Linux Distros 未修补的漏洞：CVE-2026-29004	high
312627	Linux Distros 未修补的漏洞：CVE-2026-40934	high
312626	Linux Distros 未修补的漏洞：CVE-2026-43114	critical
312625	Linux Distros 未修补的漏洞：CVE-2026-44331	high
312624	Linux Distros 未修补的漏洞：CVE-2026-43067	critical
312623	Linux Distros 未修补的漏洞：CVE-2026-43113	high
312622	Linux Distros 未修补的漏洞：CVE-2026-37458	medium
312621	Linux Distros 未修补的漏洞：CVE-2026-43115	medium

检测

Nessus 的 Misc. 系列

high

high

medium

medium

high

medium

high

medium

medium

high

high

medium

medium

high

high

medium

high

medium

medium

medium

critical

high

medium

high

high

medium

high

high

medium

medium

medium

high

high

high

medium

medium

low

high

high

high

medium

high

high

high

critical

high

critical

high

medium

medium