Re: [PATCH 02/13 RFC net-next] net: core: add IPv4 fallback stubs and guards for CONFIG_IPV4=n

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] The `SIOCGIFCONF` ioctl handler returns `-EAFNOSUPPORT` instead of an empty list, breaking UAPI.
- [High] RCU read lock leak in `neigh_xmit()` when CONFIG_IPV4 is disabled.
- [Low] Missing stubs for IPv4 functions called by IPv6 code leads to undefined references.
- [Low] Missing stubs for IP output functions and unconditional `tcp_prot` reference lead to undefined reference linker errors.
- [Low] Undefined reference to `tcp_twsk_unique` in IPv6 hashtables when CONFIG_IPV4 is disabled.
--

--- Patch [2]: [PATCH 02/13 RFC net-next] net: core: add IPv4 fallback stubs and guards for CONFIG_IPV4=n ---
commit c3ba15b9e372b7ea2df4737d8f114c24f3baec0c
Author: Fernando Fernandez Mancera <fmancera@suse.de>

net: core: add IPv4 fallback stubs and guards for CONFIG_IPV4=n

To enable compiling the core network stack without IPv4, generic
networking code must avoid referencing missing IPv4 symbols.

This patch provides static inline stubs in include/net/ip.h and
include/net/route.h that return a proper error code when IPv4 is
disabled. This behaves as IPv6 code does. In addition, it introduces
guards around IPv4 specific code in generic implementations to prevent
undefined reference errors while linking.

> diff --git a/include/net/ip.h b/include/net/ip.h
> index 7f2fe1a8401b1..aeac40d11c725 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
[ ... ]
> @@ -225,27 +235,58 @@ int ip_append_data(struct sock *sk, struct flowi4 *fl4,
[ ... ]
> +static inline void ip_flush_pending_frames(struct sock *sk)
> +{
> +}
> +#endif
> +
> +int ip_generic_getfrag(void *from, char *to, int offset, int len, int odd,
> +		       struct sk_buff *skb);
> +int ip_send_skb(struct net *net, struct sk_buff *skb);
> +int ip_push_pending_frames(struct sock *sk, struct flowi4 *fl4);
> +int ip_queue_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl);

[Severity: Low]
Could these un-stubbed declarations cause undefined reference errors during
linking? 

The declarations for ip_generic_getfrag(), ip_send_skb(),
ip_push_pending_frames(), and ip_queue_xmit() are placed outside the
CONFIG_IPV4 guard without providing static inline stubs. If net/ipv4/af_inet.c
and net/ipv4/udp.c are compiled without CONFIG_IPV4, references to these
functions and tcp_prot will break the build.

Additionally, are there missing stubs for IPv4 functions called directly by the
IPv6 subsystem? When building with CONFIG_IPV6=y and CONFIG_IPV4=n, IPv6 mapped
socket code directly calls IPv4 functions:

net/ipv6/datagram.c:ipv6_mapped_datagram_connect() calls __ip4_datagram_connect()
net/ipv6/tcp_ipv6.c:tcp_v6_connect() calls tcp_v4_connect()
net/ipv6/inet6_hashtables.c:__inet6_check_established() calls tcp_twsk_unique()

Without stubs for these functions, or proper guards in the IPv6 code, the linker
will fail.

> diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
> index a320e264eaaf0..f7ca3701b6bd1 100644
> --- a/net/core/dev_ioctl.c
> +++ b/net/core/dev_ioctl.c
> @@ -39,6 +39,7 @@ static int dev_ifname(struct net *net, struct ifreq *ifr)
>   */
>  int dev_ifconf(struct net *net, struct ifconf __user *uifc)
>  {
> +#if IS_ENABLED(CONFIG_IPV4)
>  	struct net_device *dev;
>  	void __user *pos;
>  	size_t size;
[ ... ]
> @@ -82,6 +83,9 @@ int dev_ifconf(struct net *net, struct ifconf __user *uifc)
>  	rtnl_net_unlock(net);
>  
>  	return put_user(total, &uifc->ifc_len);
> +#else
> +	return -EAFNOSUPPORT;
> +#endif
>  }

[Severity: Critical]
Will this break legacy userspace applications that enumerate interfaces?

By returning -EAFNOSUPPORT instead of an empty list, the behavior changes
for the SIOCGIFCONF ioctl when the kernel is compiled without IPv4.

Could this branch instead return 0 interfaces via put_user(0, &uifc->ifc_len)
to maintain backwards compatibility for tools expecting the ioctl to succeed?

> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 1349c0eedb642..1a40a0ab041b8 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -3208,9 +3208,13 @@ int neigh_xmit(int index, struct net_device *dev,
>  			goto out_kfree_skb;
>  		}
>  		if (index == NEIGH_ARP_TABLE) {
> +#if IS_ENABLED(CONFIG_IPV4)
>  			u32 key = *((u32 *)addr);
>  
>  			neigh = __ipv4_neigh_lookup_noref(dev, key);
> +#else
> +			goto out_kfree_skb;
> +#endif
>  		} else {
>  			neigh = __neigh_lookup_noref(tbl, addr, dev);
>  		}

[Severity: High]
Does this error path leak the RCU read lock?

The function neigh_xmit() acquires the rcu_read_lock() earlier, and this
goto out_kfree_skb jumps directly to the cleanup label, missing the
rcu_read_unlock() call.

Could this stall RCU grace periods if a packet is transmitted where
index == NEIGH_ARP_TABLE when CONFIG_IPV4 is disabled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260712013941.4570-1-fmancera@suse.de?part=2