Look up another CVE · open CVE-2026-52943 in the interactive tracker
CVE-2026-52943
net: skbuff: fix missing zerocopy reference in pskb_carve helpers
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-52943 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/core/skbuff.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on net/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-06-24 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.25%, higher than 14.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 5.10.259 | 8dbed691e43a |
| 4.7 | 5.15.210 | 9b40bdc2a329 |
| 4.7 | 6.1.176 | fd470f0a97b8 |
| 4.7 | 6.6.143 | ceafb893b12f |
| 4.7 | 6.12.93 | 2e0e74c59b27 |
| 4.7 | 6.18.35 | 96a4713ae041 |
| 4.7 | 7.0.12 | 474d6c771d79 |
| 4.7 | 7.1 | 98d0912e9f84 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
| DLA-4664-1 | 2026-07-03 | bullseye 5.10.259-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable zerocopy state is created by a local process using TCP MSG_ZEROCOPY; remote RDS/TCP packets can reach pskb_extract() but do not carry local ubuf_info destructor_arg state. A local unprivileged attacker can connect to the in-kernel RDS/TCP listener and send crafted zerocopy TCP data.
- AC:LAttack complexity, low
- The fix commit states the issue is reliably exploitable with a working proof-of-concept, and the trigger is a deterministic missing reference count rather than an attacker-uncontrolled race. The attacker controls the local TCP connection, message layout, zerocopy sends, and repeated triggering.
- PR:LPrivileges required, low
- The attack requires the ability to run local unprivileged code and create ordinary TCP sockets with SO_ZEROCOPY/MSG_ZEROCOPY, which has no capability check. No real root or init-namespace administrative privilege is required.
- UI:NUser interaction, none
- No victim user action is required once the local attacker runs the exploit. The attacker directly drives the socket operations and RDS/TCP receive path.
- S:UScope, unchanged
- The vulnerability is exploited within the kernel and impacts the same kernel security authority. It is a standard local kernel privilege escalation, not a VM escape or cross-scope boundary violation.
- C:HConfidentiality impact, high
- This is a use-after-free of ubuf_info_msgzc reachable through skb zerocopy cleanup, and the fix commit confirms a working full root privilege-escalation exploit. Such kernel UAF exploitation can provide access to protected kernel and process memory.
- I:HIntegrity impact, high
- The stale ubuf_info pointer is later dereferenced through zerocopy completion handling, giving a memory-corruption primitive suitable for control-flow or credential manipulation. The reported exploit achieves full root privilege escalation.
- A:HAvailability impact, high
- The bug produces a KASAN-confirmed slab use-after-free in skb_release_data() and can crash the kernel during skb cleanup. Even without full exploitation, repeated triggering can cause kernel oops/panic-level denial of service.