CVE-2026-71218: Iperf3: unbounded peer-controlled allocation in iperf3 json_read() allows unauthenticated remote memory exhaustion

AIONLYREPORT package: iperf3-3.17.1-5.el101 ------ Summary: Unbounded JSON message length leads to remote memory-exhaustion DoS in JSONread(): JSONread() 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.el101, control-channel parser in src/iperfapi.c, function JSONread(). Version affected: iperf3-3.17.1-5.el101 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/iperfapi.c, JSONread() 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 = cJSONParse(str); } } } free(str); } A remote peer can reach this on the server path iperfaccept() -> iperfexchangeparameters() -> getparameters() -> JSONread(). Optional authentication, when configured, is evaluated only after getparameters(), 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.createconnection((HOST,PORT)) cookie=b"A"36+b"\0" # 37 bytes s.sendall(cookie) n=25610241024 # 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: JSONread() 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/iperfapi.c b/src/iperfapi.c @@ +#define IPERFMAXJSONLEN (1024 1024U) / 1 MiB control-channel cap / @@ static cJSON JSONread(int fd) hsize = ntohl(nsize); + hsize = ntohl(nsize); + if (hsize == 0 || hsize > IPERFMAXJSONLEN) { + 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, extradata, or authtoken to reduce post-parse amplification. ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat

Iperf3: unbounded peer-controlled allocation in iperf3 jsonread() allows unauthenticated remote memory exhaustion

— Microsoft