Netdev List
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
	pabeni@redhat.com, stable@vger.kernel.org, maze@google.com,
	shiming.cheng@mediatek.com, daniel@iogearbox.net,
	lena.wang@mediatek.com, herbert@gondor.apana.org.au,
	Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] gso: fix gso fraglist segmentation after pull from frag_list
Date: Wed, 25 Sep 2024 22:59:55 +0200	[thread overview]
Message-ID: <68d4c9cf-f61f-4257-8d98-9a363142cc53@nbd.name> (raw)
In-Reply-To: <66f46003a38a0_65fdc29433@willemb.c.googlers.com.notmuch>

On 25.09.24 21:09, Willem de Bruijn wrote:
> Felix Fietkau wrote:
>> On 22.09.24 17:03, Willem de Bruijn wrote:
>> > From: Willem de Bruijn <willemb@google.com>
>> > 
>> > Detect gso fraglist skbs with corrupted geometry (see below) and
>> > pass these to skb_segment instead of skb_segment_list, as the first
>> > can segment them correctly.
>> > 
>> > Valid SKB_GSO_FRAGLIST skbs
>> > - consist of two or more segments
>> > - the head_skb holds the protocol headers plus first gso_size
>> > - one or more frag_list skbs hold exactly one segment
>> > - all but the last must be gso_size
>> > 
>> > Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
>> > modify these skbs, breaking these invariants.
>> > 
>> > In extreme cases they pull all data into skb linear. For UDP, this
>> > causes a NULL ptr deref in __udpv4_gso_segment_list_csum at
>> > udp_hdr(seg->next)->dest.
>> > 
>> > Detect invalid geometry due to pull, by checking head_skb size.
>> > Don't just drop, as this may blackhole a destination. Convert to be
>> > able to pass to regular skb_segment.
>> > 
>> > Link: https://lore.kernel.org/netdev/20240428142913.18666-1-shiming.cheng@mediatek.com/
>> > Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
>> > Signed-off-by: Willem de Bruijn <willemb@google.com>
>> > Cc: stable@vger.kernel.org
>> > 
>> > ---
>> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> > index d842303587af..e457fa9143a6 100644
>> > --- a/net/ipv4/udp_offload.c
>> > +++ b/net/ipv4/udp_offload.c
>> > @@ -296,8 +296,16 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>> >   		return NULL;
>> >   	}
>> >   
>> > -	if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST)
>> > -		return __udp_gso_segment_list(gso_skb, features, is_ipv6);
>> > +	if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST) {
>> > +		 /* Detect modified geometry and pass these to skb_segment. */
>> > +		if (skb_pagelen(gso_skb) - sizeof(*uh) == skb_shinfo(gso_skb)->gso_size)
>> > +			return __udp_gso_segment_list(gso_skb, features, is_ipv6);
>> > +
>> > +		 /* Setup csum, as fraglist skips this in udp4_gro_receive. */
>> > +		gso_skb->csum_start = skb_transport_header(gso_skb) - gso_skb->head;
>> > +		gso_skb->csum_offset = offsetof(struct udphdr, check);
>> > +		gso_skb->ip_summed = CHECKSUM_PARTIAL;
>> 
>> I also noticed this uh->check update done by udp4_gro_complete only in 
>> case of non-fraglist GRO:
>> 
>>      if (uh->check)
>>          uh->check = ~udp_v4_check(skb->len - nhoff, iph->saddr,
>>                        iph->daddr, 0);
>> 
>> I didn't see any equivalent in your patch. Is it missing or left out 
>> intentionally?
> 
> Thanks. That was not intentional. I think you're right. Am a bit
> concerned that all this testing did not catch it. Perhaps because
> CHECKSUM_PARTIAL looped to ingress on the same machine is simply
> interpreted as CHECKSUM_UNNECESSARY. Need to look into that.
> 
> If respinning this, I should also change the Fixes to
> 
> Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> 
> Analogous to the eventual TCP fix to
> 
> Fixes: bee88cd5bd83 ("net: add support for segmenting TCP fraglist GSO packets")

In the mean time, I've been working on the TCP side. I managed to
reproduce the issue on one of my devices by routing traffic from
Ethernet to Wifi using your BPF test program.

The following patch makes it work for me for TCP v4. Still need to
test and fix v6.

- Felix

---
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -101,8 +101,20 @@ static struct sk_buff *tcp4_gso_segment(struct sk_buff *skb,
  	if (!pskb_may_pull(skb, sizeof(struct tcphdr)))
  		return ERR_PTR(-EINVAL);
  
-	if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)
-		return __tcp4_gso_segment_list(skb, features);
+	if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST) {
+		struct tcphdr *th = tcp_hdr(skb);
+		const struct iphdr *iph;
+
+		if (skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size)
+			return __tcp4_gso_segment_list(skb, features);
+
+		iph = ip_hdr(skb);
+		skb_shinfo(skb)->gso_type &= ~SKB_GSO_FRAGLIST;
+		skb->csum_start = (unsigned char *)th - skb->head;
+		skb->csum_offset = offsetof(struct tcphdr, check);
+		skb->ip_summed = CHECKSUM_PARTIAL;
+		th->check = ~tcp_v4_check(skb->len, iph->saddr, iph->daddr, 0);
+	}
  
  	if (unlikely(skb->ip_summed != CHECKSUM_PARTIAL)) {
  		const struct iphdr *iph = ip_hdr(skb);


  reply	other threads:[~2024-09-25 21:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 15:03 [PATCH net] gso: fix gso fraglist segmentation after pull from frag_list Willem de Bruijn
2024-09-24 17:47 ` Felix Fietkau
2024-09-24 19:50   ` Willem de Bruijn
2024-09-25  8:10 ` Felix Fietkau
2024-09-25 19:09   ` Willem de Bruijn
2024-09-25 20:59     ` Felix Fietkau [this message]
2024-09-25 21:12       ` Felix Fietkau
2024-09-26  7:19         ` Willem de Bruijn
2024-09-26  7:38           ` Felix Fietkau
2024-09-26  7:45             ` Willem de Bruijn
2024-09-26  7:16       ` Willem de Bruijn
2024-09-26  9:17 ` Felix Fietkau
2024-09-26  9:22   ` Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68d4c9cf-f61f-4257-8d98-9a363142cc53@nbd.name \
    --to=nbd@nbd.name \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=lena.wang@mediatek.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shiming.cheng@mediatek.com \
    --cc=stable@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox