iperf_auth: fix heap-buffer-overflow in Base64Decode

[JustinStitt]

OSSFuzz initially reported iperf:auth_fuzzer: Heap-buffer-overflow in Base64Decode
earlier this year. The disclosure deadline for that particular report has passed and as such I figured I'd post the report again as well as a patch (this PR).

AI DISCLAIMER: We ran CodeMender against the report in an agent+fuzzer feedback loop until we arrived at this simple patch which was then reviewed by several humans here at Google. If this patch 1) doesn't meet iperf's coding standards or 2) is not actually correct then please let me know and I (human) will fix it :)

---

calcDecodeLength was susceptible to an unsigned integer underflow when processing malformed Base64 input (e.g., a single '=' character). In such cases, the calculation (len*3)/4 - padding resulted in SIZE_MAX.

In Base64Decode, this SIZE_MAX value was assigned to a signed int, resulting in -1. This led to malloc(0) (allocating a minimal chunk) followed by an out-of-bounds write at (*buffer)[-1].

This patch addresses the issue by:

1. Modifying calcDecodeLength to return 0 if the padding exceeds the calculated base length, preventing underflow.
2. Changing the decodeLen variable type from int to size_t to prevent signedness issues.
3. Adding a NULL check for the malloc allocation.

Verified with ASAN: previously reported a 1-byte write before the allocated region; now runs without error.

Full summary:
The vulnerability was a heap-buffer-overflow in Base64Decode in /src/iperf/src/iperf_auth.c.

Root Cause:
The helper function calcDecodeLength calculates the decoded length of a Base64 string using the formula:

return (len*3)/4 - padding;

where len is the input string length and padding is the number of '=' characters at the end (1 or 2).
When the input is a single '=' character:

• len is 1.
• padding is 1.
• (len*3)/4 is 0.
• 0 - 1 results in an unsigned integer underflow on size_t, producing SIZE_MAX.

In Base64Decode:

int decodeLen = calcDecodeLength(b64message);
*buffer = (unsigned char*)malloc(decodeLen + 1);
(*buffer)[decodeLen] = '\0';

The SIZE_MAX returned by calcDecodeLength is assigned to int decodeLen, which casts it to -1.
malloc(decodeLen + 1) becomes malloc(0), allocating a minimal chunk (1 byte).
(*buffer)[decodeLen] = '\0' becomes (*buffer)[-1] = '\0', writing 1 byte before the allocated buffer.

<snip>

Co-authored-by: CodeMender codemender-patching@google.com
Reviewed-by: Meder Kydyraliev meder@google.com
Fixes: https://issues.oss-fuzz.com/issues/474401004

[swlars]

Hi Justin,

We responded to an email from David (David@adalogics.com) about a possible disclosure on Friday, February 27th, 2026, but never heard a response about the details or a patch. The email we normally use for security disclosures is iperf@es.net.

Thank you for the pull request. We'll review the patch soon.

Thanks,
iperf3 Maintenance Team