netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Antoine Tenart <atenart@kernel.org>,
	 davem@davemloft.net,  kuba@kernel.org,  pabeni@redhat.com,
	 edumazet@google.com
Cc: Antoine Tenart <atenart@kernel.org>,
	 steffen.klassert@secunet.com,  netdev@vger.kernel.org
Subject: Re: [PATCH net 1/4] udp: do not accept non-tunnel GSO skbs landing in a tunnel
Date: Sat, 16 Mar 2024 10:05:34 -0400	[thread overview]
Message-ID: <65f5a72e62658_6ef3e294dd@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20240315151722.119628-2-atenart@kernel.org>

Antoine Tenart wrote:
> When rx-udp-gro-forwarding is enabled UDP packets might be GROed when
> being forwarded. If such packets might land in a tunnel this can cause
> various issues and udp_gro_receive makes sure this isn't the case by
> looking for a matching socket. This is performed in
> udp4/6_gro_lookup_skb but only in the current netns. This is an issue
> with tunneled packets when the endpoint is in another netns. In such
> cases the packets will be GROed at the UDP level, which leads to various
> issues later on. The same thing can happen with rx-gro-list.
> 
> We saw this with geneve packets being GROed at the UDP level. In such
> case gso_size is set; later the packet goes through the geneve rx path,
> the geneve header is pulled, the offset are adjusted and frag_list skbs
> are not adjusted with regard to geneve. When those skbs hit
> skb_fragment, it will misbehave. Different outcomes are possible
> depending on what the GROed skbs look like; from corrupted packets to
> kernel crashes.
> 
> One example is a BUG_ON[1] triggered in skb_segment while processing the
> frag_list. Because gso_size is wrong (geneve header was pulled)
> skb_segment thinks there is "geneve header size" of data in frag_list,
> although it's in fact the next packet. The BUG_ON itself has nothing to
> do with the issue. This is only one of the potential issues.
> 
> Looking up for a matching socket in udp_gro_receive is fragile: the
> lookup could be extended to all netns (not speaking about performances)
> but nothing prevents those packets from being modified in between and we
> could still not find a matching socket. It's OK to keep the current
> logic there as it should cover most cases but we also need to make sure
> we handle tunnel packets being GROed too early.
> 
> This is done by extending the checks in udp_unexpected_gso: GSO packets
> lacking the SKB_GSO_UDP_TUNNEL/_CUSM bits and landing in a tunnel must
> be segmented.
> 
> [1] kernel BUG at net/core/skbuff.c:4408!
>     RIP: 0010:skb_segment+0xd2a/0xf70
>     __udp_gso_segment+0xaa/0x560
> 
> Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
> Signed-off-by: Antoine Tenart <atenart@kernel.org>

Reviewed-by: Willem de Bruijn <willemb@google.com>

  parent reply	other threads:[~2024-03-16 14:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-15 15:17 [PATCH net 0/4] gro: various fixes related to UDP tunnels Antoine Tenart
2024-03-15 15:17 ` [PATCH net 1/4] udp: do not accept non-tunnel GSO skbs landing in a tunnel Antoine Tenart
2024-03-15 21:21   ` kernel test robot
2024-03-18 10:03     ` Antoine Tenart
2024-03-15 21:43   ` kernel test robot
2024-03-16 14:05   ` Willem de Bruijn [this message]
2024-03-15 15:17 ` [PATCH net 2/4] gro: fix ownership transfer Antoine Tenart
2024-03-16 15:25   ` Willem de Bruijn
2024-03-18  9:09     ` Antoine Tenart
2024-03-15 15:17 ` [PATCH net 3/4] udp: do not transition UDP fraglist to unnecessary checksum Antoine Tenart
2024-03-15 15:17 ` [PATCH net 4/4] udp: prevent local UDP tunnel packets from being GROed Antoine Tenart
2024-03-16 15:43   ` Willem de Bruijn
2024-03-18  8:43     ` Antoine Tenart

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=65f5a72e62658_6ef3e294dd@willemb.c.googlers.com.notmuch \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=atenart@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.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;
as well as URLs for NNTP newsgroup(s).