Re: [PATCH] netfilter: nf_tables: allow NFPROTO_INET in nft_(match/target)_validate()

[Ignat Korchagin <ignat@cloudflare.com>]

On Fri, Feb 9, 2024 at 12:38 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> Hi,

Thanks for the prompt reply

> On Fri, Feb 09, 2024 at 12:19:54PM +0000, Ignat Korchagin wrote:
> > Commit 67ee37360d41 ("netfilter: nf_tables: validate NFPROTO_* family") added
> > some validation of NFPROTO_* families in nftables, but it broke our use case for
> > xt_bpf module:
> >
> >   * assuming we have a simple bpf program:
> >
> >     #include <linux/bpf.h>
> >     #include <bpf/bpf_helpers.h>
> >
> >     char _license[] SEC("license") = "GPL";
> >
> >     SEC("socket")
> >     int prog(struct __sk_buff *skb) { return BPF_OK; }
> >
> >   * we can compile it and pin into bpf FS:
> >     bpftool prog load bpf.o /sys/fs/bpf/test
> >
> >   * now we want to create a following table
> >
> >     table inet firewall {
> >         chain input {
> >                 type filter hook prerouting priority filter; policy accept;
> >                 bpf pinned "/sys/fs/bpf/test" drop
>
> This feature does not exist in the tree.

Sorry - should have clarified this. We did indeed patch some userspace
tools to support easy creation of the above table (so it is presented
here for clarity) however we don't have any kernel-specific patches
with respect to this and it is technically possible to craft such a
table via raw netlink interface.

In fact - I just retested it on a freshly compiled 6.6.16 vanilla
kernel from a stable branch (with and without commit 67ee37360d41)
with a small program that does raw netlink messages.

> >         }
> >     }
> >
> > All above used to work, but now we get EOPNOTSUPP, when creating the table.
> >
> > Fix this by allowing NFPROTO_INET for nft_(match/target)_validate()
>
> We don't support inet family for iptables.

I've added Jordan Griege (Jordan, please comment) as he is likely more
competent here than me, but appears that we used it somehow.
For more context - we encountered this problem on 6.1 and 6.6 stable
kernels (when commit 67ee37360d41 was backported).

Ignat