CVE-2026-80841: net/packet: defer vmalloc TX_RING free until skbs finish

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

net/packet: defer vmalloc TX_RING free until skbs finish

AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb
page references preserve page-backed ring blocks after pg_vec is freed,
but they do not preserve a vmalloc mapping.

tpacket_destruct_skb() currently drops the pending reference before
writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the
decrement after those stores. The smp_wmb() in __packet_set_status()
orders the frame stores before the decrement.

Also recheck pending TX frames under pg_vec_lock before non-closing
ring replacement, so a racing send cannot add a pending skb between
the initial check and the ring swap.

Ring allocation can produce a mixture of page-backed and vmalloc-backed
blocks. Allocate deferred-work storage during TX ring setup when the
first vmalloc-backed block is encountered, and keep its pointer in the
pg_vec allocation header. If allocation fails, return -ENOMEM from ring
setup. On socket close, a non-NULL pointer identifies a vmalloc-backed
vector without a scan. If TX skbs remain, defer the whole vector to
system_long_wq.

After pg_vec is detached, a late destructor can skip the pending
decrement. Use socket write-memory accounting as the deferred lifetime
gate instead: an skb remains charged through its final sock_wfree(),
after all ring-frame accesses. The delayed work retains a socket
reference and reschedules itself until no TX skbs remain.

Move pending_refcnt release to packet_sock_destruct() so late skb
destructors and deferred cleanup can safely use it after
packet_release(). Page-backed teardown remains synchronous, and no lock
is added to the TX completion hot path.

The Linux kernel CVE team has assigned CVE-2026-80841 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.14 with commit b013840810c221f2b0cf641d01531526052dc1fb and fixed in 7.1.13 with commit 0189dce07db2dc059ae0570e06758ec4233c6e11
	Issue introduced in 3.14 with commit b013840810c221f2b0cf641d01531526052dc1fb and fixed in 7.2.3 with commit 550d00aa58193fb649a09a9c9e338c685adad784
	Issue introduced in 3.14 with commit b013840810c221f2b0cf641d01531526052dc1fb and fixed in 7.3-rc1 with commit 992cc9f94ca924089a506ba9b327caa9af797529

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-80841
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/packet/af_packet.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/0189dce07db2dc059ae0570e06758ec4233c6e11
	https://git.kernel.org/stable/c/550d00aa58193fb649a09a9c9e338c685adad784
	https://git.kernel.org/stable/c/992cc9f94ca924089a506ba9b327caa9af797529