Bug#934168: linux-image-4.19.0-5-amd64: iptables-restore may result in NULL pointer dereference at nf_tables_newrule on startup

[Salvatore Bonaccorso <carnil@debian.org>]

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: elias@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