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-next>] [day] [month] [year] [list]
Date:	Tue, 9 Jun 2015 17:04:34 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	netdev@...r.kernel.org
Subject: Fw: [Bug 99671] New: glibc deadlock in __check_pf() presumed due to
 missing netlink response



Begin forwarded message:

Date: Mon, 8 Jun 2015 21:20:23 +0000
From: "bugzilla-daemon@...zilla.kernel.org" <bugzilla-daemon@...zilla.kernel.org>
To: "shemminger@...ux-foundation.org" <shemminger@...ux-foundation.org>
Subject: [Bug 99671] New: glibc deadlock in __check_pf() presumed due to missing netlink response


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

            Bug ID: 99671
           Summary: glibc deadlock in __check_pf() presumed due to missing
                    netlink response
           Product: Networking
           Version: 2.5
    Kernel Version: 4.0
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: shemminger@...ux-foundation.org
          Reporter: dwmw2@...radead.org
        Regression: No

I keep seeing multithreaded processes deadlocked on glibc's __check_pf
function, with the culprit stuck like this:

#0  0x0000003841302edd in recvmsg () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000384131f8ee in __check_pf (pid=-52599, fd=20) at
../sysdeps/unix/sysv/linux/check_pf.c:166
#2  0x000000384131f8ee in __check_pf (seen_ipv4=seen_ipv4@...ry=0x7f5b137fdc32,
seen_ipv6=seen_ipv6@...ry=0x7f5b137fdc33, in6ai=in6ai@...ry=0x7f5b137fdc40,
in6ailen=in6ailen@...ry=0x7f5b137fdc48) at
../sysdeps/unix/sysv/linux/check_pf.c:324

I don't understand why the glibc code is waiting; even if netlink responses are
dropped, it should get ENOBUFS and bail out.

This started happening to me, sporadically, when I updated my Fedora 22 beta
installation to the 4.0 kernel. It seemed to go away when I reverted to 3.19,
and came back again when I went back to 4.0. Filed in Red Hat bugzilla as
https://bugzilla.redhat.com/show_bug.cgi?id=1209433 and reported upstream at 
https://www.marc.info/?l=linux-netdev&m=142849461211078&w=3 and
https://www.marc.info/?l=linux-netdev&m=142954024310299&w=3

Others seem to have seen it on earlier kernels though:
https://github.com/nahi/httpclient/issues/232

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ