| 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
| ||
|
Message-ID: <c9211352-3da4-6cb6-cd71-be0b9c0248d7@01019freenet.de>
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
Powered by blists - more mailing lists