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.