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

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

Security Fix(es):

* kernel: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113) * kernel: Linux kernel: Denial of Service due to memory leak in tpm2_load_cmd (CVE-2025-71147) * kernel: flex_proportions: make fprop_new_period() hardirq safe (CVE-2026-23168) * kernel: cxl/port: Fix use after free of parent_port in cxl_detach_ep() (CVE-2026-31530) * kernel: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete (CVE-2026-46116) * kernel: fanotify: fix false positive on permission events (CVE-2026-46150) * kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215) * kernel: drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() (CVE-2026-52976) * kernel: drm/xe/dma-buf: fix UAF with retry loop (CVE-2026-52950) * kernel: ice: fix double-free of tx_buf skb (CVE-2026-53009) * kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071) * kernel: can: bcm: thrtimer use-after-free during RX operation teardown ()

Bug Fix(es) and Enhancement(s):

* nfsd_file slab cache objects remaining on kmem_cache_shutdown during nfsd teardown while running bz1477872 testcase (JIRA:AlmaLinux-173103) * tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [almalinux-10.2.z] (JIRA:AlmaLinux-183975) * [AlmaLinux10-de…

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

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

cxl/port: Fix use after free of parent_port in cxl_detach_ep()

cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing:

First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this:

[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0

Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the…

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

cxl/port: Fix use after free of parent_port in cxl_detach_ep()

cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing:

First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this:

[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0

Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the…

Security update for the Linux Kernel

Affected: Rocky Linux:10: kernel

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

Security Fix(es):

* kernel: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113)

* kernel: Linux kernel: Denial of Service due to memory leak in tpm2_load_cmd (CVE-2025-71147)

* kernel: flex_proportions: make fprop_new_period() hardirq safe (CVE-2026-23168)

* kernel: cxl/port: Fix use after free of parent_port in cxl_detach_ep() (CVE-2026-31530)

* kernel: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete (CVE-2026-46116)

* kernel: fanotify: fix false positive on permission events (CVE-2026-46150)

* kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215)

* kernel: drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() (CVE-2026-52976)

* kernel: drm/xe/dma-buf: fix UAF with retry loop (CVE-2026-52950)

* kernel: ice: fix double-free of tx_buf skb (CVE-2026-53009)

* kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071)

* kernel: can: bcm: thrtimer use-after-free during RX operation teardown ()

Bug Fix(es) and Enhancement(s):

* nfsd_file slab cache objects remaining on kmem_cache_shutdown during nfsd teardown while running bz1477872 testcase (JIRA:Rocky Linux-173103)

* tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [rhel-10.2.z] (JIRA:Rocky Linux-183975)

* [Rocky Linux10-debug]: BUG: KASAN: slab-…

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 140 more

In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use after free of parent_port in cxl_detach_ep() cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing: First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this: []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0 Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the time…

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, andere nicht näher spezifizierte Auswirkungen zu verursachen und möglicherweise Code auszuführen.