Bug 2486985 (CVE-2026-46320)

Summary: CVE-2026-46320 kernel: tap: free page on error paths in tap_get_user_xdp()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's tap driver. This vulnerability occurs in the `tap_get_user_xdp()` function, where allocated memory pages are not properly freed when processing rejected network frames. Specifically, if a frame is shorter than the expected Ethernet header length or if memory allocation fails, the error handling paths do not release the previously allocated page. This oversight can lead to a memory leak, as each rejected frame in a batch can cause one page-frag chunk to be leaked, potentially impacting system stability and performance over time.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-09 13:01:39 UTC
In the Linux kernel, the following vulnerability has been resolved:

tap: free page on error paths in tap_get_user_xdp()

tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,
and returns -ENOMEM when build_skb() fails. Both paths jump to the err
label without freeing the page that vhost_net_build_xdp() allocated for
the frame. tap_sendmsg() discards the per-buffer return value and always
returns 0, so vhost_tx_batch() takes the success path and never frees
the page; each rejected frame in a batch leaks one page-frag chunk.

Free the page on both error paths, before the skb is built. This is the
tap counterpart of the same leak in tun_xdp_one().