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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c .
    d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted a . b, even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (netfilter: nft_set_pipapo: fix range overlap detection) but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map. (CVE-2026-43114)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  - net：af_key：PF_KEY导出PF_KEY导出路径中的零对齐 sockaddr 尾部在预留 sockaddr 负载空间时使用“pfkey_sockaddr_size（）”，因此 IPv6 地址在线上占用 32 字节。但是，“pfkey_sockaddr_fill（）”仅初始化“struct sockaddr_in6”的前 28 个字节，而使最后 4 个对齐字节处于未初始化状态。并非每条PF_KEY消息都会受到影响。状态和策略转储生成器在填充 sockaddr 负载之前，已经将整个消息缓冲区归零。保留对仍以普通“skb_put（）”附加对齐 sockaddr 负载的导出路径的补丁： - 'SADB_ACQUIRE' - 'SADB_X_NAT_T_NEW_MAPPING' -'SADB_X_MIGRATE' 通过仅清除“pfkey_sockaddr_fill（）”之后对齐的 sockaddr 末尾来修复这些路径。（CVE-2026-43088）

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

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

  - 蓝牙：MGMT：修复列表损坏和命令中UAF的完整处理程序提交302a1f674c00（蓝牙：
    MGMT：修复可能的UAFs）引入了mgmt_pending_valid（），不仅验证待处理命令，还会在有效时将其从待处理列表中移除链接。这种语义变化需要更新多个补全处理程序，以避免列表损坏和内存安全问题。该补丁解决了上述重做遗留的两个问题：1. 在mgmt_add_adv_patterns_monitor_complete（），成功路径中的mgmt_pending_remove（）被替换为mgmt_pending_free（）。由于 mgmt_pending_valid（） 已经在函数开头解绑了命令，调用 mgmt_pending_remove（） 会导致双重 list_del（） 以及随后的列表损坏/内核恐慌。2. 在set_mesh_complete（），错误路径中mgmt_pending_foreach（）的使用被移除。由于当前命令已经通过 mgmt_pending_valid（）解除链接，这个 foreach 循环会错误地指向其他待处理的 mesh 命令，可能导致它们在同时处理时释放它们（导致 UAF）。冗余mgmt_cmd_status（）也简化为直接使用cmd->opcode。（CVE-2026-43059）

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

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

  - gobgp v4.3.0 的 ParseIP6Extended 函数（/bgp/bgp.go）中的越界读取允许攻击者通过提供精心设计的 BGP UPDATE 消息来引发拒绝服务（DoS）。（CVE-2026-37461）

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

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

  - net：lapbether：句柄 NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit（） 预期底层设备类型为 ARPHRD_ETHER。从 lapbeth_device_event（） 返回NOTIFY_BAD确保绑定驱动程序无法打破此预期。（CVE-2026-43103）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary. Add the check to the reassignment so that this does not happen. Also update the comment which still refers to the obsolete offset argument.
    (CVE-2026-43078)

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

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

  - Jupyter Server 是 Jupyter Web 应用程序的后端。在及更早版本 2.17.0 中，REST API 中的路径遍历漏洞允许经身份验证的用户转义已配置的root_dir，并访问名称开头与root_dir相同的同级目录。例如，使用名为 test 的 root_dir，API 允许通过使用编码路径组件的 /api/contents 端点的构建请求访问名为 testtest 的同级目录。攻击者可读取、写入和删除受影响的同级目录中的文件。使用可预测命名方案的多租户部署尤其面临风险，因为目录名为 user1 的用户可访问 user10 到 user19 及更远版本的目录。能够选择单一字符文件夹名称的用户可获得对大量同级目录的访问权限。版本 2.18.0 包含一个补丁。作为变通方案，确保文件夹名称不与任何同级目录共享公共前缀。（CVE-2026-35397）

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

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

  - Jupyter Server 是 Jupyter Web 应用程序的后端。在版本和更旧版本 2.17.0 中，Origin 标头验证使用 Python 的 re.match（） 根据 allow_origin_pat 配置值检查传入源。由于 re.match（） 仅在字符串的开头定位，不需要完全匹配，因此旨在仅匹配受信任域（例如 trusted.example.com）的模式也将匹配以该域开头并跟有附加字符（例如 trusted.example.com.evil.com）的任何源。控制此类域的攻击者可绕过 CORS 源限制，并从不受信任的站点向 Jupyter Server API 发出跨源请求。此问题已在 2.18.0 版本中修复。(CVE-2026-40110)

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

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

  - wifi：brcmfmac：验证 IF 事件中的 bsscfg 索引 brcmf_fweh_handle_if_event（） 会在接触 drvr->iflist[] 之前验证固件提供的接口索引，但仍使用原始 bsscfgidx 字段作为数组索引，且未进行匹配范围检查。为接口数组编制索引之前，拒绝 bsscfg 索引不适合 drvr->iflist[] 的 IF 事件。[添加缺失的 wifi 前缀]（CVE-2026-43110）

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

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

  - Prometheus 是一个开源的监测系统和时间序列数据库。在版本3.5.33.11.3和之前，远程读取端点（/api/v1/read）在分配内存前不会在快速压缩的请求体中验证声明的解码长度。未认证的攻击者可能会发送一个小负载，导致每个请求分配大量堆。在并发负载下，这可能会耗尽可用内存并导致 Prometheus 进程崩溃。已在 3.5.3 和 3.11.3 中修补此问题。
    (CVE-2026-42154)

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

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

  - RedisTimeSeries 是 Redis 的时间序列模块。在 RedisTimeSeries 之前 1.12.14 的所有版本中，该模块未正确验证通过 Redis RESTORE 命令处理的序列化值。如果经身份验证的攻击者有权限在加载了 RedisTimeSeries 模块的服务器上执行 RESTORE，则可提供会触发无效内存访问并可能导致远程代码执行的序列化负载。变通方案是通过 ACL 规则限制对 RESTORE 命令的访问。已在版本 1.12.14.（CVE-2026-25588）

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

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

  - btrfs：tracepoints：从事件 btrfs_sync_file（） 中的 dentry 获取正确的超级块 如果在 btrfs 之上使用叠加，dentry->d_sb 会转换为叠加的超级块，并且 fsid 分配将导致崩溃。
    使用 file_inode（file）->i_sb 以始终获取btrfs_sb。 （CVE-2026-43117）

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

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

  - fs/smb/client：修复 cifs_sanitize_prepath 中的越界读取 当使用空字符串或仅包含分隔符的字符串（如 /）调用 cifs_sanitize_prepath 时，当前逻辑会尝试检查
    *（cursor2 - 1） 在 cursor2 前进之前。这会导致越界读取。此修补程序添加了剥离预置分隔符后的提前退出检查。如果没有路径内容，函数将返回 NULL。该缺陷通过手动审核确认，并使用使用 AddressSanitizer 编译的独立测试用例进行验证，这会触发受影响输入的 SEGV。（CVE-2026-43112）

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

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

  - 通过 OCSP 响应数据的 Apache HTTP 服务器的 mod_md 中无限制或节流的资源分配漏洞。此问题会影响 Apache HTTP Server 2.4.30 至 2.4.66（含）。建议用户升级到修复了此问题的版本 2.4.67。(CVE-2026-29168)

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

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

  - Redis 是内存内数据结构存储。在 redis-server from 7.2.08.6.3until 中，重新执行阻止的命令时，unblock 客户端流程不会处理来自“processCommandAndResetClient”的错误返回。如果阻止的客户端在此流期间被逐出，经过身份验证的攻击者可能会触发可能导致远程代码执行的释放后使用。已在版本 8.6.3.
    (CVE-2026-23479)

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

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

  - netfilter：nfnetlink_log：初始化 NLMSG_DONE 终止符中的 nfgenmsg 当批处理多个 NFLOG 消息 （inst->qlen > 1） 时，__nfulnl_send（） 通过 nlmsg_put（） 附加具有 sizeof（struct nfgenmsg） 负载的 NLMSG_DONE 终止符，但从不初始化 nfgenmsg 字节。nlmsg_put（） 帮助程序仅将负载之后的对齐填充清零，而不是负载本身，因此有四个字节的过时内核堆数据泄漏到NLMSG_DONE消息正文中的用户空间。使用 nfnl_msg_put（） 构建 NLMSG_DONE 终止符，通过 nfnl_fill_hdr（） 初始化 nfgenmsg 负载，这与 __build_packet_message（） 构建 NFULNL_MSG_PACKET 标头的方式一致。（CVE-2026-43085）

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

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

  - HID：roccat：修复在不保留readers_lock的情况下迭代设备>读者列表的 roccat_report_event roccat_report_event（） 中的释放后使用。这允许并行 roccat_release（） 在仍在访问阅读器时将其删除和释放，从而导致释放后使用。使用 readers_lock 互斥体保护读者列表遍历。（CVE-2026-43111）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: algif_aead - Fix minimum RX size check for decryption The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length. (CVE-2026-43077)

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

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

  - xfrm：事件大小计算中的帐户XFRMA_IF_ID xfrm_get_ae（） 通过 xfrm_aevent_msgsize（） 分配回复 skb，然后在设置 x->if_id 时 build_aevent（） 附加包括 XFRMA_IF_ID 在内的属性。
    xfrm_aevent_msgsize（） 不包含用于XFRMA_IF_ID的空间。对于具有 if_id 的状态，build_aevent（） 可因 -EMSGSIZE 而失败并在 xfrm_get_ae（） 中命中 BUG_ON（err < 0），从而将畸形 netlink 交互转变为内核错误。在大小计算中无条件考虑XFRMA_IF_ID，并将BUG_ON替换为普通错误展开。（CVE-2026-43107）

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

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

  - FRRouting中的整数下溢（FRR）stable/10.0 to stable/10.6 允许攻击者通过提供精心设计的 BGP UPDATE 消息来引发拒绝服务（DoS）。（CVE-2026-37459）

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

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

  - Redis 是内存内数据结构存储。在 redis-server 及之前 8.6.3版本中，RESTORE 命令未正确验证序列化值。具有执行 RESTORE 权限的经身份验证的攻击者可提供特制的序列化负载，触发无效的内存访问，并可能导致远程代码执行。变通方案是通过 ACL 规则限制对 RESTORE 命令的访问。此问题已在版本 8.6.3 中得到修补。(CVE-2026-25243)

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

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

  - ocfs2：在 inode 读取期间验证内联数据i_size 从磁盘读取 inode 时，ocfs2_validate_inode_block（） 会执行各种健全性检查，但不会验证内联数据的大小。
    如果文件系统损坏，inode 的i_size可超过实际的内联数据容量 （id_count）。
    这导致 ocfs2_dir_foreach_blk_id（） 在内联数据缓冲区之外迭代，从而在从已释放的内存访问目录条目时触发释放后使用。在 syzbot 报告中：- i_size 1099511627576字节 （~1TB） - 实际内联数据容量 （id_count） 通常为 <256 字节 - 垃圾rec_len （54648） 导致 ctx->pos 跳出越界 - 这触发了 ocfs2_check_dir_entry（） 中的 UAF 通过在 ocfs2_validate_inode_block（） 中添加验证检查来修复，以确保具有内联数据的 inode 具有 i_size <= id_count。这可在 inode 读取期间及早捕获损坏，并阻止所有下游代码操作无效数据。（CVE-2026-43076）

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

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

  - XFS：如果xfs_attri_recover_work xlog_recovery_iget*中iGet失败，Irele就永远不要设置@ip有效指针，因此这个Irele会离开悬挂的指针。解决这个问题。
    (CVE-2026-43063)

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

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

  - dmaengine：idxd：修复不在 .release（） 上释放工作队列的问题 释放对象时，不释放与 DSA/IAA 设备相关的工作队列。（CVE-2026-43064）

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

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

  - drm/vc4：修复挂起状态中 BO 数组的内存泄漏 挂起状态的 BO 数组在 vc4_save_hang_state（） 中与 kzalloc（） 单独分配，但从未在 vc4_free_hang_state（） 中释放。在释放挂起状态结构之前，添加 BO 数组缺少的 kfree（）。（CVE-2026-43105）

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

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

  - ext4：始终耗尽 ext4_mb_release（） 中已排入队列的丢弃工作 在查看最近的 ext4 修补程序[1]时，Sashiko 提出了以下问题[2]：> 如果文件系统最初挂载时挂载了 discard 选项，>删除文件将填充 sbi->s_discard_list 和排队> s_discard_work。如果随后使用 nodiscard 重新挂载，> EXT4_MOUNT_DISCARD 标记将被清除，但待定s_discard_work>既未取消也未刷新。[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev 此问题是合理的，但与修补程序[1] 无关。当前（早期）形式的 Sashiko 的问题之一是它将检测预先存在的问题并将其报告为正在查看的修补程序的问题。实际上很难故意命中（除非您是恶意的 syzkaller fuzzer），因为这将涉及到 -o discard 挂载文件系统，然后删除大量文件，使用 -o nodiscard 重新挂载文件系统，然后在排队的 discard 工作发生更改自行耗尽之前立即卸载文件系统。由于这是真实缺陷，因此应予以修复，并避免 Sashiko 在分析 mballoc.c 的未来修补程序时提出此问题。（CVE-2026-43065）

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

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

  - xfrm：在策略 netns 退出期间等待 RCU 读取器 xfrm_policy_fini（） 在刷新策略工作项并删除所有策略后释放policy_bydst哈希表，但不会等待并发 RCU 读取器首先离开其读取端关键部分。policy_bydst表通过 rcu_assign_pointer（） 发布并通过 rcu_dereference_check（） 进行查找，因此 netns 拆卸也必须等待 RCU 宽限期后才能释放表内存。通过在释放策略哈希表前添加 synchronize_rcu（） 来修复此问题。（CVE-2026-43091）

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

ID	名称	严重性
312644	Linux Distros 未修补的漏洞：CVE-2026-25589	high
312643	Linux Distros 未修补的漏洞：CVE-2026-43116	high
312642	Linux Distros 未修补的漏洞：CVE-2026-43098	medium
312641	Linux Distros 未修补的漏洞：CVE-2026-43118	medium
312640	Linux Distros 未修补的漏洞：CVE-2026-43104	medium
312639	Linux Distros 未修补的漏洞：CVE-2026-43080	medium
312638	Linux Distros 未修补的漏洞：CVE-2026-43070	high
312637	Linux Distros 未修补的漏洞：CVE-2026-43099	high
312636	Linux Distros 未修补的漏洞：CVE-2026-43119	medium
312635	Linux Distros 未修补的漏洞：CVE-2026-23631	medium
312634	Linux Distros 未修补的漏洞：CVE-2026-44405	low
312633	Linux Distros 未修补的漏洞：CVE-2026-43075	high
312632	Linux Distros 未修补的漏洞：CVE-2026-42151	high
312631	Linux Distros 未修补的漏洞：CVE-2026-43120	high
312630	Linux Distros 未修补的漏洞：CVE-2026-43094	medium
312629	Linux Distros 未修补的漏洞：CVE-2026-43089	medium
312628	Linux Distros 未修补的漏洞：CVE-2026-29004	high
312627	Linux Distros 未修补的漏洞：CVE-2026-40934	high
312626	Linux Distros 未修补的漏洞：CVE-2026-43114	high
312625	Linux Distros 未修补的漏洞：CVE-2026-44331	high
312624	Linux Distros 未修补的漏洞：CVE-2026-43067	critical
312623	Linux Distros 未修补的漏洞：CVE-2026-43113	high
312622	Linux Distros 未修补的漏洞：CVE-2026-37458	medium
312621	Linux Distros 未修补的漏洞：CVE-2026-43115	medium
312620	Linux Distros 未修补的漏洞：CVE-2026-43088	medium
312619	Linux Distros 未修补的漏洞：CVE-2026-43059	high
312618	Linux Distros 未修补的漏洞：CVE-2026-37461	high
312617	Linux Distros 未修补的漏洞：CVE-2026-43103	medium
312616	Linux Distros 未修补的漏洞：CVE-2026-43078	high
312615	Linux Distros 未修补的漏洞：CVE-2026-35397	high
312614	Linux Distros 未修补的漏洞：CVE-2026-40110	high
312613	Linux Distros 未修补的漏洞：CVE-2026-43110	high
312612	Linux Distros 未修补的漏洞：CVE-2026-42154	high
312611	Linux Distros 未修补的漏洞：CVE-2026-25588	high
312610	Linux Distros 未修补的漏洞：CVE-2026-43117	critical
312609	Linux Distros 未修补的漏洞：CVE-2026-43112	high
312608	Linux Distros 未修补的漏洞：CVE-2026-29168	high
312607	Linux Distros 未修补的漏洞：CVE-2026-23479	high
312606	Linux Distros 未修补的漏洞：CVE-2026-43085	medium
312605	Linux Distros 未修补的漏洞：CVE-2026-43111	high
312604	Linux Distros 未修补的漏洞：CVE-2026-43077	medium
312603	Linux Distros 未修补的漏洞：CVE-2026-43107	medium
312602	Linux Distros 未修补的漏洞：CVE-2026-37459	high
312601	Linux Distros 未修补的漏洞：CVE-2026-25243	high
312600	Linux Distros 未修补的漏洞：CVE-2026-43076	high
312599	Linux Distros 未修补的漏洞：CVE-2026-43063	high
312598	Linux Distros 未修补的漏洞：CVE-2026-43064	medium
312597	Linux Distros 未修补的漏洞：CVE-2026-43105	medium
312596	Linux Distros 未修补的漏洞：CVE-2026-43065	medium
312595	Linux Distros 未修补的漏洞：CVE-2026-43091	high

检测

Nessus 的 Misc. 系列

high

high

medium

medium

medium

medium

high

high

medium

medium

low

high

high

high

medium

medium

high

high

high

high

critical

high

medium

medium

medium

high

high

medium

high

high

high

high

high

high

critical

high

high

high

medium

high

medium

medium

high

high

high

high

medium

medium

medium

high