netdev - Re: [PATCH net-next v2 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: <20250613084812.4e945368@kernel.org>
Date: Fri, 13 Jun 2025 08:48:12 -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 v2 00/14] ipmr, ip6mr: Allow MC-routing
 locally-generated MC packets

On Thu, 12 Jun 2025 22:10:34 +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.

Crazy, the leaks are back in NIPA. 100% reproducible it seems, the
patches have been in 3 branches and every time the first run and 
the retry is reporting leaks. I'll try to dig into this a bit,
but I'm gonna set the patches as Deferred in PW in the meantime
to avoid blocking the queue.