[PATCH net 0/3] {net,bpf}: nd_tbl fixes for when ipv6.disable=1

[PATCH net 0/3] {net,bpf}: nd_tbl fixes for when ipv6.disable=1

[Ricardo B. Marlière]

Hi,

In line with [1] [2], I'm sending these small fixes for similar crashes.

Thanks,
-	Ricardo.

[1] https://lore.kernel.org/netdev/20260227112701.3990-1-fmancera@suse.de
[2] https://lore.kernel.org/netdev/20260226234059.19402-1-fmancera@suse.de

Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
---
Ricardo B. Marlière (3):
      bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled
      bpf: bpf_out_neigh_v6: Fix nd_tbl NULL dereference when IPv6 is disabled
      net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled

 drivers/net/bonding/bond_main.c | 4 ++++
 net/core/filter.c               | 7 +++++++
 2 files changed, 11 insertions(+)
---
base-commit: dabffd08545ffa1d7183bc45e387860984025291
change-id: 20260228-net-nd_tbl_fixes-ce81ca1e0bf2

Best regards,
-- 
Ricardo B. Marlière <rbm@suse.com>

[PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Ricardo B. Marlière]

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 bpf_redirect_neigh() is called from tc with an explicit
nexthop of nh_family == AF_INET6, bpf_out_neigh_v4() takes the AF_INET6
branch and calls ip_neigh_gw6(), which relies on ipv6_stub->nd_tbl.

 BUG: kernel NULL pointer dereference, address: 0000000000000248
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:skb_do_redirect+0xb93/0xf00
 Call Trace:
  <TASK>
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? __tcf_classify.constprop.0+0x83/0x160
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? tcf_classify+0x2b/0x50
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? tc_run+0xb8/0x120
  ? srso_alias_return_thunk+0x5/0xfbef5
  __dev_queue_xmit+0x6fa/0x1000
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? alloc_skb_with_frags+0x58/0x200
  packet_sendmsg+0x10da/0x1700
  ? srso_alias_return_thunk+0x5/0xfbef5
  __sys_sendto+0x1f3/0x220
  __x64_sys_sendto+0x24/0x30
  do_syscall_64+0x101/0xf80
  ? exc_page_fault+0x6e/0x170
  ? srso_alias_return_thunk+0x5/0xfbef5
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  </TASK>

Fix this by adding an early check in the AF_INET6 branch of
bpf_out_neigh_v4(). If ipv6_stub->nd_tbl is NULL, unlock RCU and drop the
packet.

Suggested-by: Fernando Fernandez Mancera <fmancera@suse.de>
Fixes: ba452c9e996d ("bpf: Fix bpf_redirect_neigh helper api to support supplying nexthop")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
---
 net/core/filter.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/core/filter.c b/net/core/filter.c
index 0d5d5a17acb2..9ab2fae3a0d9 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2335,6 +2335,10 @@ static int bpf_out_neigh_v4(struct net *net, struct sk_buff *skb,
 
 		neigh = ip_neigh_for_gw(rt, skb, &is_v6gw);
 	} else if (nh->nh_family == AF_INET6) {
+		if (!ipv6_stub->nd_tbl) {
+			rcu_read_unlock();
+			goto out_drop;
+		}
 		neigh = ip_neigh_gw6(dev, &nh->ipv6_nh);
 		is_v6gw = true;
 	} else if (nh->nh_family == AF_INET) {

-- 
2.53.0

[PATCH net 2/3] bpf: bpf_out_neigh_v6: Fix nd_tbl NULL dereference when IPv6 is disabled

[Ricardo B. Marlière]

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 bpf_redirect_neigh() is called with explicit AF_INET6
nexthop parameters, __bpf_redirect_neigh_v6() can skip the IPv6 FIB lookup
and call bpf_out_neigh_v6() directly. bpf_out_neigh_v6() then calls
ip_neigh_gw6(), which uses ipv6_stub->nd_tbl.

 BUG: kernel NULL pointer dereference, address: 0000000000000248
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:skb_do_redirect+0x44f/0xf40
 Call Trace:
  <TASK>
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? __tcf_classify.constprop.0+0x83/0x160
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? tcf_classify+0x2b/0x50
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? tc_run+0xb8/0x120
  ? srso_alias_return_thunk+0x5/0xfbef5
  __dev_queue_xmit+0x6fa/0x1000
  ? srso_alias_return_thunk+0x5/0xfbef5
  packet_sendmsg+0x10da/0x1700
  ? srso_alias_return_thunk+0x5/0xfbef5
  __sys_sendto+0x1f3/0x220
  __x64_sys_sendto+0x24/0x30
  do_syscall_64+0x101/0xf80
  ? exc_page_fault+0x6e/0x170
  ? srso_alias_return_thunk+0x5/0xfbef5
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  </TASK>

Fix this by adding an early check in bpf_out_neigh_v6(). If
ipv6_stub->nd_tbl is NULL, drop the packet before neighbor lookup.

Suggested-by: Fernando Fernandez Mancera <fmancera@suse.de>
Fixes: ba452c9e996d ("bpf: Fix bpf_redirect_neigh helper api to support supplying nexthop")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
---
 net/core/filter.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/core/filter.c b/net/core/filter.c
index 9ab2fae3a0d9..ad87c40f1393 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2228,6 +2228,9 @@ static int bpf_out_neigh_v6(struct net *net, struct sk_buff *skb,
 			return -ENOMEM;
 	}
 
+	if (!ipv6_stub->nd_tbl)
+		goto out_drop;
+
 	rcu_read_lock();
 	if (!nh) {
 		dst = skb_dst(skb);

-- 
2.53.0

[PATCH net 3/3] net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled

[Ricardo B. Marlière]

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 bonding ARP/NS validation is enabled, an IPv6
NS/NA packet received on a slave can reach bond_validate_na(), which
calls bond_has_this_ip6(). That path calls ipv6_chk_addr() and can
crash in __ipv6_chk_addr_and_flags().

 BUG: kernel NULL pointer dereference, address: 00000000000005d8
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:__ipv6_chk_addr_and_flags+0x69/0x170
 Call Trace:
  <IRQ>
  ipv6_chk_addr+0x1f/0x30
  bond_validate_na+0x12e/0x1d0 [bonding]
  ? __pfx_bond_handle_frame+0x10/0x10 [bonding]
  bond_rcv_validate+0x1a0/0x450 [bonding]
  bond_handle_frame+0x5e/0x290 [bonding]
  ? srso_alias_return_thunk+0x5/0xfbef5
  __netif_receive_skb_core.constprop.0+0x3e8/0xe50
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? update_cfs_rq_load_avg+0x1a/0x240
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? __enqueue_entity+0x5e/0x240
  __netif_receive_skb_one_core+0x39/0xa0
  process_backlog+0x9c/0x150
  __napi_poll+0x30/0x200
  ? srso_alias_return_thunk+0x5/0xfbef5
  net_rx_action+0x338/0x3b0
  handle_softirqs+0xc9/0x2a0
  do_softirq+0x42/0x60
  </IRQ>
  <TASK>
  __local_bh_enable_ip+0x62/0x70
  __dev_queue_xmit+0x2d3/0x1000
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? packet_parse_headers+0x10a/0x1a0
  packet_sendmsg+0x10da/0x1700
  ? kick_pool+0x5f/0x140
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? __queue_work+0x12d/0x4f0
  __sys_sendto+0x1f3/0x220
  __x64_sys_sendto+0x24/0x30
  do_syscall_64+0x101/0xf80
  ? exc_page_fault+0x6e/0x170
  ? srso_alias_return_thunk+0x5/0xfbef5
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  </TASK>

Fix this by adding an early check in bond_confirm_addr6(). If
ipv6_stub->nd_tbl is NULL, return before calling ipv6_chk_addr().

Suggested-by: Fernando Fernandez Mancera <fmancera@suse.de>
Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
---
 drivers/net/bonding/bond_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a1de08ee3815..013d037b644a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -90,6 +90,7 @@
 #include <net/tls.h>
 #endif
 #include <net/ip6_route.h>
+#include <net/ipv6_stubs.h>
 #include <net/netdev_lock.h>
 #include <net/xdp.h>
 
@@ -3251,6 +3252,9 @@ static int bond_confirm_addr6(struct net_device *dev,
 {
 	struct in6_addr *addr = (struct in6_addr *)priv->data;
 
+	if (!ipv6_stub->nd_tbl)
+		return 0;
+
 	return ipv6_chk_addr(dev_net(dev), addr, dev, 0);
 }
 

-- 
2.53.0

Re: [PATCH net 0/3] {net,bpf}: nd_tbl fixes for when ipv6.disable=1

[Fernando Fernandez Mancera]

On 2/28/26 6:46 PM, Ricardo B. Marlière wrote:
> Hi,
> 
> In line with [1] [2], I'm sending these small fixes for similar crashes.
> 
> Thanks,
> -	Ricardo.
> 
> [1] https://lore.kernel.org/netdev/20260227112701.3990-1-fmancera@suse.de
> [2] https://lore.kernel.org/netdev/20260226234059.19402-1-fmancera@suse.de
>
> Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
> ---
> Ricardo B. Marlière (3):
>        bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled
>        bpf: bpf_out_neigh_v6: Fix nd_tbl NULL dereference when IPv6 is disabled
>        net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled
> 
>   drivers/net/bonding/bond_main.c | 4 ++++
>   net/core/filter.c               | 7 +++++++
>   2 files changed, 11 insertions(+)
> ---

Saving some time here for reviews: 
https://lore.kernel.org/netdev/20260301155413.GA755501@shredder/ I guess 
this feedback applies here too.

Re: [PATCH net 3/3] net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled

[Hangbin Liu]

On Sat, Feb 28, 2026 at 02:46:28PM -0300, Ricardo B. Marlière wrote:
> When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never

If it's booting without ipv6 module, maybe we can use ipv6_mod_enabled() to
stop ns validation early. e.g

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a1de08ee3815..be9e01ddd6ac 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3372,7 +3372,7 @@ int bond_rcv_validate(const struct sk_buff *skb, struct bonding *bond,
        } else if (is_arp) {
                return bond_arp_rcv(skb, bond, slave);
 #if IS_ENABLED(CONFIG_IPV6)
-       } else if (is_ipv6) {
+       } else if (is_ipv6 && ipv6_mod_enabled()) {
                return bond_na_rcv(skb, bond, slave);
 #endif
        } else {

Thanks
Hangbin

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Daniel Borkmann]

Hi Ricardo,

On 2/28/26 6:46 PM, Ricardo B. Marlière 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 bpf_redirect_neigh() is called from tc with an explicit
> nexthop of nh_family == AF_INET6, bpf_out_neigh_v4() takes the AF_INET6
> branch and calls ip_neigh_gw6(), which relies on ipv6_stub->nd_tbl.
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000248
>   Oops: Oops: 0000 [#1] SMP NOPTI
>   RIP: 0010:skb_do_redirect+0xb93/0xf00
>   Call Trace:
>    <TASK>
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    ? __tcf_classify.constprop.0+0x83/0x160
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    ? tcf_classify+0x2b/0x50
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    ? tc_run+0xb8/0x120
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    __dev_queue_xmit+0x6fa/0x1000
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    ? alloc_skb_with_frags+0x58/0x200
>    packet_sendmsg+0x10da/0x1700
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    __sys_sendto+0x1f3/0x220
>    __x64_sys_sendto+0x24/0x30
>    do_syscall_64+0x101/0xf80
>    ? exc_page_fault+0x6e/0x170
>    ? srso_alias_return_thunk+0x5/0xfbef5
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
>    </TASK>
> 
> Fix this by adding an early check in the AF_INET6 branch of
> bpf_out_neigh_v4(). If ipv6_stub->nd_tbl is NULL, unlock RCU and drop the
> packet.
> 
> Suggested-by: Fernando Fernandez Mancera <fmancera@suse.de>
> Fixes: ba452c9e996d ("bpf: Fix bpf_redirect_neigh helper api to support supplying nexthop")
> Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
> ---
>   net/core/filter.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 0d5d5a17acb2..9ab2fae3a0d9 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2335,6 +2335,10 @@ static int bpf_out_neigh_v4(struct net *net, struct sk_buff *skb,
>   
>   		neigh = ip_neigh_for_gw(rt, skb, &is_v6gw);
>   	} else if (nh->nh_family == AF_INET6) {
> +		if (!ipv6_stub->nd_tbl) {
> +			rcu_read_unlock();
> +			goto out_drop;
> +		}

Can we just completely get rid of allowing IPv6 as a module?
So either its built-in or not available at all, and then we
can get rid of the stub completely rather than adding checks
in various places which also brings a small performance benefit
of not having indirect calls in some places.

Thanks,
Daniel

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Jakub Kicinski]

On Mon, 2 Mar 2026 06:58:46 +0100 Daniel Borkmann wrote:
> >   	} else if (nh->nh_family == AF_INET6) {
> > +		if (!ipv6_stub->nd_tbl) {
> > +			rcu_read_unlock();
> > +			goto out_drop;
> > +		}  
> 
> Can we just completely get rid of allowing IPv6 as a module?
> So either its built-in or not available at all, and then we
> can get rid of the stub completely rather than adding checks
> in various places which also brings a small performance benefit
> of not having indirect calls in some places.

+1 fwiw, if someone complains we can revert it back in
feels like a complete waste of everyone's time to maintain it
https://lore.kernel.org/all/20260224180544.3c865751@kernel.org/

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/3/26 2:11 AM, Jakub Kicinski wrote:
> On Mon, 2 Mar 2026 06:58:46 +0100 Daniel Borkmann wrote:
>>>    	} else if (nh->nh_family == AF_INET6) {
>>> +		if (!ipv6_stub->nd_tbl) {
>>> +			rcu_read_unlock();
>>> +			goto out_drop;
>>> +		}
>>
>> Can we just completely get rid of allowing IPv6 as a module?
>> So either its built-in or not available at all, and then we
>> can get rid of the stub completely rather than adding checks
>> in various places which also brings a small performance benefit
>> of not having indirect calls in some places.
> 
> +1 fwiw, if someone complains we can revert it back in
> feels like a complete waste of everyone's time to maintain it
> https://lore.kernel.org/all/20260224180544.3c865751@kernel.org/

Dropping IPv6 as a module sounds good to me. I could prepare a patch for 
net-next as RFC to start the discussion/feedback loop.

Anyway, I think we still need to fix these crashes on net tree first.

Thanks,
Fernando.

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Daniel Borkmann]

On 3/3/26 12:18 PM, Fernando Fernandez Mancera wrote:
> On 3/3/26 2:11 AM, Jakub Kicinski wrote:
>> On Mon, 2 Mar 2026 06:58:46 +0100 Daniel Borkmann wrote:
>>>>        } else if (nh->nh_family == AF_INET6) {
>>>> +        if (!ipv6_stub->nd_tbl) {
>>>> +            rcu_read_unlock();
>>>> +            goto out_drop;
>>>> +        }
>>>
>>> Can we just completely get rid of allowing IPv6 as a module?
>>> So either its built-in or not available at all, and then we
>>> can get rid of the stub completely rather than adding checks
>>> in various places which also brings a small performance benefit
>>> of not having indirect calls in some places.
>>
>> +1 fwiw, if someone complains we can revert it back in
>> feels like a complete waste of everyone's time to maintain it
>> https://lore.kernel.org/all/20260224180544.3c865751@kernel.org/
> 
> Dropping IPv6 as a module sounds good to me. I could prepare a patch for net-next as RFC to start the discussion/feedback loop.
> 
> Anyway, I think we still need to fix these crashes on net tree first.
Maybe the "fix" could be to just switch IPV6 from tristate to bool in
the Kconfig, and then once net merges into net-next we could deconstruct
all the helper cruft which makes the late on-demand module loading of
IPv6 work.

If Jakub thinks this is too risky, then sure we can go with the approach
in the patches here (maybe add unlikely to the branches as well), and
the rest would go all via net-next including reverting these ones here
again.

Thanks,
Daniel

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[David Ahern]

On 3/3/26 9:49 PM, Daniel Borkmann wrote:
> Maybe the "fix" could be to just switch IPV6 from tristate to bool in
> the Kconfig, and then once net merges into net-next we could deconstruct
> all the helper cruft which makes the late on-demand module loading of
> IPv6 work.

+1

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Fernando Fernandez Mancera]

On 3/4/26 4:49 PM, David Ahern wrote:
> On 3/3/26 9:49 PM, Daniel Borkmann wrote:
>> Maybe the "fix" could be to just switch IPV6 from tristate to bool in
>> the Kconfig, and then once net merges into net-next we could deconstruct
>> all the helper cruft which makes the late on-demand module loading of
>> IPv6 work.
> 
> +1

Maybe I am missing something here, but I believe this won't solve the 
problem. Even if ipv6 is built-in, it should be possible to pass 
ipv6.disable=1 during boot and therefore nd_tbl would still be 
uninitialized, not NULL tho.

Thanks,
Fernando.

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Daniel Borkmann]

On 3/4/26 5:13 PM, Fernando Fernandez Mancera wrote:
> On 3/4/26 4:49 PM, David Ahern wrote:
>> On 3/3/26 9:49 PM, Daniel Borkmann wrote:
>>> Maybe the "fix" could be to just switch IPV6 from tristate to bool in
>>> the Kconfig, and then once net merges into net-next we could deconstruct
>>> all the helper cruft which makes the late on-demand module loading of
>>> IPv6 work.
>>
>> +1
> 
> Maybe I am missing something here, but I believe this won't solve the problem. Even if ipv6 is built-in, it should be possible to pass ipv6.disable=1 during boot and therefore nd_tbl would still be uninitialized, not NULL tho.
I presume you mean disable_ipv6_mod which then bails out during the module
load process without error, right? It could be deprecated with a warning so
that it turns into a no-op:

diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 31ba677d0442..fdb8648647fd 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -1082,8 +1082,8 @@ static int __init inet6_init(void)
         raw_hashinfo_init(&raw_v6_hashinfo);
  
         if (disable_ipv6_mod) {
-               pr_info("Loaded, but administratively disabled, reboot required to enable\n");
-               goto out;
+               pr_warn("The ipv6.disable module parameter has been deprecated and will be removed in future kernels.\n");
+               disable_ipv6_mod = 0;
         }
  
         err = proto_register(&tcpv6_prot, 1);

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Jakub Kicinski]

On Thu, 5 Mar 2026 02:34:00 +0100 Daniel Borkmann wrote:
> > Maybe I am missing something here, but I believe this won't solve
> > the problem. Even if ipv6 is built-in, it should be possible to
> > pass ipv6.disable=1 during boot and therefore nd_tbl would still be
> > uninitialized, not NULL tho.  
>
> I presume you mean disable_ipv6_mod which then bails out during the module
> load process without error, right? It could be deprecated with a warning so
> that it turns into a no-op:

I believe disabling ipv6 may be legit. Some admins on ipv4 networks may
be paranoid and not want to allow any ipv6 traffic if their "firewalls"
can only understand IPv6? This is just a guess on my side, but I'm less
confident of deprecating the disable knob than =m. I'd be happy if I'm
wrong.

To answer the earlier question -- I would prefer to take the fixes now
and make IPv6 bool in net-next, feels like too big of a change for rc3
:(

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Daniel Borkmann]

On 3/5/26 2:43 AM, Jakub Kicinski wrote:
> On Thu, 5 Mar 2026 02:34:00 +0100 Daniel Borkmann wrote:
>>> Maybe I am missing something here, but I believe this won't solve
>>> the problem. Even if ipv6 is built-in, it should be possible to
>>> pass ipv6.disable=1 during boot and therefore nd_tbl would still be
>>> uninitialized, not NULL tho.
>>
>> I presume you mean disable_ipv6_mod which then bails out during the module
>> load process without error, right? It could be deprecated with a warning so
>> that it turns into a no-op:
> 
> I believe disabling ipv6 may be legit. Some admins on ipv4 networks may
> be paranoid and not want to allow any ipv6 traffic if their "firewalls"
> can only understand IPv6? This is just a guess on my side, but I'm less
> confident of deprecating the disable knob than =m. I'd be happy if I'm
> wrong.
> 
> To answer the earlier question -- I would prefer to take the fixes now
> and make IPv6 bool in net-next, feels like too big of a change for rc3
> :(

Makes sense, I think starting this process via net-next is fine and can be
better justified. Fernando, maybe in that case resend with the unlikely()
added.

Thanks,
Daniel

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Jakub Kicinski]

On Thu, 5 Mar 2026 02:59:27 +0100 Daniel Borkmann wrote:
> >> I presume you mean disable_ipv6_mod which then bails out during the module
> >> load process without error, right? It could be deprecated with a warning so
> >> that it turns into a no-op:  
> > 
> > I believe disabling ipv6 may be legit. Some admins on ipv4 networks may
> > be paranoid and not want to allow any ipv6 traffic if their "firewalls"
> > can only understand IPv6? This is just a guess on my side, but I'm less
> > confident of deprecating the disable knob than =m. I'd be happy if I'm
> > wrong.
> > 
> > To answer the earlier question -- I would prefer to take the fixes now
> > and make IPv6 bool in net-next, feels like too big of a change for rc3
> > :(  
> 
> Makes sense, I think starting this process via net-next is fine and can be
> better justified. Fernando, maybe in that case resend with the unlikely()
> added.

I think Fernando was chiming in because he sent similar patches.
Ricardo, please respin checking ipv6_mod_disabled() ?

Re: [PATCH net 1/3] bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled

[Ricardo B. Marlière]

On Wed Mar 4, 2026 at 11:50 PM -03, Jakub Kicinski wrote:
> On Thu, 5 Mar 2026 02:59:27 +0100 Daniel Borkmann wrote:
>> >> I presume you mean disable_ipv6_mod which then bails out during the module
>> >> load process without error, right? It could be deprecated with a warning so
>> >> that it turns into a no-op:  
>> > 
>> > I believe disabling ipv6 may be legit. Some admins on ipv4 networks may
>> > be paranoid and not want to allow any ipv6 traffic if their "firewalls"
>> > can only understand IPv6? This is just a guess on my side, but I'm less
>> > confident of deprecating the disable knob than =m. I'd be happy if I'm
>> > wrong.
>> > 
>> > To answer the earlier question -- I would prefer to take the fixes now
>> > and make IPv6 bool in net-next, feels like too big of a change for rc3
>> > :(  
>> 
>> Makes sense, I think starting this process via net-next is fine and can be
>> better justified. Fernando, maybe in that case resend with the unlikely()
>> added.
>
> I think Fernando was chiming in because he sent similar patches.
> Ricardo, please respin checking ipv6_mod_disabled() ?

Will do, thank you all for reviewing.