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

  - bpf：修复帮助程序原型中的内存访问标记 提交 37cce22dbd51（bpf：验证器：重构帮助程序访问类型跟踪）后，验证器开始依赖帮助程序函数原型中的访问类型标记来执行内存访问优化。目前，利用ARG_PTR_TO_MEM的几个帮助程序函数缺少相应的 MEM_RDONLY 或 MEM_WRITE 标记。这一遗漏会导致校验器错误地假定缓冲区内容在 helper 调用中保持不变。因此，校验器可能会基于这个错误的假设优化掉后续读取，从而导致正确性问题。
    对于 bpf_get_stack_proto_raw_tp，由于帮助程序写入缓冲区，原始MEM_RDONLY不正确。将其更改为 ARG_PTR_TO_UNINIT_MEM，可正确指示对可能未初始化内存的写入访问。最近针对提交 ac44dcc788b9（bpf：修复 bpf_d_path 输出缓冲区的校验器假设）和提交 2eb7648558a7（bpf：指定 bpf_sysctl_get_name 参数的访问类型）中的特定帮助程序解决了类似问题。通过添加正确的内存访问标记修复这些原型。
    (CVE-2026-45903)

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

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

  - i3c：dw：修复 dw_i3c_master_i2c_xfers（） 中的内存泄漏 dw_i3c_master_i2c_xfers（） 函数使用 dw_i3c_master_alloc_xfer（） 为 xfer 结构分配内存。如果 pm_runtime_resume_and_get（） 失败，该函数返回时不释放分配的 xfer，从而导致内存泄漏。将 dw_i3c_master_free_xfer（） 调用添加到错误路径以确保正确释放分配的内存。仅经过编译测试。使用原型静态分析工具和代码审查时发现的问题。（CVE-2026-45863）

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

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

  - usb：cdns3：修复恢复期间的角色切换 如果角色在暂停期间发生更改，cdns3 驱动程序会在恢复期间切换到新模式。但是，在此上下文中切换到主机模式会导致空指针取消引用。主机角色的 start（） 操作会注册 xhci-hcd 设备，但是当我们处于恢复路径中时，其探测会被延迟。主机角色的 resume（） 操作假设已探测 xhci-hcd 设备，但事实并非如此，因此会导致取消引用。由于已调用新角色的 start（） 操作，因此可以跳过恢复操作。因此，如果在恢复期间发生角色切换，请跳过新角色的恢复操作。一旦恢复序列完成，即可在主机模式下探测 xhci-hcd 设备。无法处理虚拟地址的内核空指针取消引用 0000000000000208 内存中止信息：... 数据中止信息： ... [0000000000000208] pgd=0000000000000000， p4d=0000000000000000 内部错误： 错误： 0000000096000004 [#1] SMP 模块链接于： CPU： 0 UID： 0 PID：
    146 Comm：sh 未受感染 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT 硬件名称：Texas Instruments J7200 EVM （DT） 状态：20000005 （nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--） pc：
    usb_hcd_is_primary_hcd+0x0/0x1c LR：cdns_host_resume+0x24/0x5c ... 调用跟踪：
    usb_hcd_is_primary_hcd+0x0/0x1c （P） cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dcvfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c 代码：52800003 f9407ca5 d63f00a0 17ffffe4 （f9410401） ---[ 结束跟踪 00000000000000000 ]--- （CVE-2026-45911）

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

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

  - 在 libsolv 中发现一个缺陷。将 EdDSA 的 MPI 复制到堆栈缓冲区时，由于未正确处理长度，PGP 验证组件中存在一个基于堆栈的缓冲区溢出漏洞。远程攻击者可利用不匹配的 MPI 长度构建恶意 Ed25519 PGP 签名。处理此特制的签名可在自动化程序包或存储库处理工作流程中导致拒绝服务。（CVE-2026-48863）

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

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

  - 7-Zip 是一款具有高压缩率的文件存档器。版本和之前版本 26.00 包含由 NTFS 压缩流缓冲区 （GetCuSize shift UB） 中的分配不足造成的堆缓冲区溢出漏洞，可能允许攻击者造成任意代码执行或应用程序崩溃。
    NTFS 处理程序中的 CInStream：：GetCuSize（） 将压缩单元缓冲区大小计算为 （UInt32）1 << （BlockSizeLog + CompressionUnit），而 ClusterSizeLog >= 28 且 CompressionUnit == 4 的构建图像将指数驱动到 32，这是未定义的行为并在 x86/x64 上折叠，因此_inBuf分配为 1 字节。然后，ReadStream_FALSE以 64 KB 迭代将多达 256 MB 的攻击者控制数据写入该 1 字节缓冲区，并且由于 CInStream 对象在_inBuf后仅停留 304 字节，因此其 vtable 指针将被覆盖，而下一个调度的调用实现 vtable 劫持。在 32 位版本中，会无条件达到溢出;在 64 位系统上，它需要成功的并行 8 GB _outBuf分配，否则将失败以致拒绝服务。默认情况下，库存7z.dll中启用 NTFS 处理程序，且在提取或测试过程中，无论文件扩展名如何，通过偏移 3 处的基于签名的回退匹配 NTFS，都将打开构建的图像。版本 26.01 已修复该问题。(CVE-2026-48095)

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

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

  - bpf：在 sync_linked_regs（） 中保留寄存器的 id sync_linked_regs（） 在使用 known_reg 关闭将 known_reg 的边界传播到 reg 时，但在将 known_reg 链接到 reg 时，将 known_reg 的 id 复制到 reg，例如：known_reg = reg ;known_reg 和 reg 获得相同的 ID known_reg += 4 ;known_reg 脱机 = 4，当调用 sync_linked_regs（） 时，它的 id 现在会BPF_ADD_CONST，假设如下：
    如果 <known_reg >= 10，则 Goto PC+2 known_reg 的新边界将传播至 reg，但现在 reg 会从副本中BPF_ADD_CONST。这意味着如果创建另一个指向 reg 的链接，例如：another_reg = reg ;another_reg应获取 reg 的 id，但 assign_scalar_id_before_mov（） 发现 reg 上的 BPF_ADD_CONST 并为其分配了新 ID。
    由于 reg 现在已使用新 id，known_reg 到 reg 的链接已损坏。如果为 known_reg 找到新的边界，它们将不会传播到 reg。这可以在下一个提交中添加的 selftest 中看出： 0： （85） 调用 bpf_get_prandom_u32#7 ;R0=scalar（） 1： （57） r0 &= 255 ;
    R0=scalar（smin=smin32=0，smax=umax=smax32=umax32=255，var_off=（0x0; 0xff）） 2：（bf） r1 = r0 ;
    R0=scalar（id=1，smin=smin32=0，smax=umax=smax32=umax32=255，var_off=（0x0; 0xff）） R1=scalar（id=1，smin=smin32=0，smax=umax=smax32=umax32=255，var_off=（0x0; 0xff）） 3： （07） r1 += 4 ;
    R1=scalar（id=1+4，smin=umin=smin32=umin32=4，smax=umax=smax32=umax32=259，var_off=（0x0; 0x1ff）） 4： （a5） if r1 < 0xa goto pc+4 ;R1=scalar（id=1+4，smin=umin=smin32=umin32=10，smax=umax=smax32=umax32=259，var_off=（0x0;
    0x1ff）） 5： （bf） r2 = r0 ;R0=scalar（id=2，smin=umin=smin32=umin32=6，smax=umax=smax32=umax32=255） R2=scalar（id=2，smin=umin=smin32=umin32=6，smax=umax=smax32=umax32=255） 6：（a5） 如果 r1 < 0xe转到 pc+2 ;
    R1=scalar（id=1+4，smin=umin=smin32=umin32=14，smax=umax=smax32=umax32=259，var_off=（0x0; 0x1ff）） 7： （35） if r0 >= 0xa goto pc+1 ;R0=scalar（id=2，smin=umin=smin32=umin32=6，smax=umax=smax32=umax32=9，var_off=（0x0;
    0xf）） 8： （37） r0 /= 0 除以零 验证 4 时，r1 的边界会传播至 r0，但 r0 也会BPF_ADD_CONST（缺陷）。当验证 5 时，r0 会获得一个新 id （2） 并且它与 r1 的链接被破坏。在 6 之后，我们知道 r1 有边界 [14， 259]，因此 r0 应该有边界 [10， 255]，因此总是采用 7 处的分支。但由于 r0 的 id 已更改为 2，r1 的新边界不会传播到 r0。校验器仍然认为 r0 在 7 之前具有边界 [6， 255]，并且执行可以达到零的 div。通过在 sync_linked_regs（） 中保留 id（如 off 和 subreg_def）来修复此问题。（CVE-2026-45933）

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

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

  - thermal/of：修复 thermal_of_cm_lookup（） 中的引用泄漏 在 thermal_of_cm_lookup（） 中，tr_np通过 of_parse_phandle（） 获得，但从未发布。使用 __free（device_node） cleanup 属性可自动释放节点并修复泄漏。[ rjw： 变更日志编辑 ]（CVE-2026-45925）

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

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

  - mtd：intel-dg：修复设置 nregions 之前的访问区域问题 区域数组由 nregions 计数，但仅在访问后才进行设置：[] UBSAN： array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c：750：15 [] 索引 0 超出类型“<unknown> [*]”的范围 通过修复一项意外行为修复该问题：循环静默忽略 ENOMEM 并继续设置其他条目。（CVE-2026-45896）

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

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

  - scsi：smartpqi：修复 pqi_report_phys_luns（） 中的内存泄漏 pqi_report_phys_luns（） 在遇到不受支持的数据格式或rpl_16byte_wwid_list分配失败时无法释放rpl_list缓冲区。这些过早返回可绕过清除逻辑，从而导致内存泄漏。
    通过添加 out_free_rpl_list 标签合并错误处理，并使用 goto 语句确保在发生故障时一致释放rpl_list。仅经过编译测试。使用原型静态分析工具和代码审查时发现的问题。（CVE-2026-45872）

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

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

  - crypto：caam - 修复 dpaa2_caam_probe 中的 netdev 内存泄漏 提交 0e1a4d427f58（crypto：caam：在 dpaa2 中取消嵌入net_dev结构）将嵌入net_device转换为动态分配的指针时，它会在 dpaa2_dpseci_disable（） 中添加清理，但缺少在 dpaa2_dpseci_free（） 中添加针对错误路径的清理。当 dpaa2_dpseci_dpio_setup（） 在探测期间失败时，由于 DPIO 设备尚未准备就绪，这会导致内存泄漏。内核的延迟探测机制成功地处理了重试，但在尝试探测失败期间分配的 netdevs 永远不会得到释放，从而导致 kmemleak 报告显示多个被泄漏的 netdev 相关分配，这些分配全部追溯到 dpaa2_caam_probe（）。通过在设置期间保留已分配 netdev 的 CPU 掩码并将其用于 dpaa2_dpseci_free（） 中的清除，来修复此问题。此方法可确保仅清理实际分配了 netdevs 的 CPU，避免 CPU 热插拔情况的潜在问题。（CVE-2026-45900）

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

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

  - net：访问转发路径数组时删除WARN_ON_ONCE 尽管不太可能，但如果用户空间设法构建足够长的转发路径，最近对 IPIP 隧道的支持会增加到达此WARN_ON_ONCE的机会。将其删除。（CVE-2026-45847）

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

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

  - net/mlx5e：修复 devlink 与 netdev 实例锁定之间的死锁 在上述 Fixes 提交中，将触发 devlink 运行状况报告者恢复的各种工作任务切换为使用 netdev_trylock 来防止同时发生正在恢复的通道中断。但这会产生引入潜在死锁的副作用，这是因为锁定顺序错误所致。init 流描述了正确的锁定顺序：probe_one -> mlx5_init_one（获取 devlink 锁定）-> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev（获取 rtnl 锁定）-> register_netdevice（获取 netdev 锁定）=> devlink lock -> rtnl 锁定 -> netdev 锁定。但在当前恢复流中，顺序是错误的：mlx5e_tx_err_cqe_work（获取 netdev 锁定）
    -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report （获得 devlink lock => boom！） -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover 在以下情况中也存在同样的情况：
    mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout 通过将工作处理程序中的工作处理程序中的 netdev_trylock 调用移动到调用堆栈较低层的相应恢复函数中来修复这些问题，这些调用实际上需要这些调用。（CVE-2026-45907）

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

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

  - RDMA/rxe：修复 QP 定时器处理程序中的争用条件 I 接收了以下警告： 警告：
    drivers/infiniband/sw/rxe/rxe_task.c：249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe]， CPU#0： swapper/0/0 ...
    libsha1 [上次卸载：ip6_udp_tunnel] CPU：0 UID：0 PID：0 Comm：swapper/0 受感染：G C 6.19.0-rc5-64k-v8+ #37 PREEMPT 受感染：[C]=CRAP 硬件名称：Raspberry Pi 4 Model B Rev 1.2 调用跟踪：
    rxe_sched_task+0x1c8/0x238 [rdma_rxe] （P） retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0
    __run_timers+0x630/0x888 ... WARNING： drivers/infiniband/sw/rxe/rxe_task.c：38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe]， CPU#0： swapper/0/0 ... 警告：
    drivers/infiniband/sw/rxe/rxe_task.c：111 at do_work+0x488/0x5c8 [rdma_rxe]， CPU#3： kworker/U17：4/93400 ...
    refcount_t：下溢;释放后使用。WARNING： lib/refcount.c：28 at refcount_warn_saturate+0x138/0x1a0， CPU#3： kworker/u17：4/93400 该问题是由 retransmit_timer（） 和 rxe_destroy_qp 之间的争用条件导致计时器处理程序执行期间队列对 （QP） 的引用计数降至零。此警告似乎无害，因为 rxe_qp_do_cleanup（） 将刷新所有待定的定时器和请求。造成问题的流示例： CPU0 CPU1 retransmit_timer（） { spin_lock_irqsave rxe_destroy_qp（） __rxe_cleanup（） __rxe_put（） // qp->ref_count 减少到 0 rxe_qp_do_cleanup（） { if （qp->valid） { rxe_sched_task（） { WARN_ON（rxe_read（task->qp） <= 0）; } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } 通过添加调用，确保保留 QP 的引用计数并在计时器回调中检查其有效性使用后rxe_get（qp）和相应的rxe_put（qp）。（CVE-2026-45910）

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

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

  - PCI/P2PDMA：当 vm_insert_page（） 失败时释放 per-CPU pgmap ref 当 vm_insert_page（） 在 p2pmem_alloc_mmap（） 中失败时，p2pmem_alloc_mmap（） 不会调用 percpu_ref_put（） 来释放在 gen_pool_alloc_owner（） 之后获取的 pgmap 的每 CPU ref，并且当尝试删除 PCI 设备时，memunmap_pages（） 将永远挂起。通过添加缺失的 percpu_ref_put（） 修复它。（CVE-2026-45880）

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (RDMA/iwcm: Simplify cm_event_handler()) changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP:
    0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS:
    00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08:
    0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12:
    ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] <TASK> [151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] </TASK> (CVE-2026-45898)

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

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

  - sound：ua101：修复探测时的除以零问题 为 detect_usb_format（） 中的 bNrChannels 添加缺少的健全性检查，以防止 playback_urb_complete（） 和 capture_urb_complete（） 中的除以零。
    USB 核心不会验证 bNrChannels 等类特定的描述符字段，因此驱动程序必须在使用前对其进行验证。如果设备提供 bNrChannels = 0，frame_bytes 会变为零，并稍后在 URB 完成处理程序中用作除数，从而导致内核崩溃。（CVE-2026-46184）

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

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

  - 用于 Perl 的 _001 之前 0.088的 CryptX 版本在四个 AEAD decrypt_verify帮助程序中存在堆栈缓冲区溢出。gcm_decrypt_verify、ccm_decrypt_verify、chacha20poly1305_decrypt_verify 和 eax_decrypt_verify XS 例程会将调用程序提供的认证标签复制到固定的 144 字节堆栈缓冲区 （MAXBLOCKSIZE） 中，而未检查提供的长度。较长的标签会覆盖经过缓冲区的堆栈。Version 0.088 将该钳子添加到 gcm_decrypt_verify， 0.088而 _001 将其添加到其他三个钳子中。
    受影响帮助程序的任何调用方转发受攻击者控制的标记的时间超过缓冲区时间，都可触发溢出。（CVE-2026-41565）

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

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

  - Bluetooth： virtio_bt：验证 rx pkt_type 标头长度 virtbt_rx_handle（） 从 RX skb 读取前导 pkt_type 字节并将剩余的字节转发到每种 event/ACL/SCO/ISO 类型的 hci_recv_frame（），但未检查剩余负载是否至少为该类型的固定 HCI 标头。在上述修补程序将后端提供的 used.len 限制为 [1， VIRTBT_RX_BUF_SIZE] 之后，在 skb->len 已拉至 0 的情况下，一字节完成仍会达到 hci_recv_frame（）。如果该字节刚好HCI_ACLDATA_PKT，则每当 HCI 设备具有活动的 CIS_LINK、BIS_LINK 或 PA_LINK 连接，读取两个字节的未初始化 RX 缓冲区数据时，hci_dev_classify_pkt_type（） 中的 ACL-vs-ISO 分类快速路径就会取消引用 hci_acl_hdr（skb）->handle。驱动程序接受的每种数据包类型都存在相同的危险，这是因为 virtbt_rx_handle（） 中的任何交换机案例都未针对每种类型的最小 HCI 标头大小检查 skb->len，然后再将帧传递到核心。剥离pkt_type后，要求 skb->len 在调用 hci_recv_frame（） 之前覆盖所选类型（事件 2、ACL 4、SCO 3、ISO 4）的固定标头大小;否则终止 ratelimited。未知pkt_type值仍采用原始 kfree_skb（） 默认路径。使用 bt_dev_err_ratelimited（），因为长度值和pkt_type值都来自不受信任的后端，否则可淹没内核日志。（CVE-2026-46186）

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

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

  - scsi：mpt3sas：将 NVMe 请求大小限制为 2 MiB HBA 固件根据底层驱动器功能报告 NVMe MDTS 值。但是，由于驱动程序为 PRP 列表分配固定的 4K 缓冲区（最多可容纳 512 个条目），因此驱动程序支持的最大 I/O 传输大小为 2 MiB。将max_hw_sectors限制为报告的 MDTS 和 2 MiB 驱动程序限制（以较小者为准），以防止发出可能导致内核 oops 的过大 I/O。（CVE-2026-46105）

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

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

  - Erlang OTP public_key（pubkey_cert 模块）中的证书信任链错误遵循漏洞允许接受非 CA 证书作为中间颁发者，从而允许证书链伪造。在 lib/public_key/src/pubkey_cert.erl 中，pubkey_cert：validate_extensions/7 包含两个缺陷，共同允许具有 basicConstraints cA：false 且无 keyUsage 扩展的证书用作传递到 public_key：pkix_path_validation/3 的链中的中间颁发者：cA：false 子句递归到其余扩展，而不会在证书处于颁发者位置时拒绝证书， 并且仅当存在扩展时才会触发 keyUsage 检查，因此缺少 keyUsage 的证书完全绕过 keyCertSign 强制执行。持有受害者信任存储中的任何 CA 颁发的具有 basicConstraints cA：false 且无 keyUsage 扩展的实体终止实体证书的任何一方均可使用该证书的私钥为任意身份签署伪造的叶证书。
    public_key：pkix_path_validation/3 接受生成的链，进而影响在依赖默认验证程序的 OTP ssl 应用程序上构建的每个 TLS 或 mTLS 端点，包括客户端的服务器身份验证和 mTLS 服务器上的客户端证书验证。此问题影响来自 OTP 17.0 的 OTP，而不是 OTP 26.2.5.21、 、 28.5.0.129.0.1 和 27.3.4.12，并且对应于之前 1.15.1.7、 和 1.20.3.11.17.1.31.21.1中的 public_key0.22。（CVE-2026-42789）

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

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

  - 已修复 Linux 内核中的下列漏洞：block: add pgmap check to biovec_phys_mergeable biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps. (CVE-2026-46115)

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

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

  - drm/amdgpu/vcn4：阻止解析 IB 时的 OOB 读取 重写 IB 解析以使用 amdgpu_ib_get_value（） 处理边界检查。（CVE-2026-46204）

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

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

  - drm/xe：修复分配失败时 xe_dma_buf_init_obj（） 中的 bo 泄漏 当 drm_gpuvm_resv_object_alloc（） 失败时，不会释放预分配的存储 bo。返回错误前添加 xe_bo_free（storage）。
    xe_dma_buf_init_obj（） 调用 xe_bo_init_locked（），这会在发生错误时释放 bo。因此，xe_dma_buf_init_obj（） 还必须释放其自身错误路径上的 bo。否则，由于 xe_gem_prime_import（） 无法区分失败是源自 xe_dma_buf_init_obj（） 还是源自 xe_bo_init_locked（），因此无法安全地决定是否应释放 bo。添加记录所有权语义的注释：
    成功后，存储的所有权将转移给返回的drm_gem_object;失败时，会在返回前释放存储。v2：添加注释以解释释放逻辑。（从提交 78a6c5f899f22338bbf48b44fb8950409c5a69b9 中精选出的内容）（CVE-2026-46224）

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

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

  - ipmi：添加对事件的限制和接收消息请求 驱动程序将只会获取事件并接收消息，直到 BMC 表示完成为止。要避免 BMC 出现从未表示已完成的问题，请添加一次提取 10 次的限制。此外，si 接口具有它可以从硬件返回的 attn 状态，该状态应该会导致标记获取以查看驱动程序是否需要获取事件或消息或其他一些内容。如果 attn 位卡住，则是类似的问题。因此允许在标记提取之间存在消息，这样驱动程序本身就不会卡住。与之前针对特定错误 BMC 的补丁相比，这是更通用的补丁，但应能够修复 BMC 中更普遍的问题，即 BMC 不会停止声称自己有数据。这从驱动程序的一开始就存在。其本身不是缺陷，但它正在解释 BMC 中的缺陷。（CVE-2026-46177）

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

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

  - KVM：arm64：修复 __pkvm_init_vcpu（） 中的引脚泄漏和发布顺序 vCPU 初始化路径中存在两个缺陷：1.如果 hyp_pin_shared_mem（） 成功后检查失败，则清除路径将跳至“解锁”而不调用 unpin_host_vcpu（） 或 unpin_host_sve_state，从而在主机 vCPU 和 SVE 状态页面上永久泄漏引脚引用。提取执行检查和存储的 register_hyp_vcpu（） 帮助程序。当 register_hyp_vcpu（） 返回错误时，在转向现有的“unlock”标签之前，内联调用 unpin_host_vcpu（） 和 unpin_host_sve_state（）。2. register_hyp_vcpu（） 将新的 vCPU 指针发布到具有裸存储的“hyp_vm->vcpus[]”中，从而允许 pkvm_load_hyp_vcpu（） 的并行调用方观察部分初始化的 vCPU 对象。确保存储使用 smp_store_release（） 并且加载使用 smp_load_acquire（）。虽然“vm_table_lock”当前对存储和负载进行序列化，但即使存在无锁路径或锁定自身的排序保证不足以进行嵌套对象初始化，这些屏障也能确保阅读器看到完全初始化的“hyp_vcpu”对象。（CVE-2026-46147）

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

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

  - libceph：修复认证消息处理中的 slab-out-of-bound 访问 如果 CEPH_MSG_AUTH_REPLY 类型的（可能损坏的）消息的结果字段中包含正值，则 ceph_handle_auth_reply（） 会将其视为错误代码并返回给 handle_auth_reply（）。此后，尝试发送预分配的 CEPH_MSG_AUTH 类型的消息，其中返回值被解释为要发送的前段的大小。如果消息中的结果值大于为前段分配的内存缓冲区大小，则会发生越界访问，并且超出此缓冲区的内存区域的内容被发送出去。此修补程序通过将结果字段中的负值仅视为错误来修复此问题。因此，正值被视为成功的方式与零值相同。
    此外，已向 __send_prepared_auth_request（） 添加了一个BUG_ON，将 len 参数与 front_alloc_len 进行比较，以便在消息超出分配边界时防止发送消息，并更容易捕获导致此消息的任何逻辑缺陷。（CVE-2026-46119）

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

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

  - Erlang OTP public_key（pubkey_cert 和 public_key 模块）中的不当证书验证漏洞允许通过 TLS 主机名验证中的主题 CommonName 回退绕过 DNS nameConstraints。
    两个缺陷结合在一起，允许 DNS nameConstraints 受到限制的从属 CA（例如
    允许的;DNS:allowed.example.com） 若要发行叶证书，OTP TLS 客户端接受该证书作为超出范围主机名（例如 victim.example.com）的有效身份： 首先，lib/public_key/src/pubkey_cert.erl 中的 pubkey_cert：validate_names/6 仅针对 nameConstraints 检查 SAN DNS 条目。根据 RFC 5280，允许的 DNS 子树仅限制包含 DNS 类型名称的证书。因此，没有 subjectAltName 的叶子可以轻易满足任何允许的条件;DNS：...约束，而不考虑其主题 commonName。其次，lib/public_key/src/public_key.erl 中的 public_key：pkix_verify_hostname/3 在不存在 subjectAltName 时回退到主题 commonName，从而提取 id-at-commonName 属性作为提供的 ID 并将它们与引用主机名进行匹配。严格的 pkix_verify_hostname_match_fun（https） 匹配程序不会禁止此回退。结果是，路径验证接受 DNS 受限的中间分支下的仅限 CN 的叶（无 SAN 意味着不触发 nameConstraints），然后主机名验证通过 CN 回退接受它。通过 verify_peer、受信任的 CA、SNI 和规范的严格 https 主机名匹配程序，可从库存 ssl：connect 访问此绕过。此问题影响来自 OTP 19.3 的 OTP，而不是 OTP 26.2.5.21、 、 28.5.0.129.0.1 和 27.3.4.12，并且对应于之前 1.15.1.7、 和 1.20.3.11.17.1.31.21.1中的 public_key1.4。（CVE-2026-42790）

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

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

  - f2fs：修复节点块的 FGGC 导致的 fsck 不一致 在 FGGC 节点块迁移过程中，fsck 可能会将迁移的节点块错误地视为 fsync 写入的数据。再现场景：
    root@vm：/mnt/f2fs# seq 1 2048 |xargs -n 1 ./test_sync // 写入内联 inode 和同步 root@vm：/mnt/f2fs# rm -f 1 root@vm：/mnt/f2fs# 同步 root@vm：/mnt/f2fs# f2fs_io gc_range // 在同步模式下移动数据块且不写入 CP SPO，fsck --dry-run 发现 inode 已检查点但仍DENT_BIT_SHIFT 根本原因是 GC 在节点块迁移过程中未清除 dentry 标记和 fsync 标记， 导致 fsck 将其误解释为用户发布的 fsync 写入。在 BGGC 模式下，节点块迁移由 f2fs_sync_node_pages（） 处理，可保证在写入前清除 dentry 和 fsync 标记。
    此修补程序将 fsync|dentry 标记的 set/clear 移至 __write_node_folio，使逻辑更清楚，并确保 fsync|dentry 标记在 FGGC 中得到清除。（CVE-2026-46175）

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

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

  - hfsplus：通过验证目录记录大小修复 uninit-value Syzbot 报告了 hfsplus_strcasecmp（） 中的一个 KMSAN uninit-value 问题。根本原因是 hfs_brec_read（） 未验证磁盘上的记录大小是否匹配正在读取的记录类型的预期大小。当挂载损坏的文件系统时，hfs_brec_read（） 读取的数据可能少于预期。例如，读取目录线程记录时，调试输出显示：HFSPLUS_BREC_READ：rec_len=520，fd->entrylength=26 HFSPLUS_BREC_READ：警告 - entrylength （26） < rec_len （520） - 部分读取！hfs_brec_read（） 仅验证 entrylength 是否不大于缓冲区大小，但不会检查其是否小于预期。它成功将 26 字节读入 520 字节结构并返回成功，494 字节未初始化。然后 tmp.thread.nodeName 中的此未初始化数据由 hfsplus_cat_build_key_uni（） 复制并由 hfsplus_strcasecmp（） 使用，从而在未初始化的字节在 case_fold（） 中用作数组索引时触发 KMSAN 警告。通过引入 hfsplus_brec_read_cat（） 封装程序进行修复：1. 调用 hfs_brec_read（） 以读取数据 2.根据类型字段验证记录大小：- 文件夹和文件记录的固定大小 - 线程记录的可变大小（取决于字符串长度） 3.如果大小与预期不匹配，则返回 -EIO 对于线程记录，在读取 nodeName.length 之前检查HFSPLUS_MIN_THREAD_SZ，以避免在未对条目结构进行零初始化的调用站点读取未初始化的数据。此外，将 hfsplus_find_cat（） 中的 tmp 变量初始化为防御性编程，确保即使在绕过验证的情况下也不会有未初始化的数据。（CVE-2026-46169）

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

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

  - spi：cadence-quadspi：修复取消绑定时的非时钟访问 确保在驱动程序取消绑定期间禁用控制器之前已恢复运行时，以避免非时钟寄存器访问。Sashiko 在查看控制器注销补丁时标记了此问题。（CVE-2026-46203）

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

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

  - KVM：x86：修复了由于非预期 GFN 导致的阴影分页释放后使用问题 阴影 MMU 使用 sp->gfn 和 SPTE 索引计算直接阴影页面的 GFN。如果在 VM 条目之间修改了客户机页表，则阴影分页会破坏此假设（类似于提交 aad885e77496，KVM：x86/mmu：创建 MMIO SPTE 时，删除/清除现有的 SPTE，2026 年 3 月 27 日）。流程如下：- 为 2MB 映射安装 PDE，并访问该区域中的页面。KVM 创建包含 512 个 4KB 页面的kvm_mmu_page;由于客户机的映射是一个巨大的页面（因此是连续的），因此 FNAME（fetch） 将kvm_mmu_page标记为直接映射。- 从客户机外部更改 PDE 映射。- 客户机访问同一 2MB 区域中的另一个页面。KVM 安装新叶 SPTE 和 rmap 条目;SPTE 使用正确的 GFN（即基于新映射，在上一步中更改），但该 GFN 超出 [sp->gfn， sp->gfn + 511] 范围;因此，在 zapped kvm_mmu_page 时无法找到和删除 rmap 条目。- 覆盖前 2MB 映射的内存插槽将被删除，并且当前无效的 GPA 的kvm_mmu_page将被删除。但是，rmap_remove（） 仅查看在步骤 1 中建立的 [sp->gfn， sp->gfn + 511] 范围，而找不到步骤 3 记录的 rmap 条目。- 导致 RMAP 遍历（针对步骤 3 访问的相同页面）的任何操作，随后会遍历过时的 rmap 并取消引用已释放的kvm_mmu_page。这包括脏日志记录或 MMU 通知程序无效（例如来自 MADV_DONTNEED）。潜在的问题是，KVM 的影子 PTE 遍历假设，如果 KVM 要安装非叶 SPTE 时存在 SPTE，则现有kvm_mmu_page必须用于正确的 gfn。因为 gfn 出错的唯一途径是 KVM 搞砸并无法清除 SPTE...这不应该发生，但是
    *实际上*仅在对客户机写入的响应中发生。这个缺陷从字面上可以永远追溯到以前，因为即使是 KVM 的第一个版本也假设 GFN 匹配并进入错误的阴影页面。然而，这只是一个不精确问题，直到 2032a93d66fa（KVM：MMU：请勿为直接的 mmu 页面分配 gfns 页面）出现。通过检查目标 gfn 是否不匹配并清除现有 SPTE 修复此问题。这样，旧的 SP 和 rmap 条目就消失了，KVM 会将 rmap 安装在正确的位置，大家会很高兴。
    (CVE-2026-46113)

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

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

  - RDMA/hns：修复对 hns_roce_qp_remove（） 的未锁定调用 Sashiko 指出，hns_roce_qp_remove（） 需要调用程序保持锁定。hns_roce_create_qp_common（） 中的错误流不会为错误展开保留这些锁，因此有损坏内存的风险。获取其他两个调用程序使用的相同锁定。
    (CVE-2026-46112)

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

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

  - nvmet-tcp：修复了 ICReq 处理与队列拆除之间的竞争条件。nvmet_tcp_handle_icreq() 在发送初始化连接响应（ICResp）后会更新 queue->state，但此操作未与目标端队列拆除进行串行化。如果 NVMe/TCP 主机发送了一个初始化连接请求（ICReq）并立即关闭连接，那么在 io_work 处理完已缓冲的 ICReq 之前，目标端可能已在软中断上下文中开始断开连接。在这种情况下，nvmet_tcp_schedule_release_queue() 会将 queue->state 设置为 NVMET_TCP_Q_DISCONNECTING，并释放 state_lock 下的队列引用。如果io_work以后处理该 ICReq，nvmet_tcp_handle_icreq（） 仍可将状态改写回 NVMET_TCP_Q_LIVE。
    这会绕过 nvmet_tcp_schedule_release_queue() 中的 DISCONNECTING 状态守护机制，从而允许后续的套接字状态变更重新进入拆卸流程，并对一个已被释放的队列再次调用 kref_put()。ICResp 发送失败路径也有同样的问题。如果拆卸已将队列移至 DISCONNECTING，发送错误仍可通过 NVMET_TCP_Q_FAILED 覆盖状态，并再次重新打开第二个拆卸路径的窗口，从而删除队列引用。通过使用 state_lock 序列化发送后状态转换并撤离（如果已开始拆卸），修复此问题。将 -ESHUTDOWN 用作该 bail-out 路径的内部哨兵，而不是将其传播为 -ECONNRESET 之类的传输错误。将 nvmet_tcp_socket_error（） 设置rcv_state保留为 NVMET_TCP_RECV_ERR，然后再接受该 sentinel，这样接收端解析就会保持静止状态，直到现有版本路径完成。（CVE-2026-46135）

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

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

  - Bluetooth：virtio_bt：在 skb_put virtbt_rx_work（） 调用 skb_put（skb， len） 之前钳制 rx 长度，其中 len 直接来自 virtqueue_get_buf（），且未针对发布到设备的缓冲区进行验证。RX skb 在 virtbt_add_inbuf（） 中分配，并通过 sg_init_one（） 正好作为 1000 字节暴露给 virtio。
    针对 skb_tailroom（skb） 检查 len 是不够的，因为 alloc_skb（） 可能预留比实际传递给设备的 1000 字节更多的尾部空间。因此，恶意或有缺陷的后端可在 1001 到 skb_tailroom（skb） 之间报告 used.len，从而导致 skb_put（） 包含设备从未写入的未初始化内核堆字节。同一路径也接受 len == 0，在这种情况下，skb_put（skb， 0） 会将 skb 留空，但 virtbt_rx_handle（） 仍然从 skb->data 读取 pkt_type 字节，从而消耗未初始化的内存。定义一次 VIRTBT_RX_BUF_SIZE 并在 alloc_skb（） 和 sg_init_one（） 中复用，然后在同一常量上保护 virtbt_rx_work（），以便检查的边界与实际暴露给设备的缓冲区匹配。拒绝同一门中的 used.len == 0，这样空完成就无法再访问 virtbt_rx_handle（）。使用 bt_dev_err_ratelimited（），因为长度值来自不受信任的后端，否则可淹没内核日志。与提交 c04db81cd028 相同类别的缺陷（net/9p：修复 USB 传输层中的缓冲区溢出），针对未经检查的设备报告长度增强 USB 9p 传输。（CVE-2026-46123）

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

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

  - ipv6：xfrm6：在 xfrm6_rcv_encap（） 中出错时释放 dst xfrm6_rcv_encap（） 在 skb 尚未附加 dst 时执行 IPv6 路由查找。即使查找解析为错误路由，ip6_route_input_lookup（） 仍会返回引用的 dst 条目。如果设置了 dst->error，则 xfrm6_rcv_encap（） 在不将 dst 附加到 skb 且不释放查找返回的引用的情况下删除 skb。因此，重复命中此路径的数据包会泄露 dst 条目。跳转到放置路径之前释放 dst。
    (CVE-2026-46172)

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

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

  - wifi：brcmfmac：修复停止监视程序任务时潜在的释放后使用问题 监视程序任务可能在 send_sig（） 和 kthread_stop（） 调用之间结束，从而导致释放后使用问题。通过在调用 send_sig（） 之前增加监视程序任务引用计数并通过切换到 kthread_stop_put（） 将其丢弃来修复此问题。（CVE-2026-46180）

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

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

  - 以前在 OpenStack Keystone 中 29.0.2发现了一个问题。Keystone 应用程序凭据认证插件未验证认证请求中提供的用户是否匹配应用程序凭据的所有者。攻击者可使用其自己的应用程序凭据 ID 和密码进行身份验证，同时在请求正文中指定不同用户的名称和域。Keystone 会发出归因于受害者用户的标记。假冒的令牌是项目范围的，并且带有应用程序凭据角色和受害者在项目中的实际角色的交集。这将实现审计逃避、读取受害者的凭据以及在共享项目中充当受害者。
    (CVE-2026-42998)

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

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

  - RDMA/rxe：在 ICRC 处理之前拒绝未知操作码 即使在应用提交 7244491dab34 之后（RDMA/rxe：在 rxe_rcv 中的 payload_size（） 之前验证 pad 和 ICRC），单一未经认证的 UDP 数据包仍可触发错误。该修补程序仅处理包含短数据包的有效操作码的 payload_size（） 下溢，而不处理携带未知操作码的数据包的下溢。下述未知操作码 OOB 读取早于提交，并且可以追溯到初始软 RoCE 驱动程序。此处添加的检查为 pkt->paylen < header_size（pkt） + bth_pad（pkt） + RXE_ICRC_SIZE，其中 header_size（pkt） 扩展为 rxe_opcode[pkt->opcode].length。数 rxe_opcode[] 组有 256 个条目，但仅填充定义的 IB 操作码;任何其他条目（例如操作码 0xff）都是零初始化的，因此长度 == 0，检查退化为 pkt->paylen < 0 + bth_pad（pkt） + RXE_ICRC_SIZE，这对 pkt->paylen 的限制不充分。
    然后，rxe_icrc_hdr（） 计算 rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES，当长度 == 0 时下溢并将大值传递给 rxe_crc32（），从而导致 skb 负载的越界读取。在应用了该补丁的 v7.0-rc7 上重现，具有 CONFIG_RDMA_RXE=y 和 CONFIG_KASAN=y 的 QEMU/KVM，在 rdma 链接之后添加 rxe0 类型 rxe netdev eth0 使用 BTH opcode=0xff 和 QPN=IB_MULTICAST_QPN 触发指向端口 4791 的单一 48 字节 UDP 数据包： 缺陷：KASAN：crc32_le+0x115/0x170 中的 slab-out-of-bound 地址处的读取大小为 1 ... 有缺陷的地址位于分配的 704 字节区域右侧的 0 字节处 调用跟踪：
    crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 具有相同形状的后续数据包会在未映射内存上发生错误，并造成内核错误。触发器只需要模块加载和 rdma 链接添加;
    无 QP，无连接，也无认证。通过在任何长度算术运行之前，拒绝通过零掩码或零长度检测到的 opcode 没有 rxe_opcode[] 条目的数据包来修复此问题。
    (CVE-2026-46133)

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

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

  - usb：usblp：修复通过 LPGETSTATUS ioctl 导致的未初始化堆泄漏 正如此驱动程序中的上一个问题一样，usblp_ctrl_msg（） 会将 usb_control_msg（） 返回值折叠为 0/-errno，并放弃实际传输的字节数。理想情况下，应该检测到该简短命令并出错，但众所周知，许多打印机会发回不正确的响应，因此我们不能直接这样做。在探测时 statusbuf 为 kmalloc（8），在第一个 LPGETSTATUS ioctl 之前从未填充。usblp_read_status（） 请求 1 字节。如果恶意打印机以零字节进行响应，则 *statusbuf 为过时 kmalloc 堆的一个字节，符号扩展为本地 int 状态，LPGETSTATUS 路径随后直接将其copy_to_user（）给 ioctl 调用程序。
    只需在探测时分配内存缓冲区时删除内存缓冲区，即可修复所有这些问题。如果稍后的调用进行短读取，则数据将与设备上次发送的数据相同，因此不会出现信息泄漏。（CVE-2026-46167）

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

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

  - RDMA/mlx4：修复 mlx4_ib_create_srq（） 中出错时的资源泄漏 Sashiko 指出，错误展开期间未撤消 mlx4_srq_alloc（），因此将缺少的调用添加到 mlx4_srq_free（）。（CVE-2026-46178）

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

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

  - ASoC：qcom：q6apm-lpass-dai：修复多个图形打开 由于 prepare 可调用多次，这可导致作为回放路径打开多个图形。这将导致内存泄漏，请通过在打开前添加检查来修复此问题。（CVE-2026-46143）

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

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

  - eventfs：重新挂载遍历事件时保持 eventfs_mutex 和 SRCU 提交 340f0c7067a9（eventfs：更新事件描述符中的所有eventfs_inodes）在重新挂载时通过 ei->children 递归 eventfs_set_attrs（）。遍历仅保留 tracefs_apply_options（） 通过 tracefs_inodes 获取的 rcu_read_lock（），这是错误的：- ei->children 上的list_for_each_entry与 eventfs_remove_rec（） 中的 list_del_rcu（） 争用 -- LIST_POISON1 deref，与 d2603279c7d6 的形状相同。- 通过 call_srcu（&eventfs_srcu， ...） 释放eventfs_inodes。rcu_read_lock（） 不会延长 SRCU 宽限期，因此可在遍历下回收 ti->private。- 对 ei->attr 的写入与持有eventfs_mutex的 eventfs_set_attr（） 争用。复制：while ：;do mount -o remount，uid=$((RANDOM%1000)） /sys/kernel/tracing;完成 &; while ：;do echo p：kp submit_bio > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done 将 tracefs_apply_options（） 的事件部分封装在采用 eventfs_mutex 和 srcu_read_lock（&eventfs_srcu） 的 eventfs_remount_lock（）/_unlock（） 中。
    eventfs_set_attrs（） 不休眠，因此嵌套的 rcu_read_lock（） 没问题;lockdep_assert_held（） 固定合约。tracefs_drop_inode（） 中的评论说 RCU 周期 -- 它是 SRCU。（CVE-2026-46106）

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

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

  - ipmi：si：如果消息分配失败则恢复正常状态 有些地方如果消息分配失败则无法启动任何操作，因此驱动程序需要返回到正常状态。（CVE-2026-46108）

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

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

  - batman-adv：在网格拆除期间停止 tp_meter 会话 在 netlink 请求完成之后，TP 计量器会话仍会在 bat_priv->tp_list 上保持链接。当删除网格界面时，batadv_mesh_free（） 当前会在不首先耗尽这些会话的情况下去除网格。然后，运行中的发送方线程或迟到的传入 tp_meter 数据包可继续针对已经关闭的网格实例进行处理。通过停止来自 batadv_mesh_free（） 的所有活动会话并等待发送方线程退出然后继续拆卸，将 tp_meter 与网格生命周期同步。（CVE-2026-46208）

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

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

  - mm/damon/sysfs-schemes：通过 damon_sysfs_lock 修补程序系列保护 kfree（） memcg_path mm/damon/sysfs-schemes：修复 [memcg_]path 的释放后使用。在 DAMON sysfs 接口中读取“memcg_path”和“path”文件可能与其写入争用，从而导致释放后使用。修复这些问题。此修补程序（共 2 个）：
    用户可通过 DAMON sysfs memcg_path文件读取和写入damon_sysfs_scheme_filter->mmecg_path。
    对于提交给 DAMON 的参数 {on，off}line，也可以间接读取此值。参数提交的读取受到damon_sysfs_lock保护，以免在读取任何参数时破坏 sysfs 文件。但是用户驱动的直接读写不受任何锁定保护，而写入则正在释放memcg_path指向缓冲区。因此，阅读器可读取已经释放的缓冲区（释放后使用）。请注意，由于 kernfs 的打开文件锁定，当写入器使用相同的打开文件时，用户读取不会发生争用。尽管如此，使用单独的打开文件进行读取和写入是很常见的。通过damon_sysfs_lock保护用户直接的读取和写入来修复此问题。（CVE-2026-46121）

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

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

  - drm/amdgpu/vcn4：解析 dec 消息时防止 OOB 读取 在访问消息时检查 BO 末尾的边界。 （CVE-2026-46199）

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

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

  - drm/amdgpu/sdma4：将 BUG_ON 替换为 隔离排放中的WARN_ON sdma_v4_0_ring_emit_fence（） 包含两个验证隔离回写地址是否与 DWORD 对齐的 BUG_ON（addr &; 0x3） 断言。可通过特制的 DRM_IOCTL_AMDGPU_CS 提交从无权限的用户空间访问这些断言，进而在计划程序工作线程中造成致命内核错误。将两个 BUG_ON（） 调用替换为 WARN_ON（），以在不导致内核崩溃的情况下记录情况。此时未对齐的隔离地址表示存在驱动程序缺陷，但当可从用户空间访问断言时，使内核崩溃绝不是正确的响应。CS IOCTL 路径是筛选无效提交的正确位置;环发射回调为时已晚，无法对此进行任何操作。（从提交 b90250bd933afd1ba94d86d6b13821997b22b18e 中精选出的内容）（CVE-2026-46220）

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

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

  - batman-adv：在拆卸期间拒绝新的 tp_meter 会话 防止tp_meter在mesh_state离开BATADV_MESH_ACTIVE后开始新的发送者或接收方会话。（CVE-2026-46206）

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

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

  - tracepoint：在 tracepoint_add_func（） 中 func_add（） 失败时平衡 regfunc（） 当跟踪点经历 0 -> 1 转换时，tracepoint_add_func（） 会调用子系统的 ext->regfunc（），然后再尝试通过 func_add（） 安装新的探测。如果 func_add（） 随后失败（例如，当 allocate_probes（） 无法在内存压力下分配新的探测数组并返回 -ENOMEM 时），该函数会在不调用相匹配的 ext->unregfunc（） 的情况下返回错误，从而留下 regfunc（） 的副作用，而没有安装探测来证明其合理性。对于 syscall 跟踪点，这尤其令人不快：syscall_regfunc（） 会在每项任务上升级sys_tracepoint_refcount并设置SYSCALL_TRACEPOINT。
    泄露失败之后，refcount 会停留在非零值且没有使用者，且每项任务都会继续支付 syscall 跟踪进入/退出开销，直到重新启动。提供 regfunc（）/unregfunc（） 对的其他子系统表现出类似范围的持久状态。镜像现有的 1 -> 0 清理并调用 func_add（） 错误路径中的 ext->unregfunc（），在使用该路径的相同条件下进行门控，以便展开与注册对称。（CVE-2026-46196）

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

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

  - RDMA/mana：修复 mana_ib_create_qp_rss（） 中的错误展开 Sashiko 指出 mana_ib_cfg_vport_steering（） 泄露，正常破坏路径将对其进行清理。（CVE-2026-46144）

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

ID	名称	严重性
317686	Linux Distros 未修补的漏洞：CVE-2026-45903	high
317685	Linux Distros 未修补的漏洞：CVE-2026-45863	medium
317684	Linux Distros 未修补的漏洞：CVE-2026-45911	medium
317683	Linux Distros 未修补的漏洞：CVE-2026-48863	high
317682	Linux Distros 未修补的漏洞：CVE-2026-48095	high
317681	Linux Distros 未修补的漏洞：CVE-2026-45933	high
317680	Linux Distros 未修补的漏洞：CVE-2026-45925	medium
317679	Linux Distros 未修补的漏洞：CVE-2026-45896	high
317678	Linux Distros 未修补的漏洞：CVE-2026-45872	medium
317677	Linux Distros 未修补的漏洞：CVE-2026-45900	medium
317676	Linux Distros 未修补的漏洞：CVE-2026-45847	medium
317675	Linux Distros 未修补的漏洞：CVE-2026-45907	medium
317674	Linux Distros 未修补的漏洞：CVE-2026-45910	high
317673	Linux Distros 未修补的漏洞：CVE-2026-45880	medium
317672	Linux Distros 未修补的漏洞：CVE-2026-45898	high
317648	Linux Distros 未修补的漏洞：CVE-2026-46184	medium
317647	Linux Distros 未修补的漏洞：CVE-2026-41565	high
317646	Linux Distros 未修补的漏洞：CVE-2026-46186	medium
317645	Linux Distros 未修补的漏洞：CVE-2026-46105	high
317644	Linux Distros 未修补的漏洞：CVE-2026-42789	high
317643	Linux Distros 未修补的漏洞：CVE-2026-46115	critical
317642	Linux Distros 未修补的漏洞：CVE-2026-46204	high
317641	Linux Distros 未修补的漏洞：CVE-2026-46224	medium
317640	Linux Distros 未修补的漏洞：CVE-2026-46177	high
317639	Linux Distros 未修补的漏洞：CVE-2026-46147	medium
317638	Linux Distros 未修补的漏洞：CVE-2026-46119	critical
317637	Linux Distros 未修补的漏洞：CVE-2026-42790	high
317636	Linux Distros 未修补的漏洞：CVE-2026-46175	high
317635	Linux Distros 未修补的漏洞：CVE-2026-46169	medium
317634	Linux Distros 未修补的漏洞：CVE-2026-46203	high
317633	Linux Distros 未修补的漏洞：CVE-2026-46113	high
317632	Linux Distros 未修补的漏洞：CVE-2026-46112	high
317631	Linux Distros 未修补的漏洞：CVE-2026-46135	critical
317630	Linux Distros 未修补的漏洞：CVE-2026-46123	high
317629	Linux Distros 未修补的漏洞：CVE-2026-46172	medium
317628	Linux Distros 未修补的漏洞：CVE-2026-46180	high
317627	Linux Distros 未修补的漏洞：CVE-2026-42998	high
317626	Linux Distros 未修补的漏洞：CVE-2026-46133	high
317625	Linux Distros 未修补的漏洞：CVE-2026-46167	medium
317624	Linux Distros 未修补的漏洞：CVE-2026-46178	high
317623	Linux Distros 未修补的漏洞：CVE-2026-46143	medium
317622	Linux Distros 未修补的漏洞：CVE-2026-46106	medium
317621	Linux Distros 未修补的漏洞：CVE-2026-46108	medium
317620	Linux Distros 未修补的漏洞：CVE-2026-46208	high
317619	Linux Distros 未修补的漏洞：CVE-2026-46121	high
317618	Linux Distros 未修补的漏洞：CVE-2026-46199	high
317617	Linux Distros 未修补的漏洞：CVE-2026-46220	medium
317616	Linux Distros 未修补的漏洞：CVE-2026-46206	high
317615	Linux Distros 未修补的漏洞：CVE-2026-46196	medium
317614	Linux Distros 未修补的漏洞：CVE-2026-46144	medium

检测

Nessus 的 Misc. 系列

high

medium

medium

high

high

high

medium

high

medium

medium

medium

medium

high

medium

high

medium

high

medium

high

high

critical

high

medium

high

medium

critical

high

high

medium

high

high

high

critical

high

medium

high

high

high

medium

high

medium

medium

medium

high

high

high

medium

high

medium

medium