远程 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Rocky Linux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1 1787305050公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - 已修复 Linux 内核中的下列漏洞：mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs) avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases. (CVE-2024-53079)

  - 已修复 Linux 内核中的下列漏洞：io_uring/kbuf: reallocate buf lists on upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - 已修复 Linux 内核中的下列漏洞：RDMA/bnxt_re: Add sanity checks on rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already freed. (CVE-2025-21901)

  - 已修复 Linux 内核中的下列漏洞：cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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

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

  - 已修复 Linux 内核中的下列漏洞：vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at:
    https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
    (CVE-2022-48862)

  - 已修复 Linux 内核中的下列漏洞：net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause use after free error. This patch adds a vlan list lock to protect the vlan list. (CVE-2022-49182)

  - 已修复 Linux 内核中的下列漏洞：perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60
    __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. (CVE-2022-49781)

  - 已修复 Linux 内核中的下列漏洞：blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable to lazy-init rq_qos policies because they are optional features and add to hot path overhead once initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit() become noop's. (CVE-2022-50550)

  - 已修复 Linux 内核中的下列漏洞：i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed.
    Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23:
    enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off (CVE-2024-26830)

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

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

  - l2tp防止可能的隧道引用计数下溢创建会话时它会设置指向其隧道的反向指针。当会话 refcount 降至 0 时如果 session->tunnel 为非 NULL则 l2tp_session_free 会丢弃通道 refcount。但是在 l2tp_session_register 增加隧道引用计数之前会在 l2tp_session_create 中设置 session->tunnel这会留下一个小窗口当隧道引用计数尚未增加时该窗口中的 session->tunnel 为非 NULL。将分配移动到 l2tp_session_register 做法微不足道，但 l2tp_session_create 会调用 l2tp_session_set_header_len，而 l2tp_session_set_header_len 使用 session->tunnel 来获取通道的 encap。将 encap 参数添加到 l2tp_session_set_header_len 以避免使用 session->tunnel。如果 l2tpv3 会话具有冲突 ID则 l2tp_v3_session_get 可能与 l2tp_session_register 争用并获取尚未设置 session->tunnel 的会话。为此案例添加检查。 (CVE-2024-49940)

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

远程 Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS 主机上安装的软件包存在多个漏洞，如 USN-8781-1 告警中所述。

    已发现在全局观察到通过无效转换进行的内存写入之前，某些 Arm 处理器可完成广播转换后备缓冲器 （TLB） 无效化。本地攻击者可能利用此缺陷在撤销权限后写入内存，从而绕过内存保护或升级权限。（CVE-2025-10263）

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

    - ARM64 架构；

    - 用户空间 API (UAPI)；

    - 内核构建系统;

    - ARM32 架构；

    - PowerPC 架构；

    - RISC-V 架构；

    - S390 架构；

    - User-Mode Linux (UML)；

    - x86 架构；

    - 加密 API；

    - 英特尔 NPU 驱动程序;

    - 计算加速框架；

    - ACPI 驱动程序；

    - 驱动程序核心；

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

    - 雷达斯块设备 （RBD） 驱动程序;

    - Ublk userspace block 驱动程序；

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

    - 蓝牙驱动程序；

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

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

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

    - EFI 核心；

    - FPGA 架构；

    - GPU 驱动程序；

    - HID 子系统；

    - 硬件监控驱动程序；

    - I2C 子系统；

    - I3C 子系统；

    - InfiniBand 驱动程序；

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

    - 输入设备（鼠标）驱动程序；

    - IOMMU 子系统；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - Fastrpc 驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

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

    - MediaTek 网络驱动程序；

    - NVME 驱动程序；

    - 操作性能点 (OPP) 驱动程序；

    - PCI 子系统；

    - PTP 时钟框架；

    - RPMSG 子系统；

    - SCSI 子系统；

    - SoundWire 子系统；

    - SPI 子系统；

    - Greybus lights 分段驱动程序；

    - 媒体分段驱动程序；

    - NVIDIA Tegra 嵌入式控制器 （NVEC） 暂存驱动程序;

    - Realtek RTL8723BS SDIO 驱动程序；

    - TCM 子系统；

    - 受信任执行环境驱动程序；

    - Thunderbolt 和 USB4 驱动程序；

    - TTY 驱动程序；

    - USB Gadget 驱动程序；

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

    - USB 串口驱动程序；

    - vDPA 驱动程序；

    - VFIO 驱动程序；

    - Virtio Host (VHOST) 子系统；

    - Virtio 驱动程序；

    - Xen 管理程序驱动程序；

    - 9P 分布式文件系统；

    - AFS 文件系统；

    - 文件系统基础设施；

    - BTRFS 文件系统；

    - Ceph 分布式文件系统；

    - exFAT 文件系统；

    - F2FS 文件系统；

    - GFS2 文件系统；

    - HFS 文件系统；

    - HFS+ 文件系统；

    - JFS 文件系统；

    - 网络文件系统库；

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

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

    - NTFS3 文件系统；

    - OCFS2 文件系统；

    - OrangeFS 文件系统；

    - SMB 网络文件系统；

    - BPF 子系统；

    - 文件系统加密 （fscrypt）;

    - 软件节点和设备属性;

    - IPv4 联网；

    - KVM 子系统；

    - Mellanox 驱动程序；

    - 内存管理；

    - Networking 核心；

    - Netfilter；

    - 套接字消息基础架构；

    - MediaTek SoC 驱动程序；

    - Sun RPC 协议；

    - 网络流量控制；

    - IPv6 联网；

    - Amateur Radio 驱动程序；

    - 蓝牙子系统；

    - IP 隧道定义；

    - KCM（Kernel Connection Multiplexor）套接字驱动程序；

    - MultiProtocol Label Switching 驱动程序；

    - TCP 网络协议；

    - XFRM 子系统；

    - 跟踪基础设施；

    - io_uring 子系统；

    - 控制群组 (cgroup)；

    - Perf 事件；

    - IRQ 子系统；

    - 锁定基元；

    - KProbes 跟踪;

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

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

    - 以太网桥接；

    - CAN 网络层；

    - Ceph Core 库；

    - 握手 API；

    - HSR 网络协议；

    - IFE协议;

    - L2TP 协议；

    - MAC80211 子系统；

    - IEEE 802.15.4 子系统；

    - 多路径 TCP；

    - NFC 子系统；

    - Open vSwitch；

    - Phonet 协议；

    - RDS 协议；

    - RxRPC 会话套接字；

    - SCTP 协议；

    - SMC 套接字；

    - TIPC 协议；

    - TLS 协议；

    - Unix 域套接字；

    - VMware vSockets 驱动程序；

    - 无线网络；

    - X.25 network layer;

    - eXpress 数据路径；

    - Rust 绑定机制；

    - AppArmor 安全模块；

    - 密钥管理；

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

    - SELinux 安全模块；

    - ALSA 框架；

    - AudioScience HPI 驱动程序；

    - Intel ASoC 驱动程序；

    - USB音响设备;（CVE-2024-14040 ， ， ， CVE-2024-41008， CVE-2024-43872CVE-2025-38498CVE-2025-21985CVE-2025-22104CVE-2024-57857CVE-2024-58089CVE-2024-56591CVE-2024-58098CVE-2024-58094CVE-2024-58100CVE-2024-58241CVE-2025-21687CVE-2025-21693CVE-2025-21984CVE-2024-56552CVE-2025-22109CVE-2025-22108CVE-2025-23132CVE-2025-37776CVE-2025-37876CVE-2025-37906CVE-2025-38064CVE-2024-53098CVE-2025-38187CVE-2025-38069CVE-2025-38204CVE-2025-38206CVE-2025-38242CVE-2025-38563CVE-2025-38565CVE-2024-52560CVE-2025-38717CVE-2025-38636CVE-2025-40025CVE-2025-39990CVE-2025-40040CVE-2025-39958CVE-2025-39933CVE-2025-39896CVE-2025-40054CVE-2025-39862CVE-2025-39859CVE-2025-39789CVE-2025-40064CVE-2025-39677CVE-2024-50217CVE-2025-40074CVE-2025-40168CVE-2025-40158CVE-2025-40170CVE-2025-40139CVE-2025-40203CVE-2025-40274CVE-2024-44932CVE-2024-49932CVE-2025-40344CVE-2024-44964CVE-2024-49940CVE-2024-50106CVE-2025-40075CVE-2024-35948、 、 、 CVE-2026-43213CVE-2026-23239CVE-2026-23208CVE-2026-23240CVE-2026-23327CVE-2026-23393CVE-2026-23469CVE-2026-31420CVE-2025-71289CVE-2026-31486CVE-2026-31479CVE-2026-31493CVE-2026-31560CVE-2026-31568CVE-2026-31630CVE-2026-31663CVE-2025-71202CVE-2026-43009CVE-2026-31771CVE-2026-43029CVE-2026-43042CVE-2026-43048CVE-2026-43101CVE-2026-43116CVE-2025-71074CVE-2026-43172CVE-2026-43126CVE-2026-43263CVE-2026-43303CVE-2026-43352CVE-2026-46158CVE-2026-46130CVE-2026-46054CVE-2026-46170CVE-2026-45944CVE-2026-45932CVE-2026-45894CVE-2026-46175CVE-2026-45850CVE-2026-43464CVE-2026-43353CVE-2026-46181CVE-2025-71073CVE-2025-68745CVE-2026-52910CVE-2026-46324CVE-2026-52909CVE-2026-46275CVE-2026-46315CVE-2026-46320CVE-2026-52908CVE-2026-52912CVE-2025-68822CVE-2026-46330CVE-2025-68360CVE-2026-46203CVE-2025-68304CVE-2025-68174CVE-2025-40354、 、 、 CVE-2026-53159CVE-2026-52988CVE-2026-52991CVE-2026-53000CVE-2026-52956CVE-2026-53009CVE-2026-53005CVE-2026-53024CVE-2026-53025CVE-2026-53053CVE-2026-53070CVE-2026-53078CVE-2026-52941CVE-2026-53090CVE-2026-53089CVE-2026-53091CVE-2026-53109CVE-2026-53118CVE-2026-53120CVE-2026-53129CVE-2026-52934CVE-2026-53132CVE-2026-53131CVE-2026-53133CVE-2026-53148CVE-2026-53182CVE-2026-53230CVE-2026-53221CVE-2026-53217CVE-2026-53232CVE-2026-53216CVE-2026-53198CVE-2026-53196CVE-2026-53239CVE-2026-53186CVE-2026-53185CVE-2026-53183CVE-2026-53250CVE-2026-52926CVE-2026-52921CVE-2026-53275CVE-2026-53266CVE-2026-53273CVE-2026-53256CVE-2026-53262CVE-2026-53264CVE-2026-53270CVE-2026-53281CVE-2026-52922CVE-2026-53269CVE-2026-52919CVE-2026-53254CVE-2026-52918CVE-2026-52916CVE-2026-52915、 、 、 CVE-2026-63906CVE-2026-63795CVE-2026-63796CVE-2026-63797CVE-2026-53399CVE-2026-63801CVE-2026-63800CVE-2026-63804CVE-2026-63807CVE-2026-63808CVE-2026-63815CVE-2026-63818CVE-2026-53398CVE-2026-63828CVE-2026-63825CVE-2026-63829CVE-2026-63830CVE-2026-63831CVE-2026-63853CVE-2026-63858CVE-2026-53384CVE-2026-63887CVE-2026-63886CVE-2026-63888CVE-2026-63893CVE-2026-63912CVE-2026-63926CVE-2026-63924CVE-2026-63922CVE-2026-63940CVE-2026-63921CVE-2026-63919CVE-2026-63917CVE-2026-63944CVE-2026-63916CVE-2026-63915CVE-2026-63914CVE-2026-63945CVE-2026-53368CVE-2026-53358CVE-2026-63979CVE-2026-63974CVE-2026-63978CVE-2026-63947CVE-2026-63948CVE-2026-63952CVE-2026-63976CVE-2026-63980CVE-2026-53361CVE-2026-63975CVE-2026-53357CVE-2026-63946CVE-2026-53355CVE-2026-53354CVE-2026-53284、 、 、 CVE-2026-64087CVE-2026-64025CVE-2026-64029CVE-2026-64032CVE-2026-64018CVE-2026-64034CVE-2026-64033CVE-2026-64039CVE-2026-64046CVE-2026-64047CVE-2026-64048CVE-2026-64051CVE-2026-64015CVE-2026-64056CVE-2026-64055CVE-2026-64064CVE-2026-64073CVE-2026-64076CVE-2026-64077CVE-2026-64082CVE-2026-64011CVE-2026-64084CVE-2026-64083CVE-2026-64085CVE-2026-64086CVE-2026-64088CVE-2026-64102CVE-2026-64099CVE-2026-64098CVE-2026-64103CVE-2026-64097CVE-2026-64096CVE-2026-64093CVE-2026-64106CVE-2026-64092CVE-2026-64091CVE-2026-64089CVE-2026-64108CVE-2026-64010CVE-2026-64000CVE-2026-64118CVE-2026-64114CVE-2026-64117CVE-2026-64111CVE-2026-64112CVE-2026-64113CVE-2026-64116CVE-2026-64121CVE-2026-64007CVE-2026-64115CVE-2026-63994CVE-2026-64109CVE-2026-63993CVE-2026-63992CVE-2026-63984、 、 、 CVE-2026-64191CVE-2026-64144CVE-2026-64147CVE-2026-64148CVE-2026-64138CVE-2026-64155CVE-2026-64153CVE-2026-64160CVE-2026-64163CVE-2026-64165CVE-2026-64166CVE-2026-64168CVE-2026-64137CVE-2026-64173CVE-2026-64170CVE-2026-64174CVE-2026-64177CVE-2026-64178CVE-2026-64179CVE-2026-64180CVE-2026-64136CVE-2026-64183CVE-2026-64182CVE-2026-64184CVE-2026-64185CVE-2026-64206CVE-2026-64237CVE-2026-64231CVE-2026-64225CVE-2026-64247CVE-2026-64221CVE-2026-64220CVE-2026-64219CVE-2026-64249CVE-2026-64218CVE-2026-64217CVE-2026-64214CVE-2026-64268CVE-2026-64135CVE-2026-64133CVE-2026-64361CVE-2026-64315CVE-2026-64355CVE-2026-64280CVE-2026-64303CVE-2026-64313CVE-2026-64320CVE-2026-64364CVE-2026-64134CVE-2026-64319CVE-2026-64128CVE-2026-64269CVE-2026-64127CVE-2026-64126CVE-2026-64125、 、 、 CVE-2026-64552CVE-2026-64394CVE-2026-64396CVE-2026-64397CVE-2026-64393CVE-2026-64400CVE-2026-64399CVE-2026-64408CVE-2026-64438CVE-2026-64441CVE-2026-64445CVE-2026-64450CVE-2026-64392CVE-2026-64510CVE-2026-64475CVE-2026-64518CVE-2026-64523CVE-2026-64529CVE-2026-64530CVE-2026-64534CVE-2026-64391CVE-2026-64541CVE-2026-64535CVE-2026-64548CVE-2026-64551CVE-2026-64554CVE-2026-68082CVE-2026-64598CVE-2026-64597CVE-2026-68083CVE-2026-64586CVE-2026-64564CVE-2026-64562CVE-2026-68117CVE-2026-64561CVE-2026-64557CVE-2026-64555CVE-2026-68123CVE-2026-64390CVE-2026-64386CVE-2026-68154CVE-2026-68138CVE-2026-68152CVE-2026-68127CVE-2026-68136CVE-2026-68137CVE-2026-68147CVE-2026-68156CVE-2026-64387CVE-2026-68144CVE-2026-64385CVE-2026-68124CVE-2026-64384CVE-2026-64383CVE-2026-64382、 、 、 CVE-2026-72083CVE-2026-68228CVE-2026-68229CVE-2026-68300CVE-2026-68213CVE-2026-68343CVE-2026-68302CVE-2026-68381CVE-2026-68388CVE-2026-68426CVE-2026-68431CVE-2026-68457CVE-2026-68210CVE-2026-68470CVE-2026-68461CVE-2026-68476CVE-2026-68477CVE-2026-72014CVE-2026-72020CVE-2026-72033CVE-2026-68209CVE-2026-72065CVE-2026-72041CVE-2026-72069CVE-2026-72071CVE-2026-72084CVE-2026-72191CVE-2026-72130CVE-2026-72129CVE-2026-72192CVE-2026-72126CVE-2026-72125CVE-2026-72124CVE-2026-72194CVE-2026-72111CVE-2026-72098CVE-2026-72085CVE-2026-72200CVE-2026-68206CVE-2026-68162CVE-2026-72289CVE-2026-72234CVE-2026-72288CVE-2026-72221CVE-2026-72222CVE-2026-72226CVE-2026-72255CVE-2026-72296CVE-2026-68198CVE-2026-72251CVE-2026-68161CVE-2026-72217CVE-2026-68160CVE-2026-68159CVE-2026-68158、 、 、 CVE-2026-72499CVE-2026-72351CVE-2026-72380CVE-2026-72383CVE-2026-72348CVE-2026-72399CVE-2026-72398CVE-2026-72421CVE-2026-72422CVE-2026-72434CVE-2026-72436CVE-2026-72451CVE-2026-72339CVE-2026-72466CVE-2026-72454CVE-2026-72472CVE-2026-72473CVE-2026-72487CVE-2026-72488CVE-2026-72489CVE-2026-72329CVE-2026-72494CVE-2026-72491CVE-2026-72495CVE-2026-72496CVE-2026-74255CVE-2026-74305CVE-2026-74302CVE-2026-74287CVE-2026-74310CVE-2026-74280CVE-2026-74279CVE-2026-74269CVE-2026-74345CVE-2026-74268CVE-2026-74267CVE-2026-74264CVE-2026-74350CVE-2026-72323CVE-2026-72320CVE-2026-74408CVE-2026-74401CVE-2026-74407CVE-2026-74384CVE-2026-74394CVE-2026-74398CVE-2026-74406CVE-2026-74410CVE-2026-72322CVE-2026-74405CVE-2026-72319CVE-2026-74376CVE-2026-72318CVE-2026-72317CVE-2026-72299、 、 、 CVE-2026-74495CVE-2026-74474CVE-2026-74473CVE-2026-74439CVE-2026-74556CVE-2026-74493CVE-2026-74541CVE-2026-74476CVE-2026-74478CVE-2026-74480CVE-2026-74538CVE-2026-74569CVE-2026-74440CVE-2026-74521CVE-2026-74436CVE-2026-74475CVE-2026-74427CVE-2026-74417CVE-2026-74411

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

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

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

  - 已修复 Linux 内核中的下列漏洞：l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - 已修复 Linux 内核中的下列漏洞：mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs) avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases. (CVE-2024-53079)

  - 已修复 Linux 内核中的下列漏洞：io_uring/kbuf: reallocate buf lists on upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - 已修复 Linux 内核中的下列漏洞：RDMA/bnxt_re: Add sanity checks on rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already freed. (CVE-2025-21901)

  - 已修复 Linux 内核中的下列漏洞：cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
216943	Ubuntu 24.04 LTS：Linux 内核漏洞 (USN-7310-1)	Nessus	Ubuntu Local Security Checks	2025/2/28	2025/9/24	critical
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
352240	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1787305050）	Nessus	Rocky Linux Local Security Checks	2026/9/30	2026/9/30	high
364688	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.2：CLSA-2026：1791741836）	Nessus	Alma Linux Local Security Checks	2026/10/12	2026/10/28	critical
231820	Linux Distros 未修补的漏洞：CVE-2024-49940	Nessus	Misc.	2025/3/6	2026/10/29	medium
348386	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS：Linux 内核（NVIDIA Tegra）漏洞（USN-8781-1）	Nessus	Ubuntu Local Security Checks	2026/9/21	2026/9/21	high
352220	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1787305050）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	high

检测

插件搜索

critical

critical

critical

high

critical

medium

high

high