Affected: AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: drm/xe: Make dma-fences compliant with the safe access rules (CVE-2025-38703) * kernel: smb: client: let recv_done verify data_offset, data_length and remaining_data_length (CVE-2025-39933) * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277) * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths (CVE-2025-68287) * kernel: libceph: fix potential use-after-free in have_mon_and_osd_map() (CVE-2025-68285)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

Security update for the Linux Kernel

kernel: x86/tdx: Fix "in-kernel MMIO" check kernel: net: af_can: do not leave a dangling sk pointer in can_create() kernel: netfilter: nft_tunnel: fix geneve_opt type confusion addition kernel: Linux kernel: RDMA/rxe use-after-free vulnerability leading to potential arbitrary code execution kernel: Linux kernel: Use-after-free vulnerability in page_pool_recycle_in_ring can lead to arbitrary code execution kernel: Linux kernel: Use-after-free in device mapper due to race condition in zone reporting kernel: drm/xe: Make dma-fences compliant with the safe access rules

Security update for the Linux Kernel

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 124 more

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Make dma-fences compliant with the safe access rules Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access. To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence. For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.