Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

2018-03-20 Thread valdis . kletnieks
On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said:
> valdis.kletni...@vt.edu  wrote:
> > (Resending because I haven't heard anything)
> [ ip6tables broken ]
>
> Sorry, did not see this email before.
>
> I'll investigate asap, thanks for the detailed report.

No problem, it reverts cleanly and looks like it's 4.17 material,
and finding stuff like this is why I build linux-next kernels :)

Just remember to stick a Reported-By: on the fix :)



pgpMRDbsiBV3S.pgp
Description: PGP signature


Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

2018-03-20 Thread Florian Westphal
valdis.kletni...@vt.edu  wrote:
> (Resending because I haven't heard anything)
[ ip6tables broken ]

Sorry, did not see this email before.

I'll investigate asap, thanks for the detailed report.


linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

2018-03-20 Thread valdis . kletnieks
(Resending because I haven't heard anything)

Am hitting an issue with this commit:

commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal 
Date:   Tue Feb 27 19:42:37 2018 +0100

netfilter: x_tables: ensure last rule in base chain matches underflow/policy

This trips on my system:

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)

More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection.  (In other words, this:

If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.

ends up meaning iptables aborts anyhow.

My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)

Messages generated as I tried to build smaller tables to narrow down the 
problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 
3
and no real correlation to the tables I was trying to load - in particular the 
numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 
1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 
928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 
824 (hook 1)

I finally got /etc/sysconfig/ip6tables down to this:

# Generated by ip6tables-save v1.6.2 on Thu Mar  8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar  8 08:20:04 2018

About as minimal as it can get. :)

Any ideas?


pgpd6Tw9aHpAS.pgp
Description: PGP signature