Yes. One 16-bit csum_fold() write at csum_start + csum_offset, always within the packet's own linear data (admission's pskb_may_pull(needed) bounds it), so no OOB, no memory safety issue and no crash; just a previously-validated header field changed after the stack committed to it. With the IPv6 geometry I reported (csum_start in [20, 40) slipping past nh_min_len == 20), the write lands in the fixed IPv6 header only -- dst/src bytes; version, payload length, nexthdr and hop limit (bytes 0-7) are unreachable from that geometry -- and the written value is attacker-derivable (precomputed csum_fold in the reproducer; wire value matched byte for byte, control run intact).
I went through the full v2 series: with 4/7 my geometry is resolved at ingress via the mismatch path (Routing-header parse -> csum_start != thoff -> completed before protocol processing), so the observed window is closed on the virtio-hdr-tested flows and my sink-side patches are superseded for that case. I'll repost them (or thin them further out) as a net-next follow-up to your v3 only for the sysctl opt-out case in 5/7 (knob off = my geometry is admitted fully intact with CHECKSUM_PARTIAL retained and the deferred write happens as before), plus the xt_CHECKSUM v6 / nf_queue / xfrm_output family gates, which 0/7 doesn't touch. On Mon, Oct 19, 2026 at 2:20 PM Michael S. Tsirkin <[email protected]> wrote: > On Mon, Oct 19, 2026 at 02:13:04PM +0530, Pranjal Kumar Singh wrote: > > Hello Security Team, > > > > The IPv4 part of this was fixed some time ago in commit 6785011f8b16 > > ("ipv4: validate checksum_start before completing checksum"): a packet > > whose virtio_net_hdr csum metadata points its checksum start inside the > > IP header makes skb_checksum_help() (the deferred csum completion) > > rewrite the header the stack has already validated (fixed checksum > > offset-width write at csum_start + csum_offset). The IPv6 paths were > > not covered, and they still are not: a 2-patch series mirroring that > > commit for IPv4->IPv6, including its remaining not-yet-IPv6-guarded > > sinks, is reproduced below and attached as patches/0001 and 0002. > > Thanks, I think this has been reported already. Just to clarify, the effect > is just packet header corruption past validation, right? > > See [PATCH net-next v2 0/7] more virtio-net csum hardening > for WIP fixes. > > -- > MST > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
