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.
Description of problem:
When using nftables' "include" directive to include a number of files in your firewall definition, if there's an error in one of the files, the error might not report the correct filename when showing the error. It may even show the contents of the misreported file, when showing error context.
Version-Release number of selected component (if applicable):
nftables-0.9.3-26.el8.x86_64
How reproducible:
Will enumerate in the next section
Steps to Reproduce:
1. In an nftables config (say, /etc/nftables/main.nft), add this line inside an allow chain (like at the end of "chain allow", after line 44 on the stock main.nft):
include "/etc/nftables/my-allow.d/*.nft"
2. Add the file /etc/nftables/my-allow.d/test1.nft, with the following contents:
tcp dport { 12345 } accept
3. Add the file /etc/nftables/my-allow.d/test2.nft, with the following contents:
ip saddr { localhost } tcp dport { 54321 } accept
4. Run: nft -f main.nft
Actual results:
In file included from main.nft:45:17-57:
/etc/nftables/my-allow.d/test1.nft:2:13-21: Error: Hostname resolves to multiple addresses
Expected results:
In file included from main.nft:45:17-57:
/etc/nftables/my-allow.d/test2.nft:2:13-21: Error: Hostname resolves to multiple addresses
Additional info:
In that test case, "test2.nft" contains an error. "localhost" technically resolves to two separate IP addresses: 127.0.0.1 and ::1. So nft rightly throws that error. However, the filename it's given to the user is test1.nft, not test2.nft. On my system where I first noticed the problem, it went even deeper and reported the *contents* of the wrong file, making the error even weirder:
In file included from nsight.nft:43:9-53:
/etc/nftables/nsight-allow.d/https.nft:3:12-20: Error: Hostname resolves to multiple addresses
ort { 443 } counter accept
^^^^^^^^^
The inclusion of the contents of the previous file is especially worrying -- note that it doesn't actually start at the beginning of the line from https.nft. The full line in https.nft starts off "tcp dport", as you'd expect, but the "tcp dp" has been cut off.
I've reproduced this on a couple of RHEL8 boxes, with both testcases and the "real" definitions which I'd had pushed out on that initial box. I have not tried confirming this on any RHEL9 boxes yet. In all testcases so far, the incorrectly-reported file has always been the *previous* file, when sorted alphanumerically, though I wouldn't want to claim that happens 100% of the time.
Upstream fix to backport:
commit 4441c0233cbcb74b08a53720557e76bf0b26c998
Author: Pablo Neira Ayuso <pablo>
Date: Thu Jan 2 16:37:31 2020 +0100
scanner: incorrect error reporting after file inclusion
scanner_pop_buffer() incorrectly sets the current input descriptor. The
state->indesc_idx field actually stores the number of input descriptors
in the stack, decrement it and then update the current input descriptor
accordingly.
Fixes: 60e917fa7cb5 ("src: dynamic input_descriptor allocation")
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1383
Signed-off-by: Pablo Neira Ayuso <pablo>
The test 0019include_error_0 from following commit triggers the problem:
commit 79cb0868d22525a8812bc8b390f50d29f25ebf27
Author: Pablo Neira Ayuso <pablo>
Date: Thu Feb 13 12:13:11 2020 +0100
tests: shell: validate error reporting with include and glob
Signed-off-by: Pablo Neira Ayuso <pablo>
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:7185
Description of problem: When using nftables' "include" directive to include a number of files in your firewall definition, if there's an error in one of the files, the error might not report the correct filename when showing the error. It may even show the contents of the misreported file, when showing error context. Version-Release number of selected component (if applicable): nftables-0.9.3-26.el8.x86_64 How reproducible: Will enumerate in the next section Steps to Reproduce: 1. In an nftables config (say, /etc/nftables/main.nft), add this line inside an allow chain (like at the end of "chain allow", after line 44 on the stock main.nft): include "/etc/nftables/my-allow.d/*.nft" 2. Add the file /etc/nftables/my-allow.d/test1.nft, with the following contents: tcp dport { 12345 } accept 3. Add the file /etc/nftables/my-allow.d/test2.nft, with the following contents: ip saddr { localhost } tcp dport { 54321 } accept 4. Run: nft -f main.nft Actual results: In file included from main.nft:45:17-57: /etc/nftables/my-allow.d/test1.nft:2:13-21: Error: Hostname resolves to multiple addresses Expected results: In file included from main.nft:45:17-57: /etc/nftables/my-allow.d/test2.nft:2:13-21: Error: Hostname resolves to multiple addresses Additional info: In that test case, "test2.nft" contains an error. "localhost" technically resolves to two separate IP addresses: 127.0.0.1 and ::1. So nft rightly throws that error. However, the filename it's given to the user is test1.nft, not test2.nft. On my system where I first noticed the problem, it went even deeper and reported the *contents* of the wrong file, making the error even weirder: In file included from nsight.nft:43:9-53: /etc/nftables/nsight-allow.d/https.nft:3:12-20: Error: Hostname resolves to multiple addresses ort { 443 } counter accept ^^^^^^^^^ The inclusion of the contents of the previous file is especially worrying -- note that it doesn't actually start at the beginning of the line from https.nft. The full line in https.nft starts off "tcp dport", as you'd expect, but the "tcp dp" has been cut off. I've reproduced this on a couple of RHEL8 boxes, with both testcases and the "real" definitions which I'd had pushed out on that initial box. I have not tried confirming this on any RHEL9 boxes yet. In all testcases so far, the incorrectly-reported file has always been the *previous* file, when sorted alphanumerically, though I wouldn't want to claim that happens 100% of the time.