Bug 1801603

Summary: Fix iptables-translate for interface names containing asterisk
Product: Red Hat Enterprise Linux 8 Reporter: Phil Sutter <psutter>
Component: iptablesAssignee: Phil Sutter <psutter>
Status: CLOSED ERRATA QA Contact: Radka Brychtova <rskvaril>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: iptables-maint-list, qe-baseos-daemons, rskvaril, surkumar, todoleza
Target Milestone: rc   
Target Release: 8.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: iptables-1.8.4-8.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1763652 Environment:
Last Closed: 2020-04-28 17:00: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:

Comment 1 Phil Sutter 2020-02-11 10:41:49 UTC
Upstream commit to backport:

commit e179e87a1179e272a9bdabb0220b17d61d099ee3
Author: Phil Sutter <phil>
Date:   Thu Feb 6 15:08:41 2020 +0100

    xtables-translate: Fix for interface name corner-cases
    
    There are two special situations xlate_ifname() didn't cover for:
    
    * Interface name containing '*': This went unchanged, creating a command
      nft wouldn't accept. Instead translate into '\*' which doesn't change
      semantics.
    
    * Interface name being '+': Can't translate into nft wildcard character
      as nft doesn't accept asterisk-only interface names. Instead decide
      what to do based on 'invert' value: Skip match creation if false,
      match against an invalid interface name if true.
    
    Also add a test to make sure future changes to this behaviour are
    noticed.
    
    Signed-off-by: Phil Sutter <phil>

Comment 3 Phil Sutter 2020-02-13 13:07:09 UTC
CI tests exposed a problem with above patch: By accident, all '+' characters
are replaced when translating interface names instead of just the last one. Fix
sent upstream:

https://lore.kernel.org/netfilter-devel/20200213130436.26755-1-phil@nwl.cc/

Comment 8 errata-xmlrpc 2020-04-28 17:00: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, 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-2020:1889