Bug 1269217 - FreeRADIUS triggers mprotect with large radius reply
FreeRADIUS triggers mprotect with large radius reply
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: freeradius (Show other bugs)
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Nikolai Kondrashov
Jaroslav Aster
Depends On: 1202751
  Show dependency treegraph
Reported: 2015-10-06 12:53 EDT by dzr0001
Modified: 2018-03-21 00:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-01 16:36:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Radiusd strace output (822.28 KB, text/plain)
2016-03-09 13:32 EST, dzr0001
no flags Details

  None (edit)
Description dzr0001 2015-10-06 12:53:38 EDT
Description of problem:
A radius request causes FreeRADIUS to die when the request is too large.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Craft large radius reply
2. Request data that produces the large radius reply with radtest

Actual results:

# radtest $username_redacted '$password_redacted' 1812 '$key_redacted' 0
Sending Access-Request Id 164 from to
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address =
        NAS-Port = 1812
        Message-Authenticator = 0x00
Sending Access-Request Id 164 from to
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address =
        NAS-Port = 1812
        Message-Authenticator = 0x00
Sending Access-Request Id 164 from to
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address =
        NAS-Port = 1812
        Message-Authenticator = 0x00
(0) No reply from server for ID 164 socket 3

11577 close(15)                         = 0
11577 munmap(0x7fca6f5d7000, 4096)      = 0
11577 gettimeofday({1444148511, 7889}, NULL) = 0
11577 mprotect(0x7fca64023000, 4096, PROT_READ|PROT_WRITE) = 0
11577 open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENXIO (No such device or address)
11577 writev(2, [{"*** ", 4}, {"stack smashing detected", 23}, {" ***: ", 6}, {"/usr/sbin/radiusd", 17}, {" terminated\n", 12}], 5) = 62
11577 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca6f5d7000
11577 futex(0x7fca6d3b8d20, FUTEX_WAKE_PRIVATE, 2147483647) = 0
11577 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
11578 +++ killed by SIGSEGV +++
11577 +++ killed by SIGSEGV +++
11576 +++ killed by SIGSEGV +++
11574 +++ killed by SIGSEGV +++
11575 +++ killed by SIGSEGV +++
11573 +++ killed by SIGSEGV +++

# wc -l /var/log/radius/radacct/
444 /var/log/radius/radacct/
# ls -l /var/log/radius/radacct/
-rw------- 1 root root 20706 Oct  6 11:21 /var/log/radius/radacct/

Expected results:

Return radius reply results. 

Additional info:

Requests for this data on FreeBSD systems will simply return a truncated RADIUS reply rather than cause the daemon to crash.
Comment 3 Nikolai Kondrashov 2016-03-08 06:35:28 EST
Hello DZR0001,

Thank you for the report and sorry for the delay, we're just going around to handling FreeRADIUS bugs.

Would it be possible for you to post the exact commands you've executed, or perhaps a script that produced these results? If not, could you please describe exactly what you mean by "request is too large"?

Also, did you report this upstream, if yes, could you please provide a link?

Thank you.
Comment 4 dzr0001 2016-03-08 17:49:04 EST

A request that is "too large" is anything over 4096. I suspect this could be any garbage response. I've not reported this upstream.

I build a test case with garbage data if that would be helpful.
Comment 5 Nikolai Kondrashov 2016-03-09 04:25:14 EST
Understood. Yes, that would be most useful. Please post it if you can, please also add whatever server configuration is necessary to make it work. Thank you!
Comment 6 dzr0001 2016-03-09 13:31:48 EST
I installed freeradius-3.0.4-6.el7.x86_64, admittedly on a centos machine. The only configuration change that I made was to add a user in /etc/raddb/users with the following configuration:

testuser Cleartext-Password := "t3stm3!"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
		Reply-Message += "THIS IS A LONG TEST MESSAGE 0",
		Reply-Message += "THIS IS A LONG TEST MESSAGE 1",

I increased the number of reply lines until I reached the 4096 limit. The behavior was as follows:

125 lines: works, response size was 4080
126-129 lines: errors: radclient: Received bad packet: Discarding packet: Larger than RFC limitation of 4096 bytes
130 lines: segfault with stack smashing error

I'll attach strace output from the segfaulted run.

Comment 7 dzr0001 2016-03-09 13:32 EST
Created attachment 1134610 [details]
Radiusd strace output
Comment 9 Nikolai Kondrashov 2016-04-29 13:12:13 EDT
Thank you for the details, dzr0001. I found the problem in the code up to version 3.0.11. However, the latest code in the upstream v3.0.x branch has it fixed.

I'll work on backporting the fix.
Comment 15 errata-xmlrpc 2017-08-01 16:36:03 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.