This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15722] New: Verify that all internal sockets opened with SOCK_CLOEXEC


http://sourceware.org/bugzilla/show_bug.cgi?id=15722

            Bug ID: 15722
           Summary: Verify that all internal sockets opened with
                    SOCK_CLOEXEC
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: thiago at kde dot org
                CC: drepper.fsp at gmail dot com

As the Summary says.

glibc has many internal sockets that it opens for internal operations and
doesn't use SOCK_CLOEXEC on. Some of those sockets are used only for a short
time (for ioctl or netlink), but some may be for a long time. Anyway, however
short the time it stays open, there's still a chance that it may leak by
another thread doing a simultaneous fork().

I've found socket openings without SOCK_CLOEXEC in:

 * __opensock (socket/opensock.c), though the override in
sysdeps/unix/sysv/linux/opensock.c uses SOCK_CLOEXEC
 * getifaddrs (sysdeps/gnu/ifaddrs.c and sysdeps/unix/sysv/linux/ifaddrs.c)
 * getaddrinfo (sysdeps/posix/getaddrinfo.c)
 * __check_native (sysdeps/unix/sysv/linux/check_native.c)
 * __check_pf (sysdeps/unix/sysv/linux/check_pf.c)
 * multiple in resolv/res_send.c

There could be more.

Maybe it would be useful to have an internal function that opens always a
socket with O_CLOEXEC semantics.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]