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

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

[Fernando Fernandez Mancera]

When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never
initialized because inet6_init() exits before ndisc_init() is called
which initializes it. Then, if neigh_suppress is enabled and an ICMPv6
Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will
dereference ipv6_stub->nd_tbl which is NULL, passing it to
neigh_lookup(). This causes a kernel NULL pointer dereference.

 BUG: kernel NULL pointer dereference, address: 0000000000000268
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 [...]
 RIP: 0010:neigh_lookup+0x16/0xe0
 [...]
 Call Trace:
  <IRQ>
  ? neigh_lookup+0x16/0xe0
  br_do_suppress_nd+0x160/0x290 [bridge]
  br_handle_frame_finish+0x500/0x620 [bridge]
  br_handle_frame+0x353/0x440 [bridge]
  __netif_receive_skb_core.constprop.0+0x298/0x1110
  __netif_receive_skb_one_core+0x3d/0xa0
  process_backlog+0xa0/0x140
  __napi_poll+0x2c/0x170
  net_rx_action+0x2c4/0x3a0
  handle_softirqs+0xd0/0x270
  do_softirq+0x3f/0x60

Fix this by adding a check before br_is_local_ip6() or neigh_lookup()
call. If ipv6_stub->nd_tbl is NULL, return immediately.

Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
Note: I am investigating more places where this might be happening too.
---
 net/bridge/br_arp_nd_proxy.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
index 1e2b51769eec..ed756518cee0 100644
--- a/net/bridge/br_arp_nd_proxy.c
+++ b/net/bridge/br_arp_nd_proxy.c
@@ -437,6 +437,12 @@ void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
 		return;
 	}
 
+	/* IPv6 disabled at boot, return before calling into br_is_local_ip6()
+	 * or neigh_lookup()
+	 */
+	if (!ipv6_stub->nd_tbl)
+		return;
+
 	if (vid != 0) {
 		/* build neigh table lookup on the vlan device */
 		vlandev = __vlan_find_dev_deep_rcu(br->dev, skb->vlan_proto,
-- 
2.53.0

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

[Fernando Fernandez Mancera]

On 2/27/26 12:40 AM, Fernando Fernandez Mancera wrote:
> When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never
> initialized because inet6_init() exits before ndisc_init() is called
> which initializes it. Then, if neigh_suppress is enabled and an ICMPv6
> Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will
> dereference ipv6_stub->nd_tbl which is NULL, passing it to
> neigh_lookup(). This causes a kernel NULL pointer dereference.
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000268
>   Oops: 0000 [#1] PREEMPT SMP NOPTI
>   [...]
>   RIP: 0010:neigh_lookup+0x16/0xe0
>   [...]
>   Call Trace:
>    <IRQ>
>    ? neigh_lookup+0x16/0xe0
>    br_do_suppress_nd+0x160/0x290 [bridge]
>    br_handle_frame_finish+0x500/0x620 [bridge]
>    br_handle_frame+0x353/0x440 [bridge]
>    __netif_receive_skb_core.constprop.0+0x298/0x1110
>    __netif_receive_skb_one_core+0x3d/0xa0
>    process_backlog+0xa0/0x140
>    __napi_poll+0x2c/0x170
>    net_rx_action+0x2c4/0x3a0
>    handle_softirqs+0xd0/0x270
>    do_softirq+0x3f/0x60
> 
> Fix this by adding a check before br_is_local_ip6() or neigh_lookup()
> call. If ipv6_stub->nd_tbl is NULL, return immediately.
> 
> Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
> Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> Note: I am investigating more places where this might be happening too.
> ---

I can confirm that there is at least one more instance of this problem. 
Although it is not on bridge driver. I will send a patch ASAP.

Thanks,
Fernando.

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

[Jakub Kicinski]

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?

> Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
> Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/

I think we should also have a Reported-by: in this case?
-- 
pw-bot: cr

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

[Fernando Fernandez Mancera]

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.

>> Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
>> Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/
> 
> I think we should also have a Reported-by: in this case?

Yep, sorry about that. Adding it on the next revision.

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

[Ido Schimmel]

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.

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

[Fernando Fernandez Mancera]

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.