{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-38413","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2025-04-16T04:51:24.013Z","datePublished":"2025-07-25T13:20:17.394Z","dateUpdated":"2026-08-05T12:01:42.803Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T12:01:42.803Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: xsk: rx: fix the frame's length check\n\nWhen calling buf_to_xdp, the len argument is the frame data's length\nwithout virtio header's length (vi->hdr_len). We check that len with\n\n\txsk_pool_get_rx_frame_size() + vi->hdr_len\n\nto ensure the provided len does not larger than the allocated chunk\nsize. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk,\nwe use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost\nto start placing data from\n\n\thard_start + XDP_PACKET_HEADROOM - vi->hdr_len\nnot\n\thard_start + XDP_PACKET_HEADROOM\n\nBut the first buffer has virtio_header, so the maximum frame's length in\nthe first buffer can only be\n\n\txsk_pool_get_rx_frame_size()\nnot\n\txsk_pool_get_rx_frame_size() + vi->hdr_len\n\nlike in the current check.\n\nThis commit adds an additional argument to buf_to_xdp differentiate\nbetween the first buffer and other ones to correctly calculate the maximum\nframe's length."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","baseScore":7.7,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The malicious input is the used-ring length reported by the virtio-net backend (untrusted hypervisor/host, vDPA/VDUSE backend, or virtio offload hardware), which is local to the guest kernel rather than delivered over the network. A remote network peer cannot trigger it, since a conforming backend can never report more bytes than the posted buffer holds.\nAC:L - The backend fully and deterministically controls the reported length field and can set it to `frame_size + 2*hdr_len` on every received packet; there is no race, no memory-layout dependency, and no condition outside the attacker's control.\nPR:N - The attacking device backend needs no credentials or privileges inside the target guest — the overflow is processed automatically in the virtio-net NAPI RX path with no guest-side authentication or capability check.\nUI:N - No victim action is required; the malformed length is consumed by `virtnet_receive_xsk_buf()` during normal NAPI packet reception once an AF_XDP zero-copy pool is bound to the queue.\nS:U - The out-of-bounds read and the resulting disclosure/crash are confined to the guest kernel that owns the vulnerable driver, so the vulnerable and impacted components share the same security authority.\nC:H - `xdp->data_end` is pushed past the end of the XSK chunk, and `xsk_construct_skb()`/`xsk_append_merge_buffer()` copy that out-of-bounds memory into an skb that is delivered to the guest network stack or retransmitted via XDP_TX/XDP_REDIRECT, leaking adjacent memory repeatedly at packet rate.\nI:N - Both copy destinations (`napi_alloc_skb()` and `napi_alloc_frag()`) are sized from the same inflated length that is copied, so no out-of-bounds write or kernel data modification occurs — the defect is a read-side bounds error only.\nA:H - The umem is a `vmap()` of pinned user pages, so reading past the final chunk lands on a vmalloc guard page and produces an unhandled kernel page fault/oops (and a KASAN BUG on hardened kernels), crashing the guest."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/net/virtio_net.c"],"versions":[{"version":"a4e7ba7027012f009f22a68bcfde670f9298d3a4","lessThan":"892f6ed9a4a38bb3360fdff091b9241cfa105b61","status":"affected","versionType":"git"},{"version":"a4e7ba7027012f009f22a68bcfde670f9298d3a4","lessThan":"6013bb6bc24c2cac3f45b37a15b71b232a5b00ff","status":"affected","versionType":"git"},{"version":"a4e7ba7027012f009f22a68bcfde670f9298d3a4","lessThan":"5177373c31318c3c6a190383bfd232e6cf565c36","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/net/virtio_net.c"],"versions":[{"version":"6.11","status":"affected"},{"version":"0","lessThan":"6.11","status":"unaffected","versionType":"semver"},{"version":"6.12.37","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.15.6","lessThanOrEqual":"6.15.*","status":"unaffected","versionType":"semver"},{"version":"6.16","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.11","versionEndExcluding":"6.12.37"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.11","versionEndExcluding":"6.15.6"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.11","versionEndExcluding":"6.16"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/892f6ed9a4a38bb3360fdff091b9241cfa105b61"},{"url":"https://git.kernel.org/stable/c/6013bb6bc24c2cac3f45b37a15b71b232a5b00ff"},{"url":"https://git.kernel.org/stable/c/5177373c31318c3c6a190383bfd232e6cf565c36"}],"title":"virtio-net: xsk: rx: fix the frame's length check","x_generator":{"engine":"bippy-1.2.0"}}}}