netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <razor@blackwall.org>
To: Ido Schimmel <idosch@nvidia.com>, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, andrew+netdev@lunn.ch, horms@kernel.org,
	petrm@nvidia.com, mcremers@cloudbear.nl
Subject: Re: [PATCH net 2/3] vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
Date: Tue, 2 Sep 2025 15:17:15 +0300	[thread overview]
Message-ID: <2e341de1-ec26-4e1f-afdf-4b4854daf38f@blackwall.org> (raw)
In-Reply-To: <20250901065035.159644-3-idosch@nvidia.com>

On 9/1/25 09:50, Ido Schimmel wrote:
> When the "proxy" option is enabled on a VXLAN device, the device will
> suppress ARP requests and IPv6 Neighbor Solicitation messages if it is
> able to reply on behalf of the remote host. That is, if a matching and
> valid neighbor entry is configured on the VXLAN device whose MAC address
> is not behind the "any" remote (0.0.0.0 / ::).
> 
> The code currently assumes that the FDB entry for the neighbor's MAC
> address points to a valid remote destination, but this is incorrect if
> the entry is associated with an FDB nexthop group. This can result in a
> NPD [1][3] which can be reproduced using [2][4].
> 
> Fix by checking that the remote destination exists before dereferencing
> it.
> 
> [1]
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> [...]
> CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
> RIP: 0010:vxlan_xmit+0xb58/0x15f0
> [...]
> Call Trace:
>   <TASK>
>   dev_hard_start_xmit+0x5d/0x1c0
>   __dev_queue_xmit+0x246/0xfd0
>   packet_sendmsg+0x113a/0x1850
>   __sock_sendmsg+0x38/0x70
>   __sys_sendto+0x126/0x180
>   __x64_sys_sendto+0x24/0x30
>   do_syscall_64+0xa4/0x260
>   entry_SYSCALL_64_after_hwframe+0x4b/0x53
> 
> [2]
>   #!/bin/bash
> 
>   ip address add 192.0.2.1/32 dev lo
> 
>   ip nexthop add id 1 via 192.0.2.2 fdb
>   ip nexthop add id 10 group 1 fdb
> 
>   ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
> 
>   ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
> 
>   bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
> 
>   arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
> 
> [3]
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> [...]
> CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014
> RIP: 0010:vxlan_xmit+0x803/0x1600
> [...]
> Call Trace:
>   <TASK>
>   dev_hard_start_xmit+0x5d/0x1c0
>   __dev_queue_xmit+0x246/0xfd0
>   ip6_finish_output2+0x210/0x6c0
>   ip6_finish_output+0x1af/0x2b0
>   ip6_mr_output+0x92/0x3e0
>   ip6_send_skb+0x30/0x90
>   rawv6_sendmsg+0xe6e/0x12e0
>   __sock_sendmsg+0x38/0x70
>   __sys_sendto+0x126/0x180
>   __x64_sys_sendto+0x24/0x30
>   do_syscall_64+0xa4/0x260
>   entry_SYSCALL_64_after_hwframe+0x4b/0x53
> RIP: 0033:0x7f383422ec77
> 
> [4]
>   #!/bin/bash
> 
>   ip address add 2001:db8:1::1/128 dev lo
> 
>   ip nexthop add id 1 via 2001:db8:1::1 fdb
>   ip nexthop add id 10 group 1 fdb
> 
>   ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
> 
>   ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
> 
>   bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
> 
>   ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0
> 
> Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries")
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>   drivers/net/vxlan/vxlan_core.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
> index 0f6a7c89a669..dab864bc733c 100644
> --- a/drivers/net/vxlan/vxlan_core.c
> +++ b/drivers/net/vxlan/vxlan_core.c
> @@ -1877,6 +1877,7 @@ static int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)
>   	n = neigh_lookup(&arp_tbl, &tip, dev);
>   
>   	if (n) {
> +		struct vxlan_rdst *rdst = NULL;
>   		struct vxlan_fdb *f;
>   		struct sk_buff	*reply;
>   
> @@ -1887,7 +1888,9 @@ static int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)
>   
>   		rcu_read_lock();
>   		f = vxlan_find_mac_tx(vxlan, n->ha, vni);
> -		if (f && vxlan_addr_any(&(first_remote_rcu(f)->remote_ip))) {
> +		if (f)
> +			rdst = first_remote_rcu(f);
> +		if (rdst && vxlan_addr_any(&rdst->remote_ip)) {
>   			/* bridge-local neighbor */
>   			neigh_release(n);
>   			rcu_read_unlock();
> @@ -2044,6 +2047,7 @@ static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)
>   	n = neigh_lookup(ipv6_stub->nd_tbl, &msg->target, dev);
>   
>   	if (n) {
> +		struct vxlan_rdst *rdst = NULL;
>   		struct vxlan_fdb *f;
>   		struct sk_buff *reply;
>   
> @@ -2053,7 +2057,9 @@ static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)
>   		}
>   
>   		f = vxlan_find_mac_tx(vxlan, n->ha, vni);
> -		if (f && vxlan_addr_any(&(first_remote_rcu(f)->remote_ip))) {
> +		if (f)
> +			rdst = first_remote_rcu(f);
> +		if (rdst && vxlan_addr_any(&rdst->remote_ip)) {
>   			/* bridge-local neighbor */
>   			neigh_release(n);
>   			goto out;

Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>


  reply	other threads:[~2025-09-02 12:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-01  6:50 [PATCH net 0/3] vxlan: Fix NPDs when using nexthop objects Ido Schimmel
2025-09-01  6:50 ` [PATCH net 1/3] vxlan: Fix NPD when refreshing an FDB entry with a nexthop object Ido Schimmel
2025-09-02 12:16   ` Nikolay Aleksandrov
2025-09-01  6:50 ` [PATCH net 2/3] vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects Ido Schimmel
2025-09-02 12:17   ` Nikolay Aleksandrov [this message]
2025-09-01  6:50 ` [PATCH net 3/3] selftests: net: Add a selftest for VXLAN with FDB nexthop groups Ido Schimmel
2025-09-02 12:17   ` Nikolay Aleksandrov
2025-09-03  0:10 ` [PATCH net 0/3] vxlan: Fix NPDs when using nexthop objects 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=2e341de1-ec26-4e1f-afdf-4b4854daf38f@blackwall.org \
    --to=razor@blackwall.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mcremers@cloudbear.nl \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.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).