RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2094894 - nft asserts if set concatenation contains a constant
Summary: nft asserts if set concatenation contains a constant
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: nftables
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 9.1
Assignee: Phil Sutter
QA Contact: Jiri Peska
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-08 14:46 UTC by Eric Garver
Modified: 2023-02-28 08:23 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2023-02-28 08:19:30 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-124660 0 None None None 2022-06-08 14:50:56 UTC
Red Hat Product Errata RHBA-2023:0950 0 None None None 2023-02-28 08:19:37 UTC

Description Eric Garver 2022-06-08 14:46:59 UTC 
[root@vm-bos-rhel9 virtual-networking]# nft 'add rule netdev mlag bond0EgressFilter ether type != vlan set update ether saddr . 0 timeout 5s @macset-tagged-b0 counter return' # tagged
nft: netlink_linearize.c:799: netlink_gen_expr: Assertion `dreg < ctx->reg_low' failed.
Aborted (core dumped)

[root@vm-bos-rhel9 virtual-networking]# nft -V
nftables v0.9.8 (E.D.S.)
  cli:          readline
  json:         yes
  minigmp:      no
  libxtables:   yes
Comment 1 Phil Sutter 2023-01-11 14:31:33 UTC 
Do you need this fixed in RHEL9.0?
Comment 2 Eric Garver 2023-01-11 14:42:06 UTC 
(In reply to Phil Sutter from comment #1)
> Do you need this fixed in RHEL9.0?

No.
Comment 3 Phil Sutter 2023-01-11 16:58:49 UTC 
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?
Comment 4 Florian Westphal 2023-01-23 16:31:17 UTC 
(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.
Comment 5 Florian Westphal 2023-02-09 11:17:55 UTC 
Fixed in nftables.git by "evaluate: set eval ctx for add/update statements with integer constants",
https://git.netfilter.org/nftables/commit/?id=4cc6b20d31498d90e90ff574ce8b70276afcee8f
Comment 6 Phil Sutter 2023-02-09 11:28:47 UTC 
(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!
Comment 7 Phil Sutter 2023-02-09 11:32:49 UTC 
Jiri, please consider this ticket for RHEL9.1.z qa_ack+.
Comment 17 errata-xmlrpc 2023-02-28 08:19:30 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.