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

  - iioimubno055修复 hw_xlate 数组的 OOB 访问 修复 bno055.c 中可能的 hw_xlate 数组越界数组访问。在 bno055_get_regmask() 中hw_xlate 在 vals 数组的长度而非 hw_xlate 数组的长度上迭代。就 bno055_gyr_scale 而言，vals 数组大于 hw_xlate 数组因此可导致越界访问。但在实践中不应发生这种情况因为应始终找到在迭代超出 hw_xlate 数组末尾之前中断 for 循环的匹配项。通过将新的 hw_xlate_len 字段添加到 bno055_sysfs_attr我们可以确保迭代正确的长度。 (CVE-2025-39719)

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

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

  - net, hsr如果 skb 无法容纳标签则拒绝 HSR 帧接收 HSR 帧其空间不足以在 skb 中容纳 HSR 标签可导致崩溃内核 BUG[ 45.390915] skbuff: skb_under_panic
    text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ 在此处剪切 ]-------- ------ [ 45.392912] 内核缺陷位于 net/core/skbuff.c:211! [ 45.393276] Oops无效的 opcode0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [45.393809] CPU: 1 UID: 0 PID: 2496 Comm重现器未受感染 6.15.0 #12 PREEMPT(undef) [ 45.394433] 硬件名称QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org04/01/2014 [ 45.395273] RIP0010:skb_panic+0x15b/0x1d0<snip registers, remove unreliable trace> [45.402911] 调用跟踪[ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483]
    __br_forward+0x42d/0x590 [ 45.409464]maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674]
    __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116]
    __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ> 此问题的发现者为 syzkaller。一旦收到线性数据中已推送 ETH 标头的损坏 skb就会在 br_dev_queue_push_xmit() 中发生错误。当尝试进行 skb_push() 调用时出现动态余量不足和 skb_push() 错误。损坏的 skb 由 HSR 层放入队列中从而在收到特定的损坏 HSR 帧具有不完整的 TAG时进行一系列意外转换。通过丢弃和消耗长度不足以同时包含以太网和 hsr 标头的帧来修复此问题。替代补丁是在 br_dev_queue_push_xmit() 中的 skb_push() 之前检查足够的余量。在重现器中这是通过 AF_PACKET 注入的但我无法轻易理解为何无法通过线路从邻近网络发送它。更多详细信息在重现器中设置了以下网络接口链veth0_to_hsr hsr_slave0 hsr0 veth1_to_hsr hsr_slave1 bridge ... 为触发导致崩溃的事件重现器会从损坏的 HSR 发送
    ---truncated--- (CVE-2025-39703)

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

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

  - netfilternf_reject不要泄漏环回数据包的 dst refcount用于在替换 skb dst 条目时添加 WARN() 的最新修补程序发现一个旧缺陷警告include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff。 h:1164 [inline] 警告include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline] 警告include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/ netfilter/nf_reject_ipv4.c:234 [..] 调用跟踪
    nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [内联] .. 这是因为被责备的提交忘记了环回数据包。即使在 PRE_ROUTING 阶段此类数据包也已经附加了 dst_entry。不检查挂钩而只检查 skb 是否已附加路由。 (CVE-2025-38732)

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

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

  - 在 libxml2 中可能因缓冲区溢出而导致越界读取。这可能导致本地信息泄露，且无需其他执行权限。无需用户交互即可利用漏洞。(CVE-2025-26434)

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

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

  - gve阻止关闭后的 ethtool 操作如果在调用 shutdown() 之后调用 ethtool 操作则可能发生崩溃。在系统关闭期间调用 shutdown() 以停止 DMA 操作而不执行成本昂贵的解除分配。不鼓励取消注册此路径中的 netdev因此该设备可能对用户空间和内核帮助程序仍可见。在 gve 中shutdown() 会破坏大多数内部数据结构。如果在 shutdown() 之后调度 ethtool 操作将会取消引用已释放的指针或空指针进而导致内核错误。虽然平稳关机通常会在调用重新启动 syscall 之前使用户空间处于静止状态但强制关机如 GCP VM 上所观察到仍可触发此路径。通过调用 shutdown() 中的 netif_device_detach() 进行修复。这会将设备标记为“已分离”以便 ethtool ioctl 处理程序将跳过对驱动程序的分派操作。 (CVE-2025-38735)

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

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

  - comedipcl726阻止无效的 irq 编号重现器传入太大的 irq 编号 (0x80008000)从而触发了 oob。添加了中断编号检查以防止用户传递过大的 irq 编号。如果“it->options[1]”为 31则“1 << it->options[1]”仍然无效因为它将 1 位移动到符号位C 中的 UB。可能的解决方案包括将“it->options[1]”值的上限降低到 30 或更低，或使用“1U << it->options[1]”。如果“options[1]”值无效旧代码不会尝试请求 IRQ。即使对“request_irq”的调用返回错误它仍会在不中断的情况下配置设备。因此最好将此测试与下面的测试结合起来。 (CVE-2025-39685)

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

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

  - smb服务器从 ksmbd_rdma_destroy() 拆分 ksmbd_rdma_stop_listening() 至无法调用 destroy_workqueue(smb_direct_wq)之前 stop_sessions()! 否则现有连接会尝试将 smb_direct_wq 用作空指针。 (CVE-2025-39692)

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

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

  - RDMA/rxe释放 RXE 资源时刷新延迟的 SKB 发出 skb 数据包时这些 skb 数据包仍然依赖于 rxe 资源例如 QP、sk 数据包被破坏时。如果在破坏 skb 数据包时释放这些 rxe 资源将出现调用跟踪。为避免 skb 数据包在某些网络设备中挂起时间过长创建这些 skb 数据包时会添加一个时间戳。如果这些 skb 数据包在网络设备中挂起时间过长这些网络设备可以释放这些 skb 数据包以释放 rxe 资源。 (CVE-2025-39695)

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

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

  - s390/ism修复 ism_cmd() 中的并发管理 s390x ISM 设备数据表明确指出每个 ISM 函数在任何时间点都仅允许一个请求-响应序列。遗憾的是截至目前Linux 中的 s390/ism 驱动程序尚未满足该要求。此修补程序旨在修正该问题。此问题是根据 Aliaksei 的缺陷报告发现的该报告指出对于某些工作负载ISM 函数最终会在一段时间后进入错误状态从日志中看到为 PEC 2因此由相应函数处理的连接中断并且考虑到 ISM 设备处于功能障碍状态，未来的连接请求将不考虑该设备。在进一步调试的过程中也发现了 PEC 3A。类似 [ 1211.244319] zpci: 061a:00:00.0: Event 0x2reports an error for PCI function 0x61a 的内核消息是 the 所述函数进入带有 PEC 2 的错误状态的可靠指标。还得指出像这样的内核消息[ 1211.244325] zpci: 061a:00:00.0绑定到设备的 ism 驱动程序不支持错误恢复是 ISM 函数不会自动恢复的可靠指标因为 ISM 驱动程序当前缺少对该函数的支持。在技术层面上，如果不进行此同步，命令（固件的输入）可能会被尝试对相同功能发出命令的另一 CPU 部分或全部覆盖（损坏）。有确实的证据表明这可导致 DMB 标记值被用作 DMB IOVA从而导致指示 DMA 无效的 PEC 2 PCI 事件。但是这只是可以想见的故障模式中的一种。理论上什至完全丢失一个命令并执行另一个命令两次然后尝试将输出解释为好像实际执行了我们打算执行的命令而不是另一个命令也是可能的。说真的我没有办法列出可能的后果的详尽清单。 (CVE-2025-39726)

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

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

  - cryptoqat - 设备关闭期间刷新其他工作队列在紧凑循环中反复加载和卸载设备特定 QAT 驱动程序例如 qat_4xxx可导致释放后使用情况所致的崩溃。就在卸载设备特定驱动程序例如 qat_4xxx.ko之前如果触发电源管理 (PM) 中断同时保留加载核心驱动程序 (intel_qat.ko)就会发生这种情况。由于该驱动程序使用跨所有设备共享的工作队列 (`qat_misc_wq`)，归 intel_qat.ko 所有来自设备特定驱动程序的延迟的例程可能仍在队列中待定。如果在驱动程序卸载后执行此例程则可能取消引用已释放的内存从而导致页面错误和内核崩溃如下所示BUG无法处理 address: ffa000002e50a01c #PF 内核模式中的主管读取访问 RIP 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] 调用跟踪pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50设备关闭，以确保在卸载驱动程序之前完成所有待定工作项目。注意：如果工作队列包含来自其他设备的作业，此方法可能会稍微增加关机延迟，但它可确保正确性和稳定性。 (CVE-2025-39721)

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

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

  - io_uring/futex确保 io_futex_wait() 在失败时正确清理 io_futex_data 已预先分配并分配给 io_kiocb async_data 字段但当时未使用 REQ_F_ASYNC_DATA 标记该请求。这两者应始终放在一起因为 标记会告知 io_uring 该字段是否有效。此外清除失败时futex 处理程序会释放数据但不清除
    ->async_data。同时清除错误路径中的数据和标记。感谢 Trend Micro 零日计划尤其感谢 ReDress 报告此问题。 (CVE-2025-39698)

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

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

  - serial8250修复因 PSLVERR 造成的错误当 PSLVERR_RESP_EN 参数设置为 1 时如果启用 FIFO 时尝试读取空的 RBR接收缓冲区寄存器设备会生成错误响应。在 serial8250_do_startup() 中调用 serial_port_out(port, UART_LCR, UART_LCR_WLEN8) 会触发 dw8250_check_lcr()从而调用 dw8250_force_idle() 和 serial8250_clear_and_reinit_fifos()。
    后一个函数通过 serial_out(p, UART_FCR, p->fcr) 使能 FIFO。执行继续至 serial_port_in(port, UART_RX)。这满足 PSLVERR 触发条件。当另一个 CPU例如使用 printk()访问 UARTUART 忙碌时当前 CPU 未能在 dw8250_check_lcr() 中进行检查 (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR)导致其进入dw8250_force_idle()。将 serial_port_out(port, UART_LCR, UART_LCR_WLEN8) 放在 port->lock 下以修复此问题。错误 backtrace[0.442336] Oops - 未知异常 [#1] [ 0.442343] epc dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra
    serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 (CVE-2025-39724)

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

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

  - mediavenus在从共享内存读取数据包大小后添加检查添加检查以确保在从共享内存读取数据包标头后数据包大小不超过可用字数。这样做可确保固件提供的大小可以安全处理，并防止潜在的越界内存访问。 (CVE-2025-39710)

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

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

  - drm/amd/display修复空指针取消引用漏洞 [原因] AMD 显示驱动程序DC 模块的清理函数 dc_destruct() 中存在空指针取消引用漏洞。当显示控制上下文 (dc->ctx) 构造失败时由于内存分配失败此指针保持为空。在后续的错误处理期间当调用 dc_destruct() 时在取消引用 perf_trace 成员 (dc->ctx->perf_trace) 之前没有进行空检查造成内核空指针取消引用崩溃。[测量方法] 在取消引用之前检查 dc->ctx 是否为非 NULL。已更新提交文本并删除不必要的错误消息从提交 9dd8e2ba268c636c240a918e0a31e6feaee19404 中精选出的内容(CVE-2025-39705)

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

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

  - iiolightas73211确保将缓冲区漏洞归零 由于缓冲区被复制到最终用户空间可读取的 kfifo确保将其归零。 (CVE-2025-39687)

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

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

  - mediausbtv流时锁定分辨率当一个程序正在流中 (ffplay) 而另一个程序 (qv4l2) 将电视标准从 NTSC 更改为 PAL 时内核会因尝试复制到未映射内存而崩溃。从 NTSC 更改为 PAL 提高了 usbtv 结构中的分辨率但视频平面缓冲区未调整因此会溢出。 [hverkuil调用 vb2_is_busy 而不是 vb2_is_streaming] (CVE-2025-39714)

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

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

  - scsiqla4xxx防止潜在错误指针取消引用 qla4xxx_get_ep_fwdb() 函数出错时应返回空值但 qla4xxx_ep_connect() 返回错误指针。传播错误指针将导致调用程序发生 Oops因此将错误指针更改为 NULL。 (CVE-2025-39676)

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

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

  - iioaccelsca3300修复未初始化的 iio 扫描数据 通过确保“channels”数组在使用前归零修复未初始化的堆栈数据可能泄漏到用户空间的问题。 (CVE-2025-39690)

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

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

  - ipv6sr将 MAC 比较修复为常数时间为防止时序攻击需要在常数时间内对 MAC 进行比较。为此使用适当的辅助函数。 (CVE-2025-39702)

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

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

  - mm/damon/ops-common忽略无效节点的迁移请求即使目标节点无效damon_migrate_pages() 也会尝试迁移。如果用户通过 DAMOS_MIGRATE_{HOT,COLD} 操作错误地提出此类无效请求可能会发生以下内核 BUG。 [ 7831.883495] BUG无法处理地址的页面错误
    0000000000001f48 [ 7831.884160] #PF内核模式下的主管读取访问 [ 7831.884681] #PF
    error_code(0x0000) - 不存在页面 [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0未受感染 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(随意) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX,1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] 7831.895953] 调用跟踪[7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c 1851) [ 7831.897228]
    __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops -common.c:405) [...] 在 damon_migrate_pages() 中添加目标节点有效性检查。有效性检查窃取自用于 move_pages() 系统调用的 do_pages_move() 的有效性检查。
    (CVE-2025-39700)

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

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

  - net/sched修复 qdisc_dequeue_internal 中的积压工作此问题适用于以下 qdisc
    调整以适应新的限制时hhf、fq、fq_codel 和 fq_pie 在其更改处理程序中会发生 和 。问题出在传递给后续 qdisc_tree_reduce_backlog 调用（给定 tbf 父项）的值中的下列问题当 tbf 父项用完所有标记时这些 qdiscs 的 skb 将放置在 gso_skb 中。其 peek 处理程序为 qdisc_peek_dequeued可同时考虑 qlen 和 backlog。然而在 qdisc_dequeue_internal 的情况下当从 gso_skb 拉取时仅考虑 qlen。这意味着这些 qdisc 在丢弃数据包以满足其变更处理程序中的新限制时缺少 qdisc_qstats_backlog_dec。可以通过以下内容观察此问题导出 TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit Burst 100b latency 1ms tc qdisc replace dev lo handle 3parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo ‘after ping’; tc -s -d qdisc show dev lo tc qdisc change dev lo 句柄 3parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc 显示 dev lo tc qdisc 替换 dev lo 句柄 2父 1:1 sfq echo ''; echo 'postraft'; tc -s -d qdisc show dev lo 倒数第二个 show 命令显示有 0 个数据包但 backlog 为正数 (74) 字节。在最后的 show 命令中该问题变得更加明显其中 qdisc_purge_queue 以正 backlog 触发 qdisc_tree_reduce_backlog并导致 tbf 父级的 backlog 中下溢4096 Mb 而不是 0。要修复此问题已简化 qdisc_dequeue_internal 的所有客户端的代码路径codel、pie、hhf、fq、fq_pie 和 fq_codel。 qdisc_dequeue_internal 处理不直接使用出列处理程序的所有情况的 backlog 调整。旧 fq_codel_change 限制调整循环会通过 cstats 字段累积参数以供后续 qdisc_tree_reduce_backlog 调用。但是这样容易造成混淆且出错因为 fq_codel_dequeue 也可能改变此字段在非 gso_skb 情况下 qdisc_dequeue_internal 会调用因此我们已将此处的代码与其他 qdisc 统一。 (CVE-2025-39677)

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

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

  - tracing当 trace_get_user 失败时限制对 parser->buffer 的访问当写入 set_ftrace_filter 的字符串长度超过 FTRACE_BUFF_MAX 时将触发以下 KASAN 警报缺陷KASAN
    strsep+0x18c/0x1b0 中的 slab 越界读取由任务 ash/165 在 addr ffff0000d00bd5ba 执行大小为 1 的 CPU: 1 UID: 0 PID: 165 Comm: ash 未受感染 6.16.0-g6bcdbd62bd56-dirty 硬件名称: linux ,dummy-virt (DT) 调用跟踪show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x15strsep /0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58
    ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 原因是trace_get_user 在处理比 FTRACE_BUG 更长的字符串时会失败，但不是设置将 parser->buffer 的值设置为 0。则将在 ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk 中触发 OOB 访问。通过在 trace_get_user 失败时限制对 parser->buffer 的访问可解决此问题。 (CVE-2025-39683)

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

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

  - parisc修订网关 LWS 调用以探测用户读取访问权限 在不写入内存的情况下使用加载和备用指令触发内存引用中断。由于实现读取访问支持的方式规定，读取访问中断只会在权限级别 2 和 3 时触发。内核和网关页面在权限级别 0 执行，因此此代码从不触发读取访问中断。因此用户代码目前可以在权限级别 3 (PRIV_USER) 受读保护的地址执行 LWS 比较和交换操作。通过在权限级别 3 探测读取访问权限来修复此问题并在不允许访问时转移至 lws_fault。 (CVE-2025-39715)

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

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

  - ftrace同时分配和复制用于读取过滤器文件的哈希 目前 set_ftrace_filter 和 set_ftrace_notrace 的阅读器仅将指向全局跟踪器哈希的指针添加到其迭代器。与分配哈希副本的写入器不同，读取器保留指向过滤器哈希的指针。这是有问题的因为该指针在释放可更新全局跟踪器哈希的锁的函数调用中是静态的。这可能会导致 UAF 及类似缺陷。分配和复制哈希以读取筛选器文件就像为编写器执行一样。这不仅修复了 UAF 缺陷而且还使代码更简单了因为不必区分何时在写入器和读取器之间释放迭代器的哈希。
    (CVE-2025-39689)

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

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

  - drm/nouveau/nvif修复 nvif_vmm_ctor() 中潜在的内存泄漏。当 nvif_vmm_type 无效时将直接返回错误而不释放 nvif_vmm_ctor() 中的参数从而导致内存泄漏。通过设置 ret -EINVAL 并转至流程修复此问题。 (CVE-2025-39679)

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

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

  - ACPIpfr_update修复驱动程序更新版本检查应使用安全版本号检查而不是针对驱动程序更新的运行时版本检查。否则，当更新二进制文件的运行时版本号低于当前版本号时，固件更新将失败。 [ rjw变更日志编辑 ] (CVE-2025-39701)

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

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

  - open_tree_attr在没有 OPEN_TREE_CLONE 的情况下不允许 id 映射变更 如提交 7a54947e727b“合并修补程序系列 fs:允许变更 idmappings”中所述需要 open_tree_attr(2) 才能创建分离的挂载并使其idmappings 更改后不会存在在其上运行的任何争用线程的风险。因此mount_setattr(2) 仍然不允许 id 映射更改。但是在提交 2462651ffa76 中存在缺陷fs 允许更改 idmappings允许用户通过调用 *不使用* OPEN_TREE_CLONE 的 open_tree_attr(2) 来绕过此限制。
    can_idmap_mount() 阻止了此缺陷允许修改附加挂载点的 id 映射感谢 is_anon_ns() 检查但这仍然允许分离但可见挂载更改其 id 映射。这会带来与合并提交中所述相同的 UAF 和锁定问题的风险，并且很可能不是特制的。 (CVE-2025-39717)

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

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

  - mediavenus探测期间防范虚假中断 确保在注册中断之前已初始化中断处理程序。如果 IRQ 在 hfi_create() 之前注册则可能在处理程序设置完成之前触发中断导致空取消引用。Rb3Gen2 上的系统启动期间会发现此错误情况。 (CVE-2025-39709)

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

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

  - drm/amd/display避免空指针取消引用 [原因] 尽管 drm_atomic_get_new_connector_state() 或 drm_atomic_get_old_connector_state() 不太可能返回 NULL。[HOW] 在取消引用前检查返回。从提交 1e5e8d672fec9f2ab352be121be971877bff2af9 中精选出的内容(CVE-2025-39693)

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

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

  - mediarainshadow-cec修复 Rain_interrupt() 中的 TOCTOU 争用条件在中断处理程序 Rain_interrupt() 中会在获取 Rain->buf_lock 之前对 Rain->buf_len 执行缓冲区完整检查。
    这会造成一个检查时间到使用时间 (TOCTOU) 争用条件因为在同一锁定下的工作处理程序 Rain_irq_work_handler() 中会同时访问和修改 Rain->buf_len。多个中断调用可争用每个中断调用在 buf_len 变满之前对其进行读取然后继续进行。这可导致两个尝试写入缓冲区的中断将 buf_len 递增超过其容量 (DATA_SIZE) 并造成缓冲区溢出。将 spin_lock() 移到缓冲区完整检查之前可修复此缺陷。
    这可确保自动执行检查和后续缓冲区修改，从而防止争用条件。已向溢出路径添加相应的 spin_unlock()以正确释放锁定。此可能的缺陷是我们的团队开发的实验性静态分析工具发现的。
    (CVE-2025-39713)

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

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

  - drm/amdgpu检查 debugfs/amdgpu_dm_capabilities 中的 hubbub 是否为空 未在 DCE 硬件上初始化 HUBBUB 结构因此在访问 debugfs 中的 amdgpu_dm_capabilities 文件时检查其是否为空以避免空取消引用。 (CVE-2025-39707)

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

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

  - drm/amd/display在 mod_hdcp_hdcp1_create_session() 中添加空指针检查 函数 mod_hdcp_hdcp1_create_session() 调用函数 get_first_active_display()但未检查其返回值。如果显示列表为空则返回值为空指针。这将导致空指针取消引用。添加对 get_first_active_display() 的空指针检查并在函数返回 null 时返回 MOD_HDCP_STATUS_DISPLAY_NOT_FOUND。这与提交 c3e9826a2202 drm/amd/display为 get_first_active_display() 添加空指针检查类似。从提交 5e43eb3cd731649c4f8b9134f857be62a416c893 中精选出的内容(CVE-2025-39675)

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

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

  - s390/sclp修复 SCCB 当前检查如果与中断关联的 SCCB 地址为 NULL则包含提前退出的 SCLP 中断处理程序调用的跟踪代码。在物理到虚拟地址转换之后执行此检查。如果内核身份映射不是从地址零开始则生成的虚拟地址决不为零因此 NULL 检查将无法工作。因此这可能会导致对身份映射的第一页进行不正确的访问。通过引入在地址转换之前处理 NULL 情况的函数来修复此问题。 (CVE-2025-39694)

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

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

  - cryptocaam - 防止以 iMX8QM / iMX8ULP 暂停时崩溃因为这些 SoC 上的 CAAM 由另一个 ARM 核心管理在 iMX8QM 上称为 SECO安全控制器而在 iMX8ULP 上称为 Secure Enclave其还保留了对寄存器 page 0 暂停的访问权限操作不能接触此页。这类似于运行 OPTEE 时OPTEE 将保留页面 0。使用新的状态变量 no_page0 跟踪此情况可以反映页面 0 是否在别处由 SoC 中的其他管理核心或 OPTEE 保留。将 suspend/resume 中的 optee_en 检查替换为新的检查。 optee_en 无法消失，因为其他地方需要它来关闭 OPTEE 特定情况。#1修复suspend: -) pc readl+0x0/0x18 lr rd_reg32+0x18/0x3c sp
    ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21:
    ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12:
    0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 :
    ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 调用跟踪
    readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store +0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+ 0x88/0x124 el0t_64_sync+0x150/0x154 代码88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) (CVE-2025-39722)

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

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

  - platform/x86/amd/hsmp确保 sock->metric_tbl_addr 为非空如果未分配指标表地址访问metrics_bin 将导致空指针取消引用因此添加了一项检查。 (CVE-2025-39678)

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

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

  - 已修复 Linux 内核中的下列漏洞：LoongArch: KVM: Fix stack protector issue in send_ipi_data() Function kvm_io_bus_read() is called in function send_ipi_data(), buffer size of parameter *val should be at least 8 bytes. Since some emulation functions like loongarch_ipi_readl() and kvm_eiointc_read() will write the buffer *val with 8 bytes signed extension regardless parameter len.
    Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR is enabled. The bug report is shown as follows: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
    send_ipi_data+0x194/0x1a0 [kvm] CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full) Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace:
    [<9000000003af3734>] show_stack+0x5c/0x180 [<9000000003aed168>] dump_stack_lvl+0x6c/0x9c [<9000000003ad0ab0>] vpanic+0x108/0x2c4 [<9000000003ad0ca8>] panic+0x3c/0x40 [<9000000004eb0a1c>]
    __stack_chk_fail+0x14/0x18 [<ffff8000023473f8>] send_ipi_data+0x190/0x1a0 [kvm] [<ffff8000023313e4>]
    __kvm_io_bus_write+0xa4/0xe8 [kvm] [<ffff80000233147c>] kvm_io_bus_write+0x54/0x90 [kvm] [<ffff80000233f9f8>] kvm_emu_iocsr+0x180/0x310 [kvm] [<ffff80000233fe08>] kvm_handle_gspr+0x280/0x478 [kvm] [<ffff8000023443e8>] kvm_handle_exit+0xc0/0x130 [kvm] (CVE-2025-39704)

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

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

  - 已修复 Linux 内核中的下列漏洞：tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length. (CVE-2025-39682)

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

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

  - mediaivsc修复因缺少 mei_cldev_disable() 调用而导致的关闭时的崩溃 ACE 和 CSI 驱动程序在其 remove() 函数中都缺少 mei_cldev_disable() 调用。这导致 mei_cl 客户端保留在 mei_device->file_list 列表的一部分即使其内存已通过 mei_cl_bus_dev_release() 调用 kfree(cldev->cl) 释放。这会导致当 mei_vsc_remove() 运行 mei_stop() 时释放后使用首先删除所有调用 mei_ace_remove() 和 mei_csi_remove() 的 mei 总线设备然后删除 mei_cl_bus_dev_release()然后调用遍历 mei_device->file_list 的 mei_cl_all_disconnect()取消引用刚释放的 cldev->cl。且 mei_vsc_remove() 自身会在关机时运行因为 vsc_tp_shutdown() 中的 platform_device_unregister(tp->pdev)。当使用 KASAN 构建内核时这会导致出现以下 KASAN 报告[ 106.634504] ======== ================================================== ======== [ 106.634623] 缺陷KASANmei_cl_set_disconnected 中的 slab-use-after-free (drivers/misc/mei/client.c:783) mei [ 106.634683] 地址 ffff88819cb62018 处大小 4 的读取通过任务 systemd-shutdow/1 [ 106.634729] [ 106.634767] 受感染[E]=UNSIGNED_MODULE [106.634770] 硬件名称Dell Inc. XPS 16 9640/09CK4V、BIOS 1.12.0 02/10/2025 [ 106.634773]调用跟踪
    [ 106.634777] <TASK>... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c) 783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (dispensator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [106.635066] platform_remove (drivers/base/platform.c:1424) 添加缺少的 mei_cldev_disable() 调用以便在释放 mei_cl 之前将其从 mei_device->file_list 中删除以修复此问题。 (CVE-2025-39711)

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

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

  - i2crtl9300修复 rtl9300_i2c_smbus_xfer 中的越界缺陷 data->block[0] 变量来自用户。
    如果没有正确的检查变量可能会很大从而造成越界缺陷。通过首先检查 data->block[0] 的值修复此缺陷。 1. commit 39244cc75482i2cismt修复 ismt_access() 中的越界缺陷2. commit 92fbb6d1296f (i2cxgene-slimpro修复 xgene_slimpro_i2c_xfer() 中的越界缺陷CVE-2025-39680)

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

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

  - netfs修复无缓冲写入错误处理 如果无缓冲写入流中的所有子请求失败subrequest 收集器不会更新 stream->transferred 值并保留其初始 LONG_MAX 值。遗憾的是如果所有活动流都失败那么我们会采取 { LONG_MAX, LONG_MAX, ... } 中的最小值作为要在 wreq->transferred 中设置的值 - 然后该值会从 ->write_iter() 返回。选择 LONG_MAX 作为初始值以便可以通过取所有 stream->transferred 中的最小值来快速评估所有流 - 但是这只在我们设置了其中任何一个之后才有效。通过添加一个标记来指示 stream->transferred 中的值是否有效并在我们集成值时进行检查来修复此问题。
    随后可将 stream->transferred 初始化为零。这是通过对 cache=none 的 cifs 运行 generic/750 xfstest 发现的。它将数据拼接到目标文件。一旦用完所有可用的擦除空间，写入将因 ENOSPC 而失败。这将导致 ->write_iter() 失败。
    但是它返回 wreq->transferred即 LONG_MAX而不是一个错误因为它认为传输的数量为非零并且 iter_file_splice_write() 之后会尝试清理数量的管道缓冲 - 导致 oops它溢出了。内核日志显示CIFSVFS发送 write = -28 中的错误随后是 BUG: kernel 空指针取消引用地址 0000000000000008使用RIP:
    0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0 或: RIP0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755) 同时将警告检查放入 splice以在->write_iter() 返回已写入的内容比要求的内容多。
    (CVE-2025-39723)

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

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

  - iommu/riscv防止 iova_to_phys 中的空取消引用 riscv_iommu_pte_fetch() 函数可为未映射/从未映射的 iova 返回空或是无需进一步验证的有效叶 pte 指针。
    riscv_iommu_iova_to_phys() 无法处理 NULL 返回。防止 riscv_iommu_iova_to_phys() 中的空指针取消引用并删除 pte 验证。 (CVE-2025-39699)

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

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

  - drm/xe修复 vm_bind_ioctl 双重释放缺陷 如果数组绑定期间的参数检查失败bind_ops 将被释放两次如下所示。通过在释放后将 bind_ops 设置为 NULL 来修复此问题。
    ================================================== ================ BUGKASANxe_vm_bind_ioctl+0x1b2/0x21f0 [xe] 由任务 xe_vm/14198 CPU: 5 UID: 0 PID: 释放 addr ffff88813bb9b800
    14198 Commxe_vm 未受感染 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full) 硬件名称Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP、BIOS ADLPFWI1。R00.2411.A02.2110081023 10/08/2021 调用跟踪 <TASK> dump_stack_lvl+0x82/0xd0 print_report+0xcb/0x610
    __virt_addr_valid+0x19a/0x300 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] kasan_report_invalid_free+0xc8/0xf0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] check_slab_allocation+0x102/0x130 kfree+0x10d/0x440 ? should_fail_ex+0x57/0x2f0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? __lock_acquire+0xab9/0x27f0 ? lock_acquire+0x165/0x300 ? drm_dev_enter+0x53/0xe0 [drm] ? find_held_lock+0x2b/0x80 ? drm_dev_exit+0x30/0x50 [drm] ? drm_ioctl_kernel+0x128/0x1c0 [drm] drm_ioctl_kernel+0x128/0x1c0 [drm] ?
    __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? find_held_lock+0x2b/0x80 ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm] ? should_fail_ex+0x57/0x2f0 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] drm_ioctl+0x352/0x620 [drm] ?
    __pfx_drm_ioctl+0x10/0x10 [drm] ? __pfx_rpm_resume+0x10/0x10 ? do_raw_spin_lock+0x11a/0x1b0 ? find_held_lock+0x2b/0x80 ? __pm_runtime_resume+0x61/0xc0 ? rcu_is_watching+0x20/0x50 trace_irq_enable.constprop.0+0xac/0xe0 xe_drm_ioctl+0x91/0xc0 [xe] __x64_sys_ioctl+0xb2/0x100 rcu_is_watching+0x20/0x50 do_syscall_64+0x68/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP
    0033:0x7fa9acb24ded从提交 a01b704527c28a2fd43a17a85f8996b75ec8492a 中精选出的内容 (CVE-2025-38731)

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

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

  - NFS修复更新现有写入时的争用。在 nfs_lock_and_join_requests() 测试请求是否仍然附加到映射之后没有任何措施可以阻止对 nfs_inode_remove_request() 的调用成功直到我们实际锁定页组。原因是无论调用者如何调用 nfs_inode_remove_request()，都不一定会锁定页组标。因此为避免争用不如先在 nfs_lock_and_join_requests() 中采用页组锁定在 nfs_inode_remove_request() 中删除请求时保持锁定。 (CVE-2025-39697)

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

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

  - mediamt9m114修复 get_frame_interval/set_frame_interval 中的死锁使用 V4L2 subdev pad ops get_frame_interval/set_frame_interval 获取/设置帧间隔会导致死锁因为 subdev 状态在 [1] 中而且在驱动程序本身中也被锁定。[2] 中描述了在这种情况下调用方负责获取和释放锁定。因此，在驱动程序中获取锁定是错误的。从 mt9m114_ifp_get_frame_interval() 和 mt9m114_ifp_set_frame_interval() 删除锁定获取/释放。
    [1] drivers/media/v4l2-core/v4l2-subdev.c - 第 1129 行 [2] Documentation/driver-api/media/v4l2-subdev.rst (CVE-2025-39712)

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

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

  - ksmbd修复导致资源未释放的 refcount 泄漏当 ksmbd_conn_relase(opinfo->conn) 返回 true 时refcount 未正确减少从而造成 refcount 泄漏该泄漏阻止计数达到零并阻止释放内存。 (CVE-2025-39720)

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

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

  - net/smc修复 smc_listen_out() 之后smcsk 上的 UAF BPF CI 测试报告 UAF 问题 [ 16.446633] BUG
    内核空指针取消引用地址000000000000003 0 [ 16.447134] #PF内核模式下的管理程序读取访问权限 [ 16.447516] #PFerror_code (0x0000) - not-present 页面 [ 16.447878] PGD 0 P4D 0 [16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 TaintedG OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] 受感染[O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] 硬件名称QEMU Ubuntu 24.04 PC (i440FX + PIIX、1996)BIOS 1.16.3-debian-1.16.3-2 201 年 4 月 04 日 [ 16.450201] Workqueuesmc_hs_wq smc_listen_work [ 16.450531] RIP
    0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI:
    00003513840053f0 RDI000000000000000 0 [ 16.453492] RBPffffa097808e3800 R08ffffa09782dba1e0 R09
    000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS:
    0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4:
    0000000000770ef 0 [ 16.456459] PKRU: 55555554 [ 16.456654] 调用跟踪 [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ?
    __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] 链接的模块bpf_testmod(OE) [上次卸载的bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590 造成此问题的直接原因是在 smc_listen_out_connected() 之后newclcsock->sk 可能为空因为它将释放 smcsk。因此如果应用程序在接受后立即关闭套接字newclcsock->sk 可以为空。可能的执行顺序如下用户空间
    -------------------------------------------------- --------------- lock_sock(sk) | smc_listen_out_connected() | smc_listen_out_connected() | smc_listen_out_connected() | smc_listen_out_connected() | - smc_listen_out | | | \- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \- socket->sk = NULL /* newclcsock->sk 现在为空 */ SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk)) 由于 smc_listen_out_connected() 不会失败因此只需交换代码的顺序即可轻松修复此问题。 (CVE-2025-38734)

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

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

  - vsock/virtio在客户机中接收 vsock 数据包时在 skb_put() 之前验证数据包标头中的长度在 virtio_vsock_skb_rx_put() 之前仅验证 virtqueue 缓冲区大小。遗憾的是virtio_vsock_skb_rx_put() 使用数据包标头中的长度作为 skb_put() 的长度参数如果主机不稳定可能造成 SKB 溢出。调用 virtio_vsock_skb_rx_put() 之前验证数据包标头公告的长度。 (CVE-2025-39718)

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

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

  - fs/buffer修复调用 bh_read() 帮助程序时的释放后使用 存在如下问题BUG: KASAN按照任务交换程序/执行地址 ffffc9000168f7f8 时end_buffer_read_sync+0xe3/0x110 中发生堆栈越界读取大小 8 3/0 CPU3 UID0 PID0 Commswapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 硬件名称QEMU Standard PCi440FX + PIIX，1996调用跟踪 <IRQ> dump_stack_lvl+0x55/ 0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh);
    blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return 将返回到调用程序 put_bh --> 触发堆栈越界在 mpage_read_folio() 函数中堆栈变量“”堆栈变量“”被传递到 nt ()。一旦 unlock_buffer() 解锁且 wait_on_buffer() 返回以继续处理堆栈变量可能会被回收。因此在 end_buffer_read_sync() 进程期间调用 put_bh() 可能会导致堆栈溢出。如果未在堆栈上分配 bh则其属于 folio。通过 drop_buffers() 释放属于 folio 的缓冲区头将无法释放仍然锁定的缓冲区。因此在调用 __end_buffer_read_notouch() 之前调用 put_bh() 是安全的。 (CVE-2025-39691)

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

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

  - Cilium 是一种网络、可观察性和安全性解决方案，具有基于 eBPF 的数据平面。基于节点的网络策略fromNodes 和 toNodes将错误允许进出非节点端点的流量从这些非节点端点共享在网络策略的 fromNodes 和 toNodes 部分指定的标签。在 Cilium 中默认禁用基于节点的网络策略。问题会影响 v1.16.0 与 v1.16.7 含之间的 Cilium v1.16以及 v1.17.0 与 v1.17.1 含之间的 v1.17。此问题已在 Cilium v1.16.8 和 v1.17.2 中修复。用户可以通过确保“fromNodes”和“toNodes”字段中使用的标签仅供节点而非其他端点使用来解决此问题。 (CVE-2025-30163)

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

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

  - userfaultfd修复 PMD 为迁移条目时 UFFDIO_MOVE 中的崩溃当 UFFDIO_MOVE 遇到迁移 PMD 条目时即使该条目为 swp_entry_t它也会继续获取 folio 并对其进行访问。添加缺少的检查并让 split_huge_pmd() 处理迁移条目。同时还删除不必要的对开检查。 [surenb@google.com删除额外的 folio 检查per David] (CVE-2025-38686

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

ID	名称	严重性
261642	Linux Distros 未修补的漏洞：CVE-2025-39719	high
261641	Linux Distros 未修补的漏洞：CVE-2025-39703	medium
261640	Linux Distros 未修补的漏洞：CVE-2025-38732	medium
261639	Linux Distros 未修补的漏洞：CVE-2025-26434	medium
261638	Linux Distros 未修补的漏洞：CVE-2025-38735	medium
261637	Linux Distros 未修补的漏洞：CVE-2025-39685	high
261636	Linux Distros 未修补的漏洞：CVE-2025-39692	medium
261635	Linux Distros 未修补的漏洞：CVE-2025-39695	medium
261634	Linux Distros 未修补的漏洞：CVE-2025-39726	medium
261633	Linux Distros 未修补的漏洞：CVE-2025-39721	medium
261632	Linux Distros 未修补的漏洞：CVE-2025-39698	medium
261631	Linux Distros 未修补的漏洞：CVE-2025-39724	medium
261630	Linux Distros 未修补的漏洞：CVE-2025-39710	high
261629	Linux Distros 未修补的漏洞：CVE-2025-39705	medium
261628	Linux Distros 未修补的漏洞：CVE-2025-39687	high
261627	Linux Distros 未修补的漏洞：CVE-2025-39714	medium
261626	Linux Distros 未修补的漏洞：CVE-2025-39676	medium
261625	Linux Distros 未修补的漏洞：CVE-2025-39690	high
261624	Linux Distros 未修补的漏洞：CVE-2025-39702	high
261623	Linux Distros 未修补的漏洞：CVE-2025-39700	medium
261622	Linux Distros 未修补的漏洞：CVE-2025-39677	medium
261621	Linux Distros 未修补的漏洞：CVE-2025-39683	high
261620	Linux Distros 未修补的漏洞：CVE-2025-39715	medium
261619	Linux Distros 未修补的漏洞：CVE-2025-39689	high
261618	Linux Distros 未修补的漏洞：CVE-2025-39679	medium
261617	Linux Distros 未修补的漏洞：CVE-2025-39701	high
261616	Linux Distros 未修补的漏洞：CVE-2025-39717	low
261615	Linux Distros 未修补的漏洞：CVE-2025-39709	medium
261614	Linux Distros 未修补的漏洞：CVE-2025-39693	medium
261613	Linux Distros 未修补的漏洞：CVE-2025-39713	medium
261612	Linux Distros 未修补的漏洞：CVE-2025-39707	medium
261611	Linux Distros 未修补的漏洞：CVE-2025-39675	medium
261610	Linux Distros 未修补的漏洞：CVE-2025-39694	medium
261609	Linux Distros 未修补的漏洞：CVE-2025-39722	medium
261608	Linux Distros 未修补的漏洞：CVE-2025-39678	medium
261607	Linux Distros 未修补的漏洞：CVE-2025-39704	medium
261606	Linux Distros 未修补的漏洞：CVE-2025-39682	high
261605	Linux Distros 未修补的漏洞：CVE-2025-39711	high
261604	Linux Distros 未修补的漏洞：CVE-2025-39680	high
261603	Linux Distros 未修补的漏洞：CVE-2025-39723	high
261602	Linux Distros 未修补的漏洞：CVE-2025-39699	medium
261601	Linux Distros 未修补的漏洞：CVE-2025-38731	high
261600	Linux Distros 未修补的漏洞：CVE-2025-39697	medium
261599	Linux Distros 未修补的漏洞：CVE-2025-39712	medium
261598	Linux Distros 未修补的漏洞：CVE-2025-39720	medium
261597	Linux Distros 未修补的漏洞：CVE-2025-38734	high
261596	Linux Distros 未修补的漏洞：CVE-2025-39718	medium
261595	Linux Distros 未修补的漏洞：CVE-2025-39691	high
261593	Linux Distros 未修补的漏洞：CVE-2025-30163	medium
261592	Linux Distros 未修补的漏洞：CVE-2025-38686	medium

检测

Nessus 的 Misc. 系列

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

medium

medium

high

high

medium

medium

high

medium

high

medium

high

low

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high

high

high

medium

high

medium

medium

medium

high

medium

high

medium

medium