From: Fernando Fernandez Mancera <fmancera@suse.de>
To: Ido Schimmel <idosch@nvidia.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, bridge@lists.linux.dev,
roopa@cumulusnetworks.com, horms@kernel.org, pabeni@redhat.com,
edumazet@google.com, davem@davemloft.net, razor@blackwall.org
Subject: Re: [PATCH net] net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled
Date: Mon, 2 Mar 2026 12:24:37 +0100 [thread overview]
Message-ID: <a0f4db13-9f18-4fcb-a6ab-73833cb0de3f@suse.de> (raw)
In-Reply-To: <20260302110838.GA875420@shredder>
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.
prev parent reply other threads:[~2026-03-02 11:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 23:40 [PATCH net] net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled Fernando Fernandez Mancera
2026-02-27 0:09 ` Fernando Fernandez Mancera
2026-02-28 20:30 ` Jakub Kicinski
2026-03-01 18:27 ` Fernando Fernandez Mancera
2026-03-02 11:08 ` Ido Schimmel
2026-03-02 11:24 ` Fernando Fernandez Mancera [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0f4db13-9f18-4fcb-a6ab-73833cb0de3f@suse.de \
--to=fmancera@suse.de \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@cumulusnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox