How are TLS session freed when the exchange fails?

[Alan DeKok]

Yannick Koehler wrote:
>   First, I am new to this mailing list, so I am trying to be extra
> careful.  I am using FreeRADIUS locally and its memory in a particular
> situation keep increasing by a lot.  Basically, I see a RADIUS
> exchange that fails (timeout) before reaching the ACCEPT/REJECT.  I
> traced the memory and debugged a lot to find out that the
> tls_new_session() inside tls.c is invoked and allocated a
> tls_session_t of 64k, then that structure is kept in memory without
> any means that I could found to be cleared when the RADIUS exchanged
> terminate abruptly.

  See "max_sessions" in the eap module.  Set it to "2", and you'll see
that the third session will be refused.

  See also "timer_expire".  Set it to "5", and when you try a new EAP
session, any sessions older than 5 seconds will be removed.

>   I can repeat this over and over and there appear to be no limit as
> to how much FreeRADIUS can steal from my main memory.  Considering
> that I saw that memory leak in the past are seen as security issue, I
> am therefore wondering if I am right or not.  I could not find any
> timeout or clean up behavior to ensure that first the number of TLS
> session is capped and second that if the RADIUS exchange is stopped
> before the end that the associated tls session gets cleared, so I help
> here would be appreciated.

  The tls data structure is tied to an EAP session.  The EAP session is
managed by a handler.  That handler is in turn managed.  See
src/modules/rlm_eap/mem.c.

>  One could reproduce something like that by sending a RADIUS Access
> Request with a EAP Identity Response and at the reception of the
> RADIUS Access Challenge, just ignore it and keep sending new RADIUS
> Access Request with new EAP Identity Response.

  Try it with the above configuration.  You should see that there are
limits both on the number of sessions, and how long each session is
allowed to last.

  Alan DeKok.