Threats Tagged 'cve-2026-52973'

This is a kernel live patch module which can be loaded by the kpatch command line utility to modify the code of a running kernel. This patch module is targeted for kernel-6.12.0-211.16.1.el10_2. Security Fix(es): * kernel: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry (CVE-2026-43114) * kernel: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath (CVE-2026-43112) * kernel: Linux kernel: Use-After-Free in net/gro due to improper handling of zerocopy skbs (CVE-2026-46323) * kernel: futex: Drop CLONE_THREAD requirement for private default hash alloc (CVE-2026-52973) * kernel: net/sched: act_api: use RCU with deferred freeing for action lifecycle (CVE-2026-53264) 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.

This is a kernel live patch module which can be loaded by the kpatch command line utility to modify the code of a running kernel. This patch module is targeted for kernel-6.12.0-211.16.1.el10_2. Security Fix(es): * kernel: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry (CVE-2026-43114) * kernel: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath (CVE-2026-43112) * kernel: Linux kernel: Use-After-Free in net/gro due to improper handling of zerocopy skbs (CVE-2026-46323) * kernel: futex: Drop CLONE_THREAD requirement for private default hash alloc (CVE-2026-52973) * kernel: net/sched: act_api: use RCU with deferred freeing for action lifecycle (CVE-2026-53264) 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.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: xfrm: Duplicate SPI Handling (CVE-2025-39797) * kernel: lib/buildid: use __kernel_read() for sleepable context (CVE-2026-23002) * kernel: futex: Drop CLONE_THREAD requirement for private default hash alloc (CVE-2026-52973) * kernel: iommu/vt-d: Avoid NULL pointer dereference or refcount corruption (CVE-2026-53281) * kernel: blk-mq: pop cached request if it is usable (CVE-2026-64017) Bug Fix(es) and Enhancement(s): * general protection fault during exportfs / nfsd4_revoke_states [rhel-9.8.z] (JIRA:RHEL-188257) * Enable Pretimeout Watchdog Panic Functionality on x86 [rhel-9.8.z] (JIRA:RHEL-193729) 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.

This security update provides a functional equivalent of RHSA-2026:45114. The original Red Hat(R) advisory is available from the Red Hat web site at https://access.redhat.com/errata/RHSA-2026:45114.

A vulnerability in the Linux kernel futex subsystem related to the CLONE_THREAD requirement for private default hash allocation has been resolved. The issue involved incorrect assumptions about concurrency when sharing memory mappings (mm) in ways other than pthread semantics, leading to use-after-free bugs. This could cause kernel memory corruption and crashes. The vulnerability has been addressed by loosening the check to cover any CLONE_VM clone except vfork, preventing the race conditions. Red Hat has released security updates for Red Hat Enterprise Linux 9 and 10 to fix this issue. The updates require system reboot to take effect.

In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle