netdev - Re: [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing locally-generated MC packets

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: <20250610055856.5ca1558a@kernel.org>
Date: Tue, 10 Jun 2025 05:58:56 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Petr Machata <petrm@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, David Ahern
 <dsahern@...il.com>, <netdev@...r.kernel.org>, Simon Horman
 <horms@...nel.org>, Nikolay Aleksandrov <razor@...ckwall.org>, Ido Schimmel
 <idosch@...dia.com>, <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing
 locally-generated MC packets

On Mon, 9 Jun 2025 22:50:16 +0200 Petr Machata wrote:
> Multicast routing is today handled in the input path. Locally generated MC
> packets don't hit the IPMR code. Thus if a VXLAN remote address is
> multicast, the driver needs to set an OIF during route lookup. In practice
> that means that MC routing configuration needs to be kept in sync with the
> VXLAN FDB and MDB. Ideally, the VXLAN packets would be routed by the MC
> routing code instead.

I think this leads to kmemleaks:

unreferenced object 0xffff88800aabe740 (size 232):
comm "kworker/0:2", pid 471, jiffies 4295215616
hex dump (first 32 bytes):
00 40 df 08 80 88 ff ff 00 f7 5d 98 ff ff ff ff  .@........].....
a1 55 19 95 ff ff ff ff 00 00 00 00 00 00 00 00  .U..............
backtrace (crc b1fabddb):
kmem_cache_alloc_noprof (./include/linux/kmemleak.h:43 mm/slub.c:4152 mm/slub.c:4197 mm/slub.c:4204) 
dst_alloc (net/core/dst.c:89) 
ip6_rt_pcpu_alloc (net/ipv6/route.c:342 net/ipv6/route.c:1419) 
ip6_pol_route (net/ipv6/route.c:1468 net/ipv6/route.c:2305) 
fib6_rule_lookup (./include/net/ip6_fib.h:617 net/ipv6/ip6_fib.c:326) 
ip6_route_output_flags (net/ipv6/route.c:2699) 
ip6_dst_lookup_tail.constprop.0 (net/ipv6/ip6_output.c:1128) 
ip6_dst_lookup_flow (net/ipv6/ip6_output.c:1260) 
udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:165 net/ipv6/ip6_udp_tunnel.c:135) ip6_udp_tunnel 
vxlan_xmit_one (drivers/net/vxlan/vxlan_core.c:2540 (discriminator 4)) vxlan 
vxlan_xmit (drivers/net/vxlan/vxlan_core.c:2809) vxlan 
dev_hard_start_xmit (./include/linux/netdevice.h:5215 ./include/linux/netdevice.h:5224 net/core/dev.c:3830 net/core/dev.c:3846) 
__dev_queue_xmit (net/core/dev.h:356 net/core/dev.c:4714) 
ip6_finish_output2 (./include/net/neighbour.h:539 net/ipv6/ip6_output.c:141) 
ip6_finish_output.constprop.0 (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) 
mld_sendpack (net/ipv6/mcast.c:1872) 

hit by netdevsim udp_tunnel_nic.sh

Also, do you have a branch with the iproute2 patches we could pull 
in the CI?