[Bug 1347] ebtables-nft: regression in -o option

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1347

--- Comment #3 from Florian Westphal <fw at strlen.de> ---
(In reply to Arturo Borrero Gonzalez from comment #2)
> (In reply to Florian Westphal from comment #1)
> > (In reply to Arturo Borrero Gonzalez from comment #0)
> > > This ruleset:
> > > 
> > > # cat ebtables-fwd-no-o-options-allowed.rules
> > > *filter
> > > :PVEFW-FORWARD ACCEPT
> > > :PVEFW-FWBR-OUT ACCEPT
> > > -A PVEFW-FORWARD -p IPv4 -j ACCEPT
> > > -A PVEFW-FORWARD -p IPv6 -j ACCEPT
> > > -A PVEFW-FORWARD -o fwln+ -j PVEFW-FWBR-OUT
> > > -A FORWARD -j PVEFW-FORWARD
> > > 
> > > works in ebtables-legacy but doesn't in ebtables-nft.
> > 
> > Fix:
> > 
> > diff --git a/iptables/xtables-eb.c b/iptables/xtables-eb.c
> > --- a/iptables/xtables-eb.c
> > +++ b/iptables/xtables-eb.c
> > @@ -197,7 +197,8 @@ int ebt_get_current_chain(const char *chain)
> >         else if (strcmp(chain, "POSTROUTING") == 0)
> >                 return NF_BR_POST_ROUTING;
> >  
> > -       return -1;
> > +       /* placeholder for user defined chain */
> > +       return NF_BR_NUMHOOKS;
> >  }
> > 
> > Let me know and I'll push it to iptables.git.
> 
> Something is wrong with the change. ebtables-nft-restore seems to be in some
> busy loop consuming 100% CPU. If called with strace, the behavior changes:
> 
> [..]
> stat("/usr/local/lib/xtables/libebt_standard.so", 0x7ffc0d6b1ca0) = -1
> ENOENT (No such file or directory)
> stat("/usr/local/lib/xtables/libxt_standard.so", {st_mode=S_IFREG|0755,
> st_size=25136, ...}) = 0
> openat(AT_FDCWD, "/usr/local/lib/xtables/libxt_standard.so",
> O_RDONLY|O_CLOEXEC) = 4
> read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\20\0\0\0\0\0\0"...,
> 832) = 832
> fstat(4, {st_mode=S_IFREG|0755, st_size=25136, ...}) = 0
> mmap(NULL, 16688, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) =
> 0x7efc36c5f000
> mmap(0x7efc36c60000, 4096, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7efc36c60000
> mmap(0x7efc36c61000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,
> 4, 0x2000) = 0x7efc36c61000
> mmap(0x7efc36c62000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7efc36c62000
> close(4)                                = 0
> mprotect(0x7efc36c62000, 4096, PROT_READ) = 0
> fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
> read(0, <--- waits here

How can I reproduce this?

It works for me, iptables-test.py --nftables passes too.

export XTABLES_LIBDIR=$(pwd)/extensions
unshare -n sh -c "iptables/xtables-nft-multi ebtables-restore < t;
iptables/xtables-nft-multi ebtables-save ; nft list ruleset"
# Generated by ebtables-save v1.8.3 on Tue Jul  2 13:21:56 2019
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
:PVEFW-FORWARD ACCEPT
:PVEFW-FWBR-OUT ACCEPT
-A FORWARD -j PVEFW-FORWARD
-A PVEFW-FORWARD -p IPv4 -j ACCEPT
-A PVEFW-FORWARD -p IPv6 -j ACCEPT
-A PVEFW-FORWARD -o fwln+ -j PVEFW-FWBR-OUT

table bridge filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                counter packets 0 bytes 0 jump PVEFW-FORWARD
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }

        chain PVEFW-FORWARD {
                ether type ip counter packets 0 bytes 0 accept
                ether type ip6 counter packets 0 bytes 0 accept
                oifname "fwln*" counter packets 0 bytes 0 jump PVEFW-FWBR-OUT
                counter packets 0 bytes 0 accept
        }

        chain PVEFW-FWBR-OUT {
                counter packets 0 bytes 0 accept
        }
}

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190702/2db016d5/attachment.html>