On Wed, Mar 14, 2018 at 10:43:29AM +0100, Phil Sutter wrote:
> Hi,
>
> I noticed that trying to create a relational with OP_EQ explicitly
> stated and a range expression on RHS makes nft segfault. A simple
> example is:
>
> | ip6 nexthdr == 33-44
>
> The culprit seems to be that payload_expr_pctx_update() is called which
> tries to export RHS value, but range expression comes with zero length
> and invalid byte-order which gmp doesn't like.
>
> The same happens with a set expression, BTW:
>
> | ip6 nexthdr == {33, 44}
>
> A simple fix (for range expression) would be to add 'goto range' to case
> OP_EQ in expr_evaluate_relational() analogous to what's in case OP_NEQ.
> Though I got curious as to why OP_RANGE is needed in the first place and
> it seems like it isn't at all. At least netlink_gen_cmp() handles ranges
> and sets on RHS correctly.
>
> What netlink_gen_cmp() lacks, is proper treatment for lists on RHS
> (which need OP_FLAGCMP), but that should be doable by adding a case for
> EXPR_LIST.
>
> So long story short, I want to eliminate OP_RANGE, OP_LOOKUP and
> OP_FLAGCMP and make OP_IMPLICIT always resolve into OP_EQ.
I specifically wanted to get rid of OP_FLAGCMP time ago. If we can
just simplify them all to OP_EQ, then it's fine.
I remember we have an assymetry already in this because OP_RANGE is
assuming equal. While we can specify OP_NEQ.
So fixing this semantic mess would be great.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
