cve/2024/CVE-2024-58099.md

### [CVE-2024-58099](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58099)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=54f00cce11786742bd11e5e68c3bf85e6dc048c9%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=6.6%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frameAndrew and Nikolay reported connectivity issues with Cilium's serviceload-balancing in case of vmxnet3.If a BPF program for native XDP adds an encapsulation header such asIPIP and transmits the packet out the same interface, then in caseof vmxnet3 a corrupted packet is being sent and subsequently droppedon 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 XDPBPF program could have moved xdp->data. While the passed buf_size iscorrect (xdpf->len), the dma_addr needs to have a dynamic offset whichcan be calculated as xdpf->data - (void *)xdpf, that is, xdp->data -xdp->data_hard_start.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/ARPSyndicate/cve-scores
- https://github.com/fkie-cad/nvd-json-data-feeds