AI analysis
A flaw in the Linux kernel IPv4 stack allows a packet that already carries bad checksum metadata to reach skb_checksum_help, which can corrupt the network header. It is triggered when such a packet is inside the IPv4 path; the published change validates checksum_start before the checksum is completed as defense in depth, and the note says fuller validation on input is still forthcoming. The kernel description limits the effect to header corruption and related mischief, while the CVSS 3.1 score of 9.3 rates a local, unprivileged attack with changed scope and high confidentiality, integrity, and availability impact. Linux systems whose kernels include the unfixed IPv4 checksum-completion path are in scope, but affected version ranges are not listed. It is not in the CISA KEV catalog and no public proof-of-concept is known.
What to do: Apply the Linux distribution or vendor kernel update that includes the IPv4 checksum_start check before checksum completion, then reboot into that kernel. Prioritize shared, multi-tenant, and container hosts because the published score is a local, unprivileged vector. Do not assume a version number: confirm the fix in the vendor changelog, since this record does not name fixed releases.
Affected
| Linux kernel (IPv4 stack) | — |
Estimated exposure
massOn the order of 1 billion+ Linux devices run the IPv4 path; the actually vulnerable subset is unknown — The Linux kernel with IPv4 is shipped on servers, cloud instances, Android, and embedded devices at a scale of well over a billion installations, but this record does not name vulnerable versions, so the unpatched subset cannot be counted…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
In the Linux kernel, the following vulnerability has been resolved: ipv4: validate checksum_start before completing checksum If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work.