Bug 1523016
| Summary: | crash in nft list on ppc64 system | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Li Shuang <shuali> |
| Component: | nftables | Assignee: | Phil Sutter <psutter> |
| Status: | CLOSED ERRATA | QA Contact: | Li Shuang <shuali> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.5 | CC: | atragler, psutter |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | nftables-0.8-6.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Cause:
Incorrect handling of 'ct helper' statement could lead to nft command crash.
Consequence:
Trying to list a ruleset which contained a 'ct helper' statement in one of its rules would lead to nft command crash under certain conditions (seen with 'ct helper tftp' on big-endian machines).
Fix:
Problematic piece of code was fixed.
Result:
Crash does not happen anymore.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 16:09:09 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Comment 4
Phil Sutter
2017-12-09 16:01:31 UTC
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 |