For message lengths between 6 and 8, subtracting HEADER_LEN (9) causes
`message_len` to become negative, which is then used in calls to malloc()
and memcpy() that both take size_t arguments, causing an integer
underflow.
For 6 and 7, the huge size requested from malloc() will fail (it exceeds
PTRDIFF_MAX) and the returned NULL pointer will cause a segmentation
fault in memcpy().
However, for 8, the allocation is 0, which succeeds. But then the -1
passed to memcpy() causes a heap-based buffer overflow (and possibly a
segmentation fault when attempting to read/write that much data).
Fortunately, if compiled with -D_FORTIFY_SOURCE=3 (the default on e.g.
Ubuntu), the compiler will use __memcpy_chk(), which prevents that buffer
overflow and causes the daemon to get aborted immediately instead.
Fixes: f98cdf7a4765 ("adding plugin for EAP-MS-CHAPv2")
Fixes: CVE-2025-62291
data = in->get_data(in);
eap = (eap_mschapv2_header_t*)data.ptr;
- if (data.len < 3) /* we want at least an error code: E=e */
+ if (data.len < HEADER_LEN + 3) /* we want at least an error code: E=e */
{
DBG1(DBG_IKE, "received invalid EAP-MS-CHAPv2 message: too short");
return FAILED;