CVE-2024-58099: vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame
Andrew and Nikolay reported connectivity issues with Cilium's service
load-balancing in case of vmxnet3.
If a BPF program for native XDP adds an encapsulation header such as
IPIP and transmits the packet out the same interface, then in case
of vmxnet3 a corrupted packet is being sent and subsequently dropped
on the path.
vmxnet3_xdp_xmit_frame() which is called e.g. via vmxnet3_run_xdp()
through vmxnet3_xdp_xmit_back() calculates an incorrect DMA address:
page = virt_to_page(xdpf->data);
tbi->dma_addr = page_pool_get_dma_addr(page) +
VMXNET3_XDP_HEADROOM;
dma_sync_single_for_device(&adapter->pdev->dev,
tbi->dma_addr, buf_size,
DMA_TO_DEVICE);
The above assumes a fixed offset (VMXNET3_XDP_HEADROOM), but the XDP
BPF program could have moved xdp->data. While the passed buf_size is
correct (xdpf->len), the dma_addr needs to have a dynamic offset which
can be calculated as xdpf->data - (void *)xdpf, that is, xdp->data -
xdp->data_hard_start.
Security readout for executives and security teams
Plain-English summary
A Linux vmxnet3 networking flaw can corrupt and drop packets when native XDP software adds an encapsulation header and sends the packet through the same interface. Reported impact includes connectivity failures in Cilium service load balancing. Exposure requires this specific networking configuration; ordinary systems not using vmxnet3 with this XDP behavior are less likely to be affected.
Executive priority
Treat as high priority for virtualized Kubernetes or service-networking environments matching the trigger conditions, especially where connectivity is business-critical. Use normal kernel maintenance priority elsewhere after confirming exposure. No supplied evidence supports emergency incident response solely for active exploitation.
Technical view
vmxnet3_xdp_xmit_frame() calculated the DMA address using fixed XDP headroom after an XDP BPF program could move the packet-data pointer. The DMA operation could therefore reference the wrong offset, producing corrupted packets. The correction derives the offset dynamically from the packet data and hard-start addresses. The CVE record assigns CVSS 3.1 score 8.6 and CWE-787.
Likely exposure
Prioritize Linux virtual machines using the vmxnet3 driver, native XDP, and BPF programs that add encapsulation such as IPIP before transmitting through the same interface. The supplied record lists affected version entries including 6.6, 6.6.59, 6.11.6, and 6.12, but package and backport status must be confirmed with the applicable Linux distributor.
Exploitation context
The sources document packet corruption and connectivity problems, not malicious exploitation. The CVE is not listed as KEV in the supplied bundle, and no source claims active exploitation. Practical triggering appears configuration-dependent and requires an XDP program that moves packet data before same-interface transmission.
Researcher notes
The central defect is a stale fixed DMA offset: buffer length remained correct, but the DMA start address did not follow the XDP-adjusted data pointer. Researchers should distinguish reproducible packet corruption from evidence of confidentiality impact or exploitation; the supplied narrative demonstrates dropped corrupted traffic but does not document attacks or data disclosure.
Mitigation direction
Identify systems combining vmxnet3, native XDP, encapsulation, and same-interface transmission.
Apply a vendor-supported kernel containing the referenced vmxnet3 correction.
Confirm fixed-package status with the relevant Linux distribution or appliance vendor.
If immediate updating is impossible, avoid the affected XDP transmission path where operationally acceptable.
Validation and detection
Inventory kernel versions and verify whether vmxnet3 is loaded on virtual machines.
Review deployed XDP programs for encapsulation and packet-data pointer adjustments.
Check Cilium and network telemetry for unexplained corruption, drops, or service-connectivity failures.
After updating, confirm the vendor package includes an applicable referenced kernel fix.
Retest affected service-load-balancing traffic and monitor packet-drop indicators.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-787: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-787 · source CWE mapping
Out-of-bounds Write
Out-of-bounds Write represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.