Bug #13842
Updated by Reid Linnemann almost 2 years ago
In the FreeRadius package, user upload/download limits can be set to any positive integer, including any values that could overflow a 32 bit unsigned integer. This causes no problems for the generation of the user entry or for FreeRADIUS parsing it. However, when these values are packed into attributes that are sent back as integers in RADIUS packets, the high word is truncated and only the bottom word is transferred. This yields situations where a user's traffic quota is specified in Megabytes as '10000', recorded in the user record's pfSense-Max-Total-Octets as:
<pre>
pfSense-Max-Total-Octets := 10485760000
</pre>
This value is a 64-bit integer @00 00 00 02 71 00 00 00@, which is truncated to @71 00 00 00@ when packed into the pfSense-Max-Total-Octets attribute of type integer, giving the client the erroneous unsigned int value 1895825408 (about 1808MB), far lower than the administrator's intended 10000MB value.
This lack of input validation may lead to overflows in other user attributes that are packed into RADIUS attributes, such as the max bandwidth values, login time constraints, number of simultaneous connections, and others. This issue will only address the values that are multiplied - the max bandwidth and max upload/download usage.