[pull] master from esnet:master#141
Open
pull[bot] wants to merge 411 commits into
Open
Conversation
Fix rcv-timeout issue because of Nread timeout
* Avoid subthread signal handling * subthread signal handling Since multiple threads responding simultaneously to a signal leading to race condition, this is used to ensure that only the main thread handles the signal. * aesthetic improvements * Revert IEPTHREADATTRDESTROY to original value
fix incorrect freeaddrinfo call
At the end of the test, the traffic thread has been reclaimed. If there is an exception in the control connection, it will cause the thread to be reclaimed repeatedly. Use sp->done to avoid repeated thread recycling.
Json read check json size
Avoid duplicate thread recycling.
fix typo in iperf_util.c
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
…e end of the interval
…-time No limit to omit time period
…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
* Update to development documentation. * Update release engineering checklist to reflect current practices. * Updates for support-ish things * Remove "Changes from iperf2" section because it's pretty obsolete/ wrong at this point. * docs: Add sections on audience and PRs. * docs: Minor updates and wordsmithing in release checklist. * Remove obsolete issue numbers. Add a note in the README about what iperf3 is used for and by whom. Other text maintenance. * Add a couple paragraphs about intended release cadence. Fix broken link.
* Add auth_test.sh to github actions
server_timer_proc - better handle server test time expiration
* Secure iperf3 systemd service Co-authored-by: Johannes Larsen <mail@johslarsen.net> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: swlars <89053414+swlars@users.noreply.github.com> Co-authored-by: Johannes Larsen <mail@johslarsen.net> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* relnotes: First draft of iperf-3.21 release notes (not completed yet). * relnotes: Add a note for the iperf3.service file change in PR #1855. * releng: Update release number and manpage dates for iperf-3.21. * Regen. * relnotes: Set release date
* 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
new error indicators. Follow-on to PR #2040.
Explicitly check the return values from Base64Decode()
Fix client file descriptor leaks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )