On Tue, Apr 22, 2014 at 04:01:20PM +0200, Martin Kletzander wrote:
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@entry=1,
   argv=argv@entry=0x7fffffffe368, env=env@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.


I've gone through bisecting the repo and found out the first bad
commit is this one:

commit d5d302e278c3a813994f3fe3026f3990fd6a23d9
Author: Nikos Mavrogiannopoulos <[email protected]>
Date:   Sat Nov 30 19:08:38 2013 +0100

   constructor and destructors were moved outside the FIPS140 mode.

Hoever, since I'm not familiar with the codebase, I'm rather reluctant
to go on.  Partyl because I don't know where to continue and partly
because I might be re-inventing the wheel.

Any thoughts about that?

Martin

Thanks for any pointers how to solve this (e.g. if there's an upstream
patch already),
Martin



_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help

Reply via email to