linux-kernel - Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 22 Apr 2019 20:49:40 +0200
From:   Andreas Hartmann <andihartmann@...19freenet.de>
To:     Florian Westphal <fw@...len.de>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to
 find_next_bit

On 22.04.19 at 19:27 Florian Westphal wrote:
> Andreas Hartmann <andihartmann@...19freenet.de> wrote:
>> Since 4.19.17, I'm facing problems during streaming of videos I've never seen before. This means:
>>
>> - video from internet stutters although enough data flow can be seen in bmon.
>> - gpu is locked:
>>   radeon 0000:0a:00.0: ring 0 stalled for more than 14084msec
>>   radeon 0000:0a:00.0: GPU lockup (current fence id 0x0000000000053ed7 last fence id 0x0000000000053f0f on ring 0)
>> - The connection of videos streamed locally by the machine for a TV suddenly breaks (upnp - serviio as server).
>>
>> After very long time of testing, I detected, that removing the complete patch series for 4.19.17 regarding netfilter: nf_conncount makes the problem disappear.
>>
>> Please remove / fix this patchset!
> 
> The state in 4.19.y is same as in mainline.

I don't use mainline.

> Could you at least tell us how you're using nf_conncount (nf/iptables
> rules)?

The host is a Ryzen 7 1700 CPU, containing 4 kvm VMs, one ethernet interface, 2 bridges (2 different networks). One VM works as a bridge between both networks.
The iptables rules are the following:

# Generated by iptables-save v1.6.2 on Mon Apr 22 20:19:30 2019
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [4423:248703]
-A INPUT -s 127.0.0.1/32 -d 239.255.255.250/32 -i lo -p udp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -d 255.255.255.255/32 -p udp -j ACCEPT
-A INPUT -d 224.0.0.1/32 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -d 127.0.0.2/32 -i lo -j ACCEPT
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.22.0/24 -j ACCEPT
-A INPUT -j LOG --log-prefix "In Input gesperrt: "
-A INPUT -s 169.254.2.1/32 -d 169.254.2.2/32 -i br1 -p tcp -m tcp --sport 80 -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.22/32 -o lo -p igmp -j ACCEPT
-A OUTPUT -d 192.168.6.173/32 -o br1 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -s 169.254.2.2/32 -d 239.255.255.250/32 -o br1 -p udp -j DROP
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.251/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 239.255.255.250/32 -o lo -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 255.255.255.255/32 -o br1 -p udp -m udp --dport 1900 -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.255.255.255/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.0.0.250/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.255.255.250/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.255.255.250/32 -o br1 -p udp -m udp --dport 1900 -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.1.1.1/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.1.1.1/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.251/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -p tcp -m tcp --dport 1935 -j ACCEPT
-A OUTPUT -s 192.168.22.0/24 -d 192.168.3.0/24 -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.2/32 -o lo -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 192.168.22.0/24 -d 192.168.22.0/24 -j ACCEPT
-A OUTPUT -j LOG --log-prefix "In Output gesperrt: "
-A OUTPUT -s 169.254.2.2/32 -d 169.254.2.1/32 -o br1 -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Mon Apr 22 20:19:30 2019


br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        ether .........  txqueuelen 1000  (Ethernet)
        RX packets 1376  bytes 139220 (135.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512
        inet 192.168.22.6  netmask 255.255.255.0  broadcast 192.168.22.255
        ether .........  txqueuelen 1000  (Ethernet)
        RX packets 1161816  bytes 2806028482 (2.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1427306  bytes 2032637199 (1.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512
        ether .........  txqueuelen 1000  (Ethernet)
        RX packets 119990  bytes 110191277 (105.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 204094  bytes 234832004 (223.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 36  memory 0xfc8c0000-fc8e0000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2474  bytes 16626724 (15.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2474  bytes 16626724 (15.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512
        ether ............  txqueuelen 1000  (Ethernet)
        RX packets 1164109  bytes 3022066875 (2.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 984171  bytes 56305461 (53.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        ether .........  txqueuelen 1000  (Ethernet)
        RX packets 1044034  bytes 66058845 (62.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1220061  bytes 3029057018 (2.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        ether ..........  txqueuelen 1000  (Ethernet)
        RX packets 1216429  bytes 3011285937 (2.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1038397  bytes 65034965 (62.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        ether ............ txqueuelen 1000  (Ethernet)
        RX packets 19875  bytes 29951674 (28.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23283  bytes 13365374 (12.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512
        ether ............  txqueuelen 1000  (Ethernet)
        RX packets 363077  bytes 24587603 (23.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 823604  bytes 2081985009 (1.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

> Could you test with debugging (KASAN, CONFIG_PROVE_RCU etc). enabled?

I don't know what you're expecting here exactly - sorry. Testing is not that easy as I don't know how to force the error.
After removing the "netfilter: nf_conncount" patches, I didn't see the problem any more - same as before 4.19.17.

> I'm really surprised about this report, before the backport nf_conncount
> caused frequent kernel crashes, how does reverting even work...?

I never had any problem w/ iptables before - it's been working always just as it should!


Thanks!
Regards
Andreas