Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
The problem is caused by optimized prefix match code generation in iptables-nft, nftables doesn't know how to represent the three-byte payload match. This is fixed by this upstream commit:
commit 8a927c56d83ed0f78785011bd92a53edc25a0ca0
Author: Phil Sutter <phil>
Date: Tue Oct 27 17:05:25 2020 +0100
src: Support odd-sized payload matches
When expanding a payload match, don't disregard oversized templates at
the right offset. A more flexible user may extract less bytes from the
packet if only parts of a field are interesting, e.g. only the prefix of
source/destination address. Support that by using the template, but fix
the length. Later when creating a relational expression for it, detect
the unusually small payload expression length and turn the RHS value
into a prefix expression.
Signed-off-by: Phil Sutter <phil>
In order to enable the same optimization in nftables as well, we might want to also backport the following commit:
commit 25338cdb6c77aa2f0977afbbb612571c9d325213
Author: Phil Sutter <phil>
Date: Tue Oct 27 17:33:15 2020 +0100
src: Optimize prefix matches on byte-boundaries
If a prefix expression's length is on a byte-boundary, it is sufficient
to just reduce the length passed to "cmp" expression. No need for
explicit bitwise modification of data on LHS. The relevant code is
already there, used for string prefix matches. There is one exception
though, namely zero-length prefixes: Kernel doesn't accept zero-length
"cmp" expressions, so keep them in the old code-path for now.
This patch depends upon the previous one to correctly parse odd-sized
payload matches but has to extend support for non-payload LHS as well.
In practice, this is needed for "ct" expressions as they allow matching
against IP address prefixes, too.
Signed-off-by: Phil Sutter <phil>
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-2021:4465
The problem is caused by optimized prefix match code generation in iptables-nft, nftables doesn't know how to represent the three-byte payload match. This is fixed by this upstream commit: commit 8a927c56d83ed0f78785011bd92a53edc25a0ca0 Author: Phil Sutter <phil> Date: Tue Oct 27 17:05:25 2020 +0100 src: Support odd-sized payload matches When expanding a payload match, don't disregard oversized templates at the right offset. A more flexible user may extract less bytes from the packet if only parts of a field are interesting, e.g. only the prefix of source/destination address. Support that by using the template, but fix the length. Later when creating a relational expression for it, detect the unusually small payload expression length and turn the RHS value into a prefix expression. Signed-off-by: Phil Sutter <phil> In order to enable the same optimization in nftables as well, we might want to also backport the following commit: commit 25338cdb6c77aa2f0977afbbb612571c9d325213 Author: Phil Sutter <phil> Date: Tue Oct 27 17:33:15 2020 +0100 src: Optimize prefix matches on byte-boundaries If a prefix expression's length is on a byte-boundary, it is sufficient to just reduce the length passed to "cmp" expression. No need for explicit bitwise modification of data on LHS. The relevant code is already there, used for string prefix matches. There is one exception though, namely zero-length prefixes: Kernel doesn't accept zero-length "cmp" expressions, so keep them in the old code-path for now. This patch depends upon the previous one to correctly parse odd-sized payload matches but has to extend support for non-payload LHS as well. In practice, this is needed for "ct" expressions as they allow matching against IP address prefixes, too. Signed-off-by: Phil Sutter <phil>