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

  - mm/vma修复 mremap() 上发生错误、无错误的合并上的 anon_vma UAF 修补程序系列 mm/vma修复 mremap() 上发生错误、无错误的合并上的 anon_vma UAF v2.0 提交 879bca0a2c4fmm/vma修复错误地禁止的匿名 VMA 合并引入了合并之前不可用的 VMA 合并场景的功能。但是当涉及到与未发生故障的 VMA 邻近的发生故障的 VMA 的 mremap() 时其会错误地处理合并。会在三种情况下出现这些问题1。上一个 VMA 无故障：复制 -----| v |------------|----------------| |无故障 |（故障 VMA）| |-----------|........|上一个 2。下一个 VMA 无故障：已复制 -----| v |........|--------| |故障 VMA|无故障 | |......|-----------| 3.两个邻近的 VMA unfaulted: 复制 -----| v |-----------|----------------|--------| |无故障 |（故障 VMA）|无故障 | |------------|........|---------|上一个 下一个 本系列修复了所有这些情况并引入自测试以断言问题已修正。我还进一步测试了已处理的情况以断言我的更改会继续正确地处理它4. prev unfaulted, next Faulted:内容已复制 -----| v |-----------|----------------|--------| |无故障 |（故障 VMA）|错误 | |------------|........|---------| prev next 此缺陷是通过 系列的第一个修补程序中链接的 syzbot 报告发现的。我确认此系列会修复此缺陷。我还发现在上述情况 1-3 中合并复制的 VMA 时我们无法检查有问题的 VMA 是否未 fork此系列问题也将解决该问题。我还添加了自我测试以断言此问题已解决（并确认测试在此之前已失败）。作为这项工作的一部分我还清理了 vma_expand()将 vma_ad_uncowed_parents() 重命名为 vma_is_fork_child()因为之前的名称过于混乱并且简化了与此函数相关的注释。此修补程序共 4 个提交 879bca0a2c4fmm/vma修复错误地禁止匿名 VMA 合并引入了合并以前不可用的 VMA 合并场景的功能。引入的关键逻辑是能够立即将有错误的 VMA 合并到无错误的 VMA 旁边从而依赖 dup_anon_vma() 正确处理 anon_vma 状态。合并现有 VMA即 VMA 的属性由邻近 VMA 共享则更改后合并这些属性会正确调用 dup_anon_vma()。但是在合并新 VMA 时会错过 mremap() 特有的极端情况。问题在于 vma_expand() 仅在目标 VMA 最终成为合并的 VMA满足以下条件时执行 dup_anon_vma() 不是下一个 VMA即在建立新 VMA 的范围之后出现的 VMA 。此处要点在于，在除 mremap() 以外的所有其他情况下，新的 VMA 合并要么扩展现有 VMA，要么使 anon_vma 为空即目标 VMA 将为该 VMA。特别是* __mmap_region() - 未部署 anon_vma初始映射。 * do_brk_flags() - 扩展现有 VMA。 * vma_merge_extend() - 扩展现有 VMA。 * relocate_vma_down() - 未到位 anon_vma初始映射。此外我们遇到一个特殊情况需要从既不是要合并的上一个也不是下一个 VMA 的 VMA 复制 anon_vma 状态。 dup_anon_vma() 专门处理 target=unfaulted、 src=faulted 情况。因此就有四种可能性每种情况下复制的 VMA 会发生故障1. 上一个无故障的 VMA复制了 -----| ---truncated--- (CVE-2026-23077)

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

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

  - PMhibernate修复释放无效加密压缩器时发生的崩溃crypto_alloc_acomp() 失败时其返回 ERR_PTR 值而非 NULL。save_compressed_image() 和 load_compressed_image() 中的清理代码无条件调用 crypto_free_acomp() 而不检查 ERR_PTR这导致 crypto_acomp_tfm() 取消引用无效指针并使内核崩溃。当压缩算法不可用（例如，CONFIG_CRYPTO_LZO 未启用）时可能会触发此问题。通过在调用 crypto_free_acomp() 和 acomp_request_free() 之前添加 IS_ERR_OR_NULL() 检查修复此缺陷与现有的 kthread_stop() 检查类似。 [ rjw添加了 2 个空代码行 ] (CVE-2026-23044)

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

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

  - 在 moodle 中发现一个缺陷。在匿名提交提交期间用户标识符会不慎在 URL 中暴露。此数据泄露允许未经授权的查看者查看内部用户 ID，从而破坏预期的匿名性并可能导致信息泄露。 (CVE-2025-67857)

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

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

  - PEAR 是一款适用于可重用 PHP 组件的框架和分发系统。在版本 1.33.0 之前，缺陷更新电子邮件处理过程中使用的 preg_replace() 带有 /e 修饰符 ，这可在攻击者控制的内容传入被求值的替换部分时造成 PHP 代码执行。已在版本 1.33.0 中修补此问题。(CVE-2026-25237)

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

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

  - ice修复 devlink 重新加载调用跟踪 Commit 4da71a77fc3bice读取内部温度传感器引入了通过 HWMON 进行的内部温度传感器读取。 ice_hwmon_init() 被添加到 ice_init_feature()并且 ice_hwmon_exit() 被添加到 ice_remove()。因此如果使用 devlink 重新加载来重新初始化设备然后删除该驱动程序则可能会发生调用跟踪。BUG：无法处理地址的页面错误：
    ffffffffc0fd4b5d 调用追踪string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60 系统监控工具例如 sadc尝试读取孤立引用已释放模块内存的 hwmon sysfs 属性。序列为 1. 驱动程序加载、从 ice_init_feature() 调用 ice_hwmon_init() 2. Devlink 重新加载、流未调用 ice_remove() 3. Devlink 重新加载、从 ice_init_feature() 调用 ice_hwmon_init() 导致第二个实例 4. 驱动程序卸载从 ice_remove() 调用 ice_hwmon_exit()使第一个 hwmon 实例因悬摆指针而孤立。通过将 ice_hwmon_exit() 从 ice_remove() 移动至 ice_deinit_features() 以确保正确清理与 ice_hwmon_init() 对称的方式修复此问题。 (CVE-2026-23104)

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

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

  - net/ena修复更新 devlink 参数时缺少的锁定。修复调用 ena 中的 devl_param_driverinit_value_set() 时的断言锁定警告。警告net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0kworker/0:0/9 CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 未受感染 6.19.0-rc2+ #1 PREEMPT(lazy) 硬件名称Amazon EC2 m8i-flex.4xlarge/、BIOS 1.0 2017 年 10 月 16 日 Workqueue 事件 work_for_cpu_fn RIP
    0010devl_assert_locked+0x62/0x90 调用跟踪 <TASK> devl_param_driverinit_value_set+0x15/0x1c0 ena_devlink_alloc+0x18c/0x220 [ena] ? __pfx_ena_devlink_alloc+0x10/0x10 [ena] ? trace_hardirqs_on+0x18/0x140? lockdep_hardirqs_on+0x8c/0x130 ? __raw_spin_unlock_irqrestore+0x5d/0x80 ?
    __raw_spin_unlock_irqrestore+0x46/0x80 ? devm_ioremap_wc+0x9a/0xd0 ena_probe+0x4d2/0x1b20 [ena] ?
    __lock_acquire+0x56a/0xbd0 ? __pfx_ena_probe+0x10/0x10 [ena] ? local_clock+0x15/0x30 ?
    __lock_release.isra.0+0x1c9/0x340 mark_held_locks+0x40/0x70 lockdep_hardirqs_on_prepare.part.0+0x92/0x170 trace_hardirqs_on+0x18/0x140? lockdep_hardirqs_on+0x8c/0x130 ? __raw_spin_unlock_irqrestore+0x5d/0x80 ?
    __raw_spin_unlock_irqrestore+0x46/0x80 ? __pfx_ena_probe+0x10/0x10 [ena] ...... </TASK> (CVE-2026-23045)

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

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

  - bonding将 BOND_MODE_8023AD 限制用于以太网设备 BOND_MODE_8023AD 仅对 ARPHRD_ETHER 有意义。
    syzbot 报告了缺陷 KASAN__hw_addr_create net/core/dev_addr_lists.c:63 [内联] 缺陷KASAN__hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists 中存在全局越界.c:118 任务 syz.1.3580/19497 在 addr ffffffff8bf94040 读取大小 16 CPU1 UID0 PID19497 Comm
    syz.1.3580 受感染：GL syzkaller #0 PREEMPT(full) 受感染：[L]=SOFTLOCKUP 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 10/25/2025 调用跟踪 <TASK> dump_stack_lvl+0xe8/0x150 lib /dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/ kasan/generic.c:-1 [内联] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200
    __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [内联]
    __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [内联] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/ bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [内联]
    __rtnl_newlink net/core/rtnetlink.c:3935 [内联] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/ af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket .c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/ socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [内联] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c :332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e </TASK> 有缺陷的地址属于变量lacpdu_mcast_addr+0x0/0x40 (CVE-2026-23099)

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

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

  - iiodacad3552r-hs修复 ad3552r_hs_write_data_source 中的越界写入simple_write_to_buffer() 成功时返回实际复制到缓冲区的字节数。该代码错误地使用“count”作为 NULL 终止的索引而不是实际复制的字节。如果计数超过缓冲区大小则会导致越界写入。添加计数检查并将返回值用作索引。此缺陷已使用反映原始代码的演示模块进行验证并在 QEMU 下进行测试。缺陷的模式- 使用计数填充固定的 64 字节堆栈缓冲区。- 如果 count > 64代码仍执行 buf[count] = '\0'从而导致 - 堆栈上的越界写入。重现步骤- 打开设备节点。- 向其写入 128 字节的 A。- 这会使 64 字节的堆栈缓冲区溢出且 KASAN 会报告 OOB。
    通过静态分析发现。这与提交 da9374819eb3iio后端修复越界写入 (CVE-2026-23092)

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

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

  - tracing修复合成堆栈跟踪字段使用时的崩溃根据具有堆栈跟踪字段的现有合成事件创建合成事件而新合成事件使用该字段时发生内核崩溃~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >>events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch ).trace(stack,$s1)' >> events/sched/sched_switch/trigger 以上内容创建了一个合成事件其会在非运行状态的任务计划退出时获取堆栈跟踪并在该任务会重新安排。它会触发其字段为“堆栈跟踪”的堆栈合成事件称为“堆栈”。 ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic. stack).trace(syscall_stack,$i0,$s3)' >>events/raw_syscalls/sys_exit/trigger上述创建另一个名为 syscall_stack 的合成事件该事件将第一个合成事件堆栈附加到 sys_exit 跟踪事件并记录来自具有正在退出的系统调用的 ID 的堆栈事件的堆栈跟踪。启用此事件或在直方图中使用此事件时~# echo 1 > events/synthetic/syscall_stack/enable 造成内核崩溃BUG无法处理地址 0000000000400010 的页面错误 #PF内核模式 #PF 中存在主管读取访问
    error_code(0x0000) - not-present 页面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash 未受感染 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware nameQEMU Standard PC (Q35 + ICH92009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP
    0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP0018:ffffd2670388f958 EFLAGS00010202 RAX: ffff8ba1065cc100 RBX
    0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11:
     R12ffffffff9a908970  : 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 调用跟踪 <TASK> ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpsstate+0x3e/0x90 ?
    _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpsstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 原因是 stacktrace 字段未作此标记且该字段被视为普通字段而非动态事件。在 trace_event_raw_event_synth() 中事件字段仍被视为动态数组但数据的检索被视为正常字段且引用只是元数据// 检索元数据而不是动态数组 ---truncated--- (CVE-2026-23088)

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

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

  - ALSAusb-audio修复 snd_usb_mixer_free() 中的释放后使用。当 snd_usb_create_mixer() 失败时snd_usb_mixer_free() 会释放mixer->id_elems但已添加到卡片的控件仍引用已释放的内存。之后当 snd_card_register() 运行时OSS 混合器层会调用其回调并发生释放后使用读取。调用跟踪 get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test +0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ...
    snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 通过在释放 id_elems 之前为所有混合器控件调用 snd_ctl_remove() 来修复。我们首先保存 next 指针因为 snd_ctl_remove() 会释放当前元素。 (CVE-2026-23089)

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

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

  - vsock/virtio上限 TX 贷项本地缓冲区大小 virtio 传输直接从 peer_buf_alloc 获取其 TX 贷项peer_buf_alloc是根据远程端点的 SO_VM_SOCKETS_BUFFER_SIZE 值设置。在主机端这意味着我们愿意排队等待连接的数据量按客户机选择的缓冲区大小缩放而不是按主机自己的 vsock 配置。恶意访客可宣传大型缓冲区并使读取缓慢进而导致主机分配相应大量的 sk_buff 内存。在恶意主机的客户机中也会发生同样的情况因为 virtio 传输共享相同的代码库。引入一个小型帮助程序 virtio_transport_tx_buf_size()其返回 min(peer_buf_alloc, buf_alloc)并在任何消耗 peer_buf_alloc 的地方使用它。此操作可确保有效 TX 窗口受限于对等机公布的缓冲区和我们自己的 buf_alloc已通过 SO_VM_SOCKETS_BUFFER_MAX_SIZE 限制在 buffer_max_size因此远程对等机无法强制对方排队比其自身 vsock 设置允许的数据更多的数据。在未修补的 Ubuntu 22.04 主机 (~64 GiB RAM)上运行具有 32 个客户机 vsock 连接的 PoC每个通告 2 GiB读取缓慢导致 Slab/SUnreclaim 从 ~0.5 GiB 降低到 ~57 GiB系统仅在终止 QEMU 进程后恢复。即使如此如果 cgroups 限制 QEMU 内存所使用的最大内存也将受到限制。应用此修补程序之后 之前MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 高信用连接 MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim
    Slab/SUnreclaim 中仅增加约 152 MiB 约 35 MiB，无主机 OOM，客户机保持响应。
    与非 virtio 传输的兼容性 - VMCI 使用 AF_VSOCK 缓冲区旋钮根据本地 vsk->buffer_* 值调整每个套接字的队列对大小远程端无法将这些队列扩大到本地端点所配置的范围之外。- Hyper-V 的 vsock 传输使用固定大小的 VMBus 环形缓冲区和 MTU 边界不存在可与 peer_buf_alloc 比较的对等机控制的 credit 字段并且远程端点无法将传输中的内核内存驱动到这些环大小以上。- 环回路径重用 virtio_transport_common.c因此它自然会遵循与 virtio 传输相同的语义。此更改仅限于 virtio_transport_common.c 会影响 virtio-vsock、vhost-vsock 和 loopback使它们与与 VMCI 和 Hyper-V 已有效拥有的本地策略行为相交的远程窗口保持一致。[Stefano更改之前的修补程序之后的小调整] [Stefano调整提交消息] (CVE-2026-23086)

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

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

  - net/schedact_ife避免可能的空取消引用 tcf_ife_encode() 必须确保 ife_encode() 不返回空。 syzbot 报告 Oops一般保护错误可能为非规范地址 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN范围 [0x0000000000000000-0x0000000000000007] RIP: 0010: netife_tlv_meta/01x4/net ife/ife.c:166 CPU3 UID0 PID8990 Commsyz.0.696 未受感染 syzkaller #0 PREEMPT(full) 调用跟踪 <TASK> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [内联] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [内联] tcf_action_exec+0x1c0/0xa20 net/sched/act_api。 c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [内联] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [内联]
    __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq .c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [内联]
    __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798 (CVE-2026-23064)

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

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

  - ALSA:carlett2修复配置检索中的缓冲区溢出。carlett2_usb_get_config() 函数在字节顺序转换代码中存在逻辑错误可在计数 > 1 时造成缓冲区溢出。该代码检查“if (size == 2)”其中“size” ` 为总缓冲区大小以字节为单位则将每个元素视为 u16（2 个字节）的“count”次循环。当缓冲区仅分配了“size”字节时这会导致循环访问“count * 2”字节。修复方法是检查元素大小 (config_item->size) 而非缓冲区总大小。这可确保字节顺序转换与实际的元素类型匹配。 (CVE-2026-23078)

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

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

  - btrfs修复 wait_current_trans() 中因忽略事务类型而导致的死锁。在 start_transaction() 期间调用 wait_current_trans() 时其当前会等待被阻止的事务而不考虑给定的事务类型是否实际上需要等待该特定事务状态。 btrfs_blocked_trans_types[] 数组已定义哪些事务类型应等待哪些事务状态但 wait_current_trans() 中缺少此检查。这可导致涉及两个事务和待定有序范围的死锁情况1. 事务 A 处于 TRANS_STATE_COMMIT_DOING 状态 2. 处理有序范围的工作线程使用 TRANS_JOIN 调用 start_transaction() 3. join_transaction() 返回 -EBUSY因为事务 A 处于TRANS_STATE_COMMIT_DOING 4.
    事务 A 移动至 TRANS_STATE_UNBLOCKED 并完成 5. 已创建新的事务 B (TRANS_STATE_RUNNING) 6. 第 2 步中的有序范围已添加到事务 B 的待定有序范围 7. 事务 B 立即开始由另一个任务提交并进入 TRANS_STATE_COMMIT_START 8.
    工作线程最终到达 wait_current_trans()发现事务 B 处于 TRANS_STATE_COMMIT_START阻止状态并且无条件等待 9。然而根据 btrfs_blocked_trans_types[] 10TRANS_JOIN 不应等待 TRANS_STATE_COMMIT_START。事务 B 正在等待待定有序盘区完成 11. 死锁事务 B 等待有序盘区有序盘区等待事务 B 以下调用堆栈会说明这一点CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A complete # 创建事务 B # 将有序范围添加到 # 事务 B 的待定列表 btrfs_commit_transaction() # 事务 B 进入 # TRANS_STATE_COMMIT_START # 等待待定有序 # 范围 wait_current_trans() # 等待事务 B # (不应等待!) btrfs_commit_transaction 中的任务 bstore_kv_sync等待有序盘区__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs]
    __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 wait_current_trans 中的任务 kworker 等待事务提交Workqueue btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xetr0xcurrent/schedule+0x64/0xetr0xcurrent/] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0worker_thread+0x4d/0x3e0kthread+0x12d/0x3c0worker_thread+0x4d/0x3e0kthread+0x12d/0x1k_from0x30ret通过在决定等待之前将事务类型传递给 wait_current_trans() 并针对给定类型检查 btrfs_blocked_trans_types[cur_trans->state]。这可确保在某些阻止状态期间被允许加入的事务类型不会不必要地等待和导致死锁。 (CVE-2025-71194)

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

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

  - uacce修复隔离 sysfs 检查条件 uacce 支持设备隔离功能。如果驱动程序实现 isolate_err_threshold_read 和 isolate_err_threshold_write 回调函数uacce 现在将创建 sysfs 文件。用户可通过 sysfs 读取和配置隔离策略。目前只要 isolate_err_threshold_read 或 isolate_err_threshold_write 回调函数存在一个即可创建 sysfs 文件。但是，访问不存在的回调函数可能会导致系统崩溃。
    因此如果 read 或 write 都不存在则拦截 sysfs 的创建如果支持任一 sysfs则创建 sysfs但在调用站点拦截不受支持的操作。 (CVE-2026-23094)

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

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

  - iioimust_lsm6dsx在没有事件检测的情况下修复传感器的 iio_chan_spec struct iio_chan_spec 的 st_lsm6dsx_acc_channels 数组具有 non-NULL event_spec 字段表示支持 IIO 事件。但并非所有传感器支持事件检测如果用户空间尝试在不支持加速计唤醒事件的传感器设备例如 LSM6DS0上配置加速计唤醒事件则 st_lsm6dsx_write_event() 在尝试写入唤醒寄存器时会取消引用空指针。定义一个其成员具有空 event_spec 字段的额外 struct iio_chan_spec 数组并使用此数组代替无事件检测功能的传感器的 st_lsm6dsx_acc_channels。 (CVE-2025-71198)

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

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

  - PEAR 是一个用于可重用 PHP 组件的框架和分发系统。在低于 的版本 1.33.0中可预测的验证哈希允许攻击者猜测验证标记并可能在未经授权的情况下验证选择帐户请求。已在版本 1.33.0 中修补此问题。
    (CVE-2026-25235)

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

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

  - idpf修复 vport 不支持 rdma 时拔出 aux 设备如果 vport 标记不包含 VIRTCHNL2_VPORT_ENABLE_RDMA驱动程序不会为此 vport 分配 vdev_info。这导致 idpf_idc_vport_dev_down() 中发生内核空指针取消引用从而导致引用每个 vport 的 vdev_info。
    检查在拔出 aux 设备之前是否分配过 vdev_info。 (CVE-2026-23042)

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

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

  - iioadcat91-sama5d2_adc修复 sama5d2_adc 驱动程序 at91_adc_interrupt 中可能的释放后使用错误可通过 schedule_work(&st->touch_st.workq) 调用 at91_adc_touch_data_handler 函数以启动工作。如果删除将调用 at91_adc_remove 进行清理的模块它将通过 iio_device_unregister 释放 indio_dev但会晚很长时间。而上述提到的作品都会被使用。可能导致 UAF 缺陷的操作序列如下CPU0 CPU1 | CPU0 CPU1 at91_adc_remove | at91_adc_workq_handler iio_device_unregister(indio_dev) | | //稍后释放 indio_dev | | iio_push_to_buffers(indio_dev) | //使用 indio_dev 通过确保在继续 at91_adc_remove 中的清理之前取消工作来修复此问题。 (CVE-2025-71199)

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

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

  - 在 mooodle 中发现一个缺陷。远程攻击者可利用策略工具返回 URL 中的反射型跨站脚本 (XSS) 漏洞。此漏洞是由于对 URL 参数的审查不充分导致的。允许攻击者通过特别构建的链接注入恶意脚本。成功利用此漏洞可能导致信息泄露或在用户的浏览器中执行任意客户端脚本。 (CVE-2025-67855)

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

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

  - be2net修复 be_cmd_get_mac_from_list 中的空指针取消引用 当 be_cmd_get_mac_from_list() 的参数 pmac_id_valid 变元设定为 false 时驱动程序可能从网卡的固件请求 PMAC_ID且此函数会在提供的地址 pmac_id 中存储该 PMAC_ID。这是此函数的约定。然而驱动程序中的某个位置可在其中同时传递 pmac_id_valid == false 和 pmac_id == NULL。这可导致取消引用空指针。要解决此问题需要将存根变量的地址传递到该函数。 (CVE-2026-23084)

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

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

  - slimbuscore修复可在接收 report-present 消息时动态分配 report present 的设备引用泄漏。查找已注册设备时务必终止引用。请注意这需要额外引用以防设备尚未注册但必须分配。 (CVE-2026-23090)

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

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

  - PEAR 是一款适用于可重用 PHP 组件的框架和分发系统。在版本 1.33.0 之前，因构建 IN (...) 列表时采用了不安全的文字替换方式，karma 查询过程中存在 SQL 注入风险。已在版本 1.33.0 中修补此问题。(CVE-2026-25236)

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

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

  - w1therm修复 alarms_store 中的差一缓冲区溢出 传递给 alarms_store() 的 sysfs 缓冲区分配有“size + 1”个字节并附加了一个 NUL 终止符。但是，“大小”参数未考虑此额外字节。然后原始代码分配“size”字节并使用 strcpy() 复制“buf”自 strcpy() 复制起始终将一个字节写入超过分配的缓冲区直到索引“size”处的 NUL 终止符。通过使用 simple_strtoll() 直接解析“buf”参数而不分配任何中间内存或字符串复制从而修复此问题。这可在简化代码的同时消除溢出。 (CVE-2025-71197)

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

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

  - canusb_8devusb_8dev_read_bulk_callback()修复 URB 内存泄漏 修复与提交 7352e1d5932a 中类似的内存泄漏 cangs_usbgs_usb_receive_bulk_callback()修复 URB 内存泄漏。在 usb_8dev_open() -> usb_8dev_start() 中已分配 USB-in 传输的 URB、将其添加到 priv->rx_submitted 定位标记并提交。在完整的回调 usb_8dev_read_bulk_callback() 中会对 URB 进行处理并重新提交。
    在 usb_8dev_close() -> unlink_all_urbs() 中通过调用 usb_kill_anchored_urbs(&priv->rx_submitted) 释放 URB。但是，这没有考虑到 USB 框架会在调用 complete 函数之前取消锚定 URB。这表示 in-URB 完成后将不再定位且最终不会在 usb_kill_anchored_urbs() 中释放。通过将 usb_8dev_read_bulk_callback() 中的 URB 定位到 priv->rx_submitted 定位标记来修复内存泄漏。 (CVE-2026-23108)

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

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

  - 在 Moodle 中发现缺陷。此认证绕过漏洞允许暂停的用户通过 Learning Tools Interoperability (LTI) 提供程序进行认证。引起此问题的原因是 LTI 身份验证处理程序无法强制将用户置于暂停状态从而可导致未经授权访问系统。这可导致本应受到限制的用户泄露信息或发生其他未经授权的操作。 (CVE-2025-67848)

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

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

  - ledsled-class仅在完全就绪时将 LED 添加至 leds_list 在此变更之前已在初始化 led_classdev.set_brightness_work 之前调用 led_init_core() 将 LED 添加到列表中。这会留下一个窗口期，其中 LED 的默认触发器的 led_trigger_register() 会调用 led_trigger_set()而后者又调用 led_set_brightness()而后者最终会将*未初始化的* led_classdev.set_brightness_work 排入队列。此争用会受到 lenovo-thinkpad-t14s EC 驱动程序的命中该驱动程序通过 snd_ctl_led.ko 提供的默认触发器快速连续注册 2 个 LED。第一个 led_classdev_register() 造成 snd_ctl_led 的 async modprobe 运行该 async modprobe 设法准确命中第二个 LED 位于 leds_list 上的窗口而未为其调用 led_init_core()从而导致------ -----[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 硬件名称LENOVO 21N2S01F0B/21N2S01F0B BIOS N42ET93W (2.23 ) 2025 年 1 月 9 日 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module +0x7e0/0x998 通过将 LED 到 leds_list 的添加移动到 led_init_core() 调用之后来关闭争用窗口。 (CVE-2026-23101)

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

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

  - timekeeping调整闰秒状态以得到正确的辅助定时器。引入 __do_ajdtimex() 来处理任何定时器的 adjtimex 时对 tk_core 的此引用未更新。在辅助定时器上调用时核心定时器会得到错误更新。这会被锁调试诊断捕获因为 timekeepers 序列锁在未保持其相关自旋锁的情况下进行 CPU#2写入time/timekeeping.c:2979) __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173) do_syscall_64 (arch/x86/entry/syscall_64.c:63鉴别器 1) arch/x86/entry/syscall_64.c:94 (discipline 1)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) 更新正确的辅助 timekeeper。 (CVE-2026-23106)

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

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

  - ksmbdsmbd修复 dma_unmap_sg() nents 应使用与 dma_map_sg() 相同的 nents 调用 dma_unmap_sg() 函数而不是映射函数返回的值。 (CVE-2026-23093)

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

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

  - drm/panel-simple修复了 DataImage SCF0700C48GGU18 面板的连接器类型 缺少 DataImage SCF0700C48GGU18 面板的连接器类型且 devm_drm_panel_bridge_add() 需要设置连接器类型。这会导致内核日志中的警告和回溯以及面板不起作用 WARNINGCPU: 3 PID: 38位于 drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 该警告由devm_drm_panel_bridge_add() 中的有效连接器类型检查。如果未为面板设置有效的连接器类型则不会打印警告且不添加面板。填写缺少的连接器类型以修复警告并使面板再次可操作。 (CVE-2026-23049)

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

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

  - fou不允许 FOU_ATTR_IPPROTO 设置为 0。 fou_udp_recv() 存在上一个修补程序中提及的相同问题。若 FOU_ATTR_IPPROTO 设为 0skb 既不会由 fou_udp_recv() 释放也不会在 ip_protocol_deliver_rcu() 中重新提交。假设 FOU_ATTR_IPPROTO 禁止为 0。 (CVE-2026-23083)

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

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

  - l2tp修复 l2tp_udp_encap_recv() 中的内存泄漏。 syzbot 报告了 l2tp_session、l2tp_tunnel、sock 等结构的内存泄漏。 [0] 引用的提交下移了 l2tp_udp_encap_recv() 中协议版本的验证。新地点需要额外的错误处理以避免内存泄露。在此调用 l2tp_session_put() 即可。 [0]bug }............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... 回溯 ( crc babb6a4f)kmemleak_alloc_recursive include/linux/kmemleak.h:44 [内联] slab_post_alloc_hook mm/slub.c:4958 [内联] slab_alloc_node mm/slub.c:5263 [内联] __do_kmalloc_node mm/slub.c:5656 [内联]
    __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [内联] kzalloc_noprof include/linux/slab.h:1094 [内联] l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c 1778 pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755 __sys_connect_file+0x7a/0xb0 net/socket.c:2089
    __sys_connect+0xde/0x110 net/socket.c:2108 __do_sys_connect net/socket.c:2114 [内联] __se_sys_connect net/socket.c:2111 [内联] __x64_sys_connect+0x1c/0x30 net/socket.c:2111 do_syscall_x64 arch/x86 /entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2026-23072)

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

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

  - iommu/io-pgtable-arm修复了取消映射路径中的 size_t 符号缺陷 __arm_lpae_unmap() 返回 size_t 但在遇到未映射的 PTE 时返回 -ENOENT负错误代码。由于 size_t 未签名
    -ENOENT通常为 -2变为一个巨大的正值64 位系统上为 0xFFFFFFFFFFFFFFFE。此损坏的值通过调用链传播__arm_lpae_unmap() 以 size_t 形式返回 -ENOENT -> arm_lpae_unmap_pages() 返回 -> __iommu_unmap() 将其添加至 iova 地址 -> iommu_pgsize() 由于 iova 损坏触发 BUG_ON 这可造成 IOVA 地址__iommu_unmap() 循环中存在溢出并因无效的地址对齐而在 iommu_pgsize() 中触发 BUG_ON。通过返回 0 而不是 -ENOENT 进行修复。WARN_ON 已指出错误情况并且返回 0 （表示没有任何未映射内容）是 size_t 返回类型的正确语义。这与其他 io-pgtable 实现io-pgtable-arm-v7s、io-pgtable-dart在错误条件下返回 0 的行为一致。 (CVE-2026-23067)

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

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

  - 在 Moodle 中发现一个缺陷。授权逻辑缺陷允许在未进行适当验证的情况下授予徽标，此缺陷主要是由于在徽标授予过程中不完整的角色检查所致。这可使未经授权的用户获得其无权获得的徽标，从而可能导致特权提升或对某些功能进行未经授权的访问。(CVE-2025-67856)

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

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

  - dmaenginexilinxxdma修复 regmap max_register 为 max_register 字段分配寄存器内存区域的大小而不是最后一个寄存器的偏移量。结果是通过 debugfs 从 regmap 读取可导致分段错误 tail /sys/kernel/debug/regmap/xdma.1.auto/registers Unable to handle kernel paging request at virtual address ffff800082f70000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25DABT当前 ELIL = 32 位 SET = 0FnV = 0 EA = 0S1PTW = 0 FSC = 0x07级别 3 转换错误 [...] 调用跟踪regmap_mmio_read32le+0x10/0x30
    _regmap_bus_reg_read+0x74/0xc0 _regmap_read+0x68/0x198 regmap_read+0x54/0x88 regmap_read_debugfs+0x140/0x380 regmap_map_read_file+0x30/0x48 full_proxy_read+0x68/0xc8 vfs_read+0xcc/0x310 ksys_read+0x7c/0x120 __arm64_sys_read+0x24/0x40 invoke_syscall.constprop.0 +0x64/0x108 do_el0_svc+0xb0/0xd8 el0_svc+0x38/0x130 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 代码
    aa1e03e9 d503201f f9400000 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- 注意 tail[1217] 因 irqs 禁用而退出 注意tail[1217] 因 preempt_count 1 分段错误而退出 (CVE-2025-71195)

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

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

  - gue修复具有内部 IP 协议 0 的 skb 内存泄漏。syzbot 报告了如下 skb 内存泄漏。 [0] 重现通过其内部协议 0 生成了 GUE 数据包。 gue_udp_recv() 为 ip_protocol_deliver_rcu() 中的重新提交返回 -guehdr->proto_ctype但这仅适用于非零协议编号。让我们丢弃此类数据包。
    请注意0 为有效数字IPv6 逐跳选项。我认为在 GUE 中封装 HOPOPT 不切实际因此一旦有人开始抱怨我们可以传递重新提交标记指针以区分来自上层的两个零* 无错误 * 重新提交 HOPOPT [0] 缺陷未引用的内存泄漏对象 0xffff888109695a00（大小 240）：comm syz.0.17，pid 6088，jiffies 4294943096 十六进制转储（前 32 字节）：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...... ............ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@............ 回溯 (crc a84b336f)kmemleak_alloc_recursive include/linux/ kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core /skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12 /0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_w rite fs/read_write.c:593 [内联] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2026-23095)

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

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

  - PEAR 是一款适用于可重用 PHP 组件的框架和分发系统。在版本 1.33.0 之前，缺陷订阅删除过程中存在 SQL 注入漏洞，使得攻击者能通过精心构造的电子邮件值注入 SQL。已在版本 1.33.0 中修补此问题。(CVE-2026-25238)

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

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

  - net/sched强制使 teql 只能用作根 qdisc teql 的设计目的是假设它只用作根 qdisc。我们需要检查该限制。尽管不重要我还是会描述一下发现此问题的场景以满足感兴趣的用户。GangMin Kim <km.kim1503@gmail.com> 成功隐蔽一个场景如下ROOT qdisc 1:0 (QFQ) 类 1:1 (weight=15, lmax=16384) netem with delay 6.4s class 1:2 (weight=1, lmax=1514) teql GangMin 发送排入 1:1 (netem) 队列的数据包。此类中 QFQ 对出列的任何调用直到 6.4s 之后才会返回数据包。同时系统会发送第二个数据包并位于 1:2上。 teql 的 enqueue 将返回成功这将激活类 1:2。主要问题是 teql 仅在出列时更新父可见 qlen (sch->q.qlen)。由于 QFQ 只会在扫视成功时调用 dequeueteql 的 peek 始终返回 NULL因此将永远不会调用 dequeue因此 qlen 将保持为 0。考虑到这一点当 GangMin 更新 1:2的 lmax 值时qfq_change_class 会调用qfq_deact_rm_from_agg。由于子 qdisc 的 qlen 未递增因此 qfq 无法停用该类但仍从聚合中释放其指针。因此在netem 的延迟 6.4 秒后重新计划第一个数据包时会访问悬摆指针进而导致 GangMin 造成 UAF。 (CVE-2026-23074)

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

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

  - phyqcom-qusb2修复提前暂停时的空指针取消引用如果在附加 QPHY 实例作为驱动程序数据之前启用运行时 PM这会导致预期有效驱动程序数据的运行时 PM 回调中发生空指针取消引用。有一个小窗口在启用 PM 运行时之后运行时禁止之前可能会在该窗口中运行暂停回调。这会造成启动期间的不定时发生零星崩溃 `` 无法处理虚拟地址 00000000000000a1 处的内核空指针取消引用 [...] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 未受感染 6.16.7+ #116 PREEMPT Workqueuepm pm_runtime_work pstate20000005 (nzCv daif -PAN -UAO -TCO -DIT
    -SSBS BTYPE=--) pc qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2] lr
    pm_generic_runtime_suspend+0x2c/0x44 [...] `` 将 QPHY 实例附加为驱动程序数据然后启用运行时 PM 以防止运行时 PM 回调中发生空指针取消引用。重新排序 pm_runtime_enable() 和 pm_runtime_forbid()以防止可能发生不必要的运行时暂停的短暂窗口。使用 devres 管理的版本确保在驱动程序删除期间对称禁用 PM 运行时以进行正确清理。 (CVE-2025-71193)

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

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

  - ipvlan使 addrs_lock 针对每个端口 使 addrs_lock 针对每个端口而不是针对每个 ipvlan dev。初始代码似乎在任何地址更改都必须在 RTNL 下发生的假设下编写。但 IPv6 的情况并非如此。因此 1) 引入 per-port addrs_lock。 2) 需要修复忘记锁定的位置 (ipvlan_open/ipvlan_close) 不过这似乎是一个非常次要的问题。由于同时在 2 个 CPU 上调用 ipvlan_add_addr() 的可能性极小。但是尽管如此这还是可能导致: 1) ipvlan_addr_busy() 的漏报一个接口会迭代某个 ipvlan 旋转锁下的所有 port->ipvlans + ipvlan->addrs而另一个会在自己的锁下添加 IP。尽管此操作仅适用于 IPv6因为看起来无需 rtnl_lock而只能调用 ipvlan_addr6_event()。 2) 由于在不同 ipvlan->addrs_lock 锁定下调用 ipvlan_ht_addr_add(port)因而存在争用情况这应不会影响性能因为添加/删除 IP 的情况极少发生并且未在快速路径上采用旋转锁。
    (CVE-2026-23103)

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

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

  - PEAR 是一款适用于可重用 PHP 组件的框架和分发系统。在版本 1.33.0 之前，/get/<package>/<version> 端点中存在无需身份验证即可触发的 SQL 注入漏洞，使得远程攻击者能通过精心构造的程序包版本执行任意 SQL。已在版本 1.33.0 中修补此问题。
    (CVE-2026-25241)

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

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

  - ALSActxfi修复音频混合器处理中潜在的 OOB 访问在 ctxfi 驱动程序的音频混合器处理代码中conf 字段用作一种循环索引并在索引回调amixer_index() 和sum_index()中引用。据模糊测试程序最近发现当前代码会在这些函数中造成 OOB 访问。 | | UBSAN/build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 中的 array-index-out-of-bounds 索引 8 超出“unsigned char [8]”类型的范围 分析后发现原因是缺少对 conj 字段的正确、重新初始化。
    此修补程序通过添加循环索引的正确初始化来解决这些 OOB 访问。
    (CVE-2026-23076)

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

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

  - arm64/fpsimdsignal在还原 ZA 时分配 SSVE 存储 用于还原 ZA 上下文的代码未在设置 TIF_SME 之前尝试分配任务的 sve_state。因此还原 ZA 上下文可将任务置于无效状态即设置了 TIF_SME 但任务的 sve_state 为 NULL。在合法但不常见的情况下即内核没有在相同任务的环境中创建 ZA 信号上下文例如使用 CRIU 之类的内容保存/还原时我们不保证之前已分配 sve_state。在这些情况下当 sve_state 为空时用户空间可进入流模式而不设陷阱| 从而导致稍后在内核尝试存储寄存器状态时发生空指针取消引用/sigreturn-za |无法处理虚拟地址 0000000000000000 处的内核空指针取消引用 |内存中止信息| ESR = 0x0000000096000046 | | EC = 0x25DABT当前 ELIL = 32 位 | | SET = 0FnV = 0 | | EA = 0S1PTW = 0 | | FSC = 0x06 级别 2 转换错误数据中止信息| ISV = 0ISS = 0x00000046ISS2 = 0x00000000 | CM = 0WnR = 1TnD = 0TagAccess = 0 | | GCS = 0Overlay = 0 DirtyBit = 0Xs = 0 | user pgtable4k 页面52 位 VA pgdp=0000000101f47c00 | | user-defined [0000000000000000] pgd=08000001021d8403、p4d=0800000102274403、 pud=0800000102275403、 pmd=0000000000000000 | | p4内部错误
    错误0000000096000046 [#1] SMP |中链接的模块| CPU0 UID0 PID153 Commsigreturn-za 未受感染 6.19.0-rc1 #1 PREEMPT |硬件名称linux,dummy-virt (DT) | pstate214000c9 (nzCv daIF +PAN
    -UAO -TCO +DIT -SSBS BTYPE=--) | | pc sve_save_state+0x4/0xf0 | lr fpsimd_save_user_state+0xb0/0x1c0 | | sp ffff80008070bcc0 | sp x29ffff80008070bcc0 x28fff00000c1ca4c40 x2763cfa172fb5cf658 | x26
    fff00000c1ca5228 x250000000000000000 x240000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x200000000000000020 x19fff00000ff6900f0 x180000000000000000 | x17
    | fff05e8e0311f000 x160000000000000000 x15028fca8f3bdaf21c | x140000000000000212 x13fff00000c0209f10 x120000000000000020 | x110000000000200b20 x100000000000000000 x9 : fff00000ff69dcc0 | x8
    00000000000003f2 x7 : 0000000000000001 x6: fff00000c1ca5b48 | | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | | x2 0000000000000001 x1fff00000c1ca5970 x00000000000000440 |调用跟踪sve_save_state+0x4/0xf0 (P) | | fpsimd_thread_switch+0x48/0x198 | fpsimd_thread_switch+0x48/0x198 __switch_to+0x20/0x1c0 | __switch_to+0x20/0x1c0 | __switch_to+0x20/0x1c0
    __schedule+0x36c/0xce0 | schedule+0x34/0x11c | schedule+0x34/0x11c | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | | __el0_irq_handler_common+0x18/0x24 | | el0t_64_irq_handler+0x10/0x1c | | el0t_64_irq+0x198/0x19c | | 代码54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ 结束跟踪 0000000000000000 ]--- 通过使 restore_za_context() 修复此问题确保分配任务的 sve_state与我们在获取 SME 陷阱时执行的操作匹配。必须保留任何实时 SVE/SSVE 状态（之前已从单独的信号上下文还原），因此不会将其归零。 (CVE-2026-23107)

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

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

  - phystm32-usphyc修复 probe() 中的差一索引变量用作具有 usbphyc->nphys 元素的 usbphyc->phys[] 数组的索引。因此如果其等于 usbphyc->nphys则为越界元素。该索引来自设备树因此是我们信任的数据并且不可能是错误但它显然仍然值得修复该缺陷。将 > 更改为 >=。
    (CVE-2025-71196)

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

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

  - 在 Moodle 中发现缺陷。远程攻击者可利用确认电子邮件服务中缺少适当速率限制的漏洞。此漏洞可让攻击者更容易地枚举或猜测用户凭据从而有助于对用户帐户进行蛮力攻击。 (CVE-2025-67853)

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

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

  - 已修复 Linux 内核中的下列漏洞：btrfs: fix NULL pointer dereference in do_abort_log_replay() Coverity reported a NULL pointer dereference issue (CID 1666756) in do_abort_log_replay(). When btrfs_alloc_path() fails in replay_one_buffer(), wc->subvol_path is NULL, but btrfs_abort_log_replay() calls do_abort_log_replay() which unconditionally dereferences wc->subvol_path when attempting to print debug information. Fix this by adding a NULL check before dereferencing wc->subvol_path in do_abort_log_replay(). (CVE-2026-23043)

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

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

  - canmcba_usbmcba_usb_read_bulk_callback()修复 URB 内存泄漏 修复与提交 7352e1d5932a 中类似的内存泄漏 (cangs_usbgs_usb_receive_bulk_callback()修复 URB 内存泄漏)。在 mcba_usb_probe() -> mcba_usb_start() 中已分配 USB-in 传输的 URB、将其添加至 priv->rx_submitted 定位标记并提交。在完整的回调 mcba_usb_read_bulk_callback() 中系统会处理并重新提交 URB。
    在 mcba_usb_close() -> mcba_urb_unlink() 中通过调用 usb_kill_anchored_urbs(&priv->rx_submitted) 释放 URB。但是，这没有考虑到 USB 框架会在调用 complete 函数之前取消锚定 URB。这表示 in-URB 完成后将不再定位且最终不会在 usb_kill_anchored_urbs() 中释放。通过将 mcba_usb_read_bulk_callback() 中的 URB 定位到 priv->rx_submitted 定位标记来修复内存泄漏。
    (CVE-2026-23080)

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

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

  - rxrpc修复 recvmsg() 无条件重新排队如果 rxrpc_recvmsg() 因指定了 MSG_DONTWAIT 但 recvmsg 队列前端的调用其互斥体已锁定而失败则该调用会重新排队 - 无论该调用是否已排队。调用在队列中可能因为也传递了 MSG_PEEK致使调用未出列或者因为 I/O 线程将其重新排队。此后无条件的重新排队可能会损坏 recvmsg 队列从而导致 UAF 或 refcount 欠载运行等情况。通过仅在呼叫尚未进入队列时才将其重新排队并在已进入队列中时将其移动到前面来修复此问题。如果不将其排入队列则必须放置通过使其出列而获得的 ref 。此外MSG_PEEK 不会使调用出列因此如果我们未用完队列中的所有数据MSG_PEEK 不应针对该调用调用 rxrpc_notify_socket()因此也请修复此问题。 (CVE-2026-23066)

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

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

  - libceph使 calc_target() 设置 t->paused 而不仅仅是清除它 当前如果请求不应再暂停 calc_target() 会清除 t->paused 但从未设置 t->paused即使它可以以确定何时应暂停请求。将 t->paused 保留在 __submit_request() 中这适用于常规请求但对延迟请求不起作用 -- 由于 __submit_request() 不对延迟请求操作因此 lreq->t.paused 无处可设置被设置。这样做的后果是在请求暂停时间足够长、足以使取消监视请求超时且后续的（重新）监视请求进入暂停状态的情况下，在暂停 -> 取消暂停转换时不会重新建立监视state。除了未重新建立监视之外rbd_reregister_watch() 还因 rbd_dev->watch_mutexheldrbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_wait 而停滞不前。其正在等待 lreq->reg_commit_wait 完成但要发生此情况需在 need_resend_linger 上结束相应的请求列出并在请求取消暂停时被踢出。如果相关请求一开始就从未被标记为暂停则不可能出现这种情况。事实上rbd_dev->watch_mutex 永远保持在取出状态然后防止图像取消映射 -- 在尝试获取互斥体时rbd unmap 将无法避免地在 D 状态下挂起。 (CVE-2026-23047)

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

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

  - 在 Moodle 中发现缺陷。此跨站脚本 (XSS) 漏洞由 AI 提示响应审查不当所导致其允许攻击者将恶意 HTML 或脚本注入网页。当其他用户查看这些遭到入侵的页面时，他们的会话可能会被窃取，或者用户界面可能会被操纵。 (CVE-2025-67849)

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

ID	名称	严重性
297931	Linux Distros 未修补的漏洞：CVE-2026-23077	medium
297930	Linux Distros 未修补的漏洞：CVE-2026-23044	medium
297929	Linux Distros 未修补的漏洞：CVE-2025-67857	medium
297928	Linux Distros 未修补的漏洞：CVE-2026-25237	critical
297927	Linux Distros 未修补的漏洞：CVE-2026-23104	medium
297926	Linux Distros 未修补的漏洞：CVE-2026-23045	medium
297925	Linux Distros 未修补的漏洞：CVE-2026-23099	medium
297924	Linux Distros 未修补的漏洞：CVE-2026-23092	high
297923	Linux Distros 未修补的漏洞：CVE-2026-23088	medium
297922	Linux Distros 未修补的漏洞：CVE-2026-23089	high
297921	Linux Distros 未修补的漏洞：CVE-2026-23086	medium
297920	Linux Distros 未修补的漏洞：CVE-2026-23064	medium
297919	Linux Distros 未修补的漏洞：CVE-2026-23078	high
297918	Linux Distros 未修补的漏洞：CVE-2025-71194	low
297917	Linux Distros 未修补的漏洞：CVE-2026-23094	high
297916	Linux Distros 未修补的漏洞：CVE-2025-71198	medium
297915	Linux Distros 未修补的漏洞：CVE-2026-25235	high
297914	Linux Distros 未修补的漏洞：CVE-2026-23042	medium
297913	Linux Distros 未修补的漏洞：CVE-2025-71199	high
297912	Linux Distros 未修补的漏洞：CVE-2025-67855	medium
297911	Linux Distros 未修补的漏洞：CVE-2026-23084	medium
297909	Linux Distros 未修补的漏洞：CVE-2026-23090	high
297908	Linux Distros 未修补的漏洞：CVE-2026-25236	medium
297907	Linux Distros 未修补的漏洞：CVE-2025-71197	high
297906	Linux Distros 未修补的漏洞：CVE-2026-23108	medium
297905	Linux Distros 未修补的漏洞：CVE-2025-67848	high
297904	Linux Distros 未修补的漏洞：CVE-2026-23101	medium
297903	Linux Distros 未修补的漏洞：CVE-2026-23106	medium
297902	Linux Distros 未修补的漏洞：CVE-2026-23093	medium
297901	Linux Distros 未修补的漏洞：CVE-2026-23049	high
297900	Linux Distros 未修补的漏洞：CVE-2026-23083	medium
297899	Linux Distros 未修补的漏洞：CVE-2026-23072	medium
297898	Linux Distros 未修补的漏洞：CVE-2026-23067	medium
297897	Linux Distros 未修补的漏洞：CVE-2025-67856	critical
297896	Linux Distros 未修补的漏洞：CVE-2025-71195	medium
297895	Linux Distros 未修补的漏洞：CVE-2026-23095	medium
297894	Linux Distros 未修补的漏洞：CVE-2026-25238	critical
297893	Linux Distros 未修补的漏洞：CVE-2026-23074	high
297892	Linux Distros 未修补的漏洞：CVE-2025-71193	medium
297891	Linux Distros 未修补的漏洞：CVE-2026-23103	medium
297890	Linux Distros 未修补的漏洞：CVE-2026-25241	critical
297889	Linux Distros 未修补的漏洞：CVE-2026-23076	high
297888	Linux Distros 未修补的漏洞：CVE-2026-23107	medium
297887	Linux Distros 未修补的漏洞：CVE-2025-71196	high
297886	Linux Distros 未修补的漏洞：CVE-2025-67853	high
297885	Linux Distros 未修补的漏洞：CVE-2026-23043	medium
297884	Linux Distros 未修补的漏洞：CVE-2026-23080	medium
297883	Linux Distros 未修补的漏洞：CVE-2026-23066	medium
297882	Linux Distros 未修补的漏洞：CVE-2026-23047	medium
297881	Linux Distros 未修补的漏洞：CVE-2025-67849	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

critical

medium

medium

medium

high

medium

high

medium

medium

high

low

high

medium

high

medium

high

medium

medium

high

medium

high

medium

high

medium

medium

medium

high

medium

medium

medium

critical

medium

medium

critical

high

medium

medium

critical

high

medium

high

high

medium

medium

medium

medium

medium