[defect]: starting freeradius in full debug mode -XXX can cause Segmentaion fault

[TobiasGruen]

What type of defect/bug is this?

Crash or memory corruption (segv, abort, etc...)

How can the issue be reproduced?

When in check-eap-tls config file in the section

server check-eap-tls {
	authorize {

contains an if-clause is with a length > 1024 chars then freeradius crashes with a Segmentation fault when started with

• freeradius -XXX -d /etc/raddb/

The Segfault happens exactly 4 lines after the ~ 2000 char long if-clause is printed out in the terminal

• interesting is that the if-clause debug output is shorted to ~1024 chars leading to my assumption that the debug output is copied to a char field which can only contain 1024 chars without boundary check

The if clause contains conditional args like if ( (&TLS-Client-Cert-Common-Name == "TESTING" && &NAS-IP-Address == "10.10.1.2" && &NAS-Port == 11) || (&TLS-Client-Cert-Common-Name == "TESTING" && &NAS-IP-Address == "10.10.2.2" && &NAS-Port == 11) || ........

• Started normally or with only -X there is no segfault as the Debug output does not contain the authorize section
• shorting the if clause to <1024 chars freeradius also works with -XXX debug level

This happens with freeradius 3.0.17

Log output from the FreeRADIUS daemon

freeradius -XXX -d /etc/raddb

Tue Aug  2 14:51:35 2022 : Debug: server check-eap-tls { # from file /etc/raddb//sites-enabled/check-eap-tls
Tue Aug  2 14:51:35 2022 : Debug:  authorize {
Tue Aug  2 14:51:35 2022 : Debug:   if ((xxxxxxxxxxxxxxxxxxxxxxxroughtly 1024 charsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  ) {
Tue Aug  2 14:51:35 2022 : Debug:    update {
Tue Aug  2 14:51:35 2022 : Debug:     &control:Auth-Type = Accept
Tue Aug  2 14:51:35 2022 : Debug:    }
Tue Aug  2 14:51:35 2022 : Debug:   }
Segmentation fault

Relevant log output from client utilities

No response

Backtrace from LLDB or GDB

No response

[alandekok]

Please try this with 3.2.0. 3.0.17 is years old, and it isn't productive for us to debug issues which were found and fixed years ago.

I tried this with both the v3.0.x and v3.2.x branches, and there were no issues.

You can also use gdb to get a backtrace of exactly where the issue is. That information is very useful, and helps us to fix issues more quickly. The issue template contains pointers for how to get this information.

[alandekok]

No response, and we can't reproduce it with the most recent code.