Bug 2094894
| Summary: | nft asserts if set concatenation contains a constant | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Eric Garver <egarver> |
| Component: | nftables | Assignee: | Phil Sutter <psutter> |
| Status: | CLOSED ERRATA | QA Contact: | Jiri Peska <jpeska> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | fwestpha, jpeska, todoleza |
| Target Milestone: | rc | Keywords: | TestCaseProvided, Triaged, Upstream |
| Target Release: | 9.1 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | nftables-1.0.4-9.el9_1 | Doc Type: | No Doc Update |
| Doc Text: |
If this bug requires documentation, please select an appropriate Doc Type value.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-28 08:19:30 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: | |||
|
Description
Eric Garver
2022-06-08 14:46:59 UTC
Do you need this fixed in RHEL9.0? (In reply to Phil Sutter from comment #1) > Do you need this fixed in RHEL9.0? No. Ah, I confused this for a dup of Bug 2094890, but it's not. The constant value in that concat seems to mess things up. Not sure if updating sets with constant values is even supported in general. Looks like stmt_evaluate_set() would have to update datatype of 'stmt->set.set->set->key' (sic!) given the referenced set's type? (In reply to Phil Sutter from comment #3) > Ah, I confused this for a dup of Bug 2094890, but it's not. The constant > value in that concat seems to mess things up. Not sure if updating sets with > constant values is even supported in general. > > Looks like stmt_evaluate_set() would have to update datatype of > 'stmt->set.set->set->key' (sic!) given the referenced set's type? Hmm, nope, it looks like the evaluation step doesn't provide any contextual information. By the time the concat expression inside the { } is seen ectx->key isn't set so we have no clue what the "0" actually is (it has integer datatype, so no specific/known length). This makes the linerization step fail later on because it believes it needs to fill two 32 bit registers, not 3 (mismatch between what the sets key definition says vs. what the embedded concat statement came up with. I think we have to add handle EXPR_SET_REF in eval step and fill out the context info. I will have a look. Fixed in nftables.git by "evaluate: set eval ctx for add/update statements with integer constants", https://git.netfilter.org/nftables/commit/?id=4cc6b20d31498d90e90ff574ce8b70276afcee8f (In reply to Florian Westphal from comment #5) > Fixed in nftables.git by "evaluate: set eval ctx for add/update statements > with integer constants", > https://git.netfilter.org/nftables/commit/ > ?id=4cc6b20d31498d90e90ff574ce8b70276afcee8f Thanks for linking to the fix! Jiri, please consider this ticket for RHEL9.1.z qa_ack+. 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 (nftables bug fix and enhancement update), 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/RHBA-2023:0950 |