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
>
>
