Re: [PATCH net] net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled

[Ido Schimmel <idosch@nvidia.com>]

On Sun, Mar 01, 2026 at 07:27:56PM +0100, Fernando Fernandez Mancera wrote:
> On 2/28/26 9:30 PM, Jakub Kicinski wrote:
> > On Fri, 27 Feb 2026 00:40:59 +0100 Fernando Fernandez Mancera wrote:
> > > Fix this by adding a check before br_is_local_ip6() or neigh_lookup()
> > > call. If ipv6_stub->nd_tbl is NULL, return immediately.
> > 
> > The problem should probably be fixed by replacing IS_ENABLED(IPV6) in
> > the callers with ipv6_mod_enabled(), rather than randomly sprinkling
> > null checks?
> > 
> 
> I agree about using ipv6__mod_enabled() instead of the NULL check. Thanks
> for that recommendation, although I do not agree with replacing
> IS_ENABLED(IPV6) because here there is some ND message suppression that can
> be applied and at the end bridge should not be look to L3 unless necessary.
> 
> E.g NUD is still being suppressed even if ipv6 is disabled on boot.
> 
> What do you think? Thanks.

I agree with Jakub and I believe it makes sense to not do any NS/NA
suppression when IPv6 is disabled. You are right that some messages can
be suppressed when IPv6 is disabled, but:

1. We are planning to send a patch to prevent the unconditional
suppression of ARP probes (DAD NS). Pending testing.

2. There are some cases where GARP (unsolicited NA) should not be
suppressed (see RFC 9161) and we plan to add a knob to control that.

3. It's unlikely that anyone is actually relying on this behavior.
Blamed commit is from 2017 and we only got a report now.

4. Suppression that can be done without the IPv6 module being loaded can
probably be achieved using stateless egress filters.