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

[Martin Kletzander]

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 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.
>

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

commit d5d302e278c3a813994f3fe3026f3990fd6a23d9
Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
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
>Gnutls-help at lists.gnutls.org
>http://lists.gnupg.org/mailman/listinfo/gnutls-help
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140426/6cb083be/attachment.sig>