CVE-2022-50483

published 2025-10-04

CVE-2022-50483: In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before…

Priority P4 20 medium 5.5 CVSS 3.1

AV L AC L PR L UI N S U C N I N A H

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

net: enetc: avoid buffer leaks on xdp_do_redirect() failure

Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software
BD in the RX ring between index orig_i and i can have one of 2 refcount
values on its page.

We are the owner of the current buffer that is being processed, so the
refcount will be at least 1.

If the current owner of the buffer at the diametrically opposed index
in the RX ring (i.o.w, the other half of this page) has not yet called
kfree(), this page's refcount could even be 2.

enetc_page_reusable() in enetc_flip_rx_buff() tests for the page
refcount against 1, and [ if it's 2 ] does not attempt to reuse it.

But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,
the page refcount can have one of 3 values. It can also be 0, if there
is no owner of the other page half, and xdp_do_redirect() for this
buffer ran so far that it triggered a flush of the devmap/cpumap bulk
queue, and the consumers of those bulk queues also freed the buffer,
all by the time xdp_do_redirect() returns the execution back to enetc.

This is the reason why enetc_flip_rx_buff() is called before
xdp_do_redirect(), but there is a big flaw with that reasoning:
enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the
enetc_page_reusable() branch, and if xdp_do_redirect() returns an error,
we call enetc_xdp_free(), which does not deal gracefully with that.

In fact, what happens is quite special. The page refcounts start as 1.
enetc_flip_rx_buff() figures they're reusable, transfers these
rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and
bumps the refcount to 2. When xdp_do_redirect() later returns an error,
we call the no-op enetc_xdp_free(), but we still haven't lost the
reference to that page. A copy of it is still at rx_ring->next_to_alloc,
but that has refcount 2 (and there are no concurrent owners of it in
flight, to drop the refcount). What r

Affected

12 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.1.4-1 (bookworm)	linux 6.1.4-1 (bookworm)
linux	linux	—	—
linux	linux	>= 9d2b68cc108db2fdb35022ed2d88cfb305c441a6 < bcf2c1dc5358dcf7e34a68cdb6b0bbf967801efa	bcf2c1dc5358dcf7e34a68cdb6b0bbf967801efa
linux	linux	>= 9d2b68cc108db2fdb35022ed2d88cfb305c441a6 < 7fba523b51ccce5f7981f8a43ad84d664da68131	7fba523b51ccce5f7981f8a43ad84d664da68131
linux	linux	>= 9d2b68cc108db2fdb35022ed2d88cfb305c441a6 < 306526331e7a37e714e11ab7c6d73eb004745224	306526331e7a37e714e11ab7c6d73eb004745224
linux	linux	>= 9d2b68cc108db2fdb35022ed2d88cfb305c441a6 < 628050ec952d2e2e46ec9fb6aa07e41139e030c8	628050ec952d2e2e46ec9fb6aa07e41139e030c8
linux	linux_kernel	>= 0 < 6.1.4-1	6.1.4-1
linux	linux_kernel	>= 0 < 6.1.4-1	6.1.4-1
linux	linux_kernel	>= 0 < 6.1.4-1	6.1.4-1
linux	linux_kernel	>= 5.13 < 5.15.86	5.15.86
linux	linux_kernel	>= 5.16 < 6.0.16	6.0.16
linux	linux_kernel	>= 6.1 < 6.1.2	6.1.2

CVSS provenance

nvd v3.1 5.5 MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv 5.5 MEDIUM

vendor_debian 5.5 MEDIUM

vendor_redhat 5.5 MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.