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

On 3/2/26 12:08 PM, Ido Schimmel wrote:
> 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.

All right, given these arguments let's replace IS_ENABLED(IPV6) with 
ipv6_mod_enabled().

Thank you for all the feedback!
Fernando.