Re: Kernel bug report: unguarded deferred skb_checksum_help() writes corrupt the previously-validated IPv6 fixed header (IPv6 counterpart of commit 6785011f8b16, "ipv4: validate checksum_start before completing checksum")

["Michael S. Tsirkin" <mst@redhat.com>]

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 <mst@redhat.com> 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
> 
>