HIGH Public PoC Introduced in 4.7
net skbuff ZeroCopy UAF
CVE-2026-52943
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI8.4HIGH
01Description
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().
02KernelScan AI Analysis
Risk summary
An unprivileged local user can trigger a use-after-free on the kernel's MSG_ZEROCOPY networking path; the upstream fix states a working proof-of-concept achieves full root privilege escalation on a stock distribution kernel. The flaw lives in core skbuff code compiled into virtually every kernel (CONFIG_NET), but it can only be reached through code that calls pskb_extract() — in practice the RDS-over-TCP transport (CONFIG_RDS + CONFIG_RDS_TCP) or the IPsec IPTFS mode (CONFIG_XFRM_IPTFS). On mainstream distributions RDS ships as an autoloadable module that an unprivileged user can pull in with a single AF_RDS socket, which is what makes the "default kernel" claim hold; builds that omit these modules, blacklist RDS autoload, or run no untrusted local code are not realistically exposed. There is no remote trigger — the attack is local only.
Vulnerability analysis
Root cause: pskb_carve_inside_header() and pskb_carve_inside_nonlinear() relocate a socket buffer and copy its shared-info (including the MSG_ZEROCOPY uarg pointer) into a new buffer without taking a reference on the zero-copy object. Both buffers then share one uarg while only one reference was counted, so on free the reference count reaches zero prematurely, the ubuf_info is freed, and a still-live transmit buffer dereferences it — a use-after-free the upstream commit reports is reliably exploitable to root.
Reachability: the only path into the vulnerable helpers is pskb_extract(), which has just two in-tree callers — the RDS-over-TCP receive path (net/rds/tcp_recv.c, CONFIG_RDS_TCP, which depends on CONFIG_RDS) and the IPsec IPTFS mode (net/xfrm/xfrm_iptfs.c, CONFIG_XFRM_IPTFS). The config mapping is CONFIG_NET because the fix only touches core net/core/skbuff.c; that captures where the vulnerable code lives, not what can drive it. The vulnerable bytes are present in essentially every kernel, but the bug is only reachable when one of those consumers is built.
Of the two, only the RDS path is unprivileged: AF_RDS (address family 21) registers an autoload alias, so socket(AF_RDS, …) makes the kernel load rds.ko on demand for any local user. IPTFS is configured through XFRM/IPsec, which requires CAP_NET_ADMIN, so it does not support the unprivileged-escalation claim. The upstream "default kernel configuration" wording refers to stock distribution kernels (Debian/Ubuntu/Fedora/RHEL/SUSE), which build RDS as a loadable module; it is not in the upstream x86_64 defconfig, where RDS is absent and the bug is not reachable at all.
Exposure and mitigations: a build is realistically affected when (1) CONFIG_RDS_TCP (or CONFIG_XFRM_IPTFS) is compiled, (2) for the unprivileged case, rds.ko autoload is not blocked, and (3) an untrusted local user can run code. The path is closed by any of: not building RDS-over-TCP / IPTFS, blacklisting RDS module autoload, setting kernel.modules_disabled, running under a container runtime that blocks module autoload, or having no untrusted local users. Upgrading to the fixed stable release remains the durable fix.
Exploit availability
KernelScan found public exploit code for this CVE. Open it in the CVE browser to see what we found, where, and how strong the evidence is — that needs a free account with a confirmed email address.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 4.7 | 6.12.93 | 2e0e74c59b27 |
| 7.0 | 4.7 | 7.0.12 | 474d6c771d79 |
| 6.18 | 4.7 | 6.18.35 | 96a4713ae041 |
| mainline | 4.7 | 7.1 | 98d0912e9f84 |
| 6.6 | 4.7 | 6.6.143 | ceafb893b12f |
| 6.1 | 4.7 | 6.1.176 | fd470f0a97b8 |
| 5.10 | 4.7 | 5.10.259 | 8dbed691e43a |
| 5.15 | 4.7 | 5.15.210 | 9b40bdc2a329 |