[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250901134602.53aaef6b@kernel.org>
Date: Mon, 1 Sep 2025 13:46:02 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Florian Westphal <fw@...len.de>
Cc: <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>, "David S.
Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
<netfilter-devel@...r.kernel.org>, pablo@...filter.org
Subject: Re: [PATCH net-next 5/8] netfilter: nf_tables: Introduce
NFTA_DEVICE_PREFIX
On Mon, 1 Sep 2025 10:08:39 +0200 Florian Westphal wrote:
> This new attribute is supposed to be used instead of NFTA_DEVICE_NAME
> for simple wildcard interface specs. It holds a NUL-terminated string
> representing an interface name prefix to match on.
>
> While kernel code to distinguish full names from prefixes in
> NFTA_DEVICE_NAME is simpler than this solution, reusing the existing
> attribute with different semantics leads to confusion between different
> versions of kernel and user space though:
>
> * With old kernels, wildcards submitted by user space are accepted yet
> silently treated as regular names.
> * With old user space, wildcards submitted by kernel may cause crashes
> since libnftnl expects NUL-termination when there is none.
>
> Using a distinct attribute type sanitizes these situations as the
> receiving part detects and rejects the unexpected attribute nested in
> *_HOOK_DEVS attributes.
>
> Fixes: 6d07a289504a ("netfilter: nf_tables: Support wildcard netdev hook specs")
Why is this not targeting net? The sooner we adjust the uAPI the better.
Powered by blists - more mailing lists