Control: forcemerge 931330 934168 hi Elias,
On Wed, Aug 07, 2019 at 06:51:12PM +0200, Elias Werberich wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Package: src:linux > Version: 4.19.37-5+deb10u1 > Severity: normal > X-Debbugs-Cc: el...@werberich.de > > > Dear Kernel Maintainer, > > I found a reproducible bug which causes a linux kernel oops if > netfilter-persistence.service tries to load IPv4 firewall rules on > startup by calling iptables-restore with the following content as > input: > > *filter > :INPUT ACCEPT [0:0] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [0:0] > :MY-ICMP - [0:0] > - -A INPUT -j MY-ICMP > - -A MY-ICMP -p icmp -m icmp --icmp-type 3 -j ACCEPT > - -A MY-ICMP -p icmp -m icmp --icmp-type 11 -j ACCEPT > - -A MY-ICMP -p icmp -m icmp --icmp-type 8 -m limit --limit 4/sec -j ACCEPT > COMMIT > > I was able to create this simple ruleset out of a more complex firewall > configuration. > This kernel oops appears on nine out of ten startups/reboots. > If it appears, iptables/nftables are not usable anymore. > For more details, consult kernel log. > > Steps to reproduce the kernel oops: > > # Install a fresh, minimal Debian 10 Buster system. (e.g. new VM) > $ apt update > $ apt install iptables iptables-persistent > # Save IPv4 rules on installation, do not save IPv6 rules. > $ cat << \EOF > /etc/iptables/rules.v4 > *filter > :INPUT ACCEPT [0:0] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [0:0] > :MY-ICMP - [0:0] > - -A INPUT -j MY-ICMP > - -A MY-ICMP -p icmp -m icmp --icmp-type 3 -j ACCEPT > - -A MY-ICMP -p icmp -m icmp --icmp-type 11 -j ACCEPT > - -A MY-ICMP -p icmp -m icmp --icmp-type 8 -m limit --limit 4/sec -j ACCEPT > COMMIT > EOF > $ reboot > > You may need to reboot a second or third time, if it does not appear > on the first startup. > > I was able to reproduce this on AMD64 using VirtualBox VM and a > cloud server provider. It may cause a broken firewall configuration > which leads to a security issue if you reboot without monitoring. Thanks for the reproducing instructions. This looks the same as the bug reported at https://bugzilla.kernel.org/show_bug.cgi?id=203681 which is #931330. This should be fixed in 5.2.6-1. But might need to check which commit(s) fix the issue and see they are already backported to the 4.19.x stable series as well. Regards, Salvatore