On Mon, Oct 19, 2026 at 02:36:14PM +0530, Pranjal Kumar Singh wrote: > 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. >
I don't get what this all means What sink side patches? 0/7 of the patches I posted touches what code? I don't think it makes sense to look at that sysctl deep in the net stack, if that is what you are saying. > 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
