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

  - Pillow 是 Python 图像库。从版本 10.3.0 到以前的版本 12.2.0，处理恶意 PSD 文件可导致内存损坏，从而可能导致崩溃或任意代码执行。
    已在版本 12.2.0 中修补此问题。(CVE-2026-42311)

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

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

  - 如果服务器发送缺少 SQLSTATE 字段的错误响应，之前 PgBouncer 中 1.25.2 可能存在的空指针引用可导致崩溃。（CVE-2026-6666）

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

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

  - 在 PgBouncer 1.25.2 中，网络数据包解析代码中的一个整数溢出会绕过边界检查，并可能导致崩溃。未经认证的远程攻击者可使用畸形 SCRAM 认证数据包造成 PgBouncer 崩溃。（CVE-2026-6664）

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

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

  - 之前 1.25.2 PgBouncer 中的 SCRAM 代码在构建 SCRAM client-final-message 的内容时未正确检查 strlcat（） 的返回值。发送含有长 nonce 的 SCRAM server-final-message 的恶意后端可触发堆栈溢出。（CVE-2026-6665）

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

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

  - net/mlx5：修复 devlink 锁定与 esw->wq 之间的死锁 esw->work_queue 执行 esw_functions_changed_event_handler -> esw_vfs_changed_event_handler 并取得 devlink 锁定。
    .eswitch_mode_set（获取 devlink_nl_pre_doit 中的 devlink 锁定） -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue esw_vfs_changed_event_handler执行时死锁。通过不再刷新工作以避免死锁，并使用生成计数器跟踪工作相关性，来修复该问题。这可避免旧处理程序操控经历过一个或多个模式变更的 esw：- 计数器在 mlx5_eswitch_event_handler_unregister 中递增。- 读取计数器并将其传递给临时mlx5_host_work结构。- 如果当前世代与计划运行的世代不同，则工作处理程序会获取 devlink 锁定并退出。- mlx5_eswitch_cleanup在破坏 wq 之前进行最后的排空。不再刷新工作队列的副作用是可能不再取消待定的 vport_change_handler 工作项，但这没关系，因为其他位置已禁用这些项目：- mlx5_eswitch_disable_locked 禁用 vport eq 通知程序。- mlx5_esw_vport_disable解除 HW EQ 通知，并将 state_lock 下的 vport->enabled 标记为 false，以防止待定的 vport 处理程序执行任何操作。- mlx5_eswitch_cleanup会破坏工作队列并确保所有事件都已禁用/完成。（CVE-2026-43468）

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

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

  - nfs：如果 d_alias 是目录，则返回nfs3_proc_create的 EISDIR 如果通过 nfs3_do_create/nfs_add_or_obtain /d_splice_alias 找到一个恰好是目录目录项的别名，我们不会返回任何错误，只是忘记了这个别名，但我们添加并作为参数传递的原始目录项仍然是负数。这稍后会造成 nfs_atomic_open_v23/finish_open 发生 oops，因为我们向 do_dentry_open 提供负目录项。在运行 lustre-racer 时发现此问题，其中目录和文件以相同的名称并发创建/删除，并且不使用 O_EXCL 打开文件（频繁的文件重定向）。虽然 d_splice_alias 通常会返回目录别名或 NULL，但我们会明确检查 d_is_dir（） 以确保不会尝试对目录 inode 执行文件操作（如 finish_open），从而触发观察到的 oops。（CVE-2026-43470）

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

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

  - netfilter：nf_tables：修复 netdev 挂钩中的重复设备 处理NETDEV_REGISTER通知时，必须避免重复的设备注册，因为创建挂钩时可能已由 nft_netdev_hook_alloc（） 添加设备。（CVE-2026-43454）

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

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

  - net/mlx5：修复切换到 switchdev 模式时的崩溃 当设备不支持 IPsec 时切换到 switchdev 模式时，我们还是会尝试清理会导致崩溃的 IPsec 资源，请通过在尝试清理其资源之前正确检查 IPsec 支持来修复此问题。[27642.515799] 警告：
    arch/x86/mm/fault.c：1276 at do_user_addr_fault+0x18a/0x680， CPU#4： devlink/6490 [27642.517159] 模块链接于：xt_conntrack xt_MASQUERADE ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype rpcsec_gss_krb5 auth_rpcgss oid_registry叠加mlx5_fwctl nfnetlink zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core ib_core [27642.521358] CPU：4 UID：0 PID：6490 通信：devlink 未受感染 6.19.0-rc5_for_upstream_min_debug_2026_01_14_16_47 #1 无 [27642.522923] 硬件名称：QEMU 标准 PC （Q35 + ICH9,2009），BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 2014 年 4 月 1 日 [27642.524528] RIP：
    0010：do_user_addr_fault+0x18a/0x680 [27642.525362] 代码： ff 0f 84 75 03 00 00 48 89 ee 4c 89 e7 e8 5e b9 22 00 49 89 c0 48 85 c0 0f 84 a8 02 00 00 f7 c3 60 80 00 00 74 22 31 c9 eb ae <0f> 0b 48 83 c4 10 48 89 ea 48 89 de 4c 89 f7 5b 5d 41 5c 41 5d 41 [27642.528166] RSP： 0018：ffff88810770f6b8 EFLAGS：00010046 [27642.529038] RAX：0000000000000000 RBX：0000000000000002 RCX：ffff88810b980f00 [27642.530158] RDX：
    000000000000000a0 RSI：0000000000000002 RDI：ffff88810770f728 [27642.531270] RBP：00000000000000a0 R08：
    0000000000000000 R09: 0000000000000000 [27642.532383] R10: 0000000000000000 R11: 0000000000000000 R12:
    ffff888103f3c4c0 [27642.533499] R13： 0000000000000000 R14： ffff88810770f728 R15： 0000000000000000 [27642.534614] FS： 00007f197c741740（0000） GS：ffff88856a94c000（0000） knlGS：0000000000000000 [27642.535915] CS：0010 DS： 0000 ES： 0000 CR0： 0000000080050033 [27642.536858] CR2： 000000000000000a0 CR3：
    000000011334c003 CR4： 00000000000172eb0 [27642.537982] 调用跟踪： [27642.538466] [27642.538907] <TASK> exc_page_fault+0x76/0x140 [27642.539583] asm_exc_page_fault+0x22/0x30 [27642.540282] RIP：
    0010：_raw_spin_lock_irqsave+0x10/0x30 [27642.541134] 代码：07 85 c0 75 11 ba ff 00 00 00 f0 0f b1 17 75 06 b8 01 00 00 00 c3 31 c0 c3 90 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 0f <f0> b1 17 75 05 48 89 d8 5b c3 89 c6 e8 7e 02 00 00 48 89 d8 5b [27642.543936] RSP： 0018：ffff88810770f7d8 EFLAGS：00010046 [27642.544803] RAX：0000000000000000 RBX：0000000000000202 RCX：ffff888113ad96d8 [27642.545916] RDX：
    0000000000000001 RSI：ffff88810770f818 RDI：000000000000000a0 [27642.547027] RBP：0000000000000098 R08：
    0000000000000400 ： ffff88810b980f00 [27642.548140] R10： 0000000000000001 R11： ffff888101845a80R12R09：
    00000000000000a8 [27642.549263] R13： fffffffffa02a9060 R14： 000000000000000a0 R15： ffff8881130d8a40 [27642.550379] complete_all+0x20/0x90 [27642.551010] mlx5e_ipsec_disable_events+0xb6/0xf0 [mlx5_core] [27642.552022] mlx5e_nic_disable+0x12d/0x220 [mlx5_core] [27642.552929] mlx5e_detach_netdev+0x66/0xf0 [mlx5_core] [27642.553822] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core] [27642.554821] mlx5e_vport_rep_load+0x419/0x590 [mlx5_core] [27642.555757] ？ xa_load+0x53/0x90 [27642.556361]
    __esw_offloads_load_rep+0x54/0x70 [mlx5_core] [27642.557328] mlx5_esw_offloads_rep_load+0x45/0xd0 [mlx5_core] [27642.558320] esw_offloads_enable+0xb4b/0xc90 [mlx5_core] [27642.559247] mlx5_eswitch_enable_locked+0x34e/0x4f0 [mlx5_core] [27642.560257] ？ mlx5_rescan_drivers_locked+0x222/0x2d0 [mlx5_core] [27642.561284] mlx5_devlink_eswitch_mode_set+0x5ac/0x9c0 [mlx5_core] [27642.562334] ？ devlink_rate_set_ops_supported+0x21/0x3a0 [27642.563220] devlink_nl_eswitch_set_doit+0x67/0xe0 [27642.564026] genl_family_rcv_msg_doit+0xe0/0x130 [27642.564816] genl_rcv_msg+0x183/0x290 [27642.565466] ？ __devlink_nl_pre_doit.isra.0+0x160/0x160 [27642.566329] ？ d ---truncated--- （CVE-2026-43467）

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

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

  - xprtrdma：减少早期退出路径上的re_receiving 如果 rpcrdma_post_recvs（） 无法创建工作请求（例如由于内存分配失败）或以其他方式提前退出，我们应在返回前减少 ep->re_receiving。否则我们将在 rpcrdma_xprt_drain（） 中挂起，因为re_receiving永远不会达到零，也永远不会触发完成。在具有高内存压力的系统上，这可能显示为以下挂起任务：INFO：任务 kworker/u385：17：8393 被阻断超过 122 秒。Tainted： G S E 6.19.0 #3 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task：kworker/u385：17 state：D stack：0 pid：8393 tgid：8393 ppid：2 task_flags：0x4248060 flags：0x00080000 工作队列：xprtiod xprt_autoclose [sunrpc] 调用跟踪： <TASK> __schedule+0x48b/0x18b0 ？ ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110
    __wait_for_common+0x98/0x180 ？__pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ？
    __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ？
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 （CVE-2026-43469）

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

远程主机上安装的 AOS 版本低于 7.3.1.9。因此，如公告 NXSA-AOS-7.3.1.9 所述，受到一个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. (CVE-2026-31431)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

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

  - btrfs：修复 btrfs_chunk_map_num_copies（） 之后 btrfs_map_block（） 中的区块映射泄漏 修复 btrfs_map_block（） 中的区块映射泄漏：如果使用 -EINVAL 提早返回，将不会释放刚才查找的区块映射。（CVE-2026-43393）

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

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

  - go-git 是用纯 Go 编写的可扩展 git 实现库。在低于 6.0.0-alpha.2 的版本 5.18.0 中，go-git 在智能 HTTP 克隆和获取操作期间跟随重定向时，可能会泄露 HTTP 认证凭据。版本和 6.0.0-alpha.2 中已修 5.18.0 补此问题。
    (CVE-2026-41506)

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

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

  - io_uring/kbuf：检查目标缓冲区列表在回收时是否仍为旧版 获取缓冲区的时间与可能回收缓冲区的时间之间存在间隙，如果列表为空，则有人可能将其升级为环形提供类型。如果通过 io-wq 强制执行请求，则可发生此情况。旧版回收缺少检查buffer_list是否仍然存在以及其类型是否正确。添加这些检查。（CVE-2026-43366）

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

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

  - net：nexthop：修复 remove_nh_grp_entry 中的 percpu 释放后使用 从群组中删除 nexthop 时，remove_nh_grp_entry（） 通过 rcu_assign_pointer（） 发布新群组，然后立即使用 free_percpu（） 释放已删除条目的 percpu 统计数据。但是，调用程序 remove_nexthop_from_groups（） 中的 synchronize_net（） 宽限期在释放之后运行。在发布之前输入的 RCU 读取器仍会看到旧群组，并且可以通过 nh_grp_entry_stats_inc（） -> get_cpu_ptr（nhge->stats） 取消引用释放的统计数据，从而在 percpu 内存上造成释放后使用。通过将 free_percpu（） 延迟到调用程序中的 synchronize_net（） 之后进行修复。删除的条目通过nh_list链接到本地延迟释放列表中。宽限期完成且所有 RCU 读取器完成后，percpu 统计数据将安全释放。（CVE-2026-43374）

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

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

  - net：ipa：修复未针对 IPA v5.0+ 编程的事件环索引 对于 IPA v5.0+，事件环索引字段从 CH_C_CNTXT_0 移至 CH_C_CNTXT_1。v5.0 寄存器定义的目的是在CH_C_CNTXT_1 fmask 数组中定义此字段，但使用的是 ERINDEX 的旧标识符，而不是 CH_ERINDEX。如果没有有效的事件环，GSI 通道永远无法发出传输完成信号。这导致 gsi_channel_trans_quiesce（） 在 wait_for_completion（） 中永久阻断。至少对于 IPA v5.2 而言，这可解决运行时暂停、系统暂停和 remoteproc 停止全部永久挂起的问题。这也意味着 IPA 数据路径完全无法运行。（CVE-2026-43345）

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/xe/sync: Fix user fence leak on alloc failure When dma_fence_chain_alloc() fails, properly release the user fence reference to prevent a memory leak. (cherry picked from commit a5d5634cde48a9fcd68c8504aa07f89f175074a0) (CVE-2026-43396)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mana: Null service_wq on setup error to prevent double destroy In mana_gd_setup() error path, set gc->service_wq to NULL after destroy_workqueue() to match the cleanup in mana_gd_cleanup(). This prevents a use-after-free if the workqueue pointer is checked after a failed setup. (CVE-2026-43440)

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

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

  - net：bonding：修复禁用 IPv6 时nd_tbl空取消引用 通过“ipv6.disable=1”参数引导时，永远不会初始化nd_tbl，因为 inet6_init（） 在调用 ndisc_init（） 之前会退出，从而对其进行初始化。如果启用绑定 ARP/NS 验证，则在从属设备上接收的 IPv6 NS/NA 数据包可到达调用 bond_has_this_ip6（） 的 bond_validate_na（）。该路径调用 ipv6_chk_addr（） 并可在 __ipv6_chk_addr_and_flags（） 中崩溃。缺陷：内核空指针取消引用，地址：000000000000005d8 哎呀：
    哎呀：0000 [#1] SMP NOPTI RIP：0010：__ipv6_chk_addr_and_flags+0x69/0x170 调用跟踪： <IRQ> ipv6_chk_addr+0x1f/0x30 bond_validate_na+0x12e/0x1d0 [bonding] ？ __pfx_bond_handle_frame+0x10/0x10 [bonding] bond_rcv_validate+0x1a0/0x450 [bonding] bond_handle_frame+0x5e/0x290 [bonding] ？ srso_alias_return_thunk+0x5/0xfbef5 __netif_receive_skb_core.constprop.0+0x3e8/0xe50 ？ srso_alias_return_thunk+0x5/0xfbef5 ？ update_cfs_rq_load_avg+0x1a/0x240 ？ srso_alias_return_thunk+0x5/0xfbef5 ？__enqueue_entity+0x5e/0x240 __netif_receive_skb_one_core+0x39/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x30/0x200 ？srso_alias_return_thunk+0x5/0xfbef5 net_rx_action+0x338/0x3b0 handle_softirqs+0xc9/0x2a0 do_softirq+0x42/0x60 </IRQ> <TASK>
    __local_bh_enable_ip+0x62/0x70 __dev_queue_xmit+0x2d3/0x1000 ？srso_alias_return_thunk+0x5/0xfbef5 ？srso_alias_return_thunk+0x5/0xfbef5 ？packet_parse_headers+0x10a/0x1a0 packet_sendmsg+0x10da/0x1700 ？kick_pool+0x5f/0x140 ？srso_alias_return_thunk+0x5/0xfbef5 ？__queue_work+0x12d/0x4f0
    __sys_sendto+0x1f3/0x220 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x101/0xf80 ？exc_page_fault+0x6e/0x170 ？srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 通过在将 IPv6 数据包分发到 bond_na_rcv（） 之前检查 ipv6_mod_enabled（） 来修复此问题。如果禁用了 IPv6，请尽早从 bond_rcv_validate（） 返回并避免路径到 ipv6_chk_addr（）。（CVE-2026-43441）

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

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

  - scsi：ufs：core：修复 UFS 暂停期间 ufshcd_rtc_work（） 中的 SError 在 __ufshcd_wl_suspend（） 中，调用 cancel_delayed_work_sync（） 取消 UFS RTC 工作，但它位于 ufshcd_vops_suspend（hba、pm_op、POST_CHANGE） 之后。这会造成争用条件，即在执行 ufshcd_vops_suspend（） 的同时 ufshcd_rtc_work（） 仍可运行。不支持 UFSHCD_CAP_CLK_GATING 时，条件 ！hba->clk_gating.active_reqs 始终成立，从而导致执行 ufshcd_update_rtc（）。
    由于 ufshcd_vops_suspend（） 通常执行时钟门控操作，因此此时执行 ufshcd_update_rtc（） 会触发 SError。内核错误跟踪如下： 内核错误 - 不同步：
    异步 SError 中断调用跟踪：dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xa0 dump_stack+0x18/0x24 panic+0x148/0x374 nmi_panic+0x3c/0x8c arm64_serror_panic+0x64/0x8c do_serror+0xc4/0xc8 el1h_64_error_handler+0x34/0x4c el1h_64_error+0x68/0x6c el1_interrupt+0x20/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c ktime_get+0xc4/0x12c ufshcd_mcq_sq_stop+0x4c/0xec ufshcd_mcq_sq_cleanup+0x64/0x1dc ufshcd_clear_cmd+0x38/0x134 ufshcd_issue_dev_cmd+0x298/0x4d0 ufshcd_exec_dev_cmd+0x1a4/0x1c4 ufshcd_query_attr+0xbc/0x19c ufshcd_rtc_work+0x10c/0x1c8 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x120/0x1d8 ret_from_fork+0x10/0x20 通过在调用之前将 cancel_delayed_work_sync（） 移动到 ufshcd_vops_suspend（hba， pm_op，PRE_CHANGE），确保届时 UFS RTC 工作完全完成或取消。（CVE-2026-43415）

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

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

  - 已修复 Linux 内核中的下列漏洞：net: Fix rcu_tasks stall in threaded busypoll I was debugging a NIC driver when I noticed that when I enable threaded busypoll, bpftrace hangs when starting up. dmesg showed: rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 10658 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 40793 jiffies old.
    rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 131273 jiffies old. rcu_tasks_wait_gp:
    rcu_tasks grace period number 85 (since boot) is 402058 jiffies old. INFO: rcu_tasks detected stalls on tasks: 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64 task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000 Call Trace: <TASK> ? napi_threaded_poll_loop+0x27c/0x2c0 ? __pfx_napi_threaded_poll+0x10/0x10 ? napi_threaded_poll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 </TASK> The cause is that in threaded busypoll, the main loop is in napi_threaded_poll rather than napi_threaded_poll_loop, where the latter rarely iterates more than once within its loop. For rcu_softirq_qs_periodic inside napi_threaded_poll_loop to report its qs state, the last_qs must be 100ms behind, and this can't happen because napi_threaded_poll_loop rarely iterates in threaded busypoll, and each time napi_threaded_poll_loop is called last_qs is reset to latest jiffies.
    This patch changes so that in threaded busypoll, last_qs is saved in the outer napi_threaded_poll, and whether busy_poll_last_qs is NULL indicates whether napi_threaded_poll_loop is called for busypoll. This way last_qs would not reset to latest jiffies on each invocation of napi_threaded_poll_loop.
    (CVE-2026-43385)

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

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

  - btrfs：修复由于名称哈希冲突在文件创建时因名称哈希冲突而造成的事务中止 如果尝试创建多个名称生成相同哈希的文件，我们必须将这些文件打包在同一个目录项中，并且该目录具有叶大小固有的限制。但是，如果达到该限制，我们将触发事务中止并将文件系统转换为 RO 模式。这允许恶意用户在不具备管理权限/功能的情况下中断系统。复制器：$ cat exploit-hash-collisions.sh #！/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # 使用最小的节点大小来加快测试速度并需要更少的文件 # 导致哈希冲突的名称。mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # 导致 btrfs 的相同 crc32c 哈希的名称列表。 declare -a names=（ 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6 jZnkDtUUru1t@RouaUe_L：@xGkbO3nCwvLNYeK9vhE628gss：T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%s hMsg-N%frgU：02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB：=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmq rMiL9-Y0I_l5Fnam04CGIg=8@U：Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%：hHgjhIjW5vnqWHKNP4' 'ET：vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O：' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38f UcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq：CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV 5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F：ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRf DfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn：' c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC：_6dBJ_' 'WHmN2gnmaN-9dVDy4aWo：yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2：%2_am' 'Wi FnuTEhAG9FEC6zopQmj-A-0T3WULz$LDQ%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r：lbwvitWRyo$odnAUYlYMmU4RvgnNd-- e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGF_ZVr@1u$ivrvhVgD%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-7phxQbUcb$ZpQfCL：BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OF EwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD：JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z：：ZRcv5O：lDCFm' 'evqk743Y@dvZAiG5J05 L_ROFV@$2%rVWJ2%3nxV72-W7$- SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG：$euFYmXn$_2rA9mKZ' ' gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1：cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma$e10V1jDRGJje%X x9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG_8lNRik3PvphqPm0yEH3P%%fYG：kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F：EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_：u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9：%Q3UxeHiViUyNzJsy：fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA-- @WqWLIuX7o1S_SfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY：' Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS：lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAY bnVn' 'UG37U6KKua2bgc：IHzRs7BnB6FD：2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW：mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD：R02ghwYo%yx7SAaaq-：x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN：x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8_jaVtQhBXpBk：pE-7ts58U0J@iR9YZntMPl7j$P$s 62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh：IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC ---truncated--- （CVE-2026-43360）

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

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

  - KVM：arm64：创建 vgic 时急切地初始化 vgic dist/redist 如果 vgic_allocate_private_irqs_locked（） 因任何奇怪原因而失败，我们将提早退出 kvm_vgic_create（），而使 dist->rd_regions 处于未初始化状态。
    然后 kvm_vgic_dist_destroy（） 出现并走进杂草丛中，试图释放 RD。必须喜欢这些东西。通过提前移动所有静态初始化来解决它，并确保如果我们中途失败，我们处于执行其余拆卸的合理状态。同时，在失败时重置 vgic 模型，以防万一......（CVE-2026-43351）

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

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

  - nfsd：修复 nfsd_nl_listener_set_doit（） 中的 cred ref 泄漏。nfsd_nl_listener_set_doit（） 使用不put_cred（） 的 get_current_cred（）。正如我们从其他调用程序中看到的，svc_xprt_create_from_sa（） 不需要额外的 refcount。nfsd_nl_listener_set_doit（） 始终处于进程上下文中，sendmsg（） 和 current->cred 不会消失。让我们在 nfsd_nl_listener_set_doit（） 中使用 current_cred（）。
    (CVE-2026-43394)

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

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

  - xfs：修复过小的 l_iclog_roundoff 值 如果超级块未列出日志条带化单位，我们将内核日志舍入值设置为 512。这导致在具有 4k 物理扇区的磁盘上，generic/617 中的日志损坏和无法挂载的文件系统... XFS （sda1）：挂载 V5 文件系统 ff3121ca-26e6-4b77-b742-aaff9a449e1cXFS （sda1）：在日志块0x318e检测到写入损坏（CRC 失败）。从0x3197截断头块。XFS （sda1）：未能找到日志末尾 XFS （sda1）：日志装载/恢复失败：错误 -74 XFS （sda1）：日志装载失败 XFS （sda1）： 挂载 V5 文件系统 ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS （sda1）： 结束干净挂载...在具有损坏的 mkfs 的当前 xfsprogs for-next 上。xfs_info表明了这一点......meta-data=/dev/sda1 isize=512 agcount=4， agsize=644992 blks = sectsz=4096 attr=2， projid32bit=1 = crc=1 finobt=1， sparse=1， rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968， imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0， ftype=1， parent=1 log =internal log bsize=4096 blocks=16384， version=2 = sectsz=4096 sunit=0 blks， lazy-count=1 realtime =none extsz=4096 blocks=0， rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...观察日志部分的 sectsz=4096 sunit=0，这意味着舍入因子为 512，而不是您预期的 4096。我们应修复 mkfs，使其不会生成损坏的文件系统，但任何人都可以模糊处理磁盘上的超级块，因此我们应更加谨慎。我认为不充分的逻辑早于 commit a6a65fef5ef8d0，但这显然需要不同的向后移植。（CVE-2026-43365）

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

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

  - ublk：修复 ublk_ctrl_set_size（） 中的空指针取消引用 ublk_ctrl_set_size（） 通过 set_capacity_and_notify（） 无条件取消引用 ub->ub_disk，而不检查其是否为空。ub->ub_disk 在 UBLK_CMD_START_DEV 完成之前为空（仅在 ublk_ctrl_start_dev（） 中赋值）和在UBLK_CMD_STOP_DEV运行后（ublk_detach_disk（） 将其设置为空）。由于UBLK_CMD_UPDATE_SIZE处理程序不执行状态验证，用户可通过将UPDATE_SIZE发送到已添加但尚未启动的设备或已停止的设备来触发空指针取消引用。通过在取消引用 ub->mutex 下 ub->ub_disk 并在磁盘不可用时返回 -ENODEV 来修复此问题。
    (CVE-2026-43364)

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

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

  - KVM：nSVM：删除用户可触发的 nested_svm_load_cr3（） 后续 WARN 终止 nested_svm_load_cr3（） 失败时 svm_set_nested_state（） 中的 WARN，因为在加载 CR3 后修改 CPUID 可轻易从用户空间触发。例如，修改状态恢复自我测试，如下所示： --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main（int argc， char *argv[]） /* 在新 VM 中还原状态。*/ vcpu = vm_recreate_with_one_vcpu（vm）;- vcpu_load_state（vcpu， state）;+ + if （stage == 4） { + state->sregs.cr3 = BIT（44）; + vcpu_load_state（vcpu， state）; + + vcpu_set_cpuid_property（vcpu， X86_PROPERTY_MAX_PHY_ADDR， 36）;
    + __vcpu_nested_state_set（vcpu，&状态>嵌套）;+ } else { + vcpu_load_state（vcpu， state）; + } /* * 在虚拟 vCPU 中还原 XSAVE 状态，首先不进行生成： 警告： CPU：30 PID：938 at arch/x86/kvm/svm/nested.c：1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] 链接的模块：kvm_amd kvm irqbypass [上次卸载：kvm] CPU：30 UID：1000 PID：938 通信：state_test 受感染： G W 6.18.0-rc7-58e10b63777d-next-vm 受感染：[W]=WARN 硬件名称：QEMU 标准 PC （Q35 + ICH9,2009 年），BIOS 0.0.0 02/06/2015 RIP：0010：svm_set_nested_state+0x34a/0x360 [kvm_amd] 调用跟踪： <TASK> kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 只需删除 WARN，而非尝试阻止用户空间将非法状态注入 CR3。无论好坏，KVM 的 ABI 允许用户空间在 SREGS 之后设置 CPUID，反之亦然，而 KVM 在涉及到客户机 CPUID 时非常宽松。即，设置 CPUID 时尝试强制实施虚拟 CPU 模型可中断用户空间。鉴于 WARN 不能为 KVM 提供任何有意义的保护或用户空间益处，因此即使破坏用户空间的几率很小，也只需将其删除即可。机会性地删除虚假换行符。
    (CVE-2026-43315)

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

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

  - MapServer 是用于开发基于 Web 的 GIS 应用程序的系统。从版本 6.0 到以前的版本 8.6.2，MapServer 的 WMS 服务器中存在反射型 XSS 漏洞，允许未经认证的攻击者将任意 HTML/JavaScript 注入任何打开构建的 WMS URL 的用户的浏览器中。该漏洞可通过 WMS 1.3.0 请求中的 FORMAT=application/openlayers 与未审查的 SRS 参数相结合来触发。已在版本 8.6.2 中修补此问题。(CVE-2026-42030)

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

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

  - Crypt：:P asswdMD5 及之前 1.42 的 Perl 版本会为 salt 生成不安全的随机值。内置的 rand 函数可预测，不适用于密码编译。（CVE-2026-6659）

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

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

  - drm/xe/sync：解析失败时清理部分初始化的同步 xe_sync_entry_parse（） 可在遇到更高版本的失败路径之前分配引用（syncobj、fence、chain fence 或 user fence）。其中一些路径直接返回，留下部分初始化状态并泄漏 refs。通过通用 free_sync 标签路由这些错误路径，并在返回错误之前调用 xe_sync_entry_cleanup（sync）。
    （从提交 f939bdd9207a5d1fc55cced5459858480686ce22 中精选出的内容）（CVE-2026-43395）

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

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

  - 已修复 Linux 内核中的下列漏洞：xhci: Fix NULL pointer dereference when reading portli debugfs files Michal reported and debgged a NULL pointer dereference bug in the recently added portli debugfs files Oops is caused when there are more port registers counted in xhci->max_ports than ports reported by Supported Protocol capabilities. This is possible if max_ports is more than maximum port number, or if there are gaps between ports of different speeds the 'Supported Protocol' capabilities. In such cases port->rhub will be NULL so we can't reach xhci behind it. Add an explicit NULL check for this case, and print portli in hex without dereferencing port->rhub.
    (CVE-2026-43431)

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

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

  - ceph：添加一批缺失的 ceph_path_info 初始值设定项 ceph_mdsc_build_path（） 必须使用零初始化的 ceph_path_info 参数调用，否则以下 ceph_mdsc_free_path_info（） 可能会崩溃。
    崩溃示例（在 Linux 6.18.12上）：virt_to_cache：对象不是 Slab 页面！警告：CPU：184 PID：mm/slub.c：6732 2871736 kmem_cache_free+0x316/0x400 [...]调用跟踪：[...] ceph_open+0x13d/0x3e0 do_dentry_open+0x134/0x480 vfs_open+0x2a/0xe0 path_openat+0x9a3/0x1160 [...] cache_from_obj：错误的 slab 缓存。names_cache但对象来自 ceph_inode_info 警告：CPU：184 PID：mm/slub.c：6746 2871736 kmem_cache_free+0x2dd/0x400 [...] mm/slub.c：634！Oops：无效操作码：0000 [#1] SMP NOPTI RIP：0010：__slab_free+0x1a4/0x350 一些 ceph_mdsc_build_path（） 调用程序具有初始值设定项，但其他调用程序则没有，即使所有 （） 调用程序都是通过提交 15f519e9f883 添加的（ceph：修复应用状态之前验证r_parent的争用条件）。没有初始值设定程序的漏洞容易发生随机崩溃。（我可以想象甚至可以利用此缺陷来提升权限。）遗憾的是，这些 Ceph 函数没有记录，其语义只能从代码中派生。我看到 ceph_mdsc_build_path（） 仅在成功时初始化结构，而不是在出错时初始化结构。在 ceph_mdsc_build_path（） 调用失败后调用 ceph_mdsc_free_path_info（） 甚至没有意义，但这是所有调用者都会做的，并且为了安全起见，结构必须是零初始化的。因此，修复此问题的侵入性最小的方法是在各处添加初始化程序。（CVE-2026-43408）

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

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

  - 在之前 1.0.2的 uriparser 中，函数系列 EqualsUri 可将两个不相等的 URI 错误分类为相等。
    (CVE-2026-44928)

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

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

  - 在 uriparser 之前 1.0.2的版本中，多处存在指针差异截断到 int。
    (CVE-2026-44927)

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

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

  - 已修复 Linux 内核中的下列漏洞：kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit().
    Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly. (CVE-2026-43402)

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

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

  - pgx 是适用于 Go 的 PostgreSQL 驱动程序和工具包。在低于该版本 5.9.2之前，当使用非默认简单协议时，在 SQL 查询中使用了美元引用的字符串文本，该字符串文本包含的文本会被解释为字符串文本外部的占位符，并且攻击者可控制该占位符的值。已在版本 5.9.2 中修补此问题。(CVE-2026-41889)

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

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

  - nsfs：加强对 ns 迭代 ioctl 的权限检查 即使是特权服务也不一定能够看到其他特权服务的命名空间，因此它们不能互相泄露信息。使用集中此策略的 may_see_all_namespaces（） 辅助函数，直到 nstree 适应为止。（CVE-2026-43403）

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

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

  - 已修复 Linux 内核中的下列漏洞：cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request() The update_cpu_qos_request() function attempts to initialize the 'freq' variable by dereferencing 'cpudata' before verifying if the 'policy' is valid. This issue occurs on systems booted with the nosmt parameter, where all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result, any call to update_qos_requests() will result in a NULL pointer dereference as the code will attempt to access pstate.turbo_freq using the NULL cpudata pointer. Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap() after initializing the 'freq' variable, so it is better to defer the 'freq' until intel_pstate_get_hwp_cap() has been called. Fix this by deferring the 'freq' assignment until after the policy and driver_data have been validated. [ rjw: Added one paragraph to the changelog ] (CVE-2026-43401)

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

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

  - usb：xhci：修复 xhci_disable_slot（） 中的内存泄漏 xhci_alloc_command（） 分配命令结构，并且在第二个参数为 true 时，还分配完成结构。目前，xhci_disable_slot（） 中的错误处理路径仅使用 kfree（） 释放命令结构，从而导致泄漏完成结构。使用 xhci_free_command（） 而不是 kfree（）。xhci_free_command（） 正确地释放命令结构和相关联的完成结构。由于命令结构是通过零初始化分配，命令>in_ctx为 NULL，并且 xhci_free_command（） 不会错误地释放。这个缺陷是使用我们正在开发的实验性静态分析工具发现的。该工具基于 LLVM 框架，专门用于检测内存管理问题。它目前正在积极开发中，尚未公开可用，但我们计划在我们的研究发表后将其开源。该缺陷最初是使用我们的静态分析工具在 v6.13-rc1 上检测到的，我们已经验证该问题在最新的主线内核中仍然存在。我们通过 allyesconfig 使用 GCC=11.4.0 对 x86_64 进行了构建测试。由于在 xhci_disable_slot（） 中触发这些错误路径需要特定的硬件条件或异常状态，因此我们无法构建测试用例以在运行时可靠地触发这些特定错误路径。（CVE-2026-43432）

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

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

  - iio：light：bh1780：修复错误路径中的 PM 运行时泄漏 在错误检查之前移动 pm_runtime_put_autosuspend（），以确保无论读取操作成功还是失败，PM 运行时引用计数始终在 pm_runtime_get_sync（） 之后递减。（CVE-2026-43355）

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

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

  - ceph：修复异步取消链接期间i_nlink欠载运行 在异步取消链接期间，我们在收到完成（最终将更新“i_nlink”）之前舍弃“i_nlink”计数器，因为我们假设取消链接会成功。这不是一个坏主意，但它与其他客户端的删除（或我们自己的取消链接的完成）竞争，并可能导致发出如下警告的欠载运行：警告：
    CPU：85 PID：25093 at fs/inode.c：407 drop_nlink+0x50/0x68 链接的模块： CPU：85 UID：3221252029 PID：
    25093 通信：php-cgi8.1 未受感染 6.14.11-cm4all1-ampere #655 硬件名称：Supermicro ARS-110M-NR/R12SPD-A，BIOS 1.1b 2023 年 10 月 17 日 pstate：60400009 （nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--） PC：drop_nlink+0x50/0x68 LR：ceph_unlink+0x6c4/0x720 SP：ffff80012173bc90 x29： ffff80012173bc90 x28：
    ffff086d0a45aaf8 x27： ffff0871d0eb5680 x26： ffff087f2a64a718 x25： 0000020000000180 x24： 0000000061c88647 x23： 0000000000000002 x22： ffff07ff9236d800 x21： 0000000000001203 x20： ffff07ff9237b000 x19：
    ffff088b8296afc0 x18： 00000000f3c93365 x17： 0000000000070000 x16： ffff08faffcbdfe8 x15： ffff08faffcbdfec x14： 0000000000000000 x13： 45445f65645f3037 x12： 34385f6369706f74 x11： 0000a2653104bb20 x10：
    ffffd85f26d73290 x9 ： ffffd85f25664f94 x8 ： 000000000000000000c0 x7 ： 0000000000000000 x6 ： 0000000000000002 x5 ： 0000000000000081 x4 ： 0000000000000481 x3 ： 00000000000000000 x2 ： 0000000000000000 x1 ：
    00000000000000000 x0 ： ffff08727d3f91e8 调用跟踪：drop_nlink+0x50/0x68 （P） vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 在 ceph_unlink（） 中，对 ceph_mdsc_submit_request（） 的调用会将CEPH_MDS_OP_UNLINK提交到 MDS， 但不会等待完成。同时，在此调用和下一个 drop_nlink（） 调用之间，工作线程可能会处理CEPH_CAP_OP_IMPORT、CEPH_CAP_OP_GRANT或仅处理CEPH_MSG_CLIENT_REPLY（后者可能是我们自己的完成）。这些将导致 set_nlink（） 调用，将“i_nlink”计数器更新为从 MDS 接收的值。如果该新的“i_nlink”值刚好为零，则将其进一步递减是违法的。但这正是 ceph_unlink（） 届时会做的。警告可以通过以下方式重现： 1.
    强制异步取消链接;只有异步代码路径会受到影响。由于对 Ceph 内部没有真正的头绪，我无法找出 MDS 为何不为我提供 Fxr 功能，因此我修补了 get_caps_for_async_unlink（） 以始终成功。（请注意，在没有此 kludge 的未经修补的内核中发现上述 WARNING 转储 - 这不是理论上的缺陷。）2. 在 ceph_mdsc_submit_request（） 之后添加 sleep 调用，以便在调用 drop_nlink（） 之前由工作线程处理取消链接完成。这保证了在 drop_nlink（） 运行之前“i_nlink”已经为零。解决方案是在计数器已经为零时跳过计数器递减，但在没有锁定的情况下这样做仍然是争用的 （TOCTOU）。
    由于 set_nlink（） 运行时 ceph_fill_inode（） 和 handle_cap_grant（） 都保留“ceph_inode_info.i_ceph_lock”自旋锁，因此这似乎是保护“i_nlink”更新的适当锁定。我在 NFS 和 SMB（使用“inode.i_lock”）和 AFS（使用“afs_vnode.cb_lock”）中找到了现有技术。这三个人也有零检查。（CVE-2026-43420）

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

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

  - ice：ptp：控制 PF 不可用时不警告 在 VFIO 传递设置中，可能仅通过不拥有源定时器的 PF。在这种情况下，PTP 控制 PF （adapter->ctrl_pf） 永远不会在 VM 中初始化，因此 ice_get_ctrl_ptp（） 返回空值并在 ice_ptp_setup_pf（） 中触发 WARN_ON（）。由于这是该配置中的预期行为，因此请将 WARN_ON（） 替换为提示消息并返回 -EOPNOTSUPP。（CVE-2026-43346）

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

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

  - drm/amdgpu：对信号 ioctl 中的用户输入添加上限检查 amdgpu_userq_signal_ioctl 中的巨大输入值可导致 OOM，并可被利用。因此，根据AMDGPU_USERQ_MAX_HANDLES检查这些输入值，该值对于真正的用例来说足够大，并且可以避免 OOM。
    （从提交 be267e15f99bc97cbe202cd556717797cdcf79a5 中精选出的内容）（CVE-2026-43400）

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

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

  - powerpc、perf：获取用户调用链前检查 current->mm 是否处于活动状态 可能已经释放 mm，从而导致内核错误。这添加了对 current->mm 的 NULL 检查，类似于提交 20afc60f892d（x86、perf：在获取用户调用链之前检查 current->mm 是否处于活动状态）。我在运行分析 BPF 程序时遇到此错误（从 bcc-tools profile.py）：[26215.051935] 内核尝试读取用户页面 （588） - 尝试利用？（uid：0） [26215.051950] 缺陷：0x00000588 处读取时发生内核空指针取消引用 [26215.051952] 错误指令地址：0xc00000000020fac0 [26215.051957] 错误：错误区域的内核访问，sig：11 [#1] [...][26215.052049] 调用跟踪：
    [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490（不可靠） [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274 [...]此外，将存储顶级堆栈条目的移至通用perf_callchain_user，以确保即使 current->mm 为 NULL，也始终捕获 top-evel 条目。[Maddy：已修复消息以避免 checkpatch 格式样式错误]（CVE-2026-43416）

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

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

  - usb：class：cdc-wdm：修复读取代码路径中的重新排序问题 引用缺陷报告：由于编译器优化或 CPU 无序执行，desc->长度更新可在 memmove 之前重新排序。
    如果发生这种情况，wdm_read（） 可看到新的长度并调用未初始化内存上的 copy_to_user（）。这也违反了 LKMM 数据争用规则 [1]。使用WRITE_ONCE和内存屏障修复此问题。（CVE-2026-43427）

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

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

  - libceph：修复 ceph_handle_auth_reply（） 中潜在的越界访问 此修补程序修复了 ceph_handle_auth_reply（） 中可通过 CEPH_MSG_AUTH_REPLY 类型消息触发的越界访问。在 ceph_handle_auth_reply（） 中，此类消息的 payload_len 字段的值存储在 int 类型的变量中。大于 INT_MAX 的值会导致整数溢出并被解释为负值。这会导致递减指针地址此值并随后访问它，因为 ceph_decode_need（） 仅检查内存访问是否超过分配的结束地址。
    此修补程序将 payload_len 的数据类型更改为 u32 来修复此问题。此外，result_msg_len 的数据类型更改为 u32，因为它也是持有非负长度的变量。此外，还引入了额外的健全性检查层，确保从消息读取后，payload_len和result_msg_len不会大于整个段长度。缺陷：KASAN：ceph_handle_auth_reply+0x642/0x7a0 中的 slab-out-of-bound [libceph] 任务 kworker/20:1/262 在地址 ffff88811404df14 读取大小为 4 CPU：20 UID：0 PID：262 Comm：kworker/20:1 未受 6.19.2 #5 感染 PREEMPT（自愿） 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作队列：
    ceph-msgr ceph_con_workfn [libceph] 调用跟踪： <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ？
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ？kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ？ceph_handle_auth_reply+0x642/0x7a0 [libceph] ？ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ？apparmor_socket_recvmsg+0x6b/0xa0 ？__pfx_mon_dispatch+0x10/0x10 [libceph] ？
    __kasan_check_write+0x14/0x30i ？mutex_unlock+0x7f/0xd0 ？__pfx_mutex_unlock+0x10/0x10 ？
    __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ？
    __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ？save_fpregs_to_fpstate+0xb0/0x230 ？raw_spin_rq_unlock+0x17/0xa0 ？finish_task_switch.isra.0+0x13b/0x760 ？__switch_to+0x385/0xda0 ？
    __kasan_check_write+0x14/0x30 ？mutex_lock+0x8d/0xe0 ？__pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ？__kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ？__pfx__raw_spin_lock_irqsave+0x10/0x10 ？__pfx_try_to_wake_up+0x10/0x10 ？kasan_print_address_stack_frame+0x1f7/0x280 ？__pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ？
    __pfx__raw_spin_lock_irq+0x10/0x10 ？__pfx_kthread+0x10/0x10 ？__kasan_check_write+0x14/0x30 ？recalc_sigpending+0x180/0x210 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ？
    __pfx_ret_from_fork+0x10/0x10 ？__switch_to+0x385/0xda0 ？__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> [ idryomov：将 if 语句替换为用于 payload_len 和 result_msg_len 的 ceph_decode_need（） ] （CVE-2026-43407）

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

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

  - ipv6：防止 addrconf_permanent_addr（） 中可能的 UaF 上述帮助程序尝试警告用户异常情况，但消息传递太晚，导致在可能被删除后访问 ipv6。重新排序语句以避免可能的 UAF;同时，请将警告放在 idev->lock 之外，因为它不需要任何保护。（CVE-2026-43339）

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

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

  - 已修复 Linux 内核中的下列漏洞：f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footer syzbot reported a f2fs bug as below: BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1 bio_endio+0x1006/0x1160 block/bio.c:1792 submit_bio_noacct+0x533/0x2960 block/blk-core.c:891 submit_bio+0x57a/0x620 block/blk-core.c:926 blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline] f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557 f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775 read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481
    __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623 do_read_inode fs/f2fs/inode.c:425 [inline] f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs/super.c:1717 f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436 vfs_get_tree+0xb3/0x5d0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] do_new_mount_fc fs/namespace.c:3763 [inline] do_new_mount+0x885/0x1dd0 fs/namespace.c:3839 path_mount+0x7a2/0x20b0 fs/namespace.c:4159 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline]
    __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338 x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is: in f2fs_finish_read_bio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue. (CVE-2026-43349)

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

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

  - staging：rtl8723bs：正确验证 rtw_get_ie_ex（） 中的数据 就像在提交 154828bf9559 中一样（staging：rtl8723bs：修复 rtw_get_ie（） 解析器中的越界读取），我们不信任帧中的数据，因此我们应在对其执行操作前更好地检查长度 （CVE-2026-43387）

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

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

  - 媒体：芯原：解码 H.264 和 HEVC 时避免 G2 总线错误 对于 i.MX8MQ 平台，存在硬件限制：g1 VPU 和 g2 VPU 无法同时解码;否则，将导致总线以下错误并产生损坏的图片，甚至可能导致系统挂起。[ 110.527986] hantro-vpu 38310000.video-codec：帧解码超时。[ 110.583517] hantro-vpu 38310000.video-codec：检测到总线错误。因此，需要确保 g1 和 g2 交替运行。这可成功解码 H.264 和 HEVC 的多实例。为了实现这一点，g1 和 g2 共享相同的v4l2_m2m_dev，然后v4l2_m2m_dev可以处理调度。（CVE-2026-43310）

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

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

  - x86/kexec：load_segments（） 后禁用 KCOV 检测 load_segments（） 函数更改段寄存器，使 GS 基（KCOV 用于 per-cpu 数据）失效。启用 CONFIG_KCOV 时，任何后续的检测 C 代码调用（如 native_gdt_invalidate（））都会开始在死循环中造成内核崩溃。要重现该问题，只需在 KCOV 检测的内核上执行 kexec 即可：$ kexec
    -l /boot/otherKernel $ kexec -e 此问题的实际环境是在 syzkaller 中启用崩溃转储集合。为此，该工具会在模糊测试前加载错误内核，然后在错误之后调用 makedumpfile。此工作流需要同时启用 CONFIG_KEXEC 和 CONFIG_KCOV。此外，不希望直接向 KCOV 快速路径 （__sanitizer_cov_trace_pc（）） 添加安全，因为这会造成额外的性能开销。禁用各个函数的检测过于脆弱，因此请禁用整个 machine_kexec_64.c 和 physaddr.c 的 KCOV 检测。如果覆盖引导的模糊测试将来需要这些组件，则应考虑其他方法。
    该问题与 32 位内核无关，因为 32 位内核不支持 CONFIG_KCOV。[ bp： 为提高可读性，请留出注释间距。 ]（CVE-2026-43331）

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

ID	名称	严重性
313601	Linux Distros 未修补的漏洞：CVE-2026-42311	high
313600	Linux Distros 未修补的漏洞：CVE-2026-6666	high
313599	Linux Distros 未修补的漏洞：CVE-2026-6664	high
313598	Linux Distros 未修补的漏洞：CVE-2026-6665	critical
313469	Linux Distros 未修补的漏洞：CVE-2026-43468	medium
313468	Linux Distros 未修补的漏洞：CVE-2026-43470	medium
313467	Linux Distros 未修补的漏洞：CVE-2026-43454	high
313466	Linux Distros 未修补的漏洞：CVE-2026-43467	medium
313465	Linux Distros 未修补的漏洞：CVE-2026-43469	high
313464	Nutanix AOS：（NXSA-AOS-7.3.1.9）	high
313457	Linux Distros 未修补的漏洞：CVE-2026-43393	medium
313456	Linux Distros 未修补的漏洞：CVE-2026-41506	high
313455	Linux Distros 未修补的漏洞：CVE-2026-43366	high
313454	Linux Distros 未修补的漏洞：CVE-2026-43374	high
313453	Linux Distros 未修补的漏洞：CVE-2026-43345	high
313452	Linux Distros 未修补的漏洞：CVE-2026-43396	medium
313451	Linux Distros 未修补的漏洞：CVE-2026-43440	high
313450	Linux Distros 未修补的漏洞：CVE-2026-43441	high
313449	Linux Distros 未修补的漏洞：CVE-2026-43415	medium
313448	Linux Distros 未修补的漏洞：CVE-2026-43385	high
313447	Linux Distros 未修补的漏洞：CVE-2026-43360	medium
313446	Linux Distros 未修补的漏洞：CVE-2026-43351	medium
313445	Linux Distros 未修补的漏洞：CVE-2026-43394	medium
313444	Linux Distros 未修补的漏洞：CVE-2026-43365	high
313443	Linux Distros 未修补的漏洞：CVE-2026-43364	medium
313442	Linux Distros 未修补的漏洞：CVE-2026-43315	medium
313441	Linux Distros 未修补的漏洞：CVE-2026-42030	medium
313440	Linux Distros 未修补的漏洞：CVE-2026-6659	high
313439	Linux Distros 未修补的漏洞：CVE-2026-43395	medium
313438	Linux Distros 未修补的漏洞：CVE-2026-43431	medium
313437	Linux Distros 未修补的漏洞：CVE-2026-43408	high
313436	Linux Distros 未修补的漏洞：CVE-2026-44928	medium
313434	Linux Distros 未修补的漏洞：CVE-2026-44927	medium
313433	Linux Distros 未修补的漏洞：CVE-2026-43402	critical
313432	Linux Distros 未修补的漏洞：CVE-2026-41889	low
313431	Linux Distros 未修补的漏洞：CVE-2026-43403	high
313430	Linux Distros 未修补的漏洞：CVE-2026-43401	medium
313404	Linux Distros 未修补的漏洞：CVE-2026-43432	medium
313403	Linux Distros 未修补的漏洞：CVE-2026-43355	medium
313402	Linux Distros 未修补的漏洞：CVE-2026-43420	medium
313401	Linux Distros 未修补的漏洞：CVE-2026-43346	medium
313400	Linux Distros 未修补的漏洞：CVE-2026-43400	medium
313399	Linux Distros 未修补的漏洞：CVE-2026-43416	medium
313398	Linux Distros 未修补的漏洞：CVE-2026-43427	high
313397	Linux Distros 未修补的漏洞：CVE-2026-43407	critical
313396	Linux Distros 未修补的漏洞：CVE-2026-43339	high
313395	Linux Distros 未修补的漏洞：CVE-2026-43349	medium
313394	Linux Distros 未修补的漏洞：CVE-2026-43387	medium
313393	Linux Distros 未修补的漏洞：CVE-2026-43310	medium
313392	Linux Distros 未修补的漏洞：CVE-2026-43331	medium

检测

Nessus 的 Misc. 系列

high

high

high

critical

medium

medium

high

medium

high

high

medium

high

high

high

high

medium

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

medium

medium

critical

low

high

medium

medium

medium

medium

medium

medium

medium

high

critical

high

medium

medium

medium

medium