All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	David Ahern <dsahern@kernel.org>,
	Eyal Birger <eyal.birger@gmail.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Antony Antony <antony.antony@secunet.com>
Subject: Re: [PATCH net-next] udp: properly deal with xfrm encap and ADDRFORM
Date: Thu, 10 Apr 2025 11:21:04 +0200	[thread overview]
Message-ID: <Z_eNgJBm5RucHjxb@krikkit> (raw)
In-Reply-To: <92bcdb6899145a9a387c8fa9e3ca656642a43634.1744228733.git.pabeni@redhat.com>

2025-04-09, 22:00:56 +0200, Paolo Abeni wrote:
> UDP GRO accounting assumes that the GRO receive callback is always
> set when the UDP tunnel is enabled, but syzkaller proved otherwise,
> leading tot the following splat:
[...]
> 
> Address the issue moving the accounting hook into
> setup_udp_tunnel_sock() and set_xfrm_gro_udp_encap_rcv(), where
> the GRO callback is actually set.
> 
> set_xfrm_gro_udp_encap_rcv() is prone to races with IPV6_ADDRFORM,
> run the relevant setsockopt under the socket lock to ensure using
> consistent values of sk_family and up->encap_type.
> 
> Refactor the GRO callback selection code, to make it clear that
> the function pointer is always initialized.
> 
> Reported-by: syzbot+8c469a2260132cd095c1@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=8c469a2260132cd095c1
> Fixes: 172bf009c18d ("xfrm: Support GRO for IPv4 ESP in UDP encapsulation")
> Fixes: 5d7f5b2f6b935 ("udp_tunnel: use static call for GRO hooks when possible")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

-- 
Sabrina

  reply	other threads:[~2025-04-10  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 20:00 [PATCH net-next] udp: properly deal with xfrm encap and ADDRFORM Paolo Abeni
2025-04-10  9:21 ` Sabrina Dubroca [this message]
2025-04-14 22:57 ` patchwork-bot+netdevbpf

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=Z_eNgJBm5RucHjxb@krikkit \
    --to=sd@queasysnail.net \
    --cc=antony.antony@secunet.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=eyal.birger@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.