[PATCH 1/2 net v2] net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled

[PATCH 1/2 net v2] 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 replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in
the callers. This is in essence disabling NS/NA suppression when IPv6 is
disabled.

Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
Reported-by: Guruprasad C P <gurucp2005@gmail.com>
Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: use ipv6_mod_enabled() instead of a null check and replace the check
on the caller
---
 net/bridge/br_device.c | 2 +-
 net/bridge/br_input.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index ee01122f466f..f7502e62dd35 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -74,7 +74,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
 	     eth_hdr(skb)->h_proto == htons(ETH_P_RARP)) &&
 	    br_opt_get(br, BROPT_NEIGH_SUPPRESS_ENABLED)) {
 		br_do_proxy_suppress_arp(skb, br, vid, NULL);
-	} else if (IS_ENABLED(CONFIG_IPV6) &&
+	} else if (ipv6_mod_enabled() &&
 		   skb->protocol == htons(ETH_P_IPV6) &&
 		   br_opt_get(br, BROPT_NEIGH_SUPPRESS_ENABLED) &&
 		   pskb_may_pull(skb, sizeof(struct ipv6hdr) +
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 1405f1061a54..2cbae0f9ae1f 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -170,7 +170,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
 	    (skb->protocol == htons(ETH_P_ARP) ||
 	     skb->protocol == htons(ETH_P_RARP))) {
 		br_do_proxy_suppress_arp(skb, br, vid, p);
-	} else if (IS_ENABLED(CONFIG_IPV6) &&
+	} else if (ipv6_mod_enabled() &&
 		   skb->protocol == htons(ETH_P_IPV6) &&
 		   br_opt_get(br, BROPT_NEIGH_SUPPRESS_ENABLED) &&
 		   pskb_may_pull(skb, sizeof(struct ipv6hdr) +
-- 
2.53.0

[PATCH 2/2 net v2] net: vxlan: 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. If an IPv6 packet is injected into the interface,
route_shortcircuit() is called and a NULL pointer dereference happens on
neigh_lookup().

 BUG: kernel NULL pointer dereference, address: 0000000000000380
 Oops: Oops: 0000 [#1] SMP NOPTI
 [...]
 RIP: 0010:neigh_lookup+0x20/0x270
 [...]
 Call Trace:
  <TASK>
  vxlan_xmit+0x638/0x1ef0 [vxlan]
  dev_hard_start_xmit+0x9e/0x2e0
  __dev_queue_xmit+0xbee/0x14e0
  packet_sendmsg+0x116f/0x1930
  __sys_sendto+0x1f5/0x200
  __x64_sys_sendto+0x24/0x30
  do_syscall_64+0x12f/0x1590
  entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fix this by adding an early check on route_shortcircuit() when protocol
is ETH_P_IPV6.

Fixes: e15a00aafa4b ("vxlan: add ipv6 route short circuit support")
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: use ipv6_mod_enabled() instead of a NULL check
---
 drivers/net/vxlan/vxlan_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 05558b6afecd..5fee680e4a8b 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -2130,6 +2130,8 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
 	{
 		struct ipv6hdr *pip6;
 
+		if (!ipv6_mod_enabled())
+			return false;
 		if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
 			return false;
 		pip6 = ipv6_hdr(skb);
-- 
2.53.0

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Sabrina Dubroca]

2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into the interface,
> route_shortcircuit() is called and a NULL pointer dereference happens on
> neigh_lookup().

VXLAN can be built-in even when IPv6 is built as a module, and then
ipv6_mod_enabled can't be used in VXLAN:

ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0): undefined reference to `ipv6_mod_enabled'


GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
("geneve: fix build with modular IPV6"):

    depends on IPV6 || !IPV6

but VXLAN doesn't.

But then I think we don't need to use ipv6_stub at all.

-- 
Sabrina

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
> 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into the interface,
>> route_shortcircuit() is called and a NULL pointer dereference happens on
>> neigh_lookup().
> 
> VXLAN can be built-in even when IPv6 is built as a module, and then
> ipv6_mod_enabled can't be used in VXLAN:
> 
> ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
> drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0): undefined reference to `ipv6_mod_enabled'
> 
> 
> GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
> ("geneve: fix build with modular IPV6"):
> 
>      depends on IPV6 || !IPV6
> 
> but VXLAN doesn't.
>

Ugh, good catch. Thanks Sabrina.

> But then I think we don't need to use ipv6_stub at all.

If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of 
ipv6_stub completely and use direct calls instead.

Would you agree to do as Ido mentioned on v1 and follow neigh_reduce() 
approach (__in6_dev_get()), then on net-next follow-up getting rid of 
ipv6_stub? I think this could be good.

Thanks,
Fernando.

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Ido Schimmel]

On Mon, Mar 02, 2026 at 04:13:14PM +0100, Fernando Fernandez Mancera wrote:
> On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
> > 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into the interface,
> > > route_shortcircuit() is called and a NULL pointer dereference happens on
> > > neigh_lookup().
> > 
> > VXLAN can be built-in even when IPv6 is built as a module, and then
> > ipv6_mod_enabled can't be used in VXLAN:
> > 
> > ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
> > drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0): undefined reference to `ipv6_mod_enabled'
> > 
> > 
> > GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
> > ("geneve: fix build with modular IPV6"):
> > 
> >      depends on IPV6 || !IPV6
> > 
> > but VXLAN doesn't.
> > 
> 
> Ugh, good catch. Thanks Sabrina.
> 
> > But then I think we don't need to use ipv6_stub at all.
> 
> If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of
> ipv6_stub completely and use direct calls instead.

I just noticed that this is already enforced for the bridge, so maybe
you can just remove ipv6_stub in patch #1?

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/2/26 5:36 PM, Ido Schimmel wrote:
> On Mon, Mar 02, 2026 at 04:13:14PM +0100, Fernando Fernandez Mancera wrote:
>> On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
>>> 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into the interface,
>>>> route_shortcircuit() is called and a NULL pointer dereference happens on
>>>> neigh_lookup().
>>>
>>> VXLAN can be built-in even when IPv6 is built as a module, and then
>>> ipv6_mod_enabled can't be used in VXLAN:
>>>
>>> ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
>>> drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0): undefined reference to `ipv6_mod_enabled'
>>>
>>>
>>> GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
>>> ("geneve: fix build with modular IPV6"):
>>>
>>>       depends on IPV6 || !IPV6
>>>
>>> but VXLAN doesn't.
>>>
>>
>> Ugh, good catch. Thanks Sabrina.
>>
>>> But then I think we don't need to use ipv6_stub at all.
>>
>> If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of
>> ipv6_stub completely and use direct calls instead.
> 
> I just noticed that this is already enforced for the bridge, so maybe
> you can just remove ipv6_stub in patch #1?
> 

Yes, after Sabrina mentioned it that was what I planned to do. But on 
VXLAN I want to avoid such patch for net tree as a fix. Instead I 
propose to use the __in6_dev_get() check as neigh_reduce() does. Later, 
do a follow-up patch on net-next tree removing ipv6_stub and enforcing 
"depends on IPV6 || IPV6=n".

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/2/26 6:44 PM, Fernando Fernandez Mancera wrote:
> On 3/2/26 5:36 PM, Ido Schimmel wrote:
>> On Mon, Mar 02, 2026 at 04:13:14PM +0100, Fernando Fernandez Mancera 
>> wrote:
>>> On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
>>>> 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into the 
>>>>> interface,
>>>>> route_shortcircuit() is called and a NULL pointer dereference 
>>>>> happens on
>>>>> neigh_lookup().
>>>>
>>>> VXLAN can be built-in even when IPv6 is built as a module, and then
>>>> ipv6_mod_enabled can't be used in VXLAN:
>>>>
>>>> ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
>>>> drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0): undefined 
>>>> reference to `ipv6_mod_enabled'
>>>>
>>>>
>>>> GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
>>>> ("geneve: fix build with modular IPV6"):
>>>>
>>>>       depends on IPV6 || !IPV6
>>>>
>>>> but VXLAN doesn't.
>>>>
>>>
>>> Ugh, good catch. Thanks Sabrina.
>>>
>>>> But then I think we don't need to use ipv6_stub at all.
>>>
>>> If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of
>>> ipv6_stub completely and use direct calls instead.
>>
>> I just noticed that this is already enforced for the bridge, so maybe
>> you can just remove ipv6_stub in patch #1?
>>
> 
> Yes, after Sabrina mentioned it that was what I planned to do. But on 
> VXLAN I want to avoid such patch for net tree as a fix. Instead I 
> propose to use the __in6_dev_get() check as neigh_reduce() does. Later, 
> do a follow-up patch on net-next tree removing ipv6_stub and enforcing 
> "depends on IPV6 || IPV6=n".
> 

FWIW; removing the ipv6_stub won't keep us from checking 
ipv6_mod_enabled() as ipv6.disable=1 can still be set at booting time 
and therefore nd_tbl will still be non-initialized because ndisc_init() 
and neigh_table_init() are never called.

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Sabrina Dubroca]

2026-03-02, 19:04:14 +0100, Fernando Fernandez Mancera wrote:
> On 3/2/26 6:44 PM, Fernando Fernandez Mancera wrote:
> > On 3/2/26 5:36 PM, Ido Schimmel wrote:
> > > On Mon, Mar 02, 2026 at 04:13:14PM +0100, Fernando Fernandez Mancera
> > > wrote:
> > > > On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
> > > > > 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into
> > > > > > the interface,
> > > > > > route_shortcircuit() is called and a NULL pointer
> > > > > > dereference happens on
> > > > > > neigh_lookup().
> > > > > 
> > > > > VXLAN can be built-in even when IPv6 is built as a module, and then
> > > > > ipv6_mod_enabled can't be used in VXLAN:
> > > > > 
> > > > > ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
> > > > > drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0):
> > > > > undefined reference to `ipv6_mod_enabled'
> > > > > 
> > > > > 
> > > > > GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
> > > > > ("geneve: fix build with modular IPV6"):
> > > > > 
> > > > >       depends on IPV6 || !IPV6
> > > > > 
> > > > > but VXLAN doesn't.
> > > > > 
> > > > 
> > > > Ugh, good catch. Thanks Sabrina.
> > > > 
> > > > > But then I think we don't need to use ipv6_stub at all.
> > > > 
> > > > If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of
> > > > ipv6_stub completely and use direct calls instead.
> > > 
> > > I just noticed that this is already enforced for the bridge, so maybe
> > > you can just remove ipv6_stub in patch #1?
> > > 
> > 
> > Yes, after Sabrina mentioned it that was what I planned to do. But on
> > VXLAN I want to avoid such patch for net tree as a fix. Instead I
> > propose to use the __in6_dev_get() check as neigh_reduce() does.

I'm not convinced __in6_dev_get() makes more sense. It's also pretty
much a random NULL check to me, and at least with checking nd_tbl
directly it's clearly related to the code that follows.

In neigh_reduce(), __in6_dev_get() seems to have been present from the
start, and back then in6_dev was used in the function. Now, it might
easily be removed by a clean-up patch that doesn't notice it's useful.


Should there be a helper ipv6_mod_available() (or a better name) in
net/ipv6/addrconf_core.c (so always available) to wrap those checks in
a way that doesn't rely on Kconfig magic nor non-obvious NULL checks?
(maybe even replacing ipv6_mod_enabled()?)

> > Later,
> > do a follow-up patch on net-next tree removing ipv6_stub and enforcing
> > "depends on IPV6 || IPV6=n".
> > 
> 
> FWIW; removing the ipv6_stub won't keep us from checking ipv6_mod_enabled()
> as ipv6.disable=1 can still be set at booting time and therefore nd_tbl will
> still be non-initialized because ndisc_init() and neigh_table_init() are
> never called.

Ok.

-- 
Sabrina

Re: [PATCH 2/2 net v2] net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/3/26 12:02 AM, Sabrina Dubroca wrote:
> 2026-03-02, 19:04:14 +0100, Fernando Fernandez Mancera wrote:
>> On 3/2/26 6:44 PM, Fernando Fernandez Mancera wrote:
>>> On 3/2/26 5:36 PM, Ido Schimmel wrote:
>>>> On Mon, Mar 02, 2026 at 04:13:14PM +0100, Fernando Fernandez Mancera
>>>> wrote:
>>>>> On 3/2/26 3:43 PM, Sabrina Dubroca wrote:
>>>>>> 2026-03-02, 15:08:47 +0100, 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. If an IPv6 packet is injected into
>>>>>>> the interface,
>>>>>>> route_shortcircuit() is called and a NULL pointer
>>>>>>> dereference happens on
>>>>>>> neigh_lookup().
>>>>>>
>>>>>> VXLAN can be built-in even when IPv6 is built as a module, and then
>>>>>> ipv6_mod_enabled can't be used in VXLAN:
>>>>>>
>>>>>> ld: drivers/net/vxlan/vxlan_core.o: in function `route_shortcircuit':
>>>>>> drivers/net/vxlan/vxlan_core.c:2133:(.text+0x116e0):
>>>>>> undefined reference to `ipv6_mod_enabled'
>>>>>>
>>>>>>
>>>>>> GENEVE has a Kconfig tweak to prevent this since 094be0927ff3
>>>>>> ("geneve: fix build with modular IPV6"):
>>>>>>
>>>>>>        depends on IPV6 || !IPV6
>>>>>>
>>>>>> but VXLAN doesn't.
>>>>>>
>>>>>
>>>>> Ugh, good catch. Thanks Sabrina.
>>>>>
>>>>>> But then I think we don't need to use ipv6_stub at all.
>>>>>
>>>>> If we enforce "depends on IPV6 || IPV6=n" on VXLAN we could get rid of
>>>>> ipv6_stub completely and use direct calls instead.
>>>>
>>>> I just noticed that this is already enforced for the bridge, so maybe
>>>> you can just remove ipv6_stub in patch #1?
>>>>
>>>
>>> Yes, after Sabrina mentioned it that was what I planned to do. But on
>>> VXLAN I want to avoid such patch for net tree as a fix. Instead I
>>> propose to use the __in6_dev_get() check as neigh_reduce() does.
> 
> I'm not convinced __in6_dev_get() makes more sense. It's also pretty
> much a random NULL check to me, and at least with checking nd_tbl
> directly it's clearly related to the code that follows.
> 
> In neigh_reduce(), __in6_dev_get() seems to have been present from the
> start, and back then in6_dev was used in the function. Now, it might
> easily be removed by a clean-up patch that doesn't notice it's useful.
> 

Fair enough, let's just stick to the nd_tbl NULL check for now on VXLAN. 
I will send a patch on net-next tree once this is merged to enforce 
"depends on IPV6 || IPV6=n" and remove ipv6_stub from there.

I hope that sounds good to you all.

> 
> Should there be a helper ipv6_mod_available() (or a better name) in
> net/ipv6/addrconf_core.c (so always available) to wrap those checks in
> a way that doesn't rely on Kconfig magic nor non-obvious NULL checks?
> (maybe even replacing ipv6_mod_enabled()?)
> 

Maybe yes, but not sure if it is worth it. As discussed here [1] 
dropping IPv6 as a module seems like a good idea. Anyway, let's discuss 
that topic there!

[1] https://lore.kernel.org/netdev/20260302171131.28373ccb@kernel.org/

Thanks,
Fernando.

>>> Later,
>>> do a follow-up patch on net-next tree removing ipv6_stub and enforcing
>>> "depends on IPV6 || IPV6=n".
>>>
>>
>> FWIW; removing the ipv6_stub won't keep us from checking ipv6_mod_enabled()
>> as ipv6.disable=1 can still be set at booting time and therefore nd_tbl will
>> still be non-initialized because ndisc_init() and neigh_table_init() are
>> never called.
> 
> Ok.
>