* [PATCH] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables @ 2025-08-29 6:50 Nikolaos Gkarlis 2025-08-29 15:08 ` Florian Westphal 0 siblings, 1 reply; 13+ messages in thread From: Nikolaos Gkarlis @ 2025-08-29 6:50 UTC (permalink / raw) To: netfilter-devel; +Cc: pablo, fw, Nikolaos Gkarlis The kernel accepts netlink messages using the legacy NFT_CT_SRC, NFT_CT_DST keys in inet tables, creating ambiguous conntrack expressions that cannot be properly evaluated during packet processing. When NFPROTO_INET is used with NFT_CT_SRC, NFT_CT_DST the register size calculation defaults to IPv6 (16 bytes) regardless of the actual packet family. This causes two issues: 1. For IPv4 packets, only 4 bytes contain valid address data while 12 bytes contain uninitialized memory during comparison. 2. nft userspace cannot properly display these rules ([invalid type]). The bug is not reproducible through standard nft commands, which properly use NFT_CT_SRC_IP(6), NFT_CT_DST_IP(6) keys instead. Fix by rejecting such expressions with EAFNOSUPPORT when used in inet tables. Signed-off-by: Nikolaos Gkarlis <nickgarlis@gmail.com> --- As an example, packets from 192.0.2.1 (0xc0000201) would also match rules filtering on c000:201:: (0xc0000201000000000000000000000000), which is likely unintended. To my knowledge, the keys NFT_CT_SRC and NFT_CT_DST were never officially used by nft userspace, so I assume rejecting them should be safe. I have tested this change and it appears to work as expected. net/netfilter/nft_ct.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c index d526e69a2..23ce90975 100644 --- a/net/netfilter/nft_ct.c +++ b/net/netfilter/nft_ct.c @@ -439,7 +439,6 @@ static int nft_ct_get_init(const struct nft_ctx *ctx, src.u3.ip); break; case NFPROTO_IPV6: - case NFPROTO_INET: len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip6); break; -- 2.34.1 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-08-29 6:50 [PATCH] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables Nikolaos Gkarlis @ 2025-08-29 15:08 ` Florian Westphal 2025-08-29 21:59 ` Nick Garlis 0 siblings, 1 reply; 13+ messages in thread From: Florian Westphal @ 2025-08-29 15:08 UTC (permalink / raw) To: Nikolaos Gkarlis; +Cc: netfilter-devel, pablo Nikolaos Gkarlis <nickgarlis@gmail.com> wrote: > The kernel accepts netlink messages using the legacy NFT_CT_SRC, > NFT_CT_DST keys in inet tables, creating ambiguous conntrack expressions > that cannot be properly evaluated during packet processing. > > When NFPROTO_INET is used with NFT_CT_SRC, NFT_CT_DST the register size > calculation defaults to IPv6 (16 bytes) regardless of the actual packet > family. > > This causes two issues: > 1. For IPv4 packets, only 4 bytes contain valid address data while 12 > bytes contain uninitialized memory during comparison. > 2. nft userspace cannot properly display these rules ([invalid type]). > > The bug is not reproducible through standard nft commands, which > properly use NFT_CT_SRC_IP(6), NFT_CT_DST_IP(6) keys instead. It breaks nftables .py tests: tests/py/nft-test.py inet/rt.t: OK inet/ct.t: ERROR: line 7: add rule inet test-inet input meta nfproto ipv4 ct original saddr 1.2.3.4: This rule should not have failed. inet/ct.t: OK ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-08-29 15:08 ` Florian Westphal @ 2025-08-29 21:59 ` Nick Garlis 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis 0 siblings, 1 reply; 13+ messages in thread From: Nick Garlis @ 2025-08-29 21:59 UTC (permalink / raw) To: Florian Westphal; +Cc: netfilter-devel, pablo On Fri, Aug 29, 2025 at 5:08 PM Florian Westphal <fw@strlen.de> wrote: > It breaks nftables .py tests: > > tests/py/nft-test.py > inet/rt.t: OK > inet/ct.t: ERROR: line 7: add rule inet test-inet input meta nfproto ipv4 ct original saddr 1.2.3.4: This rule should not have failed. > inet/ct.t: OK Apologies, I didn’t run the nftables Python tests. Thanks for pointing me in the right direction. It seems I mistakenly assumed that NFT_CT_SRC and NFT_CT_DST were never used in inet tables. I’ll look into this further and try to come up with a better approach. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-08-29 21:59 ` Nick Garlis @ 2025-09-02 21:54 ` Nikolaos Gkarlis 2025-09-02 22:21 ` Florian Westphal ` (4 more replies) 0 siblings, 5 replies; 13+ messages in thread From: Nikolaos Gkarlis @ 2025-09-02 21:54 UTC (permalink / raw) To: netfilter-devel; +Cc: pablo, fw, Nikolaos Gkarlis The kernel allows netlink messages that use the legacy NFT_CT_SRC and NFT_CT_DST keys in inet tables without an accompanying nft_meta expression specifying NFT_META_NFPROTO. This results in ambiguous conntrack expressions that cannot be reliably evaluated during packet processing. When that happens, the register size calculation defaults to IPv6 (16 bytes) regardless of the actual packet family. This causes two issues: 1. For IPv4 packets, only 4 bytes contain valid address data while 12 bytes contain uninitialized memory during comparison. 2. nft userspace cannot properly display these rules ([invalid type]). The bug is not reproducible through standard nft commands, which use NFT_CT_SRC_IP(6) and NFT_CT_DST_IP(6) keys when NFT_META_NFPROTO is not defined. Fix by adding a pointer to the parent nft_rule in nft_expr, allowing iteration over preceding expressions to ensure that an nft_meta with NFT_META_NFPROTO has been defined. Signed-off-by: Nikolaos Gkarlis <nickgarlis@gmail.com> --- Adding a pointer from nft_expr to nft_rule may be controversial, but it was the only approach I could come up with that provides context about preceding expressions when validating an expression. I am not certain if this is the best way to handle it, but I am sending the patch for review. Let me know if you would rather this handled another way. include/net/netfilter/nf_tables.h | 2 ++ include/net/netfilter/nft_meta.h | 2 ++ net/netfilter/nf_tables_api.c | 10 +++++++--- net/netfilter/nft_ct.c | 21 +++++++++++++++++++++ net/netfilter/nft_meta.c | 3 ++- 5 files changed, 34 insertions(+), 4 deletions(-) diff --git a/include/net/netfilter/nf_tables.h b/include/net/netfilter/nf_tables.h index 891e43a01bdc..4beb3aa46fe0 100644 --- a/include/net/netfilter/nf_tables.h +++ b/include/net/netfilter/nf_tables.h @@ -403,10 +403,12 @@ struct nft_set_estimate { * struct nft_expr - nf_tables expression * * @ops: expression ops + * @rule: rule this expression is contained in * @data: expression private data */ struct nft_expr { const struct nft_expr_ops *ops; + const struct nft_rule *rule; unsigned char data[] __attribute__((aligned(__alignof__(u64)))); }; diff --git a/include/net/netfilter/nft_meta.h b/include/net/netfilter/nft_meta.h index d602263590fe..93d987de78a6 100644 --- a/include/net/netfilter/nft_meta.h +++ b/include/net/netfilter/nft_meta.h @@ -51,4 +51,6 @@ void nft_meta_inner_eval(const struct nft_expr *expr, struct nft_regs *regs, const struct nft_pktinfo *pkt, struct nft_inner_tun_ctx *tun_ctx); +extern const struct nft_expr_ops nft_meta_get_ops; + #endif diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 58c5425d61c2..eab26b33d80e 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -3500,6 +3500,7 @@ int nft_expr_inner_parse(const struct nft_ctx *ctx, const struct nlattr *nla, } static int nf_tables_newexpr(const struct nft_ctx *ctx, + const struct nft_rule *rule, const struct nft_expr_info *expr_info, struct nft_expr *expr) { @@ -3507,6 +3508,7 @@ static int nf_tables_newexpr(const struct nft_ctx *ctx, int err; expr->ops = ops; + expr->rule = rule; if (ops->init) { err = ops->init(ctx, expr, (const struct nlattr **)expr_info->tb); if (err < 0) @@ -3516,6 +3518,7 @@ static int nf_tables_newexpr(const struct nft_ctx *ctx, return 0; err1: expr->ops = NULL; + expr->rule = NULL; return err; } @@ -3530,6 +3533,7 @@ static void nf_tables_expr_destroy(const struct nft_ctx *ctx, } static struct nft_expr *nft_expr_init(const struct nft_ctx *ctx, + const struct nft_rule *rule, const struct nlattr *nla) { struct nft_expr_info expr_info; @@ -3550,7 +3554,7 @@ static struct nft_expr *nft_expr_init(const struct nft_ctx *ctx, if (expr == NULL) goto err_expr_stateful; - err = nf_tables_newexpr(ctx, &expr_info, expr); + err = nf_tables_newexpr(ctx, rule, &expr_info, expr); if (err < 0) goto err_expr_new; @@ -4339,7 +4343,7 @@ static int nf_tables_newrule(struct sk_buff *skb, const struct nfnl_info *info, expr = nft_expr_first(rule); for (i = 0; i < n; i++) { - err = nf_tables_newexpr(&ctx, &expr_info[i], expr); + err = nf_tables_newexpr(&ctx, rule, &expr_info[i], expr); if (err < 0) { NL_SET_BAD_ATTR(extack, expr_info[i].attr); goto err_release_rule; @@ -6681,7 +6685,7 @@ struct nft_expr *nft_set_elem_expr_alloc(const struct nft_ctx *ctx, struct nft_expr *expr; int err; - expr = nft_expr_init(ctx, attr); + expr = nft_expr_init(ctx, NULL, attr); if (IS_ERR(expr)) return expr; diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c index d526e69a2a2b..b18bd5705872 100644 --- a/net/netfilter/nft_ct.c +++ b/net/netfilter/nft_ct.c @@ -22,6 +22,7 @@ #include <net/netfilter/nf_conntrack_timeout.h> #include <net/netfilter/nf_conntrack_l4proto.h> #include <net/netfilter/nf_conntrack_expect.h> +#include <net/netfilter/nft_meta.h> struct nft_ct_helper_obj { struct nf_conntrack_helper *helper4; @@ -440,6 +441,26 @@ static int nft_ct_get_init(const struct nft_ctx *ctx, break; case NFPROTO_IPV6: case NFPROTO_INET: + const struct nft_expr *curr, *last; + bool meta_nfproto = false; + if (!expr->rule) + return -EINVAL; + + nft_rule_for_each_expr(curr, last, expr->rule) { + if (curr == expr) + break; + + if (curr->ops == &nft_meta_get_ops) { + const struct nft_meta *meta = nft_expr_priv(curr); + if (meta->key == NFT_META_NFPROTO) { + meta_nfproto = true; + break; + } + } + } + if (!meta_nfproto) + return -EINVAL; + len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip6); break; diff --git a/net/netfilter/nft_meta.c b/net/netfilter/nft_meta.c index 05cd1e6e6a2f..aa6bf05e3907 100644 --- a/net/netfilter/nft_meta.c +++ b/net/netfilter/nft_meta.c @@ -767,7 +767,7 @@ bool nft_meta_get_reduce(struct nft_regs_track *track, } EXPORT_SYMBOL_GPL(nft_meta_get_reduce); -static const struct nft_expr_ops nft_meta_get_ops = { +const struct nft_expr_ops nft_meta_get_ops = { .type = &nft_meta_type, .size = NFT_EXPR_SIZE(sizeof(struct nft_meta)), .eval = nft_meta_get_eval, @@ -777,6 +777,7 @@ static const struct nft_expr_ops nft_meta_get_ops = { .validate = nft_meta_get_validate, .offload = nft_meta_get_offload, }; +EXPORT_SYMBOL_GPL(nft_meta_get_ops); static bool nft_meta_set_reduce(struct nft_regs_track *track, const struct nft_expr *expr) -- 2.34.1 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis @ 2025-09-02 22:21 ` Florian Westphal 2025-09-03 9:12 ` Nick Garlis 2025-09-03 10:31 ` Pablo Neira Ayuso ` (3 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Florian Westphal @ 2025-09-02 22:21 UTC (permalink / raw) To: Nikolaos Gkarlis; +Cc: netfilter-devel, pablo Nikolaos Gkarlis <nickgarlis@gmail.com> wrote: > The kernel allows netlink messages that use the legacy NFT_CT_SRC and > NFT_CT_DST keys in inet tables without an accompanying nft_meta > expression specifying NFT_META_NFPROTO. This results in ambiguous > conntrack expressions that cannot be reliably evaluated during packet > processing. > > When that happens, the register size calculation defaults to IPv6 (16 > bytes) regardless of the actual packet family. > > This causes two issues: > 1. For IPv4 packets, only 4 bytes contain valid address data while 12 > bytes contain uninitialized memory during comparison. I don't think so, they are zeroed out, see nf_ct_get_tuple(); init_conntrack copies the entire thing so I don't see how stack garbage can be placed in struct nf_conn and thus I don't see how registers can contains crap. Do they? If yes, please provide a bit more information on how this happens (e.g. kmsan report or similar). > 2. nft userspace cannot properly display these rules ([invalid type]). Thats a userspace bug; userspace that makes use of NFT_CT_SRC/DST must provide the dependency. This is not the kernels job, the kernel only must make sure that we can't crash or otherwise leak hidden state (e.g. kernel memory contents). > The bug is not reproducible through standard nft commands, which use > NFT_CT_SRC_IP(6) and NFT_CT_DST_IP(6) keys when NFT_META_NFPROTO is > not defined. Thats because not all kernel releases have NFT_CT_DST_IP(6), they were added later. Switching userspace will break compatibility with older kernels. That said, this key was added in v4.17 so we could change nftables now to always use NFT_CT_DST_IP(6) instead and avoid adding the NFPROTO implicit dep for this case. > Fix by adding a pointer to the parent nft_rule in nft_expr, allowing > iteration over preceding expressions to ensure that an nft_meta with > NFT_META_NFPROTO has been defined. But why? As far as I can see nothing is broken. We don't force dependencies for other expressions either, why make an exception here? I'm sorry that I did not mention this earlier; in v1 i assumed intent was to zap unused code (but its still used by nft), hence i did not mention the above. > Adding a pointer from nft_expr to nft_rule may be controversial, but > it was the only approach I could come up with that provides context > about preceding expressions when validating an expression. We should not force this unless not doing it causes crash or other misbehaviour, such as leaking private kernel memory content. > struct nft_expr { > const struct nft_expr_ops *ops; > + const struct nft_rule *rule; > unsigned char data[] > __attribute__((aligned(__alignof__(u64)))); Ouch, sorry, I think this is a non-starter, nft_expr should be kept as small as possible. That said, I don't see why its necessary to add this pointer here, it could be provided via nft_ctx for example. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 22:21 ` Florian Westphal @ 2025-09-03 9:12 ` Nick Garlis 2025-09-03 10:13 ` Florian Westphal 0 siblings, 1 reply; 13+ messages in thread From: Nick Garlis @ 2025-09-03 9:12 UTC (permalink / raw) To: Florian Westphal; +Cc: netfilter-devel, pablo Florian Westphal <fw@strlen.de> wrote: > I don't think so, they are zeroed out, see nf_ct_get_tuple(); > init_conntrack copies the entire thing so I don't see how stack garbage > can be placed in struct nf_conn and thus I don't see how registers can > contains crap. Yes they are zeroed out, sorry for the confusion. I haven't observed any leaks. What I meant was that if you manage to create such rules from a buggy userspace you get something like this: table inet test-table { chain test-chain { type filter hook input priority filter; policy accept; ct original saddr 0xc0000201000000000000000000000000 [invalid type] counter packets 0 bytes 0 ct original saddr 0xc0000201 [invalid type] counter packets 0 bytes 0 } } In my test, the first rule contains c000:201:: and the second one 192.0.2.1. When I send test packets with: nping --tcp -p 80 --source-ip 192.0.2.1 127.0.0.1 I see the counters for both rules being increased suggesting that both of them matched: table inet test-table { chain test-chain { type filter hook input priority filter; policy accept; ct original saddr 0xc0000201000000000000000000000000 [invalid type] counter packets 3 bytes 120 ct original saddr 0xc0000201 [invalid type] counter packets 3 bytes 120 } } > Thats a userspace bug; userspace that makes use of NFT_CT_SRC/DST must > provide the dependency. Yes I guess that makes sense, garbage in, garbage out. I was just used to seeing some kind of errno being returned from any other invalid input and I assumed that it might have been a bug in the validation. > But why? As far as I can see nothing is broken. Honestly, I am not really sure whether it is an issue or not and this was mostly driven by the assumption that the kernel shouldn't trust the userspace to properly validate its input. > We don't force dependencies for other expressions either, why make > an exception here? There is probably no strong enough reason to. Was the decision to not force dependencies intentional or something that was left as a TODO? > I'm sorry that I did not mention this earlier; in v1 i assumed intent > was to zap unused code (but its still used by nft), hence i did not > mention the above. No problem, diving into this was mostly done for fun. > Ouch, sorry, I think this is a non-starter, nft_expr > should be kept as small as possible. Yes, putting a pointer there was kinda silly. Thanks for taking the time to explain. Let me know if you'd like any more info about this or another patch involving nft_ctx instead. Otherwise, I’m fine leaving this here. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-03 9:12 ` Nick Garlis @ 2025-09-03 10:13 ` Florian Westphal 2025-09-03 10:34 ` Pablo Neira Ayuso 0 siblings, 1 reply; 13+ messages in thread From: Florian Westphal @ 2025-09-03 10:13 UTC (permalink / raw) To: Nick Garlis; +Cc: netfilter-devel, pablo Nick Garlis <nickgarlis@gmail.com> wrote: > Florian Westphal <fw@strlen.de> wrote: > > Thats a userspace bug; userspace that makes use of NFT_CT_SRC/DST must > > provide the dependency. > > Yes I guess that makes sense, garbage in, garbage out. I was just used > to seeing some kind of errno being returned from any other invalid input > and I assumed that it might have been a bug in the validation. > > > But why? As far as I can see nothing is broken. > > Honestly, I am not really sure whether it is an issue or not and this > was mostly driven by the assumption that the kernel shouldn't trust the > userspace to properly validate its input. Its simply not possible to validate it in kernel. Consider e.g. 'tcp dort 80'. nftables will insert the 'its tcp' check. But userspace can also do 'meta l4proto { 6, 17, 132} th dport { 22, 23, 80}'. The 'read 2 bytes from start of transport header' is the same. So kernel cannot 'force' anything. It will make sure that 2 bytes could be read from the given offset. But it can't make sure that those bytes have a particular meaning (port for instance). > There is probably no strong enough reason to. Was the decision to not > force dependencies intentional or something that was left as a TODO? Its fully intentional, see above example. > Thanks for taking the time to explain. Let me know if you'd like any > more info about this or another patch involving nft_ctx instead. > Otherwise, I’m fine leaving this here. You could submit a patch for nftables userspace to no longer emit NFT_CT_SRC/DST, I think there is no need to support kernels < 4.17 anymore. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-03 10:13 ` Florian Westphal @ 2025-09-03 10:34 ` Pablo Neira Ayuso 2025-09-03 11:51 ` Nikolaos Gkarlis 0 siblings, 1 reply; 13+ messages in thread From: Pablo Neira Ayuso @ 2025-09-03 10:34 UTC (permalink / raw) To: Florian Westphal; +Cc: Nick Garlis, netfilter-devel On Wed, Sep 03, 2025 at 12:13:38PM +0200, Florian Westphal wrote: [...] > You could submit a patch for nftables userspace to no longer > emit NFT_CT_SRC/DST, I think there is no need to support kernels < 4.17 > anymore. Yes. Better to fix this from userspace. linux-stable-5.4$ git grep NFT_CT_DST_IP include/ include/uapi/linux/netfilter/nf_tables.h: * @NFT_CT_DST_IP: conntrack layer 3 protocol destination (IPv4 address) include/uapi/linux/netfilter/nf_tables.h: * @NFT_CT_DST_IP6: conntrack layer 3 protocol destination (IPv6 address) include/uapi/linux/netfilter/nf_tables.h: NFT_CT_DST_IP, include/uapi/linux/netfilter/nf_tables.h: NFT_CT_DST_IP6, ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-03 10:34 ` Pablo Neira Ayuso @ 2025-09-03 11:51 ` Nikolaos Gkarlis 0 siblings, 0 replies; 13+ messages in thread From: Nikolaos Gkarlis @ 2025-09-03 11:51 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: Florian Westphal, netfilter-devel Thanks for clarifying. I'll look into preparing a userspace patch when I get the chance. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis 2025-09-02 22:21 ` Florian Westphal @ 2025-09-03 10:31 ` Pablo Neira Ayuso 2025-09-03 13:18 ` kernel test robot ` (2 subsequent siblings) 4 siblings, 0 replies; 13+ messages in thread From: Pablo Neira Ayuso @ 2025-09-03 10:31 UTC (permalink / raw) To: Nikolaos Gkarlis; +Cc: netfilter-devel, fw On Tue, Sep 02, 2025 at 11:54:33PM +0200, Nikolaos Gkarlis wrote: > The kernel allows netlink messages that use the legacy NFT_CT_SRC and > NFT_CT_DST keys in inet tables without an accompanying nft_meta > expression specifying NFT_META_NFPROTO. This results in ambiguous > conntrack expressions that cannot be reliably evaluated during packet > processing. > > When that happens, the register size calculation defaults to IPv6 (16 > bytes) regardless of the actual packet family. > > This causes two issues: > 1. For IPv4 packets, only 4 bytes contain valid address data while 12 > bytes contain uninitialized memory during comparison. > 2. nft userspace cannot properly display these rules ([invalid type]). > > The bug is not reproducible through standard nft commands, which use > NFT_CT_SRC_IP(6) and NFT_CT_DST_IP(6) keys when NFT_META_NFPROTO is > not defined. > > Fix by adding a pointer to the parent nft_rule in nft_expr, allowing > iteration over preceding expressions to ensure that an nft_meta with > NFT_META_NFPROTO has been defined. I think it is easier to work around this from userspace by translating NFT_CT_SRC to NFT_CT_SRC_{IPV4,IPV6} by peeking the datatype at the rhs of the relational. NFT_CT_{SRC,DST} only works with relational expression, they are broken with sets, that's why NFT_CT_SRC_{IPV4,IPV6} was introduced (which works with both relational expressions and sets). IIRC, I removed documentation for this syntax time ago with the expectation, it seems someone found it and it is buggy with NFPROTO_INET as you describe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis 2025-09-02 22:21 ` Florian Westphal 2025-09-03 10:31 ` Pablo Neira Ayuso @ 2025-09-03 13:18 ` kernel test robot 2025-09-03 17:47 ` [syzbot ci] " syzbot ci 2025-09-03 17:56 ` [PATCH v2] " kernel test robot 4 siblings, 0 replies; 13+ messages in thread From: kernel test robot @ 2025-09-03 13:18 UTC (permalink / raw) To: Nikolaos Gkarlis, netfilter-devel Cc: llvm, oe-kbuild-all, pablo, fw, Nikolaos Gkarlis Hi Nikolaos, kernel test robot noticed the following build warnings: [auto build test WARNING on netfilter-nf/main] [also build test WARNING on linus/master v6.17-rc4 next-20250903] [cannot apply to nf-next/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Nikolaos-Gkarlis/netfilter-nft_ct-reject-ambiguous-conntrack-expressions-in-inet-tables/20250903-055737 base: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git main patch link: https://lore.kernel.org/r/20250902215433.75568-1-nickgarlis%40gmail.com patch subject: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20250903/202509032037.4hAJJ5wS-lkp@intel.com/config) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) rustc: rustc 1.88.0 (6b00bc388 2025-06-23) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250903/202509032037.4hAJJ5wS-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509032037.4hAJJ5wS-lkp@intel.com/ All warnings (new ones prefixed by >>): >> net/netfilter/nft_ct.c:444:4: warning: label followed by a declaration is a C23 extension [-Wc23-extensions] 444 | const struct nft_expr *curr, *last; | ^ 1 warning generated. vim +444 net/netfilter/nft_ct.c 382 383 static int nft_ct_get_init(const struct nft_ctx *ctx, 384 const struct nft_expr *expr, 385 const struct nlattr * const tb[]) 386 { 387 struct nft_ct *priv = nft_expr_priv(expr); 388 unsigned int len; 389 int err; 390 391 priv->key = ntohl(nla_get_be32(tb[NFTA_CT_KEY])); 392 priv->dir = IP_CT_DIR_MAX; 393 switch (priv->key) { 394 case NFT_CT_DIRECTION: 395 if (tb[NFTA_CT_DIRECTION] != NULL) 396 return -EINVAL; 397 len = sizeof(u8); 398 break; 399 case NFT_CT_STATE: 400 case NFT_CT_STATUS: 401 #ifdef CONFIG_NF_CONNTRACK_MARK 402 case NFT_CT_MARK: 403 #endif 404 #ifdef CONFIG_NF_CONNTRACK_SECMARK 405 case NFT_CT_SECMARK: 406 #endif 407 case NFT_CT_EXPIRATION: 408 if (tb[NFTA_CT_DIRECTION] != NULL) 409 return -EINVAL; 410 len = sizeof(u32); 411 break; 412 #ifdef CONFIG_NF_CONNTRACK_LABELS 413 case NFT_CT_LABELS: 414 if (tb[NFTA_CT_DIRECTION] != NULL) 415 return -EINVAL; 416 len = NF_CT_LABELS_MAX_SIZE; 417 break; 418 #endif 419 case NFT_CT_HELPER: 420 if (tb[NFTA_CT_DIRECTION] != NULL) 421 return -EINVAL; 422 len = NF_CT_HELPER_NAME_LEN; 423 break; 424 425 case NFT_CT_L3PROTOCOL: 426 case NFT_CT_PROTOCOL: 427 /* For compatibility, do not report error if NFTA_CT_DIRECTION 428 * attribute is specified. 429 */ 430 len = sizeof(u8); 431 break; 432 case NFT_CT_SRC: 433 case NFT_CT_DST: 434 if (tb[NFTA_CT_DIRECTION] == NULL) 435 return -EINVAL; 436 437 switch (ctx->family) { 438 case NFPROTO_IPV4: 439 len = sizeof_field(struct nf_conntrack_tuple, 440 src.u3.ip); 441 break; 442 case NFPROTO_IPV6: 443 case NFPROTO_INET: > 444 const struct nft_expr *curr, *last; 445 bool meta_nfproto = false; 446 if (!expr->rule) 447 return -EINVAL; 448 449 nft_rule_for_each_expr(curr, last, expr->rule) { 450 if (curr == expr) 451 break; 452 453 if (curr->ops == &nft_meta_get_ops) { 454 const struct nft_meta *meta = nft_expr_priv(curr); 455 if (meta->key == NFT_META_NFPROTO) { 456 meta_nfproto = true; 457 break; 458 } 459 } 460 } 461 if (!meta_nfproto) 462 return -EINVAL; 463 464 len = sizeof_field(struct nf_conntrack_tuple, 465 src.u3.ip6); 466 break; 467 default: 468 return -EAFNOSUPPORT; 469 } 470 break; 471 case NFT_CT_SRC_IP: 472 case NFT_CT_DST_IP: 473 if (tb[NFTA_CT_DIRECTION] == NULL) 474 return -EINVAL; 475 476 len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip); 477 break; 478 case NFT_CT_SRC_IP6: 479 case NFT_CT_DST_IP6: 480 if (tb[NFTA_CT_DIRECTION] == NULL) 481 return -EINVAL; 482 483 len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip6); 484 break; 485 case NFT_CT_PROTO_SRC: 486 case NFT_CT_PROTO_DST: 487 if (tb[NFTA_CT_DIRECTION] == NULL) 488 return -EINVAL; 489 len = sizeof_field(struct nf_conntrack_tuple, src.u.all); 490 break; 491 case NFT_CT_BYTES: 492 case NFT_CT_PKTS: 493 case NFT_CT_AVGPKT: 494 len = sizeof(u64); 495 break; 496 #ifdef CONFIG_NF_CONNTRACK_ZONES 497 case NFT_CT_ZONE: 498 len = sizeof(u16); 499 break; 500 #endif 501 case NFT_CT_ID: 502 if (tb[NFTA_CT_DIRECTION]) 503 return -EINVAL; 504 505 len = sizeof(u32); 506 break; 507 default: 508 return -EOPNOTSUPP; 509 } 510 511 if (tb[NFTA_CT_DIRECTION] != NULL) { 512 priv->dir = nla_get_u8(tb[NFTA_CT_DIRECTION]); 513 switch (priv->dir) { 514 case IP_CT_DIR_ORIGINAL: 515 case IP_CT_DIR_REPLY: 516 break; 517 default: 518 return -EINVAL; 519 } 520 } 521 522 priv->len = len; 523 err = nft_parse_register_store(ctx, tb[NFTA_CT_DREG], &priv->dreg, NULL, 524 NFT_DATA_VALUE, len); 525 if (err < 0) 526 return err; 527 528 err = nf_ct_netns_get(ctx->net, ctx->family); 529 if (err < 0) 530 return err; 531 532 if (priv->key == NFT_CT_BYTES || 533 priv->key == NFT_CT_PKTS || 534 priv->key == NFT_CT_AVGPKT) 535 nf_ct_set_acct(ctx->net, true); 536 537 return 0; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 13+ messages in thread
* [syzbot ci] Re: netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis ` (2 preceding siblings ...) 2025-09-03 13:18 ` kernel test robot @ 2025-09-03 17:47 ` syzbot ci 2025-09-03 17:56 ` [PATCH v2] " kernel test robot 4 siblings, 0 replies; 13+ messages in thread From: syzbot ci @ 2025-09-03 17:47 UTC (permalink / raw) To: fw, netfilter-devel, nickgarlis, pablo; +Cc: syzbot, syzkaller-bugs syzbot ci has tested the following series [v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables https://lore.kernel.org/all/20250902215433.75568-1-nickgarlis@gmail.com * [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables and found the following issue: KASAN: slab-out-of-bounds Write in nft_meta_inner_init Full report is available here: https://ci.syzbot.org/series/d9b8905e-8e5d-42de-8b7a-56fc81572df6 *** KASAN: slab-out-of-bounds Write in nft_meta_inner_init tree: nf-next URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netfilter/nf-next.git base: 864ecc4a6dade82d3f70eab43dad0e277aa6fc78 arch: amd64 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 config: https://ci.syzbot.org/builds/b1146649-3f67-48cb-975c-62829433c8c5/config C repro: https://ci.syzbot.org/findings/d1f93a73-6b38-4a3b-9232-e80dea47a810/c_repro syz repro: https://ci.syzbot.org/findings/d1f93a73-6b38-4a3b-9232-e80dea47a810/syz_repro ================================================================== BUG: KASAN: slab-out-of-bounds in nft_meta_inner_init+0x1a7/0x1d0 net/netfilter/nft_meta.c:844 Write of size 1 at addr ffff88810d9f5a40 by task syz.0.17/5997 CPU: 1 UID: 0 PID: 5997 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 nft_meta_inner_init+0x1a7/0x1d0 net/netfilter/nft_meta.c:844 nft_inner_init+0x534/0x630 net/netfilter/nft_inner.c:388 nf_tables_newexpr net/netfilter/nf_tables_api.c:3513 [inline] nf_tables_newrule+0x17b0/0x28a0 net/netfilter/nf_tables_api.c:4346 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:524 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:647 [inline] nfnetlink_rcv+0x1132/0x2520 net/netfilter/nfnetlink.c:665 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2d6c18ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff1c4d5e58 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2d6c3c5fa0 RCX: 00007f2d6c18ebe9 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 00007f2d6c211e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f2d6c3c5fa0 R14: 00007f2d6c3c5fa0 R15: 0000000000000003 </TASK> Allocated by task 5997: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_noprof+0x27a/0x4f0 mm/slub.c:4377 kmalloc_noprof include/linux/slab.h:909 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] nf_tables_newrule+0x1503/0x28a0 net/netfilter/nf_tables_api.c:4328 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:524 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:647 [inline] nfnetlink_rcv+0x1132/0x2520 net/netfilter/nfnetlink.c:665 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88810d9f5a00 which belongs to the cache kmalloc-cg-64 of size 64 The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff88810d9f5a00, ffff88810d9f5a40) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810d9f5880 pfn:0x10d9f5 memcg:ffff88810dfc9601 flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff) page_type: f5(slab) raw: 057ff00000000000 ffff88801a449c80 ffffea0000f4b500 0000000000000002 raw: ffff88810d9f5880 000000008020001e 00000000f5000000 ffff88810dfc9601 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 5917, tgid 5917 (syz-executor), ts 70404800919, free_ts 68893144552 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 alloc_slab_page mm/slub.c:2487 [inline] allocate_slab+0x8a/0x370 mm/slub.c:2655 new_slab mm/slub.c:2709 [inline] ___slab_alloc+0xbeb/0x1410 mm/slub.c:3891 __slab_alloc mm/slub.c:3981 [inline] __slab_alloc_node mm/slub.c:4056 [inline] slab_alloc_node mm/slub.c:4217 [inline] __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node_noprof+0x429/0x5f0 mm/slub.c:5052 alloc_netdev_mqs+0xc7c/0x11b0 net/core/dev.c:11944 ip6_tnl_init_net+0x104/0x3b0 net/ipv6/ip6_tunnel.c:2292 ops_init+0x35c/0x5c0 net/core/net_namespace.c:136 setup_net+0x10c/0x320 net/core/net_namespace.c:438 copy_net_ns+0x31b/0x4d0 net/core/net_namespace.c:570 create_new_namespaces+0x3f3/0x720 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11c/0x170 kernel/nsproxy.c:218 ksys_unshare+0x4c8/0x8c0 kernel/fork.c:3127 __do_sys_unshare kernel/fork.c:3198 [inline] __se_sys_unshare kernel/fork.c:3196 [inline] __x64_sys_unshare+0x38/0x50 kernel/fork.c:3196 page last free pid 976 tgid 976 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1395 [inline] __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2895 kasan_depopulate_vmalloc_pte+0x74/0xa0 mm/kasan/shadow.c:472 apply_to_pte_range mm/memory.c:3015 [inline] apply_to_pmd_range mm/memory.c:3059 [inline] apply_to_pud_range mm/memory.c:3095 [inline] apply_to_p4d_range mm/memory.c:3131 [inline] __apply_to_page_range+0xb92/0x1380 mm/memory.c:3167 kasan_release_vmalloc+0xa2/0xd0 mm/kasan/shadow.c:593 kasan_release_vmalloc_node mm/vmalloc.c:2249 [inline] purge_vmap_node+0x214/0x8f0 mm/vmalloc.c:2266 __purge_vmap_area_lazy+0x7a4/0xb40 mm/vmalloc.c:2356 drain_vmap_area_work+0x27/0x40 mm/vmalloc.c:2390 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Memory state around the buggy address: ffff88810d9f5900: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ffff88810d9f5980: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc >ffff88810d9f5a00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ^ ffff88810d9f5a80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88810d9f5b00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== *** If these findings have caused you to resend the series or submit a separate fix, please add the following tag to your commit message: Tested-by: syzbot@syzkaller.appspotmail.com --- This report is generated by a bot. It may contain errors. syzbot ci engineers can be reached at syzkaller@googlegroups.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis ` (3 preceding siblings ...) 2025-09-03 17:47 ` [syzbot ci] " syzbot ci @ 2025-09-03 17:56 ` kernel test robot 4 siblings, 0 replies; 13+ messages in thread From: kernel test robot @ 2025-09-03 17:56 UTC (permalink / raw) To: Nikolaos Gkarlis, netfilter-devel Cc: llvm, oe-kbuild-all, pablo, fw, Nikolaos Gkarlis Hi Nikolaos, kernel test robot noticed the following build errors: [auto build test ERROR on netfilter-nf/main] [also build test ERROR on horms-ipvs/master linus/master v6.17-rc4 next-20250903] [cannot apply to nf-next/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Nikolaos-Gkarlis/netfilter-nft_ct-reject-ambiguous-conntrack-expressions-in-inet-tables/20250903-055737 base: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git main patch link: https://lore.kernel.org/r/20250902215433.75568-1-nickgarlis%40gmail.com patch subject: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20250904/202509040107.KmDmcM3p-lkp@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250904/202509040107.KmDmcM3p-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509040107.KmDmcM3p-lkp@intel.com/ All errors (new ones prefixed by >>): >> net/netfilter/nft_ct.c:444:4: error: expected expression 444 | const struct nft_expr *curr, *last; | ^ >> net/netfilter/nft_ct.c:449:27: error: use of undeclared identifier 'curr' 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^ >> net/netfilter/nft_ct.c:449:33: error: use of undeclared identifier 'last' 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^ >> net/netfilter/nft_ct.c:449:27: error: use of undeclared identifier 'curr' 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^ >> net/netfilter/nft_ct.c:449:33: error: use of undeclared identifier 'last' 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^ >> net/netfilter/nft_ct.c:449:27: error: use of undeclared identifier 'curr' 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^ >> net/netfilter/nft_ct.c:449:27: error: use of undeclared identifier 'curr'; did you mean 'err'? 449 | nft_rule_for_each_expr(curr, last, expr->rule) { | ^~~~ | err include/net/netfilter/nf_tables.h:1064:30: note: expanded from macro 'nft_rule_for_each_expr' 1064 | (expr) = nft_expr_next(expr)) | ^ net/netfilter/nft_ct.c:389:6: note: 'err' declared here 389 | int err; | ^ net/netfilter/nft_ct.c:450:9: error: use of undeclared identifier 'curr'; did you mean 'err'? 450 | if (curr == expr) | ^~~~ | err net/netfilter/nft_ct.c:389:6: note: 'err' declared here 389 | int err; | ^ net/netfilter/nft_ct.c:453:9: error: use of undeclared identifier 'curr' 453 | if (curr->ops == &nft_meta_get_ops) { | ^ net/netfilter/nft_ct.c:454:50: error: use of undeclared identifier 'curr'; did you mean 'err'? 454 | const struct nft_meta *meta = nft_expr_priv(curr); | ^~~~ | err net/netfilter/nft_ct.c:389:6: note: 'err' declared here 389 | int err; | ^ 10 errors generated. vim +444 net/netfilter/nft_ct.c 382 383 static int nft_ct_get_init(const struct nft_ctx *ctx, 384 const struct nft_expr *expr, 385 const struct nlattr * const tb[]) 386 { 387 struct nft_ct *priv = nft_expr_priv(expr); 388 unsigned int len; 389 int err; 390 391 priv->key = ntohl(nla_get_be32(tb[NFTA_CT_KEY])); 392 priv->dir = IP_CT_DIR_MAX; 393 switch (priv->key) { 394 case NFT_CT_DIRECTION: 395 if (tb[NFTA_CT_DIRECTION] != NULL) 396 return -EINVAL; 397 len = sizeof(u8); 398 break; 399 case NFT_CT_STATE: 400 case NFT_CT_STATUS: 401 #ifdef CONFIG_NF_CONNTRACK_MARK 402 case NFT_CT_MARK: 403 #endif 404 #ifdef CONFIG_NF_CONNTRACK_SECMARK 405 case NFT_CT_SECMARK: 406 #endif 407 case NFT_CT_EXPIRATION: 408 if (tb[NFTA_CT_DIRECTION] != NULL) 409 return -EINVAL; 410 len = sizeof(u32); 411 break; 412 #ifdef CONFIG_NF_CONNTRACK_LABELS 413 case NFT_CT_LABELS: 414 if (tb[NFTA_CT_DIRECTION] != NULL) 415 return -EINVAL; 416 len = NF_CT_LABELS_MAX_SIZE; 417 break; 418 #endif 419 case NFT_CT_HELPER: 420 if (tb[NFTA_CT_DIRECTION] != NULL) 421 return -EINVAL; 422 len = NF_CT_HELPER_NAME_LEN; 423 break; 424 425 case NFT_CT_L3PROTOCOL: 426 case NFT_CT_PROTOCOL: 427 /* For compatibility, do not report error if NFTA_CT_DIRECTION 428 * attribute is specified. 429 */ 430 len = sizeof(u8); 431 break; 432 case NFT_CT_SRC: 433 case NFT_CT_DST: 434 if (tb[NFTA_CT_DIRECTION] == NULL) 435 return -EINVAL; 436 437 switch (ctx->family) { 438 case NFPROTO_IPV4: 439 len = sizeof_field(struct nf_conntrack_tuple, 440 src.u3.ip); 441 break; 442 case NFPROTO_IPV6: 443 case NFPROTO_INET: > 444 const struct nft_expr *curr, *last; 445 bool meta_nfproto = false; 446 if (!expr->rule) 447 return -EINVAL; 448 > 449 nft_rule_for_each_expr(curr, last, expr->rule) { 450 if (curr == expr) 451 break; 452 453 if (curr->ops == &nft_meta_get_ops) { 454 const struct nft_meta *meta = nft_expr_priv(curr); 455 if (meta->key == NFT_META_NFPROTO) { 456 meta_nfproto = true; 457 break; 458 } 459 } 460 } 461 if (!meta_nfproto) 462 return -EINVAL; 463 464 len = sizeof_field(struct nf_conntrack_tuple, 465 src.u3.ip6); 466 break; 467 default: 468 return -EAFNOSUPPORT; 469 } 470 break; 471 case NFT_CT_SRC_IP: 472 case NFT_CT_DST_IP: 473 if (tb[NFTA_CT_DIRECTION] == NULL) 474 return -EINVAL; 475 476 len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip); 477 break; 478 case NFT_CT_SRC_IP6: 479 case NFT_CT_DST_IP6: 480 if (tb[NFTA_CT_DIRECTION] == NULL) 481 return -EINVAL; 482 483 len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip6); 484 break; 485 case NFT_CT_PROTO_SRC: 486 case NFT_CT_PROTO_DST: 487 if (tb[NFTA_CT_DIRECTION] == NULL) 488 return -EINVAL; 489 len = sizeof_field(struct nf_conntrack_tuple, src.u.all); 490 break; 491 case NFT_CT_BYTES: 492 case NFT_CT_PKTS: 493 case NFT_CT_AVGPKT: 494 len = sizeof(u64); 495 break; 496 #ifdef CONFIG_NF_CONNTRACK_ZONES 497 case NFT_CT_ZONE: 498 len = sizeof(u16); 499 break; 500 #endif 501 case NFT_CT_ID: 502 if (tb[NFTA_CT_DIRECTION]) 503 return -EINVAL; 504 505 len = sizeof(u32); 506 break; 507 default: 508 return -EOPNOTSUPP; 509 } 510 511 if (tb[NFTA_CT_DIRECTION] != NULL) { 512 priv->dir = nla_get_u8(tb[NFTA_CT_DIRECTION]); 513 switch (priv->dir) { 514 case IP_CT_DIR_ORIGINAL: 515 case IP_CT_DIR_REPLY: 516 break; 517 default: 518 return -EINVAL; 519 } 520 } 521 522 priv->len = len; 523 err = nft_parse_register_store(ctx, tb[NFTA_CT_DREG], &priv->dreg, NULL, 524 NFT_DATA_VALUE, len); 525 if (err < 0) 526 return err; 527 528 err = nf_ct_netns_get(ctx->net, ctx->family); 529 if (err < 0) 530 return err; 531 532 if (priv->key == NFT_CT_BYTES || 533 priv->key == NFT_CT_PKTS || 534 priv->key == NFT_CT_AVGPKT) 535 nf_ct_set_acct(ctx->net, true); 536 537 return 0; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2025-09-03 17:58 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-29 6:50 [PATCH] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables Nikolaos Gkarlis 2025-08-29 15:08 ` Florian Westphal 2025-08-29 21:59 ` Nick Garlis 2025-09-02 21:54 ` [PATCH v2] " Nikolaos Gkarlis 2025-09-02 22:21 ` Florian Westphal 2025-09-03 9:12 ` Nick Garlis 2025-09-03 10:13 ` Florian Westphal 2025-09-03 10:34 ` Pablo Neira Ayuso 2025-09-03 11:51 ` Nikolaos Gkarlis 2025-09-03 10:31 ` Pablo Neira Ayuso 2025-09-03 13:18 ` kernel test robot 2025-09-03 17:47 ` [syzbot ci] " syzbot ci 2025-09-03 17:56 ` [PATCH v2] " kernel test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).