Memory leak in FR 3.0.19 ?

Alan DeKok aland at deployingradius.com
Fri Oct 18 15:04:24 CEST 2019


On Oct 18, 2019, at 8:26 AM, Arnaud LAURIOU <arnaud.lauriou at renater.fr> wrote
> Thank's for your answers, here are some logs after testing FR 3.0.20 with about a
> hundred authentications (let me know if you need more specific information
> from valgrind, I don't know it well) :

  That's OK.

> blocks 'definitely lost' :
> 
> ==27160== 32,936 (136 direct, 32,800 indirect) bytes in 1 blocks are definitely lost in loss record 1,499 of 1,529
> ==27160==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27160==    by 0x840B31E: gnutls_x509_crt_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10)

  And that's a problem.

  DON'T use GnuTLS with FreeRADIUS.  It's wrong and broken.  For details, see:

https://networkradius.com/freeradius-packages/

  Note: CentOS and RedHat link their LDAP libraries against NSS. FreeRADIUS uses OpenSSL. NSS and OpenSSL cannot be used in the same application, as they will cause it to crash. FreeRADIUS therefore must use libldap from the LDAP Toolbox Project, which uses OpenSSL.

> Issue with the ldap module ?

  Issues with GNU TLS.  Don't use it.

  Install libldap from the LTB project, and install the FreeRADIUS packages from the Network RADIUS web site.  It should work.

  If you still see memory leaks, then we can fix them. But there is absolutely no way that we can fix GNU TLS nonsense.  Especially when the leak is buried inside of libldap.  We didn't write libldap, and we know nothing about it.  The only thing we can say is "use a version of libldap that isn't broken".

  Alan DeKok.




More information about the Freeradius-Users mailing list