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:   Fri, 22 Mar 2019 08:46:21 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 202997] New: High UDP traffic results in packet receive
 errors and system-wide UDP failure

Not sure if this a new problem, or just another case of 
"don't expect fragmented packets to be reliable".

Begin forwarded message:

Date: Thu, 21 Mar 2019 22:42:41 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 202997] New: High UDP traffic results in packet receive errors and system-wide UDP failure


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

            Bug ID: 202997
           Summary: High UDP traffic results in packet receive errors and
                    system-wide UDP failure
           Product: Networking
           Version: 2.5
    Kernel Version: 4.18.19-041819-generic
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@...workplumber.org
          Reporter: sagar@...ana.com
        Regression: No

Created attachment 281959
  --> https://bugzilla.kernel.org/attachment.cgi?id=281959&action=edit  
C file that demonstrates the problem

**OS**: Ubuntu 18.04, Ubuntu 18.10
**Kernel**: 4.18.18, 5.0.3
**Hardware**: Razer Blade 15 2018, Google Cloud Platform


Repeatedly sending large (65k) packets to a UDP socket seemingly depletes the
kernel buffers. It results in numerous "packet receive" errors in netstat and
proc/net/udp(however buffer errors are not incremented). While the receiver
sockets are left open, no other UDP traffic is processed(for example - can't
browse the web). 

The attached test, client.c, demonstrates this failure. It intentionally uses
waits/whiles to make the failure more evident. The only way to recover UDP
functionality is to kill the test. 

Alternatively, closing the receiver socket and rebinding it on ever iteration
mitigates this system-wide failure and the test can remain running. Lines 59-61
in client.c show this. 


Neither the sender, nor the receiver socket report any errors (even when the
test is modified to call recv).


I also ran this on the Windows subsystem for Linux without any trouble.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ