CVE-2025-37799

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp<br /> <br /> vmxnet3 driver&amp;#39;s XDP handling is buggy for packet sizes using ring0 (that<br /> is, packet sizes between 128 - 3k bytes).<br /> <br /> We noticed MTU-related connectivity issues with Cilium&amp;#39;s service load-<br /> balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP<br /> backend service where the XDP LB was doing IPIP encap led to overly large<br /> packet sizes but only for *some* of the packets (e.g. HTTP GET request)<br /> while others (e.g. the prior TCP 3WHS) looked completely fine on the wire.<br /> <br /> In fact, the pcap recording on the backend node actually revealed that the<br /> node with the XDP LB was leaking uninitialized kernel data onto the wire<br /> for the affected packets, for example, while the packets should have been<br /> 152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes<br /> was padded with whatever other data was in that page at the time (e.g. we<br /> saw user/payload data from prior processed packets).<br /> <br /> We only noticed this through an MTU issue, e.g. when the XDP LB node and<br /> the backend node both had the same MTU (e.g. 1500) then the curl request<br /> got dropped on the backend node&amp;#39;s NIC given the packet was too large even<br /> though the IPIP-encapped packet normally would never even come close to<br /> the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let<br /> the curl request succeed (which also indicates that the kernel ignored the<br /> padding, and thus the issue wasn&amp;#39;t very user-visible).<br /> <br /> Commit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager<br /> to also switch xdp_prepare_buff() from rcd-&gt;len to rbi-&gt;len. It really needs<br /> to stick to rcd-&gt;len which is the actual packet length from the descriptor.<br /> The latter we also feed into vmxnet3_process_xdp_small(), by the way, and<br /> it indicates the correct length needed to initialize the xdp-&gt;{data,data_end}<br /> parts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the<br /> relevant part was adapting xdp_init_buff() to address the warning given the<br /> xdp_data_hard_end() depends on xdp-&gt;frame_sz. With that fixed, traffic on<br /> the wire looks good again.