From: Simon Horman <horms@kernel.org>
To: bestswngs@gmail.com
Cc: 'Simon Horman' <horms@kernel.org>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, willemb@google.com,
martin.varghese@nokia.com, netdev@vger.kernel.org, xmei5@asu.edu
Subject: Re: [PATCH net] bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
Date: Tue, 28 Apr 2026 17:04:46 +0100 [thread overview]
Message-ID: <20260428160445.1336649-2-horms@kernel.org> (raw)
In-Reply-To: <20260426165350.1663137-2-bestswngs@gmail.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
This commit fixes a NULL pointer dereference in bareudp_fill_metadata_dst()
by adding a check for the socket in the IPv6 path. If the device is down
and the socket is NULL, it now returns -ESHUTDOWN.
> Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths
> in the same driver.
Does the IPv4 path also need to be updated to remain consistent?
While the IPv4 path lookup doesn't use the socket pointer directly, if the
socket is NULL (meaning the device is down), shouldn't the IPv4 path also
return -ESHUTDOWN instead of successfully performing a route lookup?
> diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
> index 0df3208783ad..da5866ba0699 100644
> --- a/drivers/net/bareudp.c
> +++ b/drivers/net/bareudp.c
> @@ -529,6 +529,9 @@ static int bareudp_fill_metadata_dst(struct net_device *dev,
Is it possible for an IPv6 tunnel key to be incorrectly processed as IPv4
earlier in this function?
Looking at the preceding condition in this function:
if (!ipv6_mod_enabled() || ip_tunnel_info_af(info) == AF_INET) {
struct rtable *rt;
...
info->key.u.ipv4.src = saddr;
}
If the IPv6 module is disabled at runtime, but an IPv6 tunnel key is provided
(e.g., via OVS or TC), the code falls back to the IPv4 branch.
Since key->u.ipv4.dst aliases exactly with bytes 4-7 of key->u.ipv6.src due
to the union layout in struct ip_tunnel_key, could this result in an invalid
IPv4 route lookup using portions of the IPv6 source address?
Would it be safer to explicitly reject IPv6 tunnel keys when the IPv6 module
is disabled?
> struct in6_addr saddr;
> struct socket *sock = rcu_dereference(bareudp->sock);
>
> + if (!sock)
> + return -ESHUTDOWN;
> +
> dst = udp_tunnel6_dst_lookup(skb, dev, bareudp->net, sock,
> 0, &saddr, &info->key,
> sport, bareudp->port, info->key.tos,
next prev parent reply other threads:[~2026-04-28 16:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-26 16:53 [PATCH net] bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() Weiming Shi
2026-04-28 5:33 ` Kuniyuki Iwashima
2026-04-28 16:04 ` Simon Horman [this message]
2026-04-29 0:13 ` Kuniyuki Iwashima
2026-04-29 0:18 ` Eric Dumazet
2026-04-29 1:30 ` 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=20260428160445.1336649-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bestswngs@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=martin.varghese@nokia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=xmei5@asu.edu \
/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