Bug found, patch submitted upstream: https://marc.info/?l=netfilter-devel&m=151283476531297&w=2

Hi Li Shuang,

Yes, this looks like the same issue. The problem depended on which value was given to 'ct helper' expression, so might happen on little-endian as well under certain circumstances.

BTW, upstream applied my patch:

commit a2c55e04d5a1187914cba2c02810db94de499ace (origin/master, origin/HEAD)
Author: Phil Sutter <phil>
Date:   Sat Dec 9 16:52:29 2017 +0100

    src: fix protocol context update on big-endian systems
    
    There is an obscure bug on big-endian systems when trying to list a rule
    containing the expression 'ct helper tftp' which triggers the assert()
    call in mpz_get_type().
    
    Florian identified the cause: ct_expr_pctx_update() is called for the
    relational expression which calls mpz_get_uint32() to get RHS value
    (assuming it is a protocol number). On big-endian systems, the
    misinterpreted value exceeds UINT_MAX.
    
    Expressions' pctx_update() callback should only be called for protocol
    matches, so ct_meta_common_postprocess() lacked a check for 'left->flags
    & EXPR_F_PROTOCOL' like the one already present in
    payload_expr_pctx_update().
    
    In order to fix this in a clean way, this patch introduces a wrapper
    relational_expr_pctx_update() to be used instead of directly calling
    LHS's pctx_update() callback which unifies the necessary checks (and
    adds one more assert):
    
    - assert(expr->ops->type == EXPR_RELATIONAL)
      -> This is new, just to ensure the wrapper is called properly.
    - assert(expr->op == OP_EQ)
      -> This was moved from {ct,meta,payload}_expr_pctx_update().
    - left->ops->pctx_update != NULL
      -> This was taken from expr_evaluate_relational(), a necessary
         requirement for the introduced wrapper to function at all.
    - (left->flags & EXPR_F_PROTOCOL) != 0
      -> The crucial missing check which led to the problem.
    
    Suggested-by: Florian Westphal <fw>
    Signed-off-by: Phil Sutter <phil>
    Signed-off-by: Florian Westphal <fw>

Hi Li Shuang,

Same question here: Would you be able to help in testing for this ticket? I think a crash fix would justify late addon into RHEL7.5.

Thanks, Phil

(In reply to Phil Sutter from comment #7)
> Hi Li Shuang,
> 
> Same question here: Would you be able to help in testing for this ticket? I
> think a crash fix would justify late addon into RHEL7.5.

Sure. My tests could cover this, and I took this one.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0882