Hi, while trying to reproduce the segfault and eventually looking into the diagnostic patch Alan provided I came across something which might be contributing (also freeradius should not segfault nevertheless).
When feeding a freeradius-1.1.3 (linux) an "forged" Acces-Request with bogus user name and ask it to check_cert_cn it detects the mismatch, etc. just like in your example and sends out a fatal tls alert. My test client wpa_supplicant (also linux) picks that up, recognizes the failure and essentially stops that run to authenticate and sends an tls alert ACK inside the next Access-Request. freeradius recognizes it and only then sends an Access-Reject without much further processing. After some timeout the supplicant tries anew. That would be the first Access-Request freeradius sees again from it. As its still wrongly configured the above repeats...no segfault (see attached debug log, a bit bloated as I use basically that setup for other tests too) Whereas I noticed in your debug log that immediately after the tls alert message from freeradius your client sends (keeping on with authentication?) an EAP-Message containing a CertificateVerify tls message (sort of manually decoding) EAP-Message = 0x0205002f0d800000002515030100207a99997bc8a6c68c3a5c5770c8b46fdd7b8848b6850dc4ea57d1d0e0434ae4c8 for reasons I do not understand. It's that message that leads to the segfault in cbtls_verify. As said above some strangely (wrongfully?) behaving client shouldn't be able to crash the authentication server but it looks curious. Perhaps someone might find that information helpful. regards K. Hoercher
radius_debug.log
Description: Binary data
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
