Bug 1877022 - cannot add concatenation with ip prefix in bridge table
Summary: cannot add concatenation with ip prefix in bridge table
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: nftables
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Phil Sutter
QA Contact: Jiri Peska
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-08 18:12 UTC by Tomas Dolezal
Modified: 2021-05-18 15:10 UTC (History)
2 users (show)

Fixed In Version: nftables-0.9.3-17.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 15:10:15 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1804726 0 medium CLOSED RFE: Complete among match support in ebtables-nft 2021-02-22 00:41:40 UTC

Description Tomas Dolezal 2020-09-08 18:12:02 UTC
Description of problem:
ebtables-nft added among support for mixed MAC and MAC/IP entries via c33bae9c6c, ref bug 1804726.
It leads to adding 0.0.0.0/0 ip address for macs that has no ip match specified. resulting nft ruleset cannot be restored after exporting.    

Version-Release number of selected component (if applicable):
nftables-0.9.3-16.el8.x86_64
iptables-1.8.4-15.el8.x86_64
kernel-4.18.0-234.el8.x86_64

How reproducible:
always

Steps to Reproduce:
ebtables -A FORWARD --among-src aa:bb:CC:dd:00:fb,aa:bb:CC:dd:00:fa=192.0.2.92 -j ACCEPT
nft -s list ruleset | tee rules.nft #see reduced output bellow
nft -c 'include "./rules.nft"' ; echo $?


Actual results:
table bridge filter {
 chain FORWARD {
  type filter hook forward priority filter; policy accept;
   ether saddr . ip saddr { aa:bb:cc:dd:00:fa . 192.0.2.92, aa:bb:cc:dd:00:fb . 0.0.0.0/0 } counter accept
}

BUG: invalid range expression type concat
nft: expression.c:1160: range_expr_value_low: Assertion `0' failed.
Aborted (core dumped)
134

Expected results:
the rule is accepted or printed commented out similarly to other unsuported iptables-nft rules
nft command exits cleanly without core dump

Additional info:
exit code 134

Comment 2 Phil Sutter 2020-12-02 14:32:45 UTC
Upstream works fine, probably fixed by the following commit:

commit 7aa08d45031ec7ce5dadb4979471d626367c09cd
Author: Stefano Brivio <sbrivio@redhat.com>
Date:   Wed May 27 22:51:21 2020 +0200

    evaluate: Perform set evaluation on implicitly declared (anonymous) sets
    
    If a set is implicitly declared, set_evaluate() is not called as a
    result of cmd_evaluate_add(), because we're adding in fact something
    else (e.g. a rule). Expression-wise, evaluation still happens as the
    implicit set expression is eventually found in the tree and handled
    by expr_evaluate_set(), but context-wise evaluation (set_evaluate())
    is skipped, and this might be relevant instead.
    
    This is visible in the reported case of an anonymous set including
    concatenated ranges:
    
      # nft add rule t c ip saddr . tcp dport { 192.0.2.1 . 20-30 } accept
      BUG: invalid range expression type concat
      nft: expression.c:1160: range_expr_value_low: Assertion `0' failed.
      Aborted
    
    because we reach do_add_set() without properly evaluated flags and
    set description, and eventually end up in expr_to_intervals(), which
    can't handle that expression.
    
    Explicitly call set_evaluate() as we add anonymous sets into the
    context, and instruct the same function to:
    - skip expression-wise set evaluation if the set is anonymous, as
      that happens later anyway as part of the general tree evaluation
    - skip the insertion in the set cache, as it makes no sense to have
      sets that shouldn't be referenced there
    
    For object maps, the allocation of the expression for set->data is
    already handled by set_evaluate(), so we can now drop that from
    stmt_evaluate_objref_map().
    
    v2:
     - skip insertion of set in cache (Pablo Neira Ayuso)
     - drop double allocation of expression (and leak of the first
       one) for object maps (Pablo Neira Ayuso)
    
    Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Reported-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Comment 3 Phil Sutter 2021-01-12 09:32:58 UTC
Above patch breaks /CoreOS/nftables/Regression/nft-map-with-ipv6-address-type-key-and-integer, a follow-up is needed:

commit 54eb1e16cc4787906fe8206858f0ea0bfb9c1209
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Jun 7 15:23:21 2020 +0200

    evaluate: missing datatype definition in implicit_set_declaration()
    
    set->data from implicit_set_declaration(), otherwise, set_evaluation()
    bails out with:
    
     # nft -f /etc/nftables/inet-filter.nft
     /etc/nftables/inet-filter.nft:8:32-54: Error: map definition does not specify
     mapping data type
                    tcp dport vmap { 22 : jump ssh_input }
                                   ^^^^^^^^^^^^^^^^^^^^^^^
     /etc/nftables/inet-filter.nft:13:26-52: Error: map definition does not specify
     mapping data type
                     iif vmap { "eth0" : jump wan_input }
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    Add a test to cover this case.
    
    Fixes: 7aa08d45031e ("evaluate: Perform set evaluation on implicitly declared (anonymous) sets")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=208093
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Comment 12 errata-xmlrpc 2021-05-18 15:10:15 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/RHEA-2021:1722


Note You need to log in before you can comment on or make changes to this bug.