如 TuxCare CENTOS-STREAM8：CLSA-2026：1789141176公告所述，CentOS Linux 8 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns
    -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
    (CVE-2022-50490)

  - 已修复 Linux 内核中的下列漏洞：scsi: hpsa: Fix possible memory leak in hpsa_init_one() The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to clean1 directly, which frees h and leaks the h->reply_map. Fix by calling hpda_free_ctlr_info() to release h->replay_map and h instead free h directly. (CVE-2022-50646)

  - prctl syscall 的当前实现不会在 syscall 期间立即发出 IBPB。ib_prctl_set 函数会更新任务的线程信息标记 (TIF)，并更新 __speculation_ctrl_update 函数的 SPEC_CTRL MSR，但仅在检查 TIF 位时，才会根据下一个计划发布 IBPB。这使受害者容易受到 prctl syscall 之前已在 BTB 中注入的值影响。通过 prctl (ib_prctl_set) 添加有条件缓解支持的修补程序可追溯至内核 4.9.176。我们建议升级过去的提交 a664ec9158eeddd75121d39c9a0758016097fa96 (CVE-2023-0045)

  - 在 Linux 内核的用于转换数据包的 IP 框架（XFRM 子系统）中发现一个缺陷。此问题可能允许具有 CAP_NET_ADMIN 权限的恶意用户在解析 netlink 属性时造成 XFRMA_MTIMER_THRESH 的 4 字节越界读取，从而导致敏感堆数据可能泄漏到用户空间。(CVE-2023-3773)

  - 已修复 Linux 内核中的下列漏洞：fbdev: Fix invalid page access after closing deferred I/O devices When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work.
    This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release(). (CVE-2023-52731)

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

CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：1792247642公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：ethtool: do not perform operations on net devices being unregistered There is a short period between a net device starts to be unregistered and when it is actually gone. In that time frame ethtool operations could still be performed, which might end up in unwanted or undefined behaviours[1]. Do not allow ethtool operations after a net device starts its unregistration. This patch targets the netlink part as the ioctl one isn't affected: the reference to the net device is taken and the operation is executed within an rtnl lock section and the net device won't be found after unregister. [1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace:
    dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610 (CVE-2021-47517)

  - 已修复 Linux 内核中的下列漏洞：nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.
    (CVE-2022-48686)

  - 已修复 Linux 内核中的下列漏洞：net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator.
    NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection) ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148]
    __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 (CVE-2022-49667)

  - 已修复 Linux 内核中的下列漏洞：bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32
    *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18:
    w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. (CVE-2022-49961)

  - 在 Linux 内核的 SCSI 子组件中，发现 drivers/scsi/iscsi_tcp.c 的 iscsi_sw_tcp_session_create 存在释放后使用漏洞。攻击者可利用此缺陷泄露内核内部信息。
    (CVE-2023-2162)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32
    *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18:
    w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. (CVE-2022-49961)

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

远程 Ubuntu 20.04 LTS 主机上安装的一个程序包受到 USN-8668-1 公告中提及的多个漏洞影响。

    Maxim Suhanov 发现在某些情况下，Linux 内核中的 NTFS 文件系统实现未正确验证文件名长度，从而导致越界读取。攻击者可利用此问题构建恶意 NTFS 图像，挂载并操作该图像可暴露敏感信息（内核内存）。（CVE-2023-45896）

    发现某些 AMD 处理器在推测执行期间，未能正确清除浮点拆分器单元中的数据。本地攻击者可利用此问题泄露敏感信息。
    (CVE-2025-54505)

    某些 AMD Zen 2 处理器未能正确隔离操作缓存中的共享资源。本地攻击者可能会利用此问题损坏以较高权限级别执行的指令，从而导致权限升级。（CVE-2025-54518）

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - ARM32 架构；

    - ARM64 架构；

    - MIPS 架构；

    - PowerPC 架构；

    - S390 架构；

    - x86 架构；

    - 区块层子系统；

    - 加密 API；

    - ACPI 驱动程序；

    - ATM 驱动程序；

    - 驱动程序核心；

    - 电源管理核心；

    - DRBD 分布式复制块设备驱动程序；

    - RNBD 块设备驱动程序；

    - 蓝牙驱动程序；

    - 总线设备；

    - 字符设备驱动程序；

    - TPM 设备驱动程序；

    - 时钟源驱动程序；

    - 数据采集框架和驱动程序；

    - CPU 频率缩放框架；

    - CPU 空闲管理框架；

    - 硬件加密设备驱动程序；

    - DMA 引擎子系统；

    - Arm Firmware Framework for ARMv8-A(FFA)；

    - EFI 核心；

    - GPIO 子系统；

    - GPU 驱动程序；

    - HID 子系统；

    - 硬件监控驱动程序；

    - I2C 子系统；

    - IIO 子系统；

    - IIO ADC 驱动程序；

    - InfiniBand 驱动程序；

    - 输入设备（多种）驱动程序；

    - IOMMU 子系统；

    - Mailbox 框架；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - 联发科 SMI 驱动程序;

    - NVIDIA Tegra 内存控制器驱动程序；

    - 多功能设备驱动程序；

    - IBM Advanced System Management 驱动程序;

    - MMC 子系统；

    - MTD 块设备驱动程序；

    - 网络驱动程序；

    - 以太网绑定驱动程序；

    - Mellanox 网络驱动程序；

    - Microsoft Azure Network Adapter (MANA) 驱动程序；

    - STMicroelectronics 网络驱动程序；

    - MediaTek 网络驱动程序；

    - 近场通信 (NFC) 驱动程序；

    - NTB 驱动程序；

    - NVDIMM (Non-Volatile Memory Device) 驱动程序；

    - NVME 驱动程序；

    - PCI 子系统；

    - Pin 控制器子系统；

    - x86 平台驱动程序；

    - Broadcom BCM2835 power 域驱动程序;

    - 电源驱动程序；

    - RapidIO 驱动程序；

    - 远程处理器子系统；

    - RPMSG 子系统；

    - SCSI 子系统；

    - Freescale SoC 驱动程序；

    - Texas Instruments SoC 驱动程序；

    - SPI 子系统；

    - Greybus lights 分段驱动程序；

    - 媒体分段驱动程序；

    - Realtek RTL8723BS SDIO 驱动程序；

    - SM750 帧缓冲暂存驱动程序;

    - TCM 子系统；

    - TTY 驱动程序；

    - UFS 子系统；

    - Cadence USB3 驱动程序；

    - USB 设备类驱动程序；

    - ULPI总线;

    - USB 核心驱动程序；

    - DesignWare USB2 驱动程序;

    - USB Gadget 驱动程序；

    - USB 主机控制器驱动程序；

    - Mustek MDC800 USB 数码相机驱动程序;

    - USB YUREX 驱动程序;

    - Renesas USBHS 控制器驱动程序；

    - Framebuffer 层；

    - Xen 管理程序驱动程序；

    - 文件系统基础设施；

    - BTRFS 文件系统；

    - Ceph 分布式文件系统；

    - EROFS 文件系统；

    - Ext4 文件系统；

    - F2FS 文件系统；

    - FAT 文件系统；

    - FUSE（Userspace 中的文件系统）；

    - GFS2 文件系统；

    - HFS+ 文件系统；

    - JFS 文件系统；

    - 网络文件系统 (NFS) 服务器后台程序；

    - NILFS2 文件系统；

    - 文件系统通知基础设施；

    - NTFS3 文件系统；

    - OCFS2 文件系统；

    - Proc 文件系统；

    - Pstore 文件系统；

    - Diskquota 系统；

    - SMB 网络文件系统；

    - SquashFS 文件系统；

    - UDF 文件系统；

    - XFS 文件系统；

    - 审计子系统；

    - RAS（可靠性、可用性、可服务性）子系统；

    - 软件节点和设备属性;

    - 内存管理；

    - KVM 子系统；

    - 内存管理；

    - PPP 协议驱动程序和压缩器;

    - Linux 安全模块 (LSM) 框架；

    - 网络流量控制；

    - 蓝牙子系统；

    - MAC80211 子系统；

    - Netfilter；

    - IP 隧道定义；

    - 跟踪基础设施；

    - 用户空间 API (UAPI)；

    - io_uring 子系统；

    - BPF 子系统；

    - 控制群组 (cgroup)；

    - Kernel fork() syscall；

    - Kernel futex 原语；

    - Kernel kexec() syscall；

    - 内核模块支持;

    - 计划程序基础设施；

    - 密码库;

    - KASAN 内存调试框架；

    - 异步传输模式 (ATM) 子系统；

    - B.A.T.M.A.N. 网格协议；

    - 以太网桥接；

    - CAIF 协议；

    - CAN 网络层；

    - Ceph Core 库；

    - Networking 核心；

    - Distributed Switch 架构；

    - IPv4 联网；

    - IPv6 联网；

    - XFRM 子系统；

    - L2TP 协议；

    - 管理组件传输协议 (MCTP)；

    - 多路径 TCP；

    - NCSI（网络控制器边带接口）驱动程序；

    - NFC 子系统；

    - Open vSwitch；

    - Phonet 协议；

    - 高通IPC路由器（QRTR）;

    - RDS 协议；

    - RF 交换子系统；

    - Rose 网络层；

    - RxRPC 会话套接字；

    - SCTP 协议；

    - SMC 套接字；

    - 流解析器;

    - Sun RPC 协议；

    - TIPC 协议；

    - TLS 协议；

    - Unix 域套接字；

    - VMware vSockets 驱动程序；

    - 无线网络；

    - X.25 network layer;

    - eXpress 数据路径；

    - AppArmor 安全模块；

    - 简化了强制访问控制内核框架；

    - ALSA 框架；

    - FireWire 声音驱动程序；

    - HD-audio 驱动程序；

    - AudioScience HPI 驱动程序；

    - Creative Sound Blaster X-Fi 驱动程序；

    - AMD SoC Alsa 驱动程序；

    - SoC 音频核心驱动程序；

    - STI ASoC 驱动程序;

    - USB音响设备;（CVE-2022-49803 ， ， ， CVE-2022-50073， CVE-2022-50116CVE-2025-38659CVE-2024-56719CVE-2024-56727CVE-2024-41079CVE-2024-46715CVE-2024-36922CVE-2024-47809CVE-2024-46770CVE-2024-50012CVE-2024-53221CVE-2024-56557CVE-2024-56584CVE-2024-56657CVE-2024-36898CVE-2025-21739CVE-2025-21712CVE-2025-21863CVE-2025-22107CVE-2025-23141CVE-2025-37786CVE-2025-38006CVE-2024-35865CVE-2025-38192CVE-2025-38105CVE-2025-38250CVE-2025-38562CVE-2025-38626CVE-2025-38710CVE-2025-39748CVE-2024-27389CVE-2025-40005CVE-2025-39764CVE-2025-71150CVE-2025-68358CVE-2025-71161CVE-2025-68307CVE-2025-68256CVE-2025-68239CVE-2025-71221CVE-2025-68206CVE-2025-40323CVE-2025-40103CVE-2025-71232CVE-2025-40016CVE-2023-53629CVE-2025-71233CVE-2025-71238CVE-2025-71237CVE-2025-71239CVE-2025-71236CVE-2025-71265CVE-2025-71266CVE-2022-50552CVE-2023-52737CVE-2025-71267CVE-2023-52682CVE-2023-53545CVE-2023-53596CVE-2025-71235CVE-2022-49961、 、 、 CVE-2026-23289CVE-2026-23204CVE-2026-23169CVE-2026-23220CVE-2026-23221CVE-2026-23222CVE-2026-23227CVE-2026-23228CVE-2026-23157CVE-2026-23234CVE-2026-23229CVE-2026-23235CVE-2026-23236CVE-2026-23237CVE-2026-23238CVE-2026-23241CVE-2026-23141CVE-2026-23243CVE-2026-23242CVE-2026-23253CVE-2026-23266CVE-2026-23270CVE-2026-23277CVE-2026-23279CVE-2026-23113CVE-2026-23286CVE-2026-23281CVE-2026-23290CVE-2026-23291CVE-2026-23293CVE-2026-23324CVE-2026-23318CVE-2026-23312CVE-2026-23335CVE-2026-23307CVE-2026-23304CVE-2026-23303CVE-2026-23336CVE-2026-23300CVE-2026-23298CVE-2026-23296CVE-2026-23339CVE-2026-23100CVE-2026-23031CVE-2026-23368CVE-2026-23359CVE-2026-23367CVE-2026-23352CVE-2026-23356CVE-2026-23357CVE-2026-23365CVE-2026-23370CVE-2026-23066CVE-2026-23362CVE-2025-71304CVE-2026-23340CVE-2025-71292CVE-2025-71287CVE-2025-71274、 、 、 CVE-2026-31399CVE-2026-23398CVE-2026-23399CVE-2026-23401CVE-2026-23397CVE-2026-23434CVE-2026-23420CVE-2026-23438CVE-2026-23439CVE-2026-23442CVE-2026-23444CVE-2026-23446CVE-2026-23396CVE-2026-23454CVE-2026-23452CVE-2026-23456CVE-2026-23457CVE-2026-23458CVE-2026-23460CVE-2026-23462CVE-2026-23395CVE-2026-23474CVE-2026-23463CVE-2026-31393CVE-2026-31396CVE-2026-31400CVE-2026-31421CVE-2026-31417CVE-2026-31416CVE-2026-31422CVE-2026-31415CVE-2026-31411CVE-2026-31409CVE-2026-31423CVE-2026-31408CVE-2026-31407CVE-2026-31405CVE-2026-31424CVE-2026-23392CVE-2026-23388CVE-2026-31454CVE-2026-31446CVE-2026-31452CVE-2026-31427CVE-2026-31428CVE-2026-31433CVE-2026-31450CVE-2026-31455CVE-2026-23391CVE-2026-31447CVE-2026-23382CVE-2026-31425CVE-2026-23381CVE-2026-23379CVE-2026-23372、 、 、 CVE-2026-31551CVE-2026-31494CVE-2026-31495CVE-2026-31497CVE-2026-31489CVE-2026-31507CVE-2026-31498CVE-2026-31508CVE-2026-31509CVE-2026-31510CVE-2026-31512CVE-2026-31515CVE-2026-31485CVE-2026-31521CVE-2026-31518CVE-2026-31522CVE-2026-31523CVE-2026-31524CVE-2026-31532CVE-2026-31540CVE-2026-31483CVE-2026-31546CVE-2026-31545CVE-2026-31549CVE-2026-31550CVE-2026-31552CVE-2026-31583CVE-2026-31581CVE-2026-31580CVE-2026-31585CVE-2026-31578CVE-2026-31577CVE-2026-31576CVE-2026-31586CVE-2026-31570CVE-2026-31565CVE-2026-31555CVE-2026-31588CVE-2026-31480CVE-2026-31473CVE-2026-31605CVE-2026-31598CVE-2026-31603CVE-2026-31594CVE-2026-31596CVE-2026-31597CVE-2026-31602CVE-2026-31615CVE-2026-31476CVE-2026-31599CVE-2026-31469CVE-2026-31590CVE-2026-31467CVE-2026-31466CVE-2026-31464、 、 、 CVE-2026-31680CVE-2026-31628CVE-2026-31629CVE-2026-31630CVE-2026-31627CVE-2026-31642CVE-2026-31634CVE-2026-31651CVE-2026-31656CVE-2026-31658CVE-2026-31660CVE-2026-31661CVE-2026-31626CVE-2026-31664CVE-2026-31662CVE-2026-31665CVE-2026-31667CVE-2026-31670CVE-2026-31671CVE-2026-31672CVE-2026-31625CVE-2026-31674CVE-2026-31673CVE-2026-31676CVE-2026-31679CVE-2026-31681CVE-2026-31698CVE-2026-31697CVE-2026-31696CVE-2026-31699CVE-2026-31695CVE-2026-31694CVE-2026-31687CVE-2026-31701CVE-2026-31686CVE-2026-31684CVE-2026-31683CVE-2026-31716CVE-2026-31624CVE-2026-31622CVE-2026-31749CVE-2026-31737CVE-2026-31748CVE-2026-31721CVE-2026-31726CVE-2026-31728CVE-2026-31747CVE-2026-31751CVE-2026-31623CVE-2026-31738CVE-2026-31619CVE-2026-31720CVE-2026-31618CVE-2026-31617CVE-2026-31616、 、 、 CVE-2026-43051CVE-2026-31773CVE-2026-31778CVE-2026-31780CVE-2026-31770CVE-2026-31788CVE-2026-31781CVE-2026-43014CVE-2026-43015CVE-2026-43020CVE-2026-43024CVE-2026-43026CVE-2026-31763CVE-2026-43028CVE-2026-43027CVE-2026-43030CVE-2026-43032CVE-2026-43035CVE-2026-43040CVE-2026-43041CVE-2026-31762CVE-2026-43046CVE-2026-43043CVE-2026-43047CVE-2026-43050CVE-2026-43052CVE-2026-43069CVE-2026-43068CVE-2026-43066CVE-2026-43074CVE-2026-43065CVE-2026-43062CVE-2026-43061CVE-2026-43075CVE-2026-43060CVE-2026-43058CVE-2026-43054CVE-2026-43076CVE-2026-31761CVE-2026-31758CVE-2026-43104CVE-2026-43093CVE-2026-43103CVE-2026-43080CVE-2026-43085CVE-2026-43089CVE-2026-43099CVE-2026-43105CVE-2026-31759CVE-2026-43098CVE-2026-31756CVE-2026-43079CVE-2026-31755CVE-2026-31754CVE-2026-31752、 、 、 CVE-2026-43190CVE-2026-43135CVE-2026-43136CVE-2026-43139CVE-2026-43134CVE-2026-43141CVE-2026-43140CVE-2026-43145CVE-2026-43147CVE-2026-43148CVE-2026-43149CVE-2026-43152CVE-2026-43133CVE-2026-43158CVE-2026-43156CVE-2026-43159CVE-2026-43163CVE-2026-43168CVE-2026-43171CVE-2026-43180CVE-2026-43132CVE-2026-43183CVE-2026-43182CVE-2026-43184CVE-2026-43187CVE-2026-43194CVE-2026-43211CVE-2026-43209CVE-2026-43207CVE-2026-43218CVE-2026-43206CVE-2026-43205CVE-2026-43203CVE-2026-43223CVE-2026-43202CVE-2026-43200CVE-2026-43196CVE-2026-43225CVE-2026-43130CVE-2026-43123CVE-2026-43242CVE-2026-43232CVE-2026-43241CVE-2026-43227CVE-2026-43230CVE-2026-43231CVE-2026-43236CVE-2026-43246CVE-2026-43124CVE-2026-43233CVE-2026-43113CVE-2026-43226CVE-2026-43112CVE-2026-43111CVE-2026-43110、 、 、 CVE-2026-43333CVE-2026-43273CVE-2026-43275CVE-2026-43277CVE-2026-43270CVE-2026-43281CVE-2026-43279CVE-2026-43283CVE-2026-43287CVE-2026-43289CVE-2026-43291CVE-2026-43295CVE-2026-43269CVE-2026-43302CVE-2026-43296CVE-2026-43312CVE-2026-43313CVE-2026-43314CVE-2026-43315CVE-2026-43316CVE-2026-43268CVE-2026-43327CVE-2026-43324CVE-2026-43328CVE-2026-43329CVE-2026-43334CVE-2026-43370CVE-2026-43365CVE-2026-43363CVE-2026-43373CVE-2026-43357CVE-2026-43343CVE-2026-43342CVE-2026-43380CVE-2026-43340CVE-2026-43339CVE-2026-43336CVE-2026-43381CVE-2026-43266CVE-2026-43262CVE-2026-43427CVE-2026-43411CVE-2026-43426CVE-2026-43386CVE-2026-43387CVE-2026-43405CVE-2026-43425CVE-2026-43428CVE-2026-43264CVE-2026-43420CVE-2026-43261CVE-2026-43382CVE-2026-43257CVE-2026-43255CVE-2026-43251、 、 、 CVE-2026-45843CVE-2026-43458CVE-2026-43459CVE-2026-43466CVE-2026-43453CVE-2026-43472CVE-2026-43469CVE-2026-43473CVE-2026-43475CVE-2026-43476CVE-2026-43480CVE-2026-43484CVE-2026-43452CVE-2026-43497CVE-2026-43496CVE-2026-43502CVE-2026-45834CVE-2026-45835CVE-2026-45836CVE-2026-45838CVE-2026-43451CVE-2026-45840CVE-2026-45839CVE-2026-45841CVE-2026-45842CVE-2026-45844CVE-2026-45864CVE-2026-45862CVE-2026-45860CVE-2026-45866CVE-2026-45857CVE-2026-45856CVE-2026-45852CVE-2026-45867CVE-2026-45848CVE-2026-45847CVE-2026-45846CVE-2026-45868CVE-2026-43450CVE-2026-43445CVE-2026-45890CVE-2026-45875CVE-2026-45885CVE-2026-45870CVE-2026-45871CVE-2026-45873CVE-2026-45883CVE-2026-45891CVE-2026-43449CVE-2026-45879CVE-2026-43439CVE-2026-45869CVE-2026-43432CVE-2026-43430CVE-2026-43429、 、 、 CVE-2026-45994CVE-2026-45935CVE-2026-45936CVE-2026-45941CVE-2026-45924CVE-2026-45948CVE-2026-45946CVE-2026-45954CVE-2026-45956CVE-2026-45958CVE-2026-45960CVE-2026-45964CVE-2026-45920CVE-2026-45968CVE-2026-45965CVE-2026-45969CVE-2026-45970CVE-2026-45974CVE-2026-45978CVE-2026-45983CVE-2026-45919CVE-2026-45985CVE-2026-45984CVE-2026-45986CVE-2026-45987CVE-2026-46002CVE-2026-46024CVE-2026-46023CVE-2026-46022CVE-2026-46027CVE-2026-46019CVE-2026-46018CVE-2026-46015CVE-2026-46033CVE-2026-46009CVE-2026-46006CVE-2026-46004CVE-2026-46037CVE-2026-45916CVE-2026-45912CVE-2026-46062CVE-2026-46049CVE-2026-46053CVE-2026-46044CVE-2026-46046CVE-2026-46047CVE-2026-46051CVE-2026-46064CVE-2026-45915CVE-2026-46050CVE-2026-45911CVE-2026-46040CVE-2026-45904CVE-2026-45902CVE-2026-45899、 、 、 CVE-2026-46174CVE-2026-46107CVE-2026-46108CVE-2026-46112CVE-2026-46102CVE-2026-46122CVE-2026-46120CVE-2026-46123CVE-2026-46124CVE-2026-46127CVE-2026-46128CVE-2026-46132CVE-2026-46101CVE-2026-46137CVE-2026-46133CVE-2026-46146CVE-2026-46149CVE-2026-46150CVE-2026-46151CVE-2026-46161CVE-2026-46099CVE-2026-46167CVE-2026-46163CVE-2026-46168CVE-2026-46172CVE-2026-46177CVE-2026-46206CVE-2026-46205CVE-2026-46198CVE-2026-46209CVE-2026-46197CVE-2026-46189CVE-2026-46187CVE-2026-46212CVE-2026-46186CVE-2026-46184CVE-2026-46178CVE-2026-46214CVE-2026-46098CVE-2026-46082CVE-2026-46238CVE-2026-46231CVE-2026-46236CVE-2026-46220CVE-2026-46227CVE-2026-46230CVE-2026-46234CVE-2026-46249CVE-2026-46088CVE-2026-46233CVE-2026-46080CVE-2026-46219CVE-2026-46077CVE-2026-46072CVE-2026-46070、 、 、 CVE-2026-52958CVE-2026-46301CVE-2026-46303CVE-2026-46304CVE-2026-46294CVE-2026-46319CVE-2026-46307CVE-2026-46328CVE-2026-52911CVE-2026-52912CVE-2026-52914CVE-2026-52915CVE-2026-46285CVE-2026-52919CVE-2026-52916CVE-2026-52920CVE-2026-52921CVE-2026-52922CVE-2026-52925CVE-2026-52926CVE-2026-46275CVE-2026-52954CVE-2026-52931CVE-2026-52955CVE-2026-52957CVE-2026-52962CVE-2026-52993CVE-2026-52992CVE-2026-52986CVE-2026-52995CVE-2026-52985CVE-2026-52984CVE-2026-52982CVE-2026-52998CVE-2026-52970CVE-2026-52969CVE-2026-52963CVE-2026-52999CVE-2026-46274CVE-2026-46270CVE-2026-53021CVE-2026-53006CVE-2026-53016CVE-2026-53002CVE-2026-53003CVE-2026-53004CVE-2026-53012CVE-2026-53022CVE-2026-46273CVE-2026-53011CVE-2026-46267CVE-2026-53001CVE-2026-46259CVE-2026-46253CVE-2026-46250、 、 、 CVE-2026-53128CVE-2026-53049CVE-2026-53050CVE-2026-53059CVE-2026-53048CVE-2026-53061CVE-2026-53060CVE-2026-53062CVE-2026-53064CVE-2026-53065CVE-2026-53068CVE-2026-53069CVE-2026-53047CVE-2026-53072CVE-2026-53071CVE-2026-53073CVE-2026-53074CVE-2026-53075CVE-2026-53077CVE-2026-53082CVE-2026-53046CVE-2026-53093CVE-2026-53088CVE-2026-53096CVE-2026-53112CVE-2026-53130CVE-2026-53320CVE-2026-53309CVE-2026-53306CVE-2026-53369CVE-2026-53304CVE-2026-53296CVE-2026-53295CVE-2026-53379CVE-2026-53294CVE-2026-53291CVE-2026-53287CVE-2026-63860CVE-2026-53045CVE-2026-53041CVE-2026-64055CVE-2026-64034CVE-2026-64047CVE-2026-64018CVE-2026-64032CVE-2026-64033CVE-2026-64046CVE-2026-64056CVE-2026-53043CVE-2026-64039CVE-2026-53040CVE-2026-63865CVE-2026-53039CVE-2026-53037CVE-2026-53023、 、 、 CVE-2026-64185CVE-2026-64096CVE-2026-64102CVE-2026-64103CVE-2026-64164CVE-2026-64155CVE-2026-64153CVE-2026-64165CVE-2026-64135CVE-2026-64133CVE-2026-64125CVE-2026-64166CVE-2026-64115CVE-2026-64114CVE-2026-64113CVE-2026-64168CVE-2026-64089CVE-2026-64087CVE-2026-64221CVE-2026-64179CVE-2026-64220CVE-2026-64174CVE-2026-64177CVE-2026-64178CVE-2026-64219CVE-2026-64587CVE-2026-64088CVE-2026-64218CVE-2026-64086CVE-2026-64173CVE-2026-64085CVE-2026-64084CVE-2026-64083

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

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

远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2023:2458 公告中提及的多个漏洞影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * net/bluetooth/l2cap_core.c 内 l2cap_connect 和 l2cap_le_connect_req 中存在释放后使用CVE-2022-42896

    * net/ulp监听 ULP 套接字中的释放后使用 (CVE-2023-0461)

    * cpuAMD CPU 可能会在无条件直接分支之外暂时执行 (CVE-2021-26341)

    * FBIOPUT_VSCREENINFO ioctl 的恶意数据可能导致 OOB 写入内存 (CVE-2021-33655)

    * drivers/tty/tty_buffers.c 中可能的争用条件 (CVE-2022-1462)

    * KVMkvm_mmu_invpcid_gva 中的空指针取消引用 (CVE-2022-1789)

    * free_pipe_info() 中的释放后使用可导致权限升级 (CVE-2022-1882)

    * KVMnVMX从嵌套客户机退出时缺少 IBPB 可导致 Spectre v2 攻击CVE-2022-2196

    * netfilternf_conntrack_irc 消息处理问题 (CVE-2022-2663)

    * xfrm_probe_algs 中的争用条件可导致 OOB 读取/写入 (CVE-2022-3028)

    * net/ipv4/fib_semantics.c 文件的 fib_nh_match 中存在越界读取 (CVE-2022-3435)

    * mm/hugetlb.c 中 hugetlb_no_page() 中的争用条件 (CVE-2022-3522)

    * ipv6_renew_options() 中的内存泄漏 (CVE-2022-3524)

    * do_ipv6_setsockopt 中围绕 icsk->icsk_af_ops 的数据争用 (CVE-2022-3566)

    * 围绕 sk->sk_prot 的数据争用 (CVE-2022-3567)

    * 文件 net/bluetooth/l2cap_core.c 的 l2cap_recv_acldata 中存在内存泄漏 (CVE-2022-3619)

    * 由于 pte 条目中毒mm/gup.c 中的 follow_page_pte 中存在拒绝服务CVE-2022-3623

    * devlink_param_get 中 devlink 重新加载失败后的释放后使用 (CVE-2022-3625)

    * brcmfmac 中存在可通过 USB 访问的缓冲区溢出CVE-2022-3628

    * net/bluetooth/l2cap_core.c 中 l2cap_conn_del 中的释放后使用缺陷 (CVE-2022-3640)

    * 当函数 intel_gvt_dma_map_guest_page 失败时split_2MB_gtt_entry 中发生双重释放 (CVE-2022-3707)

    * mptcp断开连接时子流遍历中的空指针取消引用 (CVE-2022-4128)

    * l2tp清除 sk_user_data 时缺少锁定可导致空指针取消引用CVE-2022-4129

    * igmp打开和关闭 inet 套接字时 ip_check_mc_rcu 中的释放后使用 (CVE-2022-20141)

    * 使用 IMA 的锁定绕过 (CVE-2022-21505)

    * drivers/net/can/usb/usb_8dev.c 中 usb_8dev_start_xmit 中存在的双重释放 (CVE-2022-28388)

    * 网络后端可能导致 Linux netfront 使用释放的 SKB (XSA-405) (CVE-2022-33743)

    * VM_PFNMAP 映射中的 unmap_mapping_range() 与 munmap() 争用导致过时 TLB 条目 (CVE-2022-39188)

    * 某些 KVM_VCPU_PREEMPTED 中未正确处理 TLB 刷新操作导致客户机故障 (CVE-2022-39189)

    * cfg80211_update_notlisted_nontrans() 中的 u8 溢出问题 (CVE-2022-41674)

    * 与叶 anon_vma 双重重用有关的释放后使用 (CVE-2022-42703)

    * net/wireless/scan.c 中 bss_ref_get 中的释放后使用 (CVE-2022-42720)

    * net/wireless/scan.c 内 cfg80211_add_nontrans_list 中的 BSS 列表损坏 (CVE-2022-42721)

    * P2P 设备的信标保护中的拒绝服务 (CVE-2022-42722)

    * usbmon 驱动程序中的内存损坏 (CVE-2022-43750)

    * 流量控制子系统中的空指针取消引用 (CVE-2022-47929)

    * rawv6_push_pending_frames 中的空指针取消引用 (CVE-2023-0394)

    * 由于 qdisc_graft() 中的争用条件导致的释放后使用 (CVE-2023-0590)

    * fs/cifs/connect.c 中无效的指针主机名导致释放后使用 (CVE-2023-1195)

    * tipc_conn_close 中的拒绝服务 (CVE-2023-1382)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

    其他变更：

    如需有关此发行版本的详细变更信息，请参阅可从“参考”部分链接的 Red Hat Enterprise Linux 9.2 版本说明。

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

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

CentOS Linux 8.4 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.4：CLSA-2026：1791858083 12 公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: Fix use-after-free of encap entry in neigh update handler Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock removal from TC filter update path and properly handle concurrent encap entry insertion/deletion which can lead to following use-after-free: [23827.464923] ================================================================== [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core] [23827.476731] Call Trace: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831] ? process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ?
    __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Allocated by task 28248: [23827.507694] kasan_save_stack+0x1b/0x40 [23827.508476]
    __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.517300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg+0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131]
    ____sys_sendmsg+0x590/0x770 [23827.520851] ___sys_sendmsg+0xd8/0x160 [23827.521552]
    __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae [23827.523797] [23827.524163] Freed by task 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] kasan_set_free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] process_one_work+0x8ac/0x14e0 [23827.530770] worker_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/0x30 [23827.532785] [23827.533147] Last potentially related work creation: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] kvfree_call_rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncated--- (CVE-2021-47247)

  - 已修复 Linux 内核中的下列漏洞：bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32
    *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18:
    w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. (CVE-2022-49961)

  - 已修复 Linux 内核中的下列漏洞：nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure On error situation `clp->cl_cb_conn.cb_xprt` should not be given a reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP:
    0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX:
    0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10:
    0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14:
    ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2:
    0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] <TASK> [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ? dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] </TASK> [72.564189] ---[ end trace 031117b1c72ec616 ]--- [ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ------------[ cut here ]------------ (CVE-2022-50401)

  - 已修复 Linux 内核中的下列漏洞：blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0:
    resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue:
    kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace:
    __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0 (CVE-2022-50552)

  - prctl syscall 的当前实现不会在 syscall 期间立即发出 IBPB。ib_prctl_set 函数会更新任务的线程信息标记 (TIF)，并更新 __speculation_ctrl_update 函数的 SPEC_CTRL MSR，但仅在检查 TIF 位时，才会根据下一个计划发布 IBPB。这使受害者容易受到 prctl syscall 之前已在 BTB 中注入的值影响。通过 prctl (ib_prctl_set) 添加有条件缓解支持的修补程序可追溯至内核 4.9.176。我们建议升级过去的提交 a664ec9158eeddd75121d39c9a0758016097fa96 (CVE-2023-0045)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
361969	CentOS Linux 8 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS-STREAM8：CLSA-2026：1789141176）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
366854	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2026：1792247642）	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/17	high
245820	Linux Distros 未修补的漏洞：CVE-2022-49961	Nessus	Misc.	2025/8/8	2026/11/5	high
340682	Ubuntu 20.04 LTS：Linux 内核 (GCP) 漏洞 (USN-8668-1)	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/9/24	high
175477	RHEL 9：内核 (RHSA-2023:2458)	Nessus	Red Hat Local Security Checks	2023/5/13	2025/9/10	high
368032	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2026：1791858083）	Nessus	CentOS Local Security Checks	2026/10/20	2026/10/20	high

检测

插件搜索

high

high

high

high

high

high