Re: [PATCH 09/11 net-next v5] bpf: remove ipv6_bpf_stub completely and use direct function calls

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 3/25/26 11:40 PM, David Ahern wrote:
> On 3/25/26 2:29 PM, Fernando Fernandez Mancera wrote:
>> Hi Martin,
>>
>> I don't think so. The IS_ENABLED(CONFIG_IPV6) check here is just to
>> prevent an undefined reference when compiling with CONFIG_IPV6=n. Note
>> that this code isn't reachable when ipv6.disable=1 is set during
>> booting, as it would have crashed even before this change because
>> ipv6_stub->nd_tbl is NULL if the IPV6 is disabled since booting.
>>
>> We addressed the vulnerable paths already during this series:
>>
>> https://lore.kernel.org/netdev/20260307-net-nd_tbl_fixes-v4-0-e2677e85628c@suse.com/#
> 
> What about the use case of IPv4 routes with IPv6 nexthop address? Has
> that been tested with a bpf forwarding program?
> 

Hi David, I did the following testing:

1. ipv6.disabled=1 since booting - the IPv6 nexthop cannot be added to 
the IPv4 route at all.

2. ipv6.disabled=1 after booting but before configuring the IPv4 route - 
same result as above.

3. ipv6.disabled=1 after booting and after the IPv4 is configured - the 
neighbor lookup is fine as the nd_tbl is initialized. It didn't crash.

I did tracing to make sure that code path was hit. I tested the 
forwarding with 3 namespaces 1<-->2<-->3 loading the BPF program on the 
second one performing the bpf_fib_lookup() instruction.

I could do more testing regarding this if needed, let me know.

Thanks,
Fernando.