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

  - dpll防止重复注册修改内部注册帮助程序 dpll_xa_ref_{dpll,pin}_add() 以拒绝重复注册尝试。以前如果一个调用程序尝试在同一设备上多次注册相同的 pin使用相同的 ops、priv 和 cookie则内核会静默增加引用计数并返回成功。此行为不正确因为如果调用程序进行这些重复注册则对于第一个注册将分配 dpll_pin_registration对于其他注册将递增相关的 dpll_pin_ref.refcount。在第一次取消注册期间相关的 dpll_pin_registration 将被释放而对于其他内容则会触发 WARN。通过更新逻辑来修复此问题以在找到匹配的注册时返回“-EEXIST”以强制执行严格的注册一次策略。
    (CVE-2026-23129)

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

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

  - 已修复 Linux 内核中的下列漏洞：ice: add missing ice_deinit_hw() in devlink reinit path devlink-reload results in ice_init_hw failed error, and then removing the ice driver causes a NULL pointer dereference. [ +0.102213] ice 0000:ca:00.0: ice_init_hw failed: -16 ... [ +0.000001] Call Trace: [ +0.000003] <TASK> [ +0.000006] ice_unload+0x8f/0x100 [ice] [ +0.000081] ice_remove+0xba/0x300 [ice] Commit 1390b8b3d2be (ice: remove duplicate call to ice_deinit_hw() on error paths) removed ice_deinit_hw() from ice_deinit_dev(). As a result ice_devlink_reinit_down() no longer calls ice_deinit_hw(), but ice_devlink_reinit_up() still calls ice_init_hw(). Since the control queues are not uninitialized, ice_init_hw() fails with -EBUSY. Add ice_deinit_hw() to ice_devlink_reinit_down() to correspond with ice_init_hw() in ice_devlink_reinit_up(). (CVE-2026-23117)

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

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

  - 已修复 Linux 内核中的下列漏洞：can: gs_usb:
    gs_usb_receive_bulk_callback(): fix error message Sinc commit 79a6d1bfe114 (can: gs_usb:
    gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error) a failing resubmit URB will print an info message. In the case of a short read where netdev has not yet been assigned, initialize as NULL to avoid dereferencing an undefined value. Also report the error value of the failed resubmit.
    (CVE-2026-23155)

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

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

  - mm/damon/sysfs-scheme方案目录中的清理 access_pattern 子目录设置失败设置 access_pattern/ 目录后如果 DAMOS-scheme DAMON sysfs 目录设置失败则不会清除 access_pattern/ 目录的子目录。因此在系统重新启动之前DAMON sysfs 接口几近崩溃且未删除目录的内存泄露。清理此类故障下的目录。 (CVE-2026-23142)

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

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

  - ice修复 ice_vsi_set_napi_queues 中的空指针取消引用。在 ice_vsi_set_napi_queues() 中添加空指针检查以防止在 ring[q_idx]->q_vector 为空时在从暂停恢复期间崩溃。已测试的适配器 60:00.0 以太网控制器 [0200]: Intel Corporation 以太网控制器 E810-XXV for SFP [8086:159b] (rev 02) 子系统: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003] SR -IOV 状态：禁用和启用 都会重现此问题。内核版本v6.18 重现步骤
    启动并执行暂停如 systemctl suspend 或 rtcwake。Log <1>[ 231.443607] 缺陷内核空指针取消引用地址0000000000000040 <1>[ 231.444052] #PF内核模式下的主管读取访问 <1>[ 231.444484] #PFerror_code(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170 <4>[ 231.447067] 代码31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 03 0b 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX
    ffff8b848caf2028 RCX 0000000000000010 <4>[ 231.448443] RDX0000000000000000 RSI0000000000000000 RDI
     <4>ffff8b848dbd4000  [ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13:
     R14ffff8b848dbd4000  : ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[231.451629] PKRU: 55555554 <4>[ 231.452076] 调用跟踪: <4>[ 231.452549] <TASK> <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice] <4>[ 231.453482] ice_resume+0xfd/0x220 [ice] <4>[ 231.453977] ?
    __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.454425] pci_pm_resume+0x8c/0x140 <4>[ 231.454872] ?
    __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.455347] dpm_run_callback+0x5f/0x160 <4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170 <4>[ 231.456244] device_resume+0x177/0x270 <4>[ 231.456708] dpm_resume+0x209/0x2f0 <4>[ 231.457151] dpm_resume_end+0x15/0x30 <4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0 <4>[ 231.458054] enter_state+0x10e/0x570 在取消引用之前同时为环指针及其 q_vector 添加防御性检查允许系统即使在 q_vectors 未映射时也能成功恢复。 (CVE-2026-23166)

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

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

  - pmdomainimx8m-blk-ctrl删除 8mq vpu 的单独 rst 和 clk 掩码对于 i.MX8MQ 平台VPUMIX 域中的 ADB 没有单独的重置和时钟启用位但与 VPU 一起解锁和重置。因此我们无法单独重置 G1 或 G2否则可能会导致系统挂起。删除 imx8mq_vpu_blk_ctl_domain_data 的 rst_mask 和 clk_mask。使 imx8mq_vpu_power_notifier() 真正执行 vpu 重置。 (CVE-2026-23116)

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

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

  - wifiath10k修复 dma_free_coherent() 指针 dma_alloc_coherent() 会分配 DMA 映射的缓冲区并将地址存储在 XXX_unaligned 字段中。释放缓冲区时应重用这些地址而不是对齐的地址。 (CVE-2026-23133)

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

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

  - 已修复 Linux 内核中的下列漏洞：perf: Fix refcount warning on event->mmap_count increment When calling refcount_inc(&event->mmap_count) inside perf_mmap_rb(), the following warning is triggered: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 PoC:
    struct perf_event_attr attr = {0}; int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); int victim = syscall(__NR_perf_event_open, &attr, 0,
    -1, fd, PERF_FLAG_FD_OUTPUT); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0); This occurs when creating a group member event with the flag PERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing the event triggers the warning. Since the event has copied the output_event in perf_event_set_output(), event->rb is set. As a result, perf_mmap_rb() calls refcount_inc(&event->mmap_count) when event->mmap_count = 0. Disallow the case when event->mmap_count = 0.
    This also prevents two events from updating the same user_page. (CVE-2026-23127)

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

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

  -互连debugfs将 src_node 和 dst_node 初始化为空字符串 debugfs_create_str() API 假设字符串指针为 NULL 或指向有效的 kmalloc() 内存。不初始化指针会导致问题。在创建 debugfs 条目之前将 src_node 和 dst_node 初始化为空字符串以保证读取和写入是安全的。 (CVE-2026-23123)

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

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

  - wifiath12k修复 dma_free_coherent() 指针 dma_alloc_coherent() 会分配 DMA 映射的缓冲区并将地址存储在 XXX_unaligned 字段中。释放缓冲区时应重用这些地址而不是对齐的地址。 (CVE-2026-23135)

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

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

  - sctp将 SCTP_CMD_ASSOC_SHKEY 移动到 SCTP_CMD_PEER_INIT 之后 SCTP-AUTH 密钥初始化失败时SCTP 传输路径中报告了 null-ptr-deref
    ================================================== ================ KASAN范围 [0x0000000000000018-0x000000000000001f] CPU0 PID16 Comm: ksoftirqd/0 Tainted: GW 6.6.0 #2 RIP
    0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP
    0010sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 调用跟踪
    sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.a5+0x15/isra 0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [内联] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c 1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 当 sctp_auth_asoc_init_active_key( ) 处理 INIT_ACK 时sctp_sf_do_5_1C_ack() 中发生故障。在这种情况下，命令序列当前为 - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO 如果 SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO 如果 SCTP_CMD_ASSOC_SHKEY 失败asoc->shkey SCTP_CMD_PEER_INIT 已设置 asoc->peer.peer_chunks。这允许 auth = 1 且 shkey = NULL 的 DATA 区块由 sctp_datamsg_from_user() 排队。由于命令解释在失败时停止因此不应通过 SCTP_CMD_GEN_COOKIE_ECHO 发送 COOKIE_ECHO。然而T1_COOKIE 定时器已经启动它可能稍后将 COOKIE_ECHO 排入输出队列。因此DATA 区块可与 sctp_outq_flush_data() 中的 COOKIE_ECHO 一起传输从而导致观察到的问题。类似于在 sctp_process_init() 之后调用 sctp_auth_asoc_init_active_key() 的其他位置类似此修补程序将 SCTP_CMD_ASSOC_SHKEY 移动到紧接在 SCTP_CMD_PEER_INIT 之后、停止 T1_INIT 并启动 T1_COOKIE 之前。这可确保在共享密钥生成失败时无法发送经过身份验证的 DATA。它还允许 T1_INIT 定时器重新传输 INIT从而为客户端提供另一次处理 INIT_ACK 和重试密钥设置的机会。 (CVE-2026-23125)

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

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

  - net/mlx5eTC仅删除现有对等机的流当删除 TC 转向流时仅迭代实际的 devcom 对等机而不是假设所有可能的端口存在。这可避免接触不存在的对等机，并确保仅限于驱动程序当前连接的设备进行清理。缺陷内核空指针取消引用地址0000000000000008 #PF内核模式中的主管写入访问 #PFerror_code(0x0002)
    - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE 硬件名称QEMU Standard PC (Q35 + ICH9 、2009、BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] 代码00 00 a8 08 74 a8 49 8b 46 18 f66 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 08 d84 89 2c 24 49 89 5c ce 96 e1 49 RSP0018:ff11000143867528 EFLAGS00010246 RAX: 0000000000000000 RBXdead000000000122 RCX
    0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12:
    ff11000115f0ae78 R130000000000000000 R14ff11000115f0a800 R15ff11000106f3d2a0 FS
    00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [ cls_Flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress]
    __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320
    __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60____sys_sendmsg+0x1ef/0x230 copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ?
    __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX000000000000002e RAXffffffffffffffda RBX000055a2efcc75e0 RCX00007f35238bb764 RDX
    0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13:
    000000006947df8f R14000055a2efcc75e0 R1500007ffed4c35780 (CVE-2026-23173)

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

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

  - arm64/fpsimdptrace修复 !SME 系统上的 SVE 写入支持 SVE 但不支持 SME 时对 NT_ARM_SVE regset 的 ptrace 写入可将被跟踪者置于存储非流式 SVE 寄存器数据的无效状态为 FP_STATE_SVE 格式但 TIF_SVE 已清除。这会导致稍后来自 fpsimd_restore_current_state() 的警告例如 WARNING: CPU: 0 PID: 7214@arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748 当发生这种情况时fpsimd_restore_current_state() 将设置 TIF_SVE会将任务转换为正确的状态。这会在可能发生 TIF_SVE 的任何其他检查之前发生，因为 TIF_SVE 的其他检查仅在 FPSIMD/SVE/SME 状态为实时时发生。因此，除该警告外，不存在任何功能问题。此缺陷是在重做 commit: 9f8bf718f2923 中的错误处理期间引入的 (arm64/fpsimd: ptrace妥善处理错误) ... 其中 TIF_SVE 的设置已移至仅当 system_supports_sme() 为 true 时才执行的区块。通过删除 system_supports_sme() 检查来修复此问题。这可确保针对 NT_ARM_SVE 的SVE 格式写入设置 TIF_SVE，但代价是无条件操纵被跟踪者已保存的 svcr 值。svcr 的操纵属于良性且成本低我们也已经在其他地方做了类似的事情例如在信号处理期间所以我认为不值得通过 system_supports_sme() 检查来保护这一点。除上述内容外无任何功能变更。当 system_supports_sme() 时sve_set_common() 的 'type' 参数仅设置为 ARM64_VEC_SME在 ssve_set()中因此当 !system_supports_sme() 时switch 语句中的 ARM64_VEC_SME 情况仍然不可访问。当 CONFIG_ARM64_SME=n 时sve_set_common() 的唯一调用程序是 sve_set()编译器可对 type 为 ARM64_VEC_SVE 的情况进行常量折叠删除其他情况的逻辑。
    (CVE-2026-23114)

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

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

  - libceph重置 osd_fault() 中的稀疏读取状态发生错误时连接会被放弃、重新建立并会重试任何待定操作。OSD 客户端使用基本上独立于 messenger 状态的独立状态机跟踪 sparse-read 回复的进度。如果连接在负载过程中丢失或 sparse-read 状态机返回错误则 sparse-read 状态不会重置。
    然后OSD 客户端会将新回复的开始解释为旧回复的继续。如果这导致稀疏读取机制进入故障状态它可能永远不会恢复并产生如下循环
    libceph[0] 获得 0 个区段 libcephdata len 142248331 != extent len 0 libceph: osd0 (1)...:6801 套接字读取时发生错误 libcephdata len 142248331 != extent len 0 libceph: osd0 (1)。 ..6801 套接字读取时出错因此请重置 osd_fault() 中的 sparse-read 状态确保从干净的状态开始重试。
    (CVE-2026-23136)

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

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

  - l2tp避免 l2tp_tunnel_del_work() 中的一个数据争用 我们应该仅在处理内核套接字时读取 sk->sk_socket。 syzbot 报告以下 data-race: BUGKCSAN: l2tp_tunnel_del_work / sk_common_release 中的数据争用由任务 5365 在 cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/ 写入 8 字节的 0xffff88811c182b20 sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [内联] sock_close+0x6b/0x150 net/socket.c:1455
    __fput+0x29b/0x650 fs/file_table.c:468____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [内联]
    __exit_to_user_mode_loop kernel/entry/common.c:44 [内联] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [内联] syscall_exit_to_user_mode_prepare include/linux/irq -entry-common.h:256 [内联] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [内联] syscall_exit_to_user_mode include/linux/entry-common.h:194 [内联] do_syscall_64+0x1e1/0x2b0 arch/x86/ entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由 cpu 1 上的任务 827 读取到 0xffff88811c182b20 (8 字节)
    l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 work_thread+0x582/0x770 kernel/workqueue.c:3421 kthread +0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 值已更改
    0xffff88811b818000 -> 0x0000000000000000 (CVE-2026-23120)

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

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

  - 蓝牙MGMT修复 set_ssp_complete 中的内存泄漏修复 set_ssp_complete() 中的内存泄漏其中从待定列表删除后未释放 mgmt_pending_cmd 结构。Commit 302a1f674c00蓝牙MGMT修复可能的 UAF将 mgmt_pending_foreach() 调用替换为单个命令处理但缺少在 set_ssp_complete() 的错误和成功路径中添加 mgmt_pending_free() 调用的方法。其他完成函数如 set_le_complete() 已在同一个提交中正确修复。对于每个完成的 SSP 命令这将导致 mgmt_pending_cmd 结构及其相关参数数据发生内存泄漏。在两个代码路径中添加缺少的 mgmt_pending_free(cmd) 调用以修复内存泄漏。也修复 set_advertising_complete() 中的相同问题。 (CVE-2026-23151)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl() Since GEM bo handles are u32 in the uapi and the internal implementation uses idr_alloc() which uses int ranges, passing a new handle larger than INT_MAX trivially triggers a kernel warning: idr_alloc(): ... if (WARN_ON_ONCE(start < 0)) return -EINVAL; ... Fix it by rejecting new handles above INT_MAX and at the same time make the end limit calculation more obvious by moving into int domain. (CVE-2026-23149)

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

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

  - igc将每个队列的 TSN TX 数据包缓冲区从 7 KB 减少到 5 KB 在重时间戳负载下之前每个队列的 7 KB 造成 TX 单元挂起。减少到 5 KB 可避免这些挂起并符合 I225/I226 SW 用户手册第 7.5.4中的 TSN 建议。此更改释放的 8 KB 当前未使用。此减少预期不会影响吞吐量因为小 TSN 数据包 i226 受到 PCIe 限制而非 TX 缓冲区限制。 (CVE-2026-23122)

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

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

  - bpf、test_run从允许的元数据大小中减去 xdp_frame 的大小 xdp_frame 结构占用部分 XDP 帧余量从而限制了元数据的大小。但是在 bpf_test_run 中我们没有考虑到这一点因此用户空间可能提供大小过大的元数据占用整个余量。如果用户空间在实时数据包模式中提供如此之大的元数据则 xdp_test_run_init_page() 调用中的 xdp_update_frame_from_buff() 调用将会失败随后数据包传输将使用未初始化的帧结构导致通常的 Bad Stuff。修复 标签中的 提交修复了 xdp_update_frame_from_buff() 中的第二次检查可能失败的相关缺陷但未对元数据大小添加任何其他限制。通过添加元数据大小的额外检查来完成该补丁。稍微对检查重新排序使逻辑更清楚并添加注释。
    (CVE-2026-23140)

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

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

  - mISDN注解围绕 dev->work 的数据争用 dev->work 会在 mISDN_read() 和 mISDN_poll() 中无锁地重新读取。添加 READ_ONCE()/WRITE_ONCE() 注释。缺陷KCSANmISDN_ioctl / mISDN_read 中的数据争用由任务 10864 在 cpu 1 上写入 0xffff88812d848280 共 4 字节misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/ timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [内联] __do_sys_ioctl fs/ioctl.c:597 [内联] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c 583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c :94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 被任务 10857 在 cpu 0 上读取 0xffff88812d848280 共 4 字节mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vread_write.c:847 /0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [内联]
    __se_sys_readv fs/read_write.c:1162 [内联] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/ syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 值已更改0x00000000 -> 0x00000001 (CVE-2026-23121)

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

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

  - ipv6注解 ndisc_router_discovery() 中的数据争用 syzbot 发现 ndisc_router_discovery() 可在不保持锁定的情况下读取和写入 in6_dev->ra_mtu [1] 这看起来很好IFLA_INET6_RA_MTU 已尽力而为。
    添加 READ_ONCE()/WRITE_ONCE() 以记录争用。请注意在未来的修补程序中我们也可能拒绝非法的 MTU 值 (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu)。 [1] BUGKCSANndisc_router_discovery / ndisc_router_discovery 中的数据争用由任务 25817 在 cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0ipv6d/0xffff888119809c20 读取 4 字节ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/ linux/netfilter.h:318 [内联] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [内联] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... 由任务 25816 在 cpu 0 上写入 0xffff888119809c20共 4 字节: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x3d2ad net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c 489 NF_HOOK include/linux/netfilter.h :318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/ 0x340 net/ipv6/ip6_input.c:79 ... 值已更改
    0x00000000 -> 0xe5400659CVE-2026-23124

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

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

  - flex_proportions确保 fprop_new_period() hardirq 安全Bernd 报告了来自弹性比例代码的 lockdep splat其本质上是在抱怨以下争用 <timer fires> run_timer_softirq
    - 位于 softirq 上下文 call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); <hardirq is raised> ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_rac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - 发现奇数序列因此无限循环请注意仅当 bdi 已配置写出吞吐量的最大分数时才可能发生类似的死锁这种死锁通常很少见但在 FUSE bdis 之例中很常见。要修复此问题必须确保序列计数器的写入部分是 irqsafe。 (CVE-2026-23168)

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

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

  - drm/xe/nvm修复 aux 添加失败时的双重释放在成功 auxiliary_device_init() 后aux_dev->dev.release (xe_nvm_release_dev()) 将负责 kfree(nvm)。当 auxiliary_device_add() 失败时驱动程序将调用 auxiliary_device_uninit()后者又调用 put_device()。以便触发 .release 回调释放 auxiliary_device 关联内存。将 kfree(nvm) 移动到 auxiliary_device_init() 故障路径并删除错误转至路径以修复以下错误。
     [ 13.232905] ============================================== ==================== [ 13.232911] BUG: KASAN
    xe_nvm_init+0x751/0xf10 中的双重释放 [xe] [ 13.233112] 由任务 systemd-udevd/273 释放的 addr ffff888120635000 [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd 未受感染 6.19.0 -rc2-lgci-xe-kernel+ #225 PREEMPT(随意) ... [ 13.233125] 调用跟踪[ 13.233126] <TASK> [ 13.233127] dump_stack_lvl+0x7f/0xc0 [ 13.233132] print_report+0xce/0x610 [ 13.233136]? kasan_complete_mode_report_info+0x5d/0x1e0 [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe] ... v2终止错误前往路径。(Alexander) 从提交 a3187c0c2bbd947ffff97f90d077ac88f9c2a215 中选取的最好条目(CVE-2026-23162)

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

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

  - perfsched修复使用新的 is_user_task() 帮助程序时发生的 perf 崩溃为了进行用户空间堆栈跟踪当前任务必须是已在用户空间中执行的用户任务。以前可以通过检查 task_struct mm 字段来测试任务是否为用户任务。如果非 NULL则为用户任务否则为内核任务。但情况随着时间推移发生了变化一些内核任务现在有了自己的 mm 字段。有人提议改为测试 PF_KTHREAD 并使用两个函数来封装此检查以防测试任务是否为用户任务变得更加复杂[1]。但是这会被拒绝C 代码只会直接检查 PF_KTHREAD。之后发现并非所有内核线程都设置 PF_KTHREAD。io-uring 帮助程序改为设置 PF_USER_WORKER并且这也需要添加。但仅检查标记仍然不够。存在非常小的任务退出时窗口其释放其 mm 字段并将其设置回 NULL。如果 perf 此时触发则标记测试会提示其为用户空间任务但当 perf 读取 mm 字段时其会在空指针取消引用时崩溃。现在有一些标记可用于测试任务是否正在退出但在这些区域中进行设置的 perf 可能仍要分析用户空间任务以查看其退出位置。唯一真正的测试是同时检查标记和 mm 字段。无需在每个位置都进行此修改，而是创建一个新的 is_user_task() 辅助函数，由该函数进行所需的所有测试，以了解读取用户空间内存是否安全。 [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ (CVE-2026-23159)

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

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

  - efivarf修复 efivar_entry_get() 中的错误传播即使底层 __efivar_entry_get() 失败efivar_entry_get() 也始终返回成功掩码错误。这可能导致未初始化的堆内存被复制到 efivarfs_file_read() 路径中的用户空间。通过从 返回错误来修复此问题
    __efivar_entry_get()。 (CVE-2026-23156)

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

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

  - procfs避免在保持 VMA 锁定的情况下提取版本 ID 修复 PROCMAP_QUERY 以便仅在放置 mmap_lock 或每个 VMA 的锁定（以用于锁定相关 VMA 的任何一个）之后提取可选的版本 ID 以避免 syzbot 报告的死锁-> #1 (&mm ->mmap_lock){++++}-{4:4}__might_fault+0xed/0x170
    _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sb->s_type- >i_mutex_key#8){++++}-{4:4}:
    __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0
    __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this可能不安全的锁定情况CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock);
    lock(&sb->s_type->i_mutex_key#8) lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8) *** 死锁
    *** 这种情况似乎因最近的
    777a8560fd29 (lib/buildid将 __kernel_read() 用于可休眠环境为确保此问题我们需要在 VMA 仍处于锁定状态时获取文件引用计数但除此之外一切都非常简单。
    内部 build_id_parse() API 假设 VMA 已传递但由于仅需要基础文件引用因此只需添加另一个预期文件会直接传递的 build_id_parse_file() 变体。 [akpm@linux-foundation.org修复 kerneldoc] (CVE-2026-23199)

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

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

  - ALSAusb-audio防止帧数过多在这种情况下用户通过适用于速率 22050 / pps 1000 的 maxpacksize 40 和 packsize[0] 22 packsize[1] 23 构建参数。每个数据 URB 的缓冲区大小为 maxpacksize * packets在此示例中为 40 * 6 = 240;用户执行写入操作以将音频数据发送到 ALSA PCM 回放流时计算的帧数为 packsize[0] * packet = 264这超出了分配的 URB 缓冲区大小从而触发越界 (OOB) syzbot [1] 报告的问题。添加了计算帧数时对单个数据 URB 帧的数量的检查以防止 [1]。 [1] BUGKASAN通过任务 syz.0.17/5506 调用跟踪copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 在 addr ffff88804337e800 写入大小为 264 的 slab 越界copy_to_urb+0x261/ 0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 (CVE-2026-23208)

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

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

  - macvlan修复 macvlan_common_newlink() 中的错误恢复 valis 提供了造成内核崩溃的良好重现
    ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He 也提供了非常详细的分析 <quote valis> 当建立新的 macvlan 链接时会触发该问题使用 MACVLAN_MODE_SOURCE 模式和 MACVLAN_MACADDR_ADD或 MACVLAN_MACADDR_SET 参数时较低的设备已具有 macvlan 端口并且从 macvlan_common_newlink() 调用 register_netdevice() 失败例如因为无效的链路名称。在这种情况下会从 macvlan_change_sources() / macvlan_common_newlink() 调用 macvlan_hash_add_source这会添加对 vlan 的引用到使用 macvlan_source_entry 的端口的 vlan_source_hash。 vlan 是指向正在创建的链接的 priv 数据的指针。当 register_netdevice() 失败时错误从 macvlan_newlink() 返回至 rtnl_newlink_create() if (ops->newlink) err = ops->newlink(dev, ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out并调用 free_netdev()导致附加到较低设备的 macvlan 端口的源条目中仍引用 struct net_device 上的 kvfree()。现在在 macvlan 端口上发送的所有具有匹配源 mac 地址的数据包将触发 macvlan_forward_source() 中的释放后使用。</quote valis> 尽管如此我的修复是确保每当 goto destroy_macvlan_port 时调用 macvlan_flush_sources() 而不管 @create 的值已占用路径。
    非常感谢 valis 关注此问题。 (CVE-2026-23209)

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

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

  - pmdomainimx8m-blk-ctrl修复了 bc->domains 的超出范围访问问题 修复 imx8m_blk_ctrl_remove() 中的 bc->domains 超出范围访问问题。 (CVE-2026-23187)

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

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

  - netusbr8152修复恢复重置死锁 rtl8152 可在重置期间触发设备重置这可能导致死锁**** 10 秒后 DPM 设备超时距离错误发生还有 15 秒 **** 调用跟踪 <TASK> schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470
    __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110 The problem is that rtl8152 resume calls reset under tp ->control 重置时的互斥体基本上会重新进入 rtl8152 并尝试再次获取相同的 tp->control 锁定。在 tp->control 互斥体范围之外重置 INACCESSIBLE 设备以避免递归 mutex_lock() 死锁。 (CVE-2026-23188)

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

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

  - smb/server命令为重放操作且 时修复 parse_durable_handle_context() 中的 refcount 泄漏
    -返回 ENOEXEC必须释放 ksmbd_file 的 refcount。 (CVE-2025-71204)

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

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

  - netcpsw在工作队列 Commit 1767bb2d47b7 (ipv6mcast不保持 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 的 RTNL。) 中执行 ndo_set_rx_mode 删除了 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 操作的 RTNL 锁。然而此变更在我的 BeagleBone Black 板上触发了以下调用跟踪WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124 CPU#0: rpcbind/481 RTNL:
    在 net/8021q/vlan_core.c 的断言失败 (236) 中链接的模块CPU: 0 UID: 997 PID: 481 Comm: rpcbind 未受感染 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT 硬件名称Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x28/0x2c show_stack from dump_stack_lvl+0x30/0x38 dump_stack_lvl from __warn+0xb8/0x11c __warn from warn_slowpath_fmt+0x130/0x194 warn_slowpath_fmt from vlan_for_each+0x120/0x124 vlan_for_each from cpsw_add_mc_addr+0x54 /0x98 cpsw_add_mc_addr 来自 __hw_addr_ref_sync_dev+0xc4/0xec __hw_addr_ref_sync_dev 来自 __dev_mc_add+0x78/0x88
    来自 igmp6_group_added+0x84/0xec 的 __dev_mc_add 来自 __ipv6_dev_mc_inc+0x1fc/0x2f0 的 igmp6_group_added
    __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4 __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168 do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8 ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c do_sock_setsockopt from __sys_setsockopt+0x84/0xac __sys_setsockopt from ret_fast_syscall+0x0/0x54 This trace occurs because vlan_for_each() is在 cpsw_ndo_set_rx_mode() 中调用从而预期保持 RTNL 锁。由于修改 vlan_for_each() 以在没有 RTNL 锁定的情况下进行操作并不简单而且由于在具有和不具有 RTNL 锁定的情况下会在不同的代码路径中调用 ndo_set_rx_mode()因此在 cpsw_ndo_set_rx_mode() 中简单地添加 rtnl_lock() 不是可行的解决方案。为解决此问题我们选择遵循 icssg-prueth 驱动程序使用的方法在工作队列内执行实际处理。请注意：为重现此问题，我手动还原了提交 c477358e66a3 中对 am335x-bone-common.dtsi 的更改 (ARMdts: am335x-bone切换到新的 cpsw 交换机 drv)，以便还原为旧的 cpsw 驱动程序。 (CVE-2026-23175)

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

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

  - net/schedcls_u32使用 skb_header_pointer_careful() skb_header_pointer() 未充分验证负的 @offset 值。改用 skb_header_pointer_careful()。GangMin Kim 提供了报告和欺骗 u32_classify()BUGKASANu32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221 中的 slab 越界 (CVE-2026-23204)

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

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

  - netcpsw_new在工作队列 Commit 1767bb2d47b7 (ipv6mcast不保持 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 的 RTNL。) 中执行 ndo_set_rx_mode 删除了 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 操作的 RTNL 锁。然而此变更在我的 BeagleBone Black 板上触发了以下调用跟踪警告: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124 CPU#0: rpcbind/496 RTNL:
    net/8021q/vlan_core.c 的断言失败 (236) 中链接的模块CPU: 0 UID: 997 PID: 496 Comm: rpcbind 未受感染 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT 硬件名称Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x28/0x2c show_stack from dump_stack_lvl+0x30/0x38 dump_stack_lvl from __warn+0xb8/0x11c __warn from warn_slowpath_fmt+0x130/0x194 warn_slowpath_fmt from vlan_for_each+0x120/0x124 vlan_for_each from cpsw_add_mc_addr+0x54 /0xd8 cpsw_add_mc_addr 来自 __hw_addr_ref_sync_dev+0xc4/0xec __hw_addr_ref_sync_dev 来自 __dev_mc_add+0x78/0x88
    来自 igmp6_group_added+0x84/0xec 的 __dev_mc_add 来自 __ipv6_dev_mc_inc+0x1fc/0x2f0 的 igmp6_group_added
    __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4 __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168 do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8 ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c do_sock_setsockopt from __sys_setsockopt+0x84/0xac __sys_setsockopt from ret_fast_syscall+0x0/0x5 This trace occurs because vlan_for_each() is在 cpsw_ndo_set_rx_mode() 中调用从而预期保持 RTNL 锁。由于修改 vlan_for_each() 以在没有 RTNL 锁定的情况下进行操作并不简单而且由于在具有和不具有 RTNL 锁定的情况下会在不同的代码路径中调用 ndo_set_rx_mode()因此在 cpsw_ndo_set_rx_mode() 中简单地添加 rtnl_lock() 不是可行的解决方案。为解决此问题我们选择遵循 icssg-prueth 驱动程序使用的方法在工作队列内执行实际处理。 (CVE-2026-23203)

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

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

  - wifiiwlwifimld取消 mlo_scan_start_wk 断开连接时未取消 mlo_scan_start_wk。实际上它在任何地方都不会被取消除了在重新启动清理中我们实际上并没有必要这样做。在下面发生这种情况时可能会造成 init-after-queue 问题例如如果工作已排入队列然后执行 drv_change_interface。如果在释放 vif 后执行工作这也会造成释放后使用。
    (CVE-2026-23185)

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

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

  - cgroup/dmem修复设置 max 时的空指针取消引用触发了一个问题缺陷内核空指针取消引用地址0000000000000000 #PF内核模式下的主管读取访问
    error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 658 Comm: bash 受感染的 6.19.0-rc6-next-2026012 受感染的[ O]=OOT_MODULE 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)RIP0010:strcmp+0x10/0x30 RSP0018:ffffc900017f7dc0 EFLAGS00000246 RAX
    0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358 RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000 RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714 R10:
     R110000000000000001  : ffff888107cd4358 R12: 0007ffffffffffff R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3:
    0000000105c79000 CR4: 00000000000006f0 调用跟踪 <TASK> dmemcg_limit_write.constprop.0+0x16d/0x390
    __pfx_set_resource_max+0x10/0x10 kernfs_fop_write_iter+0x14e/0x200 vfs_write+0x367/0x510 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP
    0033:0x7f42697e1887 此触发了设置 max 无限制该命令类似于echo test/region0 > dmem.max。要修复此问题请添加在解析 region_name 后选项是否有效的检查。 (CVE-2026-23183)

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

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

  - nvmet-tcp修复 nvmet_tcp_listen_data_ready() 中的挂起如果在 TCP_LISTEN 中套接字关闭则将运行回调以刷新所有未完成的数据包进而通过持有 sk_callback_lock 调用 nvmet_tcp_listen_data_ready()。因此在尝试获取 sk_callback_lock() 之前需要检查是否处于 TCP_LISTEN 状态以避免死锁。 (CVE-2026-23179)

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

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

  - ceph修复 ceph_mds_auth_match() 中的空指针取消引用 CephFS 内核客户端存在从 6.18-rc1 开始的回归。如果 fs_name == NULL我们在 ceph_mds_auth_match() 中存在问题 const char fs_name = mdsc->fsc->mount_options->mds_namespace ... if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) { / fsname 不匹配，尝试下一个 */ return 0; Patrick Donnelly 建议如下总而言之我们应该从 MDSMap 开始解码“fs_name”并对其进行严格的授权检查。
    请注意“-o mds_namespace=foo”应仅用于选择要挂载的文件系统而不得用于其他用途。有可能未指定 mds_namespace但内核将挂载唯一可能具有名称 foo 的文件系统。此修补程序重做 ceph_mdsmap_decode() 和 namespace_equals()其目标是支持建议的概念。现在 struct ceph_mdsmap 包含 m_fs_name 字段用于接收 ceph_extract_encoded_string() 提取的 FS 名称的副本。对于旧 CephFS 文件系统使用 cephfs 名称。 [ idryomov在 ceph_mdsmap_decode() 中将冗余的 %*pE 替换为 %s删除 ceph_namespace_match() 中的一系列 strlen() 调用删除对 namespace_equals() 正文的更改以避免将空的 mds_namespace 视为相等删除对 ceph_mdsc_handle_fsmap 的更改()因为 namespace_equals() 不是等效替换] (CVE-2026-23189)

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

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

  - wifimac80211ocb接口未加入时跳过 rx_no_sta ieee80211_ocb_rx_no_sta() 假定仅在 JOIN_OCB 之后出现的有效通道上下文。RX 可能在执行 JOIN_OCB 之前运行这种情况下 OCB 接口不可操作。当接口未加入时跳过 RX 对等机处理以避免 RX 路径中出现警告。 (CVE-2025-71224)

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

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

  - smb/client修复 smb2_open_file() Re Producer 中的内存泄漏1. 服务器目录导出为只读 2. 客户端mount -t cifs //${server_ip}/export /mnt 3. 客户端dd if=/ dev/zero of=/mnt/file bs=512 count=1000 oflag=direct 4. 客户端umount /mnt 5. 客户端sleep 1 6. 客户端modprobe -r cifs 错误消息如下===== ================================================== ====================== 缺陷 cifs_small_rq未受感染__kmem_cache_shutdown() 上剩余的对象
    -------------------------------------------------- --------------------------- 对象 0x00000000d47521be @offset=14336... 警告mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440 CPU#0modprobe/1577 ...
    Call Trace: <TASK> kmem_cache_destroy+0x94/0x190 cifs_destroy_request_bufs+0x3e/0x50 [cifs] cleanup_module+0x4e/0x540 [cifs] __se_sys_delete_module+0x278/0x400 __x64_sys_delete_module+0x5f/0x70 x64_sys_call+0x2299/0x2ff0 do_syscall_64+0x89/0x350 entry_SYSCALL_64_after_hwframe+0x76/ 0x7e ...
    kmem_cache_destroy cifs_small_rq从 cifs_destroy_request_bufs+0x3e/0x50 调用时Slab 缓存中仍然包含对象 [cifs] 警告mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190 CPU#0: modprobe/1577 (CVE-2026-23205)

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

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

  - linkwatch在调用程序中使用 __dev_put() 以防止 UAF空列表且无阻塞返回)等待 refcount 通过 netdev_wait_allrefs_any() 变成 1然后通过 kobject_put() 释放设备。当 __linkwatch_run_queue() 尝试在已释放的设备上调用 netdev_unlock_ops() 时这会造成释放后使用。
    请注意在 netdev_run_todo() 中在 kobject_put() 之前添加 netdev_lock_ops()/netdev_unlock_ops() 对是行不通的因为 netdev_lock_ops() 是有条件的 - 它仅在 netdev_need_ops_lock() 返回 true 时才锁定。如果设备不需要 ops_lock则 linkwatch 将不会保持任何锁定并且获取锁定的 netdev_run_todo() 将不会提供同步。通过将 __dev_put() 从 linkwatch_do_dev() 移动到其调用方来修复此问题。设备引用在逻辑上与从列表中删除的设备配对因此从列表中删除该设备的调用方释放该设备是合理的。这允许在所有设备访问完成之后放置 __dev_put()从而阻止 UAF。此缺陷通过在 __linkwatch_run_queue() 中的 linkwatch_do_dev() 之后添加 mdelay(2000)然后运行ip tuntap add mode tun name tun_test ip link set tun_test up ip link set tun_testcarrier off ip link set tun_testcarrier on sleep 0.5 重现该缺陷ip tuntap del mode tun name tun_test KASAN 报告 ======================================== ========================== BUGKASANnetdev_need_ops_lock include/net/netdev_lock.h:33 中的释放后使用 [inline] BUG KASANnetdev_unlock_ops include/net/netdev_lock.h:47 中的释放后使用 [内联] 缺陷
    __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 由任务 kworker/u32:10/8123 CPU:0 UID:0 PID:8123 Comm: kworker/u32:10 位于 addr ffff88804de5c008 进行的大小为 8 的读取位于 addr ffff88804de5c008 #0 的syzkaller  PREEMPT(full) 硬件名称QEMU Standard PC (Q35 + ICH92009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作队列events_unbound linkwatch_event 调用跟踪 <TASK> __dump_stack lib/dump_stack .c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x156/0x4c9 mm/kasan/report.c:482 kasan_report+0xdf/ 0x1a0 mm/kasan/report.c:595 netdev_need_ops_lock include/net/netdev_lock.h:33 [内联] netdev_unlock_ops include/net/netdev_lock.h:47 [内联] __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304 process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3421 kthread +0x3b 3/0x730 kernel/kthread.c:463 ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> ====== ================================================== ========== (CVE-2026-23192)

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

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

  - ice修复 VSI 重建期间的 PTP 空指针取消引用 修复争用条件即重建 VSI 时 PTP 定期工作运行访问空 vsi->rx_rings。序列为 1. ice_ptp_prepare_for_reset() 取消 PTP 工作 2. ice_ptp_rebuild() 立即将 PTP 工作排入队列 3. 在 ice_ptp_rebuild() 之后发生 VSI 重建 4. PTP 工作运行并访问空 vsi->rx_rings修复了重建期间取消的 PTP 工作保持状态只在 ice_rebuild() 中完成 VSI 重建后才将其排队。添加了 ice_ptp_queue_work() 辅助函数以封装排队 PTP 工作的逻辑确保其仅在支持 PTP 且状态为 ICE_PTP_READY 时排队。错误日志[ 121.392544] ice 0000:60:00.1PTP 重置成功 [121.392692] 缺陷内核空指针取消引用地址0000000000000000 [ 121.392712] #PF内核模式下的主管读取访问权限 [ 121.392720] #PF error_code(0x0000) - not-present 页面 [ 121.392727] PGD 0 [121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp- 0000:60 受感染的 GS 6.19.0-rc6+ #4 PREEMPT(typical) [ 121.392761] 受感染的 [S]=CPU_OUT_OF_SPEC [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice] [ 121.393042] 调用跟踪[ 121.393047] <TASK> [121.393055] ice_ptp_periodic_work+0x69/0x180 [ice] [ 121.393202] kthread_worker_fn+0xa2/0x260 [121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice] [ 121.393359] ?
    __pfx_kthread_worker_fn+0x10/0x10 [ 121.393371] kthread+0x10d/0x230 [ 121.393382] ?
    __pfx_kthread+0x10/0x10 [ 121.393393] ret_from_fork+0x273/0x2b0 [ 121.393407] ? __pfx_kthread+0x10/0x10 [121.393417] ret_from_fork_asm+0x1a/0x30 [ 121.393432] </TASK> (CVE-2026-23210)

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

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

  - hwmon (acpi_power_meter) 修复与 acpi_power_meter_notify() 相关的死锁 acpi_power_meter 驱动程序的 .notify() 回调函数 acpi_power_meter_notify() 在也由未注册设备的 sysfs 属性中的回调获取的锁定下调用 hwmon_device_unregister()该锁定容易在 sysfs 访问和设备删除之间发生死锁。通过将 acpi_power_meter_notify() 中的 hwmon 设备删除移到相关锁定之外解决此问题但请注意单独执行此操作是不够的因为两个并发 METER_NOTIFY_CONFIG 通知可能会同时尝试删除同一设备。为防止这种情况发生请在 acpi_power_meter_notify() 中添加新的锁以序列化执行 switch () 语句。为简单起见，我们将其设置为静态互斥体，从性能的角度而言这不应成为问题。新锁还允许在内锁之外调用 acpi_power_notify() 中的 hwmon_device_register_with_info()因为它可以防止由该函数处理的其他通知在注册基于其的 hwmon 设备时操纵资源对象。新的锁也将序列化从 acpi_power_meter_notify() 发送的 ACPI netlink 消息这通常有助于确保处理固件通知的顺序与发送与之相关的 netlink 消息的顺序相同。此外请注意hwmon_device_register_with_info() 可能会失败在这种情况下resource->hwmon_dev 将变成一个错误指针因此需要向 acpi_power_meter_notify() 和 acpi_power_meter_remove() 添加检查以避免在该情况下由其尝试取消注册 hwmon 设备指针。 (CVE-2026-23186)

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

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

  - HIDIntel-thc-hidIntel-thc添加安全检查读取 DMA 缓冲区在读取 DMA 缓冲区之前添加 DMA 缓冲区准备情况检查以避免意外的空指针访问。 (CVE-2026-23196)

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

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

  - wifiwlcore在 skb_push 之前确保 skb 余量 这可避免 wl1271_tx_work 偶尔的 skb_under_panic Oops。在这种情况下，余量小于所需的量（通常为 110 - 94 = 16 字节）。
    (CVE-2025-71222)

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

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

  - ceph修复因 parse_longname() 中 kfree() 的无效指针而造成的 oops 这可修复读取 ceph 快照目录 (.snap) 时发生的内核 oops例如通过运行“ls /mnt/my_ceph/.snap”。变量 str 受到 __free(kfree) 保护但因跳过快照名称中开头的“_”而变量 str 增加一。因此会通过无效指针调用 kfree()。此修补程序不再需要推进指针因此以正确的内存指针调用 kfree()。重现步骤 1. 在 cephfs 卷上创建快照我的测试案例中有 63 个快照2. 将 cephfs 挂载添加到 fstab $ echo samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/ test/stuff ceph acl,noatime,_netdev 0 0 >> /etc/fstab 3. 重新引导系统 $ systemctl restart 4. 检查是否已真正挂载 $ mount | test/stuff ceph acl,noatime,_netdev 0 0 >> /etc/fstab grep stuff 5. 列出快照我的系统上预期有 63 个快照$ ls /mnt/test/stuff/.snap 现在 ls 永远挂起内核日志显示 oops。 (CVE-2026-23201)

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

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

  - smb/server在 create_smb2_pipe() 中的错误路径上调用 ksmbd_session_rpc_close() 当 ksmbd_iov_pin_rsp() 失败时应调用 ksmbd_session_rpc_close()。 (CVE-2025-71220)

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

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

  - dpaa2-switch为 IRQ 处理程序中的 if_id 添加边界检查 IRQ 处理程序从硬件状态寄存器的较高 16 位提取 if_id并在未经验证的情况下将其用于 ethsw->ports[] 的索引。由于 if_id 可以是任何 16 位值 (0-65535) 但端口数组仅分配了 sw_attr.num_ifs 元素因此这可能导致越界读取。在访问数组之前添加边界检查这与 dpaa2_switch_rx() 中的现有验证一致。 (CVE-2026-23180)

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

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

  - 已修复 Linux 内核中的下列漏洞：rust_binder: correctly handle FDA objects of length zero Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used `skip == 0` to mean this is a pointer fixup, but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace. The pattern of using `skip == 0` as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum. I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff. The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt: > There appears to be a bug in @drivers/android/binder/thread.rs where > the Fixups oob bug is triggered with 316 304 316 324. This implies > that we somehow ended up with a fixup where buffer A has a pointer to > buffer B, but the pointer is located at an index in buffer A that is > out of bounds.
    Please investigate the code to find the bug. You may > compare with @drivers/android/binder.c that implements this correctly. (CVE-2026-23194)

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

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

  - cgroup/dmem避免池 UAF 发现 UAF 问题缺陷KASAN由任务 insmod/527 CPU: 4 UID: 0 PID造成的 page_counter_uncharge+0x65/0x150 地址 ffff888106715440 中发生大小 8 的 slab-use-after-free 写入527 Comminsmod 6.19.0-rc7-next-20260129+ #11 受感染[O]=OOT_MODULE 调用追踪 <TASK> dump_stack_lvl+0x82/0xd0 kasan_report+0xca/0x100 kasan_check_range+0x39/0x1c0 page_counter_uncharge+0x65/0x150x65/0x150xgroup_cgroup_charge +0x1f/0x260 由任务 527 分配 由任务 0 释放
    有缺陷的地址属于 ffff888106715400 的对象该对象属于大小 512 的缓存 kmalloc-512 有缺陷的地址位于已释放的 512 字节区域内部 64 字节 [ffff888106715400、ffff888106715600) 有缺陷的地址属于物理页内存状态围绕缺陷地址
    ffff888106715300fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888106715400fa fb fb fb fb fb fb fb fb fb fb fb ^ ffff888106715480fb fb fb fb fb fb fb fb fb fb fb ffff888106715500fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 发生此问题的原因是在其关联的内存区域取消注册后可由调用程序保留。当前的实现会释放池即使用户仍然保留对它的引用例如在取消充值操作完成之前。此修补程序向每个池添加一个引用计数器以确保池仅在其引用计数降至零时才得到释放。 (CVE-2026-23195)

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

ID	名称	严重性
299219	Linux Distros 未修补的漏洞：CVE-2026-23129	medium
299218	Linux Distros 未修补的漏洞：CVE-2026-23117	medium
299217	Linux Distros 未修补的漏洞：CVE-2026-23155	medium
299216	Linux Distros 未修补的漏洞：CVE-2026-23142	medium
299215	Linux Distros 未修补的漏洞：CVE-2026-23166	medium
299183	Linux Distros 未修补的漏洞：CVE-2026-23116	medium
299182	Linux Distros 未修补的漏洞：CVE-2026-23133	medium
299181	Linux Distros 未修补的漏洞：CVE-2026-23127	high
299180	Linux Distros 未修补的漏洞：CVE-2026-23123	medium
299179	Linux Distros 未修补的漏洞：CVE-2026-23135	high
299178	Linux Distros 未修补的漏洞：CVE-2026-23125	medium
299177	Linux Distros 未修补的漏洞：CVE-2026-23173	high
299176	Linux Distros 未修补的漏洞：CVE-2026-23114	high
299175	Linux Distros 未修补的漏洞：CVE-2026-23136	high
299174	Linux Distros 未修补的漏洞：CVE-2026-23120	medium
299173	Linux Distros 未修补的漏洞：CVE-2026-23151	medium
299172	Linux Distros 未修补的漏洞：CVE-2026-23149	medium
299171	Linux Distros 未修补的漏洞：CVE-2026-23122	medium
299170	Linux Distros 未修补的漏洞：CVE-2026-23140	medium
299169	Linux Distros 未修补的漏洞：CVE-2026-23121	medium
299168	Linux Distros 未修补的漏洞：CVE-2026-23124	medium
299167	Linux Distros 未修补的漏洞：CVE-2026-23168	high
299152	Linux Distros 未修补的漏洞：CVE-2026-23162	medium
299151	Linux Distros 未修补的漏洞：CVE-2026-23159	medium
299150	Linux Distros 未修补的漏洞：CVE-2026-23156	medium
299123	Linux Distros 未修补的漏洞：CVE-2026-23199	high
299122	Linux Distros 未修补的漏洞：CVE-2026-23208	medium
299121	Linux Distros 未修补的漏洞：CVE-2026-23209	medium
299120	Linux Distros 未修补的漏洞：CVE-2026-23187	high
299119	Linux Distros 未修补的漏洞：CVE-2026-23188	medium
299118	Linux Distros 未修补的漏洞：CVE-2025-71204	high
299117	Linux Distros 未修补的漏洞：CVE-2026-23175	high
299116	Linux Distros 未修补的漏洞：CVE-2026-23204	high
299115	Linux Distros 未修补的漏洞：CVE-2026-23203	high
299114	Linux Distros 未修补的漏洞：CVE-2026-23185	high
299113	Linux Distros 未修补的漏洞：CVE-2026-23183	medium
299112	Linux Distros 未修补的漏洞：CVE-2026-23179	medium
299111	Linux Distros 未修补的漏洞：CVE-2026-23189	medium
299110	Linux Distros 未修补的漏洞：CVE-2025-71224	high
299109	Linux Distros 未修补的漏洞：CVE-2026-23205	medium
299108	Linux Distros 未修补的漏洞：CVE-2026-23192	high
299107	Linux Distros 未修补的漏洞：CVE-2026-23210	medium
299106	Linux Distros 未修补的漏洞：CVE-2026-23186	medium
299105	Linux Distros 未修补的漏洞：CVE-2026-23196	high
299104	Linux Distros 未修补的漏洞：CVE-2025-71222	medium
299103	Linux Distros 未修补的漏洞：CVE-2026-23201	medium
299102	Linux Distros 未修补的漏洞：CVE-2025-71220	medium
299101	Linux Distros 未修补的漏洞：CVE-2026-23180	high
299100	Linux Distros 未修补的漏洞：CVE-2026-23194	medium
299099	Linux Distros 未修补的漏洞：CVE-2026-23195	high

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

medium

high

high

high

high

high

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

high

medium

high