Re: [PATCH net v5] net: use skb_header_pointer() only for DODGY TCPv4 GSO skbs

[Guoyu Su <yss2813483011xxl@gmail.com>]

> Perhaps you're running a different repro from the one I used. Which is
> the C repro from the run at commit ca4ee40bf13d.

I reran with the exact ReproC from that run:
https://syzkaller.appspot.com/text?tag=ReproC&x=10e3fe5a580000
(commit ca4ee40bf13d), rebuilt locally, and reran.

> I see that the virtio_net_hdr has hdr_len 106 and csum_start 88.
> Those are fine. Same for your repro?

Yes, same in my run as well:
vnet_hlen=106, vnet_csum_start=88 (first 20 dumps are consistent).

> The question is how skb->network_header can be greater than
> skb->transport_header right after virtio_net_hdr_to_skb.

From my instrumentation on the same skb in packet_snd():
- packet_parse_headers() sets netoff from device L2 layout:
  hard_hlen=172 on ip6gretap0, so netoff=172.
- then virtio NEEDS_CSUM path sets transoff from csum_start:
  transoff=88 (p_off=108).

So for the same skb I consistently see:
- snd_pre_parse / snd_post_parse: headlen=172, netoff=172
- virtio_needs_csum: start=88, needed=108, p_off=108, transoff=88
- gso_dodgy: nhoff=172, headlen=172, netoff=172, transoff=88

I agree early sanity/drop in virtio_net_hdr_to_skb() is preferable if we can
make the check precise. The current patch is only to make gso_features_check()
safe for DODGY packets in the current path.

For reference, skb_dump metadata on that same skb shows:
headroom=4, mac=(4,172), trans=92, net=(176,-84), headlen=172.