[gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1

[Martin Kletzander]

Hello,

I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
processes.  Looking at the code it looks like there should be
FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
opening those files is:

#0  open64 () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff60f20a7 in open (__oflag=0, __path=0x7ffff61031b9 "/dev/urandom")
    at /usr/include/bits/fcntl2.h:53
#2  _rnd_system_entropy_init () at rnd-common.c:192
#3  0x00007ffff60f29b0 in wrap_nettle_rnd_init (ctx=<optimized out>) at rnd.c:231
#4  0x00007ffff6055cce in _gnutls_rnd_init () at random.c:49
#5  0x00007ffff6047714 in gnutls_global_init () at gnutls_global.c:251
#6  0x00007ffff6025fdb in lib_init () at gnutls_global.c:385
#7  0x00007ffff7dea94b in call_init (l=<optimized out>, argc=argc at entry=1,
    argv=argv at entry=0x7fffffffe368, env=env at entry=0x7fffffffe378) at dl-init.c:78
#8  0x00007ffff7deaa5c in call_init (env=0x7fffffffe378, argv=0x7fffffffe368, argc=1,
    l=<optimized out>) at dl-init.c:36
#9  _dl_init (main_map=0x7ffff7ffe148, argc=1, argv=0x7fffffffe368, env=0x7fffffffe378)
    at dl-init.c:126
#10 0x00007ffff7ddc2da in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0000000000000001 in ?? ()
#12 0x00007fffffffe67a in ?? ()
#13 0x0000000000000000 in ?? ()

No matter if I change it to use O_CLOEXEC when opening the file, it
still behaves the same.  When stepping through the code and looking at
the flags of the file using `lsof +fg -p <pid>`, the ouput of lsof
should read "LG,CX", but instead of the CX flag, lsof shows 0x80000
(FD_CLOEXEC should be 1 according to all my header files), however,
fcntl(device_fd, F_GETFD) returns 1 and works perfectly in other
programs.  I don't know if that matters, but I'm running kernel-3.14.1
and glibc-2.19 and it works properly in other programs.

Thanks for any pointers how to solve this (e.g. if there's an upstream
patch already),
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140422/a3e1f635/attachment.sig>