AI_ONLY_REPORT
package: iperf3-3.17.1-5.el10_1
------
Summary: Unbounded numeric parameters from peer JSON can trigger resource  
exhaustion (blksize / num_streams / duration etc.): The server accepts  
peer-controlled numeric values from the control-channel JSON without  
server-side bounds checks; confirmed exploitation through oversized  
`parallel` and `len` values can drive excessive stream/thread creation and  
large per-stream buffer allocation, causing remote denial of service.
Requirements to exploit: Network reachability to an `iperf3` server and the  
ability to send crafted control-channel JSON during parameter exchange. No  
user interaction is required. If iperf authentication is not enabled, no  
credentials are needed.
Component affected: `iperf3` server control-channel parameter handling in  
`get_parameters()` (`src/iperf_api.c`), server `CREATE_STREAMS` processing  
(`src/iperf_server_api.c`), and `iperf_new_stream()` buffer/stream setup  
(`src/iperf_api.c`)
Version affected: Confirmed on the `3.17.1` source baseline and present  
through the inspected current `HEAD`; older versions may also be affected,  
but were not confirmed.
Patch available: No upstream patch identified. A minimal patch sketch is  
included below.
Version fixed (if any already): unknown
Upstream coordination: Not yet notified. This report is prepared for  
initial disclosure to the project maintainers.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH)
AV:N - Reachable over the network through the `iperf3` control channel.
AC:L - Exploitation only requires sending oversized numeric parameters  
during normal parameter exchange.
PR:N - No credentials are required when the server accepts  
unauthenticated clients.
UI:N - No user interaction is required.
S:U  - The impact remains within the `iperf3` service scope.
C:N  - No confidentiality impact was demonstrated.
I:N  - No integrity impact was demonstrated.
A:H  - Oversized `parallel` and `len` values can drive large buffer  
mapping, heavy `readentropy()` work, and excessive stream/thread creation,  
causing serious service disruption.
Impact: Important. The strongest confirmed impact is server-side  
availability loss: oversized `parallel` and `len` values drive per-stream  
buffer allocation, `readentropy()` work, and stream/thread creation in the  
server path. No direct confidentiality or integrity impact was  
demonstrated, but a remote client can cause substantial service disruption  
or keep the service unavailable by repeatedly triggering resource-intensive  
or failing tests.
Embargo: yes
Reason: The issue is reachable over the network against exposed `iperf3`  
servers, requires no user interaction, and no fixed release is known.  
Coordinated disclosure gives upstream time to add server-side validation  
before public release of detailed reproduction steps.
Suggested public date: 19-Jul-2026
Acknowledgement: Aisle Research
Steps to reproduce:
1. Build the current source and start the server with `./src/iperf3 -s`.
2. Build a modified client, or a custom control-channel client, that  
overwrites the parameter JSON before `JSON_write()` and sends out-of-range  
values such as `"parallel": 100000` and `"len": 1073741824`.
3. Connect the malicious client to the server and let it proceed through  
the normal control handshake and stream setup.
4. Observe repeated large `ftruncate()` / `mmap()` attempts per stream,  
heavy memory/CPU pressure, excessive stream/socket/thread creation  
attempts, and test abort/reset. Repeated requests can keep the service  
degraded or unavailable.


Vulnerability Details






`get_parameters()` accepts peer-controlled numeric fields from the  
control-channel JSON and assigns them directly without reapplying the  
bounds enforced by CLI parsing:
```c
if ((j_p = iperf_cJSON_GetObjectItemType(j, "parallel", cJSON_Number)) !=  
NULL)
test->num_streams = j_p->valueint;
...
if ((j_p = iperf_cJSON_GetObjectItemType(j, "len", cJSON_Number)) != NULL)
test->settings->blksize = j_p->valueint;
```
The strongest confirmed reachable sink is on the server path. During  
`CREATE_STREAMS`, the server eventually calls `iperf_new_stream()`, where  
`len` controls per-stream buffer sizing and `parallel` controls how many  
streams and worker threads are created:
```c
sp = iperf_new_stream(test, s, flag);
...
if (ftruncate(sp->buffer_fd, test->settings->blksize) < 0) ...
sp->buffer = (char *) mmap(NULL, test->settings->blksize, ...);
ret = readentropy(sp->buffer, test->settings->blksize);
```
CLI parsing applies checks such as `MAX_STREAMS` and `MAX_BLOCKSIZE`, but  
equivalent validation is not performed when values come from peer JSON. The  
same missing-validation pattern also affects other numeric peer fields such  
as `time`, `omit`, `burst`, and `mss`; however, the strongest confirmed  
availability impact in the source material is via oversized `parallel` and  
`len`.
Most relevant CWEs:
`CWE-20` (Improper Input Validation): peer-controlled control-channel  
integers are accepted without range checks.

`CWE-400` (Uncontrolled Resource Consumption): oversized values can drive  
excessive memory, CPU, socket, and thread use.




Affected Versions






The reviewed repository history indicates that the vulnerable assignments  
in `get_parameters()` are present in the `72fc90d` `3.17.1` baseline and  
remain present in the inspected current `HEAD` (`15586ce`). The  
corresponding sink code in `iperf_new_stream()` and server stream setup is  
also present in that baseline. Older versions may also be affected, but  
were not confirmed from the available history.


Proposed Fix






```diff
diff --git a/src/iperf_api.c b/src/iperf_api.c
@@ static int get_parameters(struct iperf_test *test)
   if ((j_p = iperf_cJSON_GetObjectItemType(j, "parallel",  
cJSON_Number)) != NULL)

       test->num_streams = j_p->valueint;
+    if ((j_p = iperf_cJSON_GetObjectItemType(j, "parallel",  
cJSON_Number)) != NULL) {
+        if (j_p->valueint < 1 || j_p->valueint > MAX_STREAMS) {
+            i_errno = IENUMSTREAMS;
+            r = -1;
+            goto done;
+        }
+        test->num_streams = j_p->valueint;
+    }
@@

   if ((j_p = iperf_cJSON_GetObjectItemType(j, "len", cJSON_Number)) !=  
NULL)

       test->settings->blksize = j_p->valueint;
+    if ((j_p = iperf_cJSON_GetObjectItemType(j, "len", cJSON_Number)) !=  
NULL) {
+        int blksize = j_p->valueint;
+        if ((test->protocol->id != Pudp && (blksize <= 0 || blksize >  
MAX_BLOCKSIZE)) ||
+            (test->protocol->id == Pudp &&
+             blksize > 0 &&
+             (blksize < MIN_UDP_BLOCKSIZE || blksize >  
MAX_UDP_BLOCKSIZE))) {
+            i_errno = (test->protocol->id == Pudp) ? IEUDPBLOCKSIZE :  
IEBLOCKSIZE;
+            r = -1;
+            goto done;
+        }
+        test->settings->blksize = blksize;
+    }
@@
+done:
      cJSON_Delete(j);
      return r;
```


Peer numeric fields such as `time`, `omit`, `burst`, and `mss` should also  
be reviewed and validated using the existing max/min constants where  
applicable.
------
This report was generated using AI technology. Always review AI-generated  
content prior to use