netdev - Re: [PATCH net] vxlan: vnifilter: Fix unlocked deletion of default FDB entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8d644855-0d78-4d0f-85c4-b71158b819d3@blackwall.org>
Date: Wed, 23 Apr 2025 17:58:39 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, andrew+netdev@...n.ch, petrm@...dia.com,
 roopa@...dia.com
Subject: Re: [PATCH net] vxlan: vnifilter: Fix unlocked deletion of default
 FDB entry

On 4/23/25 17:51, Ido Schimmel wrote:
> When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
> entry associated with the default remote (assuming one was configured)
> is deleted without holding the hash lock. This is wrong and will result
> in a warning [1] being generated by the lockdep annotation that was
> added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
> 
> Reproducer:
> 
>  # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
>  # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
>  # bridge vni del vni 10010 dev vx0
> 
> Fix by acquiring the hash lock before the deletion and releasing it
> afterwards. Blame the original commit that introduced the issue rather
> than the one that exposed it.
> 
> [1]
> WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
> [...]
> RIP: 0010:vxlan_find_mac+0x17f/0x1a0
> [...]
> Call Trace:
>  <TASK>
>  __vxlan_fdb_delete+0xbe/0x560
>  vxlan_vni_delete_group+0x2ba/0x940
>  vxlan_vni_del.isra.0+0x15f/0x580
>  vxlan_process_vni_filter+0x38b/0x7b0
>  vxlan_vnifilter_process+0x3bb/0x510
>  rtnetlink_rcv_msg+0x2f7/0xb70
>  netlink_rcv_skb+0x131/0x360
>  netlink_unicast+0x426/0x710
>  netlink_sendmsg+0x75a/0xc20
>  __sock_sendmsg+0xc1/0x150
>  ____sys_sendmsg+0x5aa/0x7b0
>  ___sys_sendmsg+0xfc/0x180
>  __sys_sendmsg+0x121/0x1b0
>  do_syscall_64+0xbb/0x1d0
>  entry_SYSCALL_64_after_hwframe+0x4b/0x53
> 
> Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
> I'm sorry, but I only noticed this issue after the recent VXLAN patches
> were applied to net-next. There will be a conflict when merging net into
> net-next, but resolution is trivial. Reference:
> https://github.com/idosch/linux/commit/ed95370ec89cccbf784d5ef5ea4b6fb6fa0daf47.patch
> ---
>  drivers/net/vxlan/vxlan_vnifilter.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Oops, yup. Thanks,
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>