From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 2/2] evaluate: restrict allowed subtypes of concatenations
Date: Fri, 11 Apr 2025 00:50:22 +0200 [thread overview]
Message-ID: <Z_hLLgRswOjXUKMa@calendula> (raw)
In-Reply-To: <20250402145045.4637-2-fw@strlen.de>
Hi Florian,
On Wed, Apr 02, 2025 at 04:50:40PM +0200, Florian Westphal wrote:
> We need to restrict this, included bogon asserts with:
> BUG: unknown expression type prefix
> nft: src/netlink_linearize.c:940: netlink_gen_expr: Assertion `0' failed.
>
> Prefix expressions are only allowed if the concatenation is used within
> a set element, not when specifying the lookup key.
>
> For the former, anything that represents a value is allowed.
> For the latter, only what will generate data (fill a register) is
> permitted.
>
> Add a new list recursion counter for this. If its 0 then we're building
> the lookup key, if its the latter the concatenation is the RHS part
> of a relational expression and prefix, ranges and so on are allowed.
[...]
> diff --git a/src/evaluate.c b/src/evaluate.c
> index d099be137cb3..0c8af09492d1 100644
> --- a/src/evaluate.c
> +++ b/src/evaluate.c
[...]
> @@ -1704,10 +1706,48 @@ static int expr_evaluate_concat(struct eval_ctx *ctx, struct expr **expr)
> if (list_member_evaluate(ctx, &i) < 0)
> return -1;
>
> - if (i->etype == EXPR_SET)
> + switch (i->etype) {
> + case EXPR_VALUE:
> + case EXPR_UNARY:
> + case EXPR_BINOP:
> + case EXPR_RELATIONAL:
> + case EXPR_CONCAT:
> + case EXPR_MAP:
> + case EXPR_PAYLOAD:
> + case EXPR_EXTHDR:
> + case EXPR_META:
> + case EXPR_RT:
> + case EXPR_CT:
> + case EXPR_SET_ELEM:
> + case EXPR_NUMGEN:
> + case EXPR_HASH:
> + case EXPR_FIB:
> + case EXPR_SOCKET:
> + case EXPR_OSF:
> + case EXPR_XFRM:
I am expecting more new selector expressions here that would need to
be added and I think it is less likely to see new constant expressions
in the future, so maybe reverse this logic ...
if (i->etype == EXPR_RANGE ||
i->etype == EXPR_PREFIX) {
/* allowed on RHS (e.g. th dport . mark { 1-65535 . 42 }
* ~~~~~~~~ allowed
* but not on LHS (e.g 1-4 . mark { ...}
* ~~~ illegal
...
... and let anything else be accepted?
> + break;
> + case EXPR_RANGE:
> + case EXPR_PREFIX:
> + /* allowed on RHS (e.g. th dport . mark { 1-65535 . 42 }
> + * ~~~~~~~~ allowed
> + * but not on LHS (e.g 1-4 . mark { ...}
> + * ~~~ illegal
> + *
> + * recursion.list > 0 means that the concatenation is
> + * part of another expression, such as EXPR_MAPPING or
> + * EXPR_SET_ELEM (is used as RHS).
> + */
> + if (ctx->recursion.list > 0)
> + break;
So recursion.list is used to provide context to identify this is rhs,
correct? Is your intention is to use this recursion.list to control to
deeper recursions in a follow up patch?
Not related, but if goal is to provide context then I also need more
explicit context hints for bitfield payload and bitwise expressions
where the evaluation needs to be different depending on where the
expression is located (not the same if the expression is either used
as selector or as lhs/rhs of assignment).
I don't know yet how such new context enum to modify evaluation
behaviour will look, so we can just use recursion.list by now, I don't
want to block this fix.
> +
> + return expr_error(ctx->msgs, i,
> + "cannot use %s in concatenation",
> + expr_name(i));
> + default:
> return expr_error(ctx->msgs, i,
> "cannot use %s in concatenation",
> expr_name(i));
> + }
>
> if (!i->dtype)
> return expr_error(ctx->msgs, i,
> diff --git a/tests/shell/testcases/bogons/nft-f/unknown_expression_type_prefix_assert b/tests/shell/testcases/bogons/nft-f/unknown_expression_type_prefix_assert
> new file mode 100644
> index 000000000000..d7f8526092a5
> --- /dev/null
> +++ b/tests/shell/testcases/bogons/nft-f/unknown_expression_type_prefix_assert
> @@ -0,0 +1,9 @@
> +table t {
> + set sc {
> + type inet_service . ifname
> + }
> +
> + chain c {
> + tcp dport . bla* @sc accept
> + }
> +}
> --
> 2.49.0
>
>
next prev parent reply other threads:[~2025-04-10 22:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 14:50 [PATCH nft 1/2] evaluate: rename recursion counter to recursion.binop Florian Westphal
2025-04-02 14:50 ` [PATCH nft 2/2] evaluate: restrict allowed subtypes of concatenations Florian Westphal
2025-04-10 22:50 ` Pablo Neira Ayuso [this message]
2025-04-11 5:52 ` Florian Westphal
2025-04-11 9:44 ` Pablo Neira Ayuso
2025-04-11 9:48 ` Florian Westphal
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=Z_hLLgRswOjXUKMa@calendula \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.