Bug 1657075

Summary: iptables shouldn't accept negative realm values.
Product: Red Hat Enterprise Linux 7 Reporter: yiche <yiche>
Component: iptablesAssignee: Phil Sutter <psutter>
Status: CLOSED ERRATA QA Contact: Jiri Peska <jpeska>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.6CC: fwestpha, iptables-maint-list, jpeska, todoleza
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: iptables-1.4.21-31.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 13:06:28 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 4 Phil Sutter 2018-12-12 12:35:51 UTC
Should be fixed by backporting the following upstream commit:

commit 29b1d97764d1849651388d870565b3fa815a0bd8
Author: Serhey Popovych <serhe.popovych>
Date:   Thu Mar 1 13:03:11 2018 +0200

    xtables: Introduce and use common function to parse val[/mask] arguments
    
    There are a couple of places in both core and extensions where arguments
    in the form of val[/mask] is parsed (see XTTYPE_MARKMASK32).
    
    In some cases symbolic name might be used which is mapped in code to
    numeric value.
    
    Introduce common function to handle both cases where value given is
    either val[/mask] or symbolic name.
    
    Signed-off-by: Serhey Popovych <serhe.popovych>
    Signed-off-by: Florian Westphal <fw>

Comment 7 Phil Sutter 2019-04-03 19:43:46 UTC
Backport of the above commit caused a few conflicts. Looking at the missing
changes revealed that they are fixes to issues which can be reproduced on
RHEL7, so I decided to backport them as dependency (instead of adjusting the
original backport). The additional backports are:

    commit 93ad9ea1b86bdaacffd8e33654abcea3d4e148b2
    Author: Ana Rey <anarey>
    Date:   Thu Sep 18 13:06:42 2014 +0200

        extensions: libxt_devgroup: Fix the path of the group mappings file

        Use "/etc/iproute2/group" as the default path to the mapping file
        instead of "/etc/iproute2/group_map".

        Signed-off-by: Ana Rey <anarey>
        Signed-off-by: Pablo Neira Ayuso <pablo>

    commit 56aadc01b258ef7849463723ab5ddc4885db22f6
    Author: Serhey Popovych <serhe.popovych>
    Date:   Thu Mar 1 13:03:10 2018 +0200

        extensions: Initialize linear mapping of symbols in _init() of extension

        libxt_devgroup and libipt_realm currently unable to display symbolic
        names in save/print commands because linear mapping is not initialized.

        It looks bit confusing as linear mapping initialization is done in init()
        of extension, which is expected to be called before any other function of
        extension.

        However init is called only when '-m' option specified on command line,
        that is true only for insert, append, replace and destroy iptables
        commands.

        Move initialization to extension _init() function before calling
        any function in extension.

        Before:
        -------
        ... src-group 0x1 dst-group 0x2
        ... src-group 0x2 dst-group 0x1

        After:
        ------
        ... src-group grp1 dst-group grp2
        ... src-group grp2 dst-group grp1

        Signed-off-by: Serhey Popovych <serhe.popovych>
        Signed-off-by: Florian Westphal <fw>

In RHEL7, there is indeed /etc/iproute2/group and no /etc/iproute2/group_map.
Anyone trying to refer to a defined group in that file from devgroup match
(e.g. via '-m devgroup --src-group <name>') would get an error indicating the
group doesn't exist.

Comment 11 errata-xmlrpc 2019-08-06 13:06:28 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/RHBA-2019:2218