The logs clearly show nft segfault. Reassigning to nftables.

Any updates on when we can expect this segfault to be fixed in RHEL8?

Upstream commits to backport:

commit 5d57fa3e99bb9f2044e236d4ddb7d874cfefe1dd
Author: Phil Sutter <phil>
Date:   Thu Jan 9 13:34:20 2020 +0100

    monitor: Do not decompose non-anonymous sets
    
    They have been decomposed already, trying to do that again causes a
    segfault. This is a similar fix as in commit 8ecb885589591 ("src:
    restore --echo with anonymous sets").
    
    Signed-off-by: Phil Sutter <phil>
    Acked-by: Pablo Neira Ayuso <pablo>

commit 02174ffad484d9711678e5d415c32307efc39857
Author: Phil Sutter <phil>
Date:   Thu Jan 9 17:43:11 2020 +0100

    monitor: Fix for use after free when printing map elements
    
    When populating the dummy set, 'data' field must be cloned just like
    'key' field.
    
    Fixes: 343a51702656a ("src: store expr, not dtype to track data in sets")
    Signed-off-by: Phil Sutter <phil>
    Acked-by: Pablo Neira Ayuso <pablo>

Here's how to reproduce the issue firewalld exposed:

With a given ruleset of:

| table t {
| 	set s {
| 		type inet_service
| 		flags interval
| 		elements = { 20, 30-40 }
| 	}
| 	chain c {
| 	}
| }

Running the following command segfaults:

| nft --echo add rule t c tcp dport @s

This is caused by echo option handling code trying to decompose the referenced
interval set in cache although that had already happened before. The fix
contained in the first patch above avoids a call to interval_map_decompose() if
given set is not an anonymous one.

Echo code is shared with monitor code, so while the above command doesn't
segfault if --echo option is not used, it will crash a possibly running
instance of 'nft monitor'.

Requirements for reproducing are non-trivial, but not uncommon:

- set has interval flag
- set contains elements (not 100% sure, but at least a range is needed)
- nft is called with --echo option (or 'nft monitor' being used)

(In reply to Phil Sutter from comment #9)
> Upstream commits to backport:
> 
[...]
> 
> commit 02174ffad484d9711678e5d415c32307efc39857
> Author: Phil Sutter <phil>
> Date:   Thu Jan 9 17:43:11 2020 +0100
> 
>     monitor: Fix for use after free when printing map elements
>     
>     When populating the dummy set, 'data' field must be cloned just like
>     'key' field.
>     
>     Fixes: 343a51702656a ("src: store expr, not dtype to track data in sets")
>     Signed-off-by: Phil Sutter <phil>
>     Acked-by: Pablo Neira Ayuso <pablo>

This one is in fact not needed, the commit it fixes is not present in RHEL8.

Upstream fix is faulty, luckily covscan noticed it. I've sent a follow-up: http://patchwork.ozlabs.org/patch/1222144/

Follow-up to backport:

commit ddbacd70d061eb1b6808f501969809bfb5d03001
Author: Phil Sutter <phil>
Date:   Mon Jan 13 14:53:24 2020 +0100

    monitor: Fix output for ranges in anonymous sets
    
    Previous fix for named interval sets was simply wrong: Instead of
    limiting decomposing to anonymous interval sets, it effectively disabled
    it entirely.
    
    Since code needs to check for both interval and anonymous bits
    separately, introduce set_is_interval() helper to keep the code
    readable.
    
    Also extend test case to assert ranges in anonymous sets are correctly
    printed by echo or monitor modes. Without this fix, range boundaries are
    printed as individual set elements.
    
    Fixes: 5d57fa3e99bb9 ("monitor: Do not decompose non-anonymous sets")
    Signed-off-by: Phil Sutter <phil>
    Reviewed-by: Pablo Neira Ayuso <pablo>

*** Bug 1778558 has been marked as a duplicate of this bug. ***

As per the process, requesting z-stream backport for this ticket to cover customer-case referenced in bug 1778558.

Fixes work in RHEL 8.2 Beta
and
CentOS 8.1(packages rebuilt from Beta srpms)

It would be nice if we got the fix in RHEL 8.1 itself 😊.

thanks

*** Bug 1801861 has been marked as a duplicate of this bug. ***

any plans to backport the fix to 8.1?

(In reply to Vlad from comment #29)
> any plans to backport the fix to 8.1?

Yes. See bug 1802056.

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:1774