netdev - Re: 2.6.34: Problem with UDP traffic on lo + poll(?)

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Sep 2010 17:37:05 +0200
From:	Krzysztof Olędzki <ole@....pl>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev@...r.kernel.org
Subject: Re: 2.6.34: Problem with UDP traffic on lo + poll(?)

On 2010-09-06 22:48, Krzysztof Olędzki wrote:
> On 2010-09-06 22:44, Krzysztof Olędzki wrote:
>> On 2010-09-06 22:29, Eric Dumazet wrote:
>>> Le lundi 06 septembre 2010 à 21:55 +0200, Krzysztof Olędzki a écrit :
>>>
>>>> Yes, conntrack is one of possibilities. However, this problem only
>>>> manifests on 2.6.34 and never on 2.6.31 where iptables and conntrack
>>>> configurations are identically. And of course, each time it is a
>>>> different port.
>>>>
>>>> Please also note that this problem only exists when communication is
>>>> handled over a loopback interface - I'm not able to trigger this from a
>>>> remote host even if I run the test on two hosts (local&    remote)
>>>> simultaneously.
>>>>
>>>
>>> No particular error shown in "netstat -s" ?
>>
>> No... :(
>>
>> Udp:
>>        8542243 packets received
>>        489605 packets to unknown port received.
>>        1 packet receive errors
>>        4254527 packets sent
>>        RcvbufErrors: 1
>>
>>> port randomization on UDP changed in the past, and conntracking changed
>>> a bit too ;)
>>
>> I know but AFAIR all important changs were alredy included in 2.6.31.
>> And again: there is no problem in quering DNS from a remote host:
>>     [client 2.6.24.6]<-ethernet->   [server 2.6.34.6]
>>
>> BTW: I have been able to reproduce this problem on a different, less
>> critical host after upgrading its kernel to 2.6.34.6. Unfortunately I'm
>> still not able to do in on my lab environment. :( Anyway, I'll try to
>> catch "conntrack -E" output and see what conntrack thinks about such
>> packets.
>
> OK, got it:
>
> *strace (1682.t.lan):
> socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.130.53")}, 28) = 0
> poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
> sendto(4, "Gz\1\0\0\1\0\0\0\0\0\0\0041683\1t\3lan\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
> poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
> poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
>
> * tcpdump:
> 1283805361.395859 IP (tos 0x0, ttl 64, id 47011, offset 0, flags [DF], proto UDP (17), length 56)
>      192.168.130.53.49279>  192.168.130.53.53: 27611+ A? 1682.t.lan. (28)
> 1283805361.395933 IP (tos 0x0, ttl 64, id 10738, offset 0, flags [none], proto UDP (17), length 112)
>      192.168.130.53.53>  192.168.130.53.49279: 27611* 1/1/1 1682.t.lan. A 127.0.0.1 (84)
>
> * conntrack:
> [1283805361.395862]         [NEW] ipv4     2 udp      17 30 src=192.168.130.53 dst=192.168.130.53 sport=49279 dport=53 [UNREPLIED] src=192.168.130.53 dst=192.168.130.53 sport=53 dport=49279 id=3423125776
> [1283805361.395939]      [UPDATE] ipv4     2 udp      17 30 src=192.168.130.53 dst=192.168.130.53 sport=49279 dport=53 src=192.168.130.53 dst=192.168.130.53 sport=53 dport=49279 id=3423125776

So far I have found that:

2.6.31.7/2.6.31.12: OK
2.6.32.21: OK
2.6.33-rc1: bad
2.6.33-rc5: bad
2.6.33.7: bad
2.6.34.4/2.6.34.6: bad

It looks like the bug must have been introduced in 2.6.33-rc1. There are 
8904 commits between 2.6.32 and 2.6.33-rc1, so with ~15 more reboots I 
should be able to point the problematic commit. I hope. ;)


Best regards,

			Krzysztof Olędzki

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html