AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2025：2025：1751916475 公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b (khugepaged: add support of collapse for tmpfs/shmem pages), but most of the security impact of this only came in commit 27e1f8273113 (khugepaged: enable collapse pmd for pte-mapped THP), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
    (CVE-2022-48991)

  - 已修复 Linux 内核中的下列漏洞：nfsd: prevent panic for nfsv4.0 closed files in nfs4_show_open Prior to commit 3f29cc82a84c (nfsd: split sc_status out of sc_type) states_show() relied on sc_type field to be of valid type before calling into a subfunction to show content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0 opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178 (CVE-2024-46682)

  - 已修复 Linux 内核中的下列漏洞：nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter. (CVE-2024-50043)

  - 已修复 Linux 内核中的下列漏洞：bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it.
    The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses. (CVE-2024-50063)

  - 已修复 Linux 内核中的下列漏洞：nfsd: fix race between laundromat and free_stateid There is a race between laundromat handling of revoked delegations and a client sending free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revoke_delegation() function for this particular delegation but that means it will no release the lock lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning: kernel:
    ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dump_backtrace+0x98/0x120 kernel: show_stack+0x1c/0x30 kernel:
    dump_stack_lvl+0x80/0xe8 kernel: print_address_description.constprop.0+0x84/0x390 kernel:
    print_report+0xa4/0x268 kernel: kasan_report+0xb4/0xf8 kernel: __asan_report_load8_noabort+0x1c/0x28 kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd] kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd] kernel:
    nfsd4_process_open2+0xa40/0x1a40 [nfsd] kernel: nfsd4_open+0xa08/0xe80 [nfsd] kernel:
    nfsd4_proc_compound+0xb8c/0x2130 [nfsd] kernel: nfsd_dispatch+0x22c/0x718 [nfsd] kernel:
    svc_process_common+0x8e8/0x1960 [sunrpc] kernel: svc_process+0x3d4/0x7e0 [sunrpc] kernel:
    svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 This patch proposes a fixed that's based on adding 2 new additional stid's sc_status values that help coordinate between the laundromat and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()). First to make sure, that once the stid is marked revoked, it is not removed by the nfsd4_free_stateid(), the laundromat take a reference on the stateid. Then, coordinating whether the stid has been put on the cl_revoked list or we are processing FREE_STATEID and need to make sure to remove it from the list, each check that state and act accordingly.
    If laundromat has added to the cl_revoke list before the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove it from the list. If nfsd4_free_stateid() finds that operations arrived before laundromat has placed it on cl_revoke list, it marks the state freed and then laundromat will no longer add it to the list. Also, for nfsd4_delegreturn() when looking for the specified stid, we need to access stid that are marked removed or freeable, it means the laundromat has started processing it but hasn't finished and this delegreturn needs to return nfserr_deleg_revoked and not nfserr_bad_stateid.
    The latter will not trigger a FREE_STATEID and the lack of it will leave this stid on the cl_revoked list indefinitely. (CVE-2024-50106)

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

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

  - 已修复 Linux 内核中的下列漏洞：mptcp: fix race on unaccepted mptcp sockets When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one. (CVE-2022-49669)

  - 已修复 Linux 内核中的下列漏洞：tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the gsm->receive() function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur.
    Fix this by avoiding the call to gsm->receive() in case the function is not initialized by adding a sanity check. Call Trace: <TASK> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [inline] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49940)

  - 已修复 Linux 内核中的下列漏洞：drm/amd/display: clear optc underflow before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off.
    (CVE-2022-49969)

  - 已修复 Linux 内核中的下列漏洞：net: atlantic: fix aq_vec index out of range error The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue:
    events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed warning: variable 'aq_vec' set but not used v3. simplified a for loop (CVE-2022-50066)

  - 已修复 Linux 内核中的下列漏洞：NFSv4/pnfs: Fix a use-after-free bug in open If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call. (CVE-2022-50072)

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

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

  - 在 Linux 内核中，已解决以下漏洞： nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter. (CVE-2024-50043)

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

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

    Attila Szsz 发现 Linux 内核的 HFS+ 文件系统实施包含一个堆溢出漏洞。攻击者可利用特别构建的文件系统映像，安装此映像可造成拒绝服务（系统崩溃）或可能执行任意代码。(CVE-2025-0927)

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

    - ARM32 架构；

    - ARM64 架构；

    - PowerPC 架构；

    - RISC-V 架构；

    - S390 架构；

    - SuperH RISC 架构；

    - User-Mode Linux (UML)；

    - x86 架构；

    - 区块层子系统；

    - 加密 API；

    - 计算加速框架；

    - ACPI 驱动程序；

    - 驱动程序核心；

    - ATA over Ethernet (AOE) 驱动程序；

    - RAM 支持的块设备驱动程序；

    - 网络块设备驱动程序；

    - Ublk userspace block 驱动程序；

    - 压缩 RAM 块设备驱动程序；

    - 蓝牙驱动程序；

    - TPM 设备驱动程序；

    - 时钟框架和驱动程序；

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

    - CPU 频率缩放框架；

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

    - CXL (Compute Express Link) 驱动程序；

    - 对差分内存框架的 DAX dirext 访问；

    - 缓冲区共享和同步框架；

    - EDAC 驱动程序；

    - FireWire 子系统；

    - ARM SCMI 消息协议；

    - ARM SCPI 消息协议；

    - EFI 核心；

    - Qualcomm 固件驱动程序；

    - GPIO 子系统；

    - GPU 驱动程序；

    - HID 子系统；

    - I2C 子系统；

    - I3C 子系统；

    - IIO ADC 驱动程序；

    - IIO 子系统；

    - InfiniBand 驱动程序；

    - 输入设备核心驱动程序；

    - IOMMU 子系统；

    - IRQ 芯片驱动程序；

    - Mailbox 框架；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - 多功能设备驱动程序；

    - MMC 子系统；

    - MTD 块设备驱动程序；

    - 以太网绑定驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - STMicroelectronics 网络驱动程序；

    - NTB 驱动程序；

    - Virtio pmem 驱动程序；

    - NVME 驱动程序；

    - Parport 驱动程序；

    - PCI 子系统；

    - Alibaba DDR Sub-System Driveway PMU 驱动程序；

    - PHY 驱动程序；

    - Pin 控制器子系统；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - Powercap sysfs 驱动程序；

    - 电压和电流调节器驱动程序；

    - 远程处理器子系统；

    - StarFive 重置控制器驱动程序；

    - Real Time Clock 驱动程序；

    - SCSI 子系统；

    - SuperH / SH-Mobile 驱动程序；

    - QCOM SoC 驱动程序；

    - Xilinx SoC 驱动程序；

    - SPI 子系统；

    - Direct Digital Synthesis 驱动程序；

    - 媒体分段驱动程序；

    - TCM 子系统；

    - 热驱动程序；

    - Thunderbolt 和 USB4 驱动程序；

    - TTY 驱动程序；

    - UFS 子系统；

    - USB 设备类驱动程序；

    - DesignWare USB3 驱动程序；

    - USB Gadget 驱动程序；

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

    - USB Dual Role (OTG-ready) Controller 驱动程序；

    - USB 串口驱动程序；

    - USB Type-C 支持驱动程序；

    - USB Type-C Port Controller Manager 驱动程序；

    - TI TPS6598x USB Power Delivery 控制器驱动程序；

    - USB Type-C 连接器系统软件接口驱动程序；

    - vDPA 驱动程序；

    - VFIO 驱动程序；

    - Virtio Host (VHOST) 子系统；

    - Framebuffer 层；

    - Virtio 驱动程序；

    - Xen 管理程序驱动程序；

    - AFS 文件系统；

    - BTRFS 文件系统；

    - 文件系统基础设施；

    - Ceph 分布式文件系统；

    - EROFS 文件系统；

    - Ext4 文件系统；

    - F2FS 文件系统；

    - GFS2 文件系统；

    - JFS 文件系统；

    - 网络文件系统库；

    - 网络文件系统 (NFS) 客户端；

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

    - NILFS2 文件系统；

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

    - NTFS3 文件系统；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - UBI 文件系统；

    - BPF 子系统；

    - 网络文件系统 (NFS) 超级块；

    - Virtio 网络驱动程序；

    - 蓝牙子系统；

    - 网络流量控制；

    - 网络套接字；

    - TCP 网络协议；

    - 跟踪基础设施；

    - 用户空间 API (UAPI)；

    - 内核 init 基础架构；

    - io_uring 子系统；

    - IPC 子系统；

    - Perf 事件；

    - Kernel fork() syscall；

    - 内核线程帮助程序 (kthread)；

    - Padata 并行执行机制；

    - RCU 子系统；

    - 任意资源管理；

    - 计划程序基础设施；

    - 信号处理机制；

    - 静态调用机制；

    - 任务处理机制；

    - Timer 子系统驱动程序；

    - Maple Tree 数据结构库；

    - 内存管理；

    - 9P 文件系统网络协议；

    - 以太网桥接；

    - CAN 网络层；

    - Networking 核心；

    - DCCP（数据报拥塞控制协议）；

    - Distributed Switch 架构；

    - IPv4 联网；

    - IPv6 联网；

    - IUCV 驱动程序；

    - L2TP 协议；

    - MAC80211 子系统；

    - IEEE 802.15.4 子系统；

    - 多路径 TCP；

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

    - Netfilter；

    - Netlink；

    - RxRPC 会话套接字；

    - SCTP 协议；

    - SMC 套接字；

    - Sun RPC 协议；

    - TIPC 协议；

    - Unix 域套接字；

    - VMware vSockets 驱动程序；

    - 无线网络；

    - eXpress 数据路径；

    - XFRM 子系统；

    - AppArmor 安全模块；

    - 完整性度量架构 (IMA) 框架；

    - 密钥管理；

    - ALSA 框架；

    - FireWire 声音驱动程序；

    - AudioScience HPI 驱动程序；

    - HD-audio 驱动程序；

    - SoC Audio for Freescale CPU 驱动程序；

    - MediaTek ASoC 驱动程序；

    - QCOM ASoC 驱动程序；

    - SoC 音频核心驱动程序；

    - STMicroelectronics SoC 驱动程序；

    - USB 音频设备；

    - KVM 核心；（CVE-2024-50244、CVE-2024-56754、CVE-2024-50082、CVE-2024-47737、CVE-2024-50300、CVE-2024-49872、CVE-2024-50180、CVE-2024-50218、CVE-2024-49956、CVE-2024-53189、CVE-2024-56705、CVE-2024-50119、CVE-2024-53192、CVE-2024-49950、CVE-2024-56722、CVE-2024-49943、CVE-2024-50031、CVE-2024-47685、CVE-2024-50296、CVE-2024-49939、CVE-2024-47696、CVE-2024-47752、CVE-2024-49937、CVE-2024-53140、CVE-2024-50236、CVE-2024-50151、CVE-2024-50069、CVE-2024-50170、CVE-2024-50246、CVE-2024-50217、CVE-2024-53125、CVE-2024-50084、CVE-2024-50005、CVE-2024-53137、CVE-2024-50233、CVE-2024-49991、CVE-2024-50067、CVE-2024-50290、CVE-2024-47735、CVE-2024-53133、CVE-2024-50289、CVE-2024-49855、CVE-2024-49868、CVE-2024-56728、CVE-2024-56726、CVE-2024-50012、CVE-2024-53078、CVE-2024-50223、CVE-2024-50143、CVE-2024-50287、CVE-2024-49971、CVE-2024-49900、CVE-2024-50263、CVE-2024-50206、CVE-2024-47707、CVE-2024-47751、CVE-2024-56747、CVE-2024-50260、CVE-2024-50173、CVE-2024-47680、CVE-2024-50009、CVE-2024-53219、CVE-2024-53144、CVE-2024-50008、CVE-2024-53208、CVE-2024-49966、CVE-2024-50104、CVE-2024-50030、CVE-2024-53049、CVE-2024-53201、CVE-2024-50130、CVE-2024-49856、CVE-2024-53095、CVE-2024-50033、CVE-2024-47730、CVE-2024-53216、CVE-2024-50286、CVE-2024-50284、CVE-2024-47744、CVE-2023-52917、CVE-2024-50275、CVE-2024-53114、CVE-2024-49968、CVE-2024-50111、CVE-2024-50000、CVE-2024-53081、CVE-2024-49857、CVE-2024-50262、CVE-2024-50281、CVE-2024-53156、CVE-2024-50225、CVE-2024-53239、CVE-2024-50036、CVE-2024-50187、CVE-2024-53165、CVE-2024-49931、CVE-2024-53111、CVE-2024-49862、CVE-2024-47701、CVE-2024-53091、CVE-2024-50103、CVE-2024-53046、CVE-2024-56678、CVE-2024-56749、CVE-2024-53175、CVE-2024-49970、CVE-2024-50035、CVE-2024-50088、CVE-2024-50297、CVE-2024-47721、CVE-2024-50240、CVE-2024-50076、CVE-2024-56683、CVE-2024-53120、CVE-2024-50074、CVE-2024-50095、CVE-2024-49963、CVE-2024-50158、CVE-2024-50020、CVE-2024-53083、CVE-2024-50029、CVE-2024-56755、CVE-2024-49969、CVE-2024-50022、CVE-2024-50278、CVE-2024-50125、CVE-2024-47706、CVE-2024-50204、CVE-2024-56543、CVE-2024-53108、CVE-2024-49885、CVE-2024-50128、CVE-2024-50062、CVE-2024-50139、CVE-2024-50183、CVE-2024-50288、CVE-2024-56729、CVE-2024-49945、CVE-2024-47695、CVE-2024-56533、CVE-2024-53234、CVE-2024-50002、CVE-2024-50040、CVE-2024-49903、CVE-2024-47702、CVE-2024-47728、CVE-2024-49874、CVE-2024-47718、CVE-2024-53142、CVE-2024-49983、CVE-2024-50211、CVE-2024-50294、CVE-2024-50132、CVE-2024-53236、CVE-2024-50042、CVE-2024-49999、CVE-2024-50001、CVE-2024-50046、CVE-2024-50133、CVE-2024-50256、CVE-2024-49869、CVE-2024-49852、CVE-2024-47717、CVE-2024-56704、CVE-2024-50102、CVE-2024-50150、CVE-2024-49880、CVE-2024-50235、CVE-2024-49892、CVE-2024-53194、CVE-2024-53104、CVE-2024-50232、CVE-2024-50226、CVE-2024-56684、CVE-2024-47713、CVE-2024-50191、CVE-2024-49850、CVE-2024-50277、CVE-2024-53113、CVE-2024-50013、CVE-2024-53221、CVE-2024-50220、CVE-2024-49960、CVE-2024-53228、CVE-2024-50152、CVE-2024-56689、CVE-2024-53220、CVE-2024-50209、CVE-2024-50285、CVE-2024-50197、CVE-2024-53072、CVE-2024-50273、CVE-2024-49928、CVE-2024-53132、CVE-2024-56720、CVE-2024-50194、CVE-2024-50112、CVE-2024-53079、CVE-2024-56696、CVE-2024-47750、CVE-2024-53212、CVE-2024-56541、CVE-2024-50024、CVE-2024-53168、CVE-2024-50247、CVE-2024-50193、CVE-2024-47754、CVE-2024-56540、CVE-2024-50026、CVE-2024-53047、CVE-2024-53151、CVE-2024-50176、CVE-2024-49975、CVE-2024-50034、CVE-2024-50126、CVE-2024-49863、CVE-2024-47693、CVE-2024-49954、CVE-2024-49938、CVE-2024-50171、CVE-2024-50185、CVE-2024-50200、CVE-2024-50201、CVE-2024-53184、CVE-2024-47709、CVE-2024-50138、CVE-2024-49935、CVE-2024-50049、CVE-2024-56537、CVE-2024-50057、CVE-2024-56677、CVE-2024-47743、CVE-2024-50293、CVE-2024-50099、CVE-2024-47720、CVE-2024-50021、CVE-2024-50059、CVE-2024-49871、CVE-2024-49884、CVE-2024-47694、CVE-2024-56723、CVE-2024-47724、CVE-2024-50038、CVE-2024-53123、CVE-2024-53177、CVE-2024-49932、CVE-2024-50196、CVE-2024-50234、CVE-2024-50078、CVE-2024-53043、CVE-2024-49926、CVE-2024-49988、CVE-2024-53187、CVE-2024-53056、CVE-2024-53217、CVE-2024-56745、CVE-2024-47726、CVE-2024-50063、CVE-2024-49987、CVE-2024-49955、CVE-2024-50179、CVE-2024-49866、CVE-2024-50283、CVE-2024-49997、CVE-2024-47742、CVE-2024-56691、CVE-2024-50253、CVE-2024-56690、CVE-2024-47710、CVE-2024-53129、CVE-2024-50190、CVE-2024-50090、CVE-2024-56702、CVE-2024-50148、CVE-2024-53183、CVE-2024-50070、CVE-2024-50154、CVE-2024-50243、CVE-2024-50003、CVE-2024-50117、CVE-2024-56751、CVE-2024-56697、CVE-2024-53166、CVE-2024-53196、CVE-2024-47677、CVE-2024-56679、CVE-2024-49996、CVE-2024-47681、CVE-2024-53181、CVE-2024-47700、CVE-2024-53071、CVE-2024-50015、CVE-2024-53126、CVE-2024-50165、CVE-2024-50172、CVE-2024-53063、CVE-2024-53200、CVE-2024-53135、CVE-2024-49974、CVE-2024-53088、CVE-2024-49936、CVE-2024-53121、CVE-2024-50166、CVE-2024-50087、CVE-2024-53065、CVE-2024-53214、CVE-2024-53076、CVE-2024-53059、CVE-2024-50230、CVE-2024-49985、CVE-2024-50092、CVE-2024-53233、CVE-2024-50047、CVE-2024-56685、CVE-2024-47682、CVE-2024-47705、CVE-2024-50077、CVE-2024-53224、CVE-2024-49887、CVE-2024-49940、CVE-2024-47741、CVE-2024-49858、CVE-2024-56536、CVE-2024-53055、CVE-2024-56687、CVE-2024-50100、CVE-2024-53075、CVE-2024-47699、CVE-2024-53213、CVE-2024-49977、CVE-2024-50268、CVE-2024-53146、CVE-2024-50304、CVE-2024-50096、CVE-2024-53162、CVE-2024-56725、CVE-2024-49953、CVE-2024-53077、CVE-2024-50107、CVE-2024-53226、CVE-2024-53134、CVE-2024-49873、CVE-2024-56548、CVE-2024-53145、CVE-2024-53141、CVE-2024-56741、CVE-2024-53067、CVE-2024-53152、CVE-2024-50072、CVE-2024-50282、CVE-2024-53232、CVE-2024-50140、CVE-2024-53198、CVE-2024-53150、CVE-2024-49876、CVE-2024-50302、CVE-2024-53115、CVE-2024-47692、CVE-2024-50301、CVE-2024-50202、CVE-2024-50155、CVE-2024-56693、CVE-2024-53082、CVE-2024-53167、CVE-2024-56748、CVE-2024-53064、CVE-2024-50227、CVE-2024-56539、CVE-2024-50215、CVE-2024-50043、CVE-2024-50146、CVE-2024-50147、CVE-2024-56699、CVE-2024-50122、CVE-2024-53044、CVE-2024-47712、CVE-2024-53230、CVE-2024-50121、CVE-2024-50216、CVE-2024-53084、CVE-2024-56703、CVE-2024-50178、CVE-2024-49934、CVE-2024-47678、CVE-2024-50271、CVE-2024-50144、CVE-2024-50252 、CVE-2024-47734、CVE-2024-47711、CVE-2024-50214、CVE-2024-53100、CVE-2024-56680、CVE-2024-50198、CVE-2024-50025、CVE-2024-50044、CVE-2024-50098、CVE-2024-47745、CVE-2024-49860、CVE-2024-49881、CVE-2024-53048、CVE-2024-56721、CVE-2024-56756、CVE-2024-53171、CVE-2024-49901、CVE-2024-53109、CVE-2024-53061、CVE-2024-49929、CVE-2024-47691、CVE-2024-50045、CVE-2024-47723、CVE-2024-56546、CVE-2024-50157、CVE-2024-53169、CVE-2024-47716、CVE-2024-53093、CVE-2024-50224、CVE-2024-53193、CVE-2024-49895、CVE-2024-47698、CVE-2024-49942、CVE-2024-50167、CVE-2024-53202、CVE-2024-49870、CVE-2024-50291、CVE-2024-50156、CVE-2024-53153、CVE-2024-50272、CVE-2024-50145、CVE-2024-50298、CVE-2024-50274、CVE-2024-56694、CVE-2024-50108、CVE-2024-50222、CVE-2024-53163、CVE-2024-50164、CVE-2024-53062、CVE-2024-50212、CVE-2024-53127、CVE-2024-47688、CVE-2024-49959、CVE-2024-50203、CVE-2024-49927、CVE-2024-50083、CVE-2024-53227、CVE-2024-47697、CVE-2024-53053、CVE-2024-53172、CVE-2024-56752、CVE-2024-50207、CVE-2024-50169、CVE-2024-53176、CVE-2024-53089、CVE-2024-56707、CVE-2024-53195、CVE-2024-49851、CVE-2024-53209、CVE-2024-49972、CVE-2024-53130、CVE-2024-53157、CVE-2024-53094、CVE-2024-50182、CVE-2024-49879、CVE-2024-53191、CVE-2024-49925、CVE-2024-49949、CVE-2024-56534、CVE-2024-47714、CVE-2024-53161、CVE-2024-49992、CVE-2024-47732、CVE-2024-53143、CVE-2024-53119、CVE-2024-50064、CVE-2024-50039、CVE-2024-53087、CVE-2024-49886、CVE-2024-49979、CVE-2024-50041、CVE-2024-50184、CVE-2024-49958、CVE-2024-50221、CVE-2024-56688、CVE-2024-49941、CVE-2024-50245、CVE-2024-50017、CVE-2024-53180、CVE-2024-56535、CVE-2024-50142、CVE-2024-50295、CVE-2024-56708、CVE-2024-50016、CVE-2024-49902、CVE-2024-50120、CVE-2024-47748、CVE-2024-49982、CVE-2024-50257、CVE-2024-50086、CVE-2024-50261、CVE-2024-53188、CVE-2024-49888、CVE-2024-53106、CVE-2024-50073、CVE-2024-50186、CVE-2024-56544、CVE-2024-47739、CVE-2024-50238、CVE-2024-56739、CVE-2024-49964、CVE-2024-47686、CVE-2024-46869、CVE-2024-53116、CVE-2024-50014、CVE-2024-53231、CVE-2024-53138、CVE-2024-50213、CVE-2024-50265、CVE-2024-49998、CVE-2024-50292、CVE-2024-50137、CVE-2024-50114、CVE-2024-53237、CVE-2024-49952、CVE-2024-53074、CVE-2024-49981、CVE-2024-47733、CVE-2024-50019、CVE-2024-47719、CVE-2024-53068、CVE-2024-49944、CVE-2024-50066、CVE-2024-50007、CVE-2024-53155、CVE-2024-47756、CVE-2024-49947、CVE-2024-49951、CVE-2024-50065、CVE-2024-49957、CVE-2024-50116、CVE-2024-50188、CVE-2024-50255、CVE-2024-53197、CVE-2024-50267、CVE-2024-50124、CVE-2024-53069、CVE-2024-53139、CVE-2024-47676、CVE-2024-56545、CVE-2024-53085、CVE-2024-50163、CVE-2024-53092、CVE-2024-53099、CVE-2024-49889、CVE-2024-53052、CVE-2024-49995、CVE-2024-49976、CVE-2024-50110、CVE-2024-50192、CVE-2024-50208、CVE-2024-50276、CVE-2024-53170、CVE-2024-50259、CVE-2024-47731、CVE-2024-49924、CVE-2024-56532、CVE-2024-50048、CVE-2024-49965、CVE-2024-53147、CVE-2024-50205、CVE-2024-49859、CVE-2024-53066、CVE-2024-47687、CVE-2024-50149、CVE-2024-49864、CVE-2024-49867、CVE-2024-50160、CVE-2024-53058、CVE-2024-47753、CVE-2024-49883、CVE-2024-53199、CVE-2024-56746、CVE-2024-50094、CVE-2024-49946、CVE-2024-50006、CVE-2024-53101、CVE-2024-49891、CVE-2024-50075、CVE-2024-47747、CVE-2024-47740、CVE-2024-50248、CVE-2024-50162、CVE-2024-53090、CVE-2024-53203、CVE-2024-50242、CVE-2024-49961、CVE-2024-50085、CVE-2024-50299、CVE-2024-49980、CVE-2024-50280、CVE-2024-53107、CVE-2024-50199、CVE-2024-53122、CVE-2024-56674、CVE-2024-50079、CVE-2024-50060、CVE-2024-53210、CVE-2024-50177、CVE-2024-53223、CVE-2024-50127、CVE-2024-53190、CVE-2022-49034、CVE-2024-56744、CVE-2024-50136、CVE-2024-47675、CVE-2024-50303、CVE-2024-50123、CVE-2024-47738、CVE-2024-50239、CVE-2024-50135、CVE-2024-53218、CVE-2024-50109、CVE-2024-56724、CVE-2024-56681、CVE-2024-50027、CVE-2024-50081、CVE-2024-50068、CVE-2024-50101、CVE-2024-50071、CVE-2024-50129、CVE-2024-50091、CVE-2024-53112、CVE-2024-50181、CVE-2024-50080、CVE-2024-47703、CVE-2024-47727、CVE-2024-53215、CVE-2024-53105、CVE-2024-50174、CVE-2024-50105、CVE-2024-56700、CVE-2024-53173、CVE-2024-49865、CVE-2024-49973、CVE-2024-56538、CVE-2024-50251、CVE-2024-56692、CVE-2024-47671、CVE-2024-50189、CVE-2024-49853、CVE-2024-50153、CVE-2024-53124、CVE-2024-56549、CVE-2024-53160、CVE-2024-53174、CVE-2024-53117、CVE-2024-50279、CVE-2024-50118、CVE-2024-47757、CVE-2024-50055、CVE-2024-49875、CVE-2024-50141、CVE-2024-49890、CVE-2024-49878、CVE-2024-50134、CVE-2024-53042、CVE-2024-56727、CVE-2024-49861、CVE-2024-49948、CVE-2024-50010、CVE-2024-49930、CVE-2024-49877、CVE-2024-47690、CVE-2024-50115、CVE-2024-50254、CVE-2024-50250、CVE-2024-47679、 CVE-2024-50258、 CVE-2024-53128、 CVE-2024-49994、 CVE-2024-53154、 CVE-2024-50037、 CVE-2024-53149、 CVE-2024-50266、CVE-2024-50061、CVE-2024-56698、CVE-2024-53118、CVE-2024-47689、CVE-2024-47708、CVE-2024-50131、CVE-2024-50168、CVE-2024-53158、CVE-2024-49894、CVE-2024-50056、CVE-2024-50231、CVE-2024-50270、CVE-2024-50269、CVE-2024-50237、CVE-2024-56742、CVE-2024-49882、CVE-2024-47749、CVE-2024-49962、CVE-2024-49933、CVE-2024-53045、CVE-2024-50028、CVE-2024-53178、CVE-2024-50229、CVE-2024-50023、CVE-2024-50161、CVE-2024-56701、CVE-2024-49978、CVE-2024-50093、CVE-2024-50195、CVE-2024-49986、CVE-2024-53098、CVE-2024-53131、CVE-2024-47684、CVE-2024-53148、CVE-2024-50058、CVE-2024-53086、CVE-2024-50113、CVE-2024-49989、CVE-2024-50106、CVE-2024-53080、CVE-2024-53229、CVE-2024-50159、CVE-2024-56531、CVE-2024-53110、CVE-2024-47736、CVE-2024-56542、CVE-2024-47746）

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

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

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

  - 已修复 Linux 内核中的下列漏洞：ath11k: free peer for station when disconnect from AP for QCA6390/WCN6855 Commit b4a0f54156ac (ath11k: move peer delete after vdev stop of station for QCA6390 and WCN6855) is to fix firmware crash by changing the WMI command sequence, but actually skip all the peer delete operation, then it lead commit 58595c9874c6 (ath11k: Fixing dangling pointer issue upon peer delete failure) not take effect, and then happened a use-after-free warning from KASAN. because the peer->sta is not set to NULL and then used later. Change to only skip the WMI_PEER_DELETE_CMDID for QCA6390/WCN6855. log of user-after-free: [ 534.888665] BUG: KASAN: use-after-free in ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860 [ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted:
    G W 5.15.0-wt-ath+ #523 [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 534.888716] Call Trace: [ 534.888720] <IRQ> [ 534.888726] dump_stack_lvl+0x57/0x7d [ 534.888736] print_address_description.constprop.0+0x1f/0x170 [ 534.888745] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888771] kasan_report.cold+0x83/0xdf [534.888783] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888810] ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888840] ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k] [ 534.888874] ? ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? check_prev_add+0x20f0/0x20f0 [534.888922] ? __lock_acquire+0xb72/0x1870 [ 534.888937] ? find_held_lock+0x33/0x110 [ 534.888954] ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k] [ 534.888981] ? rcu_read_unlock+0x40/0x40 [534.888990] ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k] [ 534.889026] ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889075] call_timer_fn+0x167/0x4a0 [ 534.889084] ? add_timer_on+0x3b0/0x3b0 [ 534.889103] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 534.889117] __run_timers.part.0+0x539/0x8b0 [ 534.889123] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889157] ? call_timer_fn+0x4a0/0x4a0 [534.889164] ? mark_lock_irq+0x1c30/0x1c30 [ 534.889173] ? clockevents_program_event+0xdd/0x280 [534.889189] ? mark_held_locks+0xa5/0xe0 [ 534.889203] run_timer_softirq+0x97/0x180 [ 534.889213]
    __do_softirq+0x276/0x86a [ 534.889230] __irq_exit_rcu+0x11c/0x180 [ 534.889238] irq_exit_rcu+0x5/0x20 [534.889244] sysvec_apic_timer_interrupt+0x8e/0xc0 [ 534.889251] </IRQ> [ 534.889254] <TASK> [ 534.889259] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 0000000000000006 RBX:
    0000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI:
    0000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f [534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13:
    ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? mark_lock+0xd0/0x14a0 [534.889332] klist_next+0x1d4/0x450 [ 534.889340] ? dpm_wait_for_subordinate+0x2d0/0x2d0 [ 534.889350] device_for_each_child+0xa8/0x140 [ 534.889360] ? device_remove_class_symlinks+0x1b0/0x1b0 [ 534.889370] ?
    __lock_release+0x4bd/0x9f0 [ 534.889378] ? dpm_suspend+0x26b/0x3f0 [ 534.889390] dpm_wait_for_subordinate+
    ---truncated--- (CVE-2022-49238)

  - 已修复 Linux 内核中的下列漏洞：tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the gsm->receive() function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur.
    Fix this by avoiding the call to gsm->receive() in case the function is not initialized by adding a sanity check. Call Trace: <TASK> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [inline] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49940)

  - 已修复 Linux 内核中的下列漏洞：net: qrtr: start MHI channel after endpoit creation MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device.
    --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet.
    -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it. (CVE-2022-50044)

  - 已修复 Linux 内核中的下列漏洞：net: atlantic: fix aq_vec index out of range error The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue:
    events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed warning: variable 'aq_vec' set but not used v3. simplified a for loop (CVE-2022-50066)

  - 已修复 Linux 内核中的下列漏洞：NFSv4/pnfs: Fix a use-after-free bug in open If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call. (CVE-2022-50072)

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

远程 Oracle Linux 8/9 主机上安装的多个程序包受到 ELSA-2026-50261 公告中提及的多个漏洞影响。

    - xfrm：esp：ipv4：修复标记设置 （Greg Kroah-Hartman） [Orabug： 39344515] {CVE-2026-43284}
    - xfrm：esp：避免对共享 skb frag 进行就地解密 （Kuan-Ting Chen） [Orabug： 39344515] {CVE-2026-43284}
    - x86/CPU/AMD：添加 AMD-SB-7052 的补丁 （Prathyushi Nangia） [Orabug： 39327141] {CVE-2025-54518}
    - crypto：algif_aead - 恢复到原位操作 （Herbert Xu） [Orabug： 39250686] {CVE-2026-31431}
    - x86/CPU：修复 Zen1 上的 FPDSS （Borislav Petkov） [Orabug： 39241228,39273722] {CVE-2026-31628}
    - net/handshake：重复的握手取消泄漏套接字 （Scott Mayhew） [Orabug： 38847720] {CVE-2025-68775}
    - ipv6：使用 ip6_xmit（） 中的 RCU （Eric Dumazet） [Orabug： 38649062] {CVE-2025-40135}
    - scsi：qla2xxx：审查负载大小以防止成员溢出 （Jiasheng Jiang） [Orabug： 38930868] {CVE-2026-23059}
    - bpf：修复 bpf_prog_test_run_xdp（） 中的引用计数泄漏 （Tetsuo Handa） [Orabug： 38887702] {CVE-2026-22994}
    - nfsd：检查服务器是否在 unlock_filesystem 中运行 （Olga Kornievskaia） [Orabug： 38887682] {CVE-2026-22989}
    - net/mlx5e：TC，仅删除现有对等机的流 （Mark Bloch） [Orabug：38970398] {CVE-2026-23173}
    - net/handshake：提交失败时还原析构函数 （Caoping） [Orabug：38887601] {CVE-2025-71148}
    - scsi：qla2xxx：修复 purex 项目的不正确释放 （Zilin Guan） [Orabug： 38798929] {CVE-2025-68741}
    - bnxt_en：修复XDP_TX路径 （Michael Chan） [Orabug：38847684] {CVE-2025-68770}
    - perf/x86/amd：启用前检查事件以避免 GPF （George Kennedy） [Orabug： 38847849] {CVE-2025-68798}
    - scsi：smartpqi：修复设备删除后访问的设备资源 （Mike Mcgowen） [Orabug：38798848] {CVE-2025-68371}
    - KVM：SVM：替换 INT3/INTO 时不跳过不相关的指令 （Omar Sandoval） [Orabug： 38773579] {CVE-2025-68259}
    - x86/fpu：确保信号传送时的 XFD 状态 （Chang S. Bae） [Orabug： 38773165] {CVE-2025-68171}
    - virtio-net：修复大数据包中收到的长度检查 （Bui Quang Minh） [Orabug： 38737152] {CVE-2025-40292}
    - ACPI：CPPC：修复使用 nosmp 时的空指针取消引用 （Yunhui Cui） [Orabug： 38641284] {CVE-2025-38113}
    - EDAC/i10nm：在已禁用的内存控制器上跳过 DIMM 枚举 （Qiuxu Zhuo） [Orabug： 38649173] {CVE-2025-40157}
    - sunrpc：修复零长度校验和中的空指针取消引用 （Lei Lu） [Orabug： 38649042] {CVE-2025-40129}
    - cpufreq：CPPC：修复 cppc_get_cpu_cost（） 可能的 null-ptr-deref （Jinjie Ruan） [Orabug： 38641275] {CVE-2024-53230}
    - cpufreq：CPPC：修复 cpufreq_cpu_get_raw（） 可能的 null-ptr-deref （Jinjie Ruan） [Orabug： 38641272] {CVE-2024-53231}
    - vhost：vringh：修复返回值检查copy_to_iter （Michael S. Tsirkin） [Orabug： 38592117] {CVE-2025-40056}
    - crypto：qat - 设备关机期间刷新 misc 工作队列 （Giovanni Cabiddu） [Orabug： 38401717] {CVE-2025-39721}
    - vhost：vringh：修改返回值检查 （Zhang Jiao） [Orabug：38592085] {CVE-2025-40051}
    - virtio-net：修复 probe（） 期间的递归 rtnl_lock（） （Zigit Zo） [Orabug： 38324330] {CVE-2025-38551}
    - gve：关闭后防止 ethtool 操作 （Jordan Rhee） [Orabug： 38401492] {CVE-2025-38735}
    - KVM：SVM：如果 vCPU 创建正在运行中，则拒绝 SEV{-ES} 内部主机迁移 （Sean Christopherson） [Orabug：38254140] {CVE-2025-38455}
    - net：usb：lan78xx：断开连接时修复 __netif_napi_del_locked 中的 WARN （Oleksij Rempel） [Orabug： 38253871] {CVE-2025-38385}
    - net/mlx5e：禁用上行链路表示者配置文件的 MACsec 卸载 （Carolina Jubran） [Orabug： 38094809] {CVE-2025-38020}
    - dmaengine：idxd：修复idxd_alloc错误处理路径中的内存泄漏 （Shuai Xue） [Orabug： 38094794] {CVE-2025-38015}
    - net/mlx5：修复关闭流上的 ECVF vports 卸载 （Amir Tzin） [Orabug： 38152903] {CVE-2025-38109}
    - bnxt：正确刷新 XDP 重定向列表 （Yan Zhai） [Orabug： 38175054] {CVE-2025-38246}
    - eth：bnxt：修复错误路径上缺少的环索引修剪 （Jakub Kicinski） [Orabug： 37937451] {CVE-2025-37873}
    - net/mlx5：修复 mlx5_create_{inner_，}ttc_table（） 中的 null-ptr-deref （Henry Martin） [Orabug： 37938078] {CVE-2025-37888}
    - nfsd：修复 FREE_STATEID 中可能的不良问题 （Olga Kornievskaia） [Orabug： 37989102] {CVE-2024-50043}
    - devlink：修复 xa_alloc_cyclic（） 错误处理 （Michal Swiatkowski） [Orabug： 37828271] {CVE-2025-22017}
    - xsk：修复 xp_create_and_assign_umem（） 中的整数溢出 （Gavrilov Ilia） [Orabug： 37828202] {CVE-2025-21997}
    - RDMA/mlx5：修复 UMR QP 的恢复流 （Yishai Hadas） [Orabug： 37766306] {CVE-2025-21892}
    - misc：misc_minor_alloc将 ida 用于所有动态/杂项动态次要 （Vimal Agrawal） [Orabug： 37678552] {CVE-2024-58078}
    - net/sched：cls_api：修复造成空取消引用的错误处理 （Pierre Riteau） [Orabug： 37702083] {CVE-2025-21857}
    - bpf、test_run：修复 eth_skb_pkt_type（） 中的释放后使用问题 （Shigeru Yoshida） [Orabug： 37766220] {CVE-2025-21867}
    - net：xdp：禁止在通用模式下附加设备绑定程序 （Toke Hoiland-Jorgensen） [Orabug：
    37650238] {CVE-2025-21808}
    - iommufd/iova_bitmap：修复 iova_bitmap_offset_to_index（） 中的越界移位 （Qasim Ijaz） [Orabug：
    37649891] {CVE-2025-21724}
    - xfrm：删除数据包卸载模式下的中间 secpath 条目 （Alexandre Cassen） [Orabug： 37649866] {CVE-2025-21720}
    - gpiolib：修复 gpiochip_get_ngpios（） 中出错时的崩溃 （Andy Shevchenko） [Orabug： 37650154] {CVE-2025-21783}
    - scsi：mpi3mr：修复设置 bsg 失败时可能发生的崩溃 （Guixin Liu） [Orabug： 37649886] {CVE-2025-21723}
    - KVM：x86/mmu：即使创建 MMIO SPTE 时，删除/清除现有的当前 SPTE （Sean Christopherson） [Orabug： 39151165,39159089] {CVE-2026-23401}
    - scsi：core：修复 tagset_refcnt 的 refcount 泄漏 （Junxiao Bi） [Orabug： 38976650,39130775] {CVE-2026-23296}
    - net：atm：修复由于 sigd_send（） 中未经验证的 vcc 指针造成的崩溃 （Jiayuan Chen） [Orabug： 39188477] {CVE-2026-31411}
    - RDMA/umad：拒绝 ib_umad_write 中的负data_len （Yunje Shin） [Orabug： 39103109] {CVE-2026-23243}

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

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
360282	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多种漏洞（ALMALINUX9.2：CLSA-2025：1751916475）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
360874	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel-core / kernel-debug / kernel-debug-core / 等多个漏洞（CENTOS8.4：CLSA-2025：1753297988）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
231086	Linux Distros 未修补的漏洞: CVE-2024-50043	Nessus	Misc.	2025/3/6	2026/7/17	high
216943	Ubuntu 24.04 LTS：Linux 内核漏洞 (USN-7310-1)	Nessus	Ubuntu Local Security Checks	2025/2/28	2025/9/24	critical
351710	CentOS Linux 8.5 [TuxCare] 安全更新：kernel-cross-headers / kernel-debug-modules-extra / 等多个漏洞（CENTOS8.5：CLSA-2025：1753298320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
314332	Oracle Linux 8/9：Unbreakable Enterprise 内核 (ELSA-2026-50261)	Nessus	Oracle Linux Local Security Checks	2026/5/12	2026/5/13	high
216492	Ubuntu 24.10：Linux 内核漏洞 (USN-7277-1)	Nessus	Ubuntu Local Security Checks	2025/2/19	2026/6/3	critical
216493	Ubuntu 24.10：Linux 内核漏洞 (USN-7276-1)	Nessus	Ubuntu Local Security Checks	2025/2/19	2025/9/24	critical

检测

插件搜索

high

high

high

critical

high

high

critical

critical