KernelScan.io

HIGH

packet TxRing UAF

CVE-2026-98503

CVSS 7.1 / 10.0 KernelScan AI

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

01

In the Linux kernel, the following vulnerability has been resolved: packet: use ubuf_info completion for TX_RING packets tpacket_snd sends skbs with frags pointing into its ring slots. Slots are released when skb->destructor is called. A call to skb_orphan calls skb->destructor before the skb is freed. This can cause the slot to be reused while still linked into the skb. Switch to standard zerocopy completion (ubuf_info) so the slot is only released once all references to the payload are freed or copied. Restore skb->destructor to standard sock_wfree. The ubuf_info completion callback can be called with a NULL skb, but only from net_zcopy_put and related API, used by zerocopy implementations that hold their own reference on the uarg, such as MSG_ZEROCOPY. This uarg is only ever completed from skb_zcopy_clear, so skb is always set. To prevent userspace from aliasing in-flight state on shared ring slots, allocate tpacket_uarg per packet, rather than per slot. This adds a small allocation to the transmit path. Use standard kmalloc to allow backporting to stable kernels. The uarg holds an sk_wmem_alloc reference, rather than an sk_refcnt reference. packet_free_tx_ring waits on sk_wmem_alloc before freeing the ring pages. Always allocate vec->deferred for tx_ring so page-backed rings also wait on sk_wmem_alloc when skb_copy_ubufs drops page refs before calling tpacket_ubuf_complete. Drop the tx_ring.pg_vec test that tpacket_destruct_skb performed before accessing the slot. The sk_wmem_alloc reference now guarantees that the slot is valid. The test is also not sufficient by itself, as it reads pg_vec without pg_vec_lock, so it can race with packet_set_ring. As a result a slot is released when its payload is copied, which can be before transmission (e.g., in skb_orphan_frags_rx). If copied before skb_tx_timestamp() is called, no slot timestamp is recorded, similar to when skb_orphan() was called early in the datapath before this patch. Revert the now unused previous skb_zcopy_.._nouarg infra. Depends on commit 992cc9f94ca9 ("net/packet: defer vmalloc TX_RING free until skbs finish").

02

Engine v0.9.0

Risk summary

A local attacker with CAP_NET_RAW (obtainable in a user namespace) can trigger a use-after-free in the AF_PACKET TX_RING implementation by causing skb_orphan to release a ring slot while the skb still references it. This allows kernel memory corruption, leading to privilege escalation or denial of service. Products running untrusted code in containers or multi-tenant environments are most at risk.

Affectednet/packet/af_packet.c (packet socket TX_RING)

Vulnerability analysis

The AF_PACKET TX_RING code transmits packets by linking skb fragments directly into ring buffer slots. The original design released a slot in the skb destructor, but skb_orphan() invokes the destructor early — before the skb is actually freed — while the skb's fragments still point to that slot. This creates a window where the slot can be reused for a new packet while the old skb still references it, resulting in a use-after-free. The fix replaces the custom destructor with the standard zerocopy completion mechanism (ubuf_info), allocating a per-packet tracking object that holds an sk_wmem_alloc reference. The slot is now released only when all references to the payload are dropped, eliminating the race. The vulnerability is reachable by any local user who can create an AF_PACKET socket with TX_RING enabled (requiring CAP_NET_RAW, available in user namespaces), making it exploitable from containers or unprivileged user namespaces.

03

BranchIntroducedFixed inPatch commit
4.144.14.864.15e67c455d79fb
4.194.19.74.20eda9bcb721f1
6.12—6.12.1122a0c9afefc0e
6.18—6.18.55951840561386
7.2—7.2.9—
mainline—7.3—
cip/6.12—6.12.112-cip33e67c455d79fb

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.112-cip33
cip/4.19Affected — no CIP fix yet (latest 4.19.325-cip136)
cip/4.19-rtAffected — no CIP fix yet (latest 4.19.325-cip136-rt50)