Fedora Account System
Red Hat Associate
Red Hat Customer
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2026062406-CVE-2026-52943-88f7@gregkh/T
Summary: Please re-check the RHEL impact of CVE-2026-52943 Description: Hello, Red Hat currently lists CVE-2026-52943 as not affecting supported RHEL products. However, a working local privilege escalation exploit has now been publicly released. The exploit achieves root privileges from an unprivileged local user by exploiting a use-after-free in the skbuff MSG_ZEROCOPY handling. The issue is fixed by the following upstream commit: https://github.com/torvalds/linux/commit/98d0912e9f841e5529a5b89a972805f34cb1c69d Fix title: net: skbuff: fix missing zerocopy reference in pskb_carve helpers The public exploit repository is available here: https://github.com/vn-lazyming/CVE-2026-52943 The repository includes executable exploit code and a QEMU reproduction environment. The author reports successful root privilege escalation on: Linux 6.12.89 LTS Oracle Linux 10.1 UEK R8 kernel 6.12.0-202.76.4.2 The vulnerability occurs because pskb_carve_inside_header() and pskb_carve_inside_nonlinear() copy the MSG_ZEROCOPY destructor_arg without incrementing its reference count, allowing ubuf_info_msgzc to be freed while it is still referenced. Could you please confirm whether the vulnerable code path introduced by commit 6fa01cc is absent from the RHEL 8, 9, and 10 kernels? In particular, since RHEL 10 uses a 6.12-based kernel, could you please re-check whether RHEL 10 is genuinely unaffected or whether the upstream fix needs to be backported? Thank you.