Skip to content

[pull] master from esnet:master#141

Open
pull[bot] wants to merge 419 commits into
kubestone:masterfrom
esnet:master
Open

[pull] master from esnet:master#141
pull[bot] wants to merge 419 commits into
kubestone:masterfrom
esnet:master

Conversation

@pull

@pull pull Bot commented May 10, 2023

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull Bot added the ⤵️ pull label May 10, 2023
bmah888 and others added 23 commits September 20, 2024 11:21
Avoid duplicate thread recycling.
No size limit for received server output JSON
…t-loss-compared-to-nuttcp

No select() when reading stream data
Fix memory leak for parallel tests
…t_sent-simplify

Remove the usage of pacing_timer and simplify iperf_mt_send
Bump actions/checkout to v4
…l-NULL-thread

Do not try to cancel NULL thread (causing Segmentation fault)
…sage

NET_SOFTERROR on UDP send EAGAIN/EINTR errno if no data was sent
swlars and others added 5 commits December 13, 2024 15:18
This avoids a potential server crash with malformed iperf3
parameter sets. (CVE-2024-53580)

Vulnerability report submitted by Leonid Krolle Bi.Zone.

Original version of fix by @dopheide-esnet.
Add a variant of cJSON_GetObjectItem that does type-checking.
Otherwise, the server keeps the last congestion protocol asked by a
client (-C option), applying it to the following clients not asking for
a specific protocol.
bmah888 and others added 30 commits April 9, 2026 12:43
* docs: Change http:// links to https:// and fix old broken links.

* docs: Use contemporary version of ESnet logo in page footer.

While here, clean up old unused logo files.

* docs: Fix GitHub icon in header.

* docs: Convert "ESnet" link text in header to orb from the 2025 logo set.

* docs: Stop linking to the RST source for pages.

* docs: Fix formatting of make_release step.

* docs: Move a bunch of releases into the "Older News" section.

* docs: Add one of the new iperf3 logos to the front docs page.
A heap-buffer-overflow was discovered in `Base64Decode` when processing
malformed input, such as a single '=' character.

The issue stemmed from an unsigned integer underflow in
`calcDecodeLength`. For an input of length 1 with 1 padding character,
the formula `(len*3)/4 - padding` resulted in `0 - 1`, producing
`SIZE_MAX`. In `Base64Decode`, this value was truncated when assigned to
an `int decodeLen`, resulting in `-1`. This caused `malloc(decodeLen +
1)` to call `malloc(0)` and a subsequent out-of-bounds write at
`(*buffer)[-1]`.

Changes:
- Modified `calcDecodeLength` to explicitly check for underflow and
  return 0 if padding exceeds the calculated base length.
- Changed the type of `decodeLen` from `int` to `size_t` in
  `Base64Decode` to ensure consistency and avoid signedness issues.
- Added a NULL pointer check for the `malloc` allocation.

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.

Debugger verification: Before the fix, the debugger showed `decodeLen`
as `-1` (int) and ASAN reported a write 1 byte before the allocated
region. After the fix, `decodeLen` is `0`, and the program runs without
error.

Fix: The fix involves:
1.  Modifying `calcDecodeLength` to explicitly check if `padding >
    (len*3)/4` and return 0 to prevent underflow.
2.  Changing `decodeLen` to `size_t` in `Base64Decode`.
3.  Adding a NULL check for `malloc`.

Co-authored-by: CodeMender <codemender-patching@google.com>
Reviewed-by: Meder Kydyraliev <meder@google.com>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Fixes: https://issues.oss-fuzz.com/issues/474401004
iperf_auth: fix heap-buffer-overflow in Base64Decode
In --bidir mode, iperf_tcp_connect() was called twice: first for the
sender stream, then for the receiver. The old connect() call returned
immediately on EINPROGRESS, so both TCP handshakes completed in
parallel.
Under load with RSS, the server's accept() could return them out of
order, causing both sides to assign the same role (both sender or both
receiver) and deadlock.

Replace connect() with timeout_connect() so each handshake fully
completes before the next connect() is issued, ensuring deterministic
accept() order.

Signed-off-by: Alexandr Moshkov <dtalexundeer@yandex-team.ru>
Fixes: #2029
Remove a stray carriage return from the service file
Close stream buffer fd in `iperf_client_end()`. Close operation is
protected by checking if the fd is valid. This prevents double close in
case there's a code path calling iperf_free_stream() before
iperf_client_end().

Protect stream buffer fd close in `iperf_free_stream()` with fd validity
check. This prevent double close in normal test success. Double close
is probably fine for close() call but valgrind will nag about it.

Close /dev/urandom file in `readentropy()` after reading it. This
prevents fd leaks in cases where libiperf is dlopen()'ed, a test is
executed and the lib is dlclose()'ed repeatedly.
…times-at-test-end

Cancel periodic timers at test end
…gments-in-message-to-maximum-allowed

Suggested fix to PR #1925 to limit the number of segments in UDP GSO message to 128, which is the maximum allowed. The problem was with messages length 507 or less, as 507 is the maximum length where MAX_UDP_BLOCKSIZE/length >= 129.

The limit GSO_MAX_DG_IN_BF is defined as a constant as I didn't find a reliable way to determine it dynamically. From what I found, the value is defined in Linux as UDP_MAX_SEGMENTS. Although it seems that in some (newer?) Linux distributions it is defined in udp.h, as in here, at least in WSL Linux that I use it is not defined in a header file, and probably it is defined in udpgso.c like in here.
* Add JSON value checks for get_parameters.

Special thanks to Dirk Müller for directing our attention to this.
…t_connect

iperf_tcp: replace connect() with timeout_connect().

This eliminates race conditions in accepting connections, which can lead to deadlocks when doing bidirectional TCP tests.

Fixes #2029.
iperf_auth: check BIO_read return value in Base64Decode
Explicitly check the return values from Base64Decode()
…eams

Do not allow setting zero parallel streams
…nhance__zerocopy_skip-rx-copy_parallel

Allow --zerocopy and --skip-rx-copy when only server supports them
…ckets-DSCP-and-TOS

Ensure DSCP/ToS is set in the first UDP/TCP streams packets.

Also improves some error handling and adds an error message specific to DSCP in case of a bad DSCP parameter specified from the command-line.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.