netdev - Fw: [Bug 196469] New: UDPv4+UDPv6 receive silently fails after heavy UDP load

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>] [day] [month] [year] [list]

Date:   Tue, 25 Jul 2017 11:40:25 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 196469] New: UDPv4+UDPv6 receive silently fails after
 heavy UDP load

Begin forwarded message:

Date: Mon, 24 Jul 2017 20:52:01 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 196469] New: UDPv4+UDPv6 receive silently fails after heavy UDP load

https://bugzilla.kernel.org/show_bug.cgi?id=196469

            Bug ID: 196469
           Summary: UDPv4+UDPv6 receive silently fails after heavy UDP
                    load
           Product: Networking
           Version: 2.5
    Kernel Version: 4.12.2
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@...workplumber.org
          Reporter: CFSworks@...il.com
        Regression: No

I have a system that's performing heavy SNMP monitoring on various devices over
IPv6. After upgrading it from 4.11.5 to 4.12.2 last week, I noticed this
weekend that all UDP packets received by the system were being silently
dropped.

The problem happened this weekend, after the system had been running for about
2 days with no issue, and without any human intervention at the time (i.e. it
broke on its own - no configuration changes were made). I verified UDP replies
were coming in via tcpdump, and checked netfilter and conntrack to make sure
nothing was blocking it (indeed netfilter/conntrack is able to see the traffic,
indicating the problem is deeper in the network stack). There is no relevant or
even unusual output whatsoever in dmesg.

This affects ALL received UDPv4/UDPv6 packets, even traffic on a loopback
interface: opening a pair of Python sessions and trying to send UDP traffic
back and forth on 127.0.0.1 results in the traffic getting dropped as well.
ICMP and TCP are unaffected.

My gut says it's a race condition somewhere in the UDP receive queue(s). What
puzzles me is why heavy UDPv6 load caused the kernel to shut out all UDPv4
traffic too.

-- 
You are receiving this mail because:
You are the assignee for the bug.