Linux Netfilter development
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: pablo@netfilter.org
Cc: netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, horms@kernel.org, fw@strlen.de, ja@ssi.bg
Subject: Re: [PATCH net 7/9] netfilter: arp_tables: remove the 32bit compat interface
Date: Tue, 08 Sep 2026 18:04:02 +0000	[thread overview]
Message-ID: <178889064289.219967.7333044974025476861@kernel.org> (raw)
In-Reply-To: <20260907171732.1407739-8-pablo@netfilter.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 1

- [Low] The arptables 32-bit compat interface is only partially removed.

--

netfilter: arp_tables: remove the 32bit compat interface

This removes all arptables-specific 32-bit compat translation code from
net/ipv4/netfilter/arp_tables.c, drops struct compat_arpt_entry and its
accessor from include/linux/netfilter_arp/arp_tables.h, and updates the
NETFILTER_XTABLES_COMPAT help text to no longer mention arp.

> diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
> index a87e07e80d0de..db307fa49f3f6 100644
> --- a/net/ipv4/netfilter/arp_tables.c
> +++ b/net/ipv4/netfilter/arp_tables.c

[ ... ]

> @@ -811,23 +736,11 @@ static int get_info(struct net *net, void __user *user, const int *len)
>  		return -EFAULT;
>  
>  	name[XT_TABLE_MAXNAMELEN-1] = '\0';
> -#ifdef CONFIG_NETFILTER_XTABLES_COMPAT
> -	if (in_compat_syscall())
> -		xt_compat_lock(NFPROTO_ARP);
> -#endif
>  	t = xt_request_find_table_lock(net, NFPROTO_ARP, name);
>  	if (!IS_ERR(t)) {
>  		struct arpt_getinfo info;
>  		const struct xt_table_info *private = t->private;
> -#ifdef CONFIG_NETFILTER_XTABLES_COMPAT
> -		struct xt_table_info tmp;
>  
> -		if (in_compat_syscall()) {
> -			ret = compat_table_info(private, &tmp);
> -			xt_compat_flush_offsets(NFPROTO_ARP);
> -			private = &tmp;
> -		}
> -#endif
>  		memset(&info, 0, sizeof(info));
>  		info.valid_hooks = t->valid_hooks;
>  		memcpy(info.hook_entry, private->hook_entry,

[ ... ]

> @@ -1432,12 +981,7 @@ static int do_arpt_set_ctl(struct sock *sk, int cmd, sockptr_t arg,
>  
>  	switch (cmd) {
>  	case ARPT_SO_SET_REPLACE:
> -#ifdef CONFIG_NETFILTER_XTABLES_COMPAT
> -		if (in_compat_syscall())
> -			ret = compat_do_replace(sock_net(sk), arg, len);
> -		else
> -#endif
> -			ret = do_replace(sock_net(sk), arg, len);
> +		ret = do_replace(sock_net(sk), arg, len);
>  		break;
>  
>  	case ARPT_SO_SET_ADD_COUNTERS:

[Severity: Low]

Should the two arptables ctl handlers also stop accepting compat callers?
Both do_arpt_set_ctl() and do_arpt_get_ctl() still start with:

	if (!xt_compat_check())
		return -EPERM;

and that helper intentionally lets 32-bit callers continue when
CONFIG_NETFILTER_XTABLES_COMPAT is set:

include/linux/netfilter/x_tables.h:xt_compat_check() {
	if (!in_compat_syscall())
		return true;

	pr_warn_once("%s %s\n",
		     "xtables 32bit compat interface no longer supported",
		     "in namespaces and will be removed soon.");

	if (!capable(CAP_NET_ADMIN))
		return false;
#endif
	return true;
}

So a 32-bit task with CAP_NET_ADMIN now falls straight into the native
handlers, which gives three different behaviours:

ARPT_SO_GET_INFO succeeds and copies out the native xt_table_info values,
since the compat_table_info() rescaling above is gone:

		memcpy(info.hook_entry, private->hook_entry,
		       sizeof(info.hook_entry));
		memcpy(info.underflow, private->underflow,
		       sizeof(info.underflow));
		info.num_entries = private->number;
		info.size = private->size;

Are those offsets and size still meaningful to a caller that will walk them
using the 32-bit struct arpt_entry layout?

ARPT_SO_SET_REPLACE and ARPT_SO_GET_ENTRIES end up failing with -EINVAL
purely as a side effect of header size arithmetic in do_replace() and
get_entries() (76 vs 80 bytes for the replace header, 36 + size vs
40 + size for the get_entries header) rather than a defined unsupported
error.  Would an explicit rejection be clearer here, for example:

	if (in_compat_syscall())
		return -EOPNOTSUPP;

ARPT_SO_SET_ADD_COUNTERS keeps a working 32-bit ABI, because
do_add_counters() -> xt_copy_counters() still carries its own compat branch
that converts compat_xt_counters_info for every family, NFPROTO_ARP
included:

net/netfilter/x_tables.c:xt_copy_counters() {
#ifdef CONFIG_NETFILTER_XTABLES_COMPAT
	if (in_compat_syscall()) {
		/* structures only differ in size due to alignment */
		struct compat_xt_counters_info compat_tmp;
	...
}

Does "remove the 32bit compat interface" then hold for that sockopt?  If
leaving the shared counter path compat-capable until the other three
flavors are converted is intended, could the commit message say so?

One more asymmetry: the ip_tables, ip6_tables and ebtables ctl handlers
still branch on in_compat_syscall() after the same xt_compat_check() call,
so the shared helper now means "translate" for those flavors and "warn,
then run the native path" for arptables.  Along the same lines, a 32-bit
task without CAP_NET_ADMIN now gets -EPERM plus a warning about a compat
interface that no longer exists for this flavor.

> @@ -1466,12 +1010,7 @@ static int do_arpt_get_ctl(struct sock *sk, int cmd, void __user *user, int *len
>  		break;
>  
>  	case ARPT_SO_GET_ENTRIES:
> -#ifdef CONFIG_NETFILTER_XTABLES_COMPAT
> -		if (in_compat_syscall())
> -			ret = compat_get_entries(sock_net(sk), user, len);
> -		else
> -#endif
> -			ret = get_entries(sock_net(sk), user, len);
> +		ret = get_entries(sock_net(sk), user, len);
>  		break;
>  
>  	case ARPT_SO_GET_REVISION_TARGET: {

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260907171732.1407739-2-pablo%40netfilter.org

  reply	other threads:[~2026-09-08 18:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 17:17 [PATCH net,v2 0/9] Netfilter/IPVS fixes for net Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 1/9] ipvs: reject invalid states in connection template sync records Pablo Neira Ayuso
2026-09-08 21:00   ` patchwork-bot+netdevbpf
2026-09-07 17:17 ` [PATCH net 2/9] ipvs: fix reversed sequence option serialization Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 3/9] netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 4/9] netfilter: cttimeout: prevent UAF during module unload Pablo Neira Ayuso
2026-09-08 18:04   ` netdev-bot+sashiko
2026-09-08 20:24     ` Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 5/9] netfilter: nf_log: unregister loggers before per-net teardown Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 6/9] netfilter: nfnetlink_log: cope with concurrent instance destruction Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 7/9] netfilter: arp_tables: remove the 32bit compat interface Pablo Neira Ayuso
2026-09-08 18:04   ` netdev-bot+sashiko [this message]
2026-09-08 20:32     ` Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 8/9] netfilter: ip6_tables: set F_PROTO when proto value is nonzero Pablo Neira Ayuso
2026-09-08 18:04   ` netdev-bot+sashiko
2026-09-08 20:22     ` Pablo Neira Ayuso
2026-09-08 20:35     ` Pablo Neira Ayuso
2026-09-07 17:17 ` [PATCH net 9/9] netfilter: report NLM_F_DUMP_FILTERED when all is filtered out Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178889064289.219967.7333044974025476861@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=horms@kernel.org \
    --cc=ja@ssi.bg \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox