A flaw was found in iperf3. A remote attacker can exploit this vulnerability by sending crafted control-channel JSON with oversized numeric parameters, such as parallel and len, which are not properly validated by the server. This improper input validation can lead to excessive stream and thread creation, as well as large buffer allocations, causing resource exhaustion. Consequently, this can result in a Denial of Service (DoS) on the affected iperf3 server.

AIONLYREPORT package: iperf3-3.17.1-5.el101 ------ Summary: Unbounded numeric parameters from peer JSON can trigger resource exhaustion (blksize / numstreams / 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 getparameters() (src/iperfapi.c), server CREATESTREAMS processing (src/iperfserverapi.c), and iperfnewstream() buffer/stream setup (src/iperfapi.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 JSONwrite() 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

getparameters() accepts peer-controlled numeric fields from the control-channel JSON and assigns them directly without reapplying the bounds enforced by CLI parsing: c if ((jp = iperfcJSONGetObjectItemType(j, "parallel", cJSONNumber)) != NULL) test->numstreams = jp->valueint; ... if ((jp = iperfcJSONGetObjectItemType(j, "len", cJSONNumber)) != NULL) test->settings->blksize = jp->valueint; The strongest confirmed reachable sink is on the server path. During CREATESTREAMS, the server eventually calls iperfnewstream(), where len controls per-stream buffer sizing and parallel controls how many streams and worker threads are created: c sp = iperfnewstream(test, s, flag); ... if (ftruncate(sp->bufferfd, 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 MAXSTREAMS and MAXBLOCKSIZE, 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 getparameters() are present in the 72fc90d 3.17.1 baseline and remain present in the inspected current HEAD (15586ce). The corresponding sink code in iperfnewstream() 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/iperfapi.c b/src/iperfapi.c @@ static int getparameters(struct iperftest test) if ((jp = iperfcJSONGetObjectItemType(j, "parallel", cJSONNumber)) != NULL)

test->numstreams = jp->valueint; + if ((jp = iperfcJSONGetObjectItemType(j, "parallel", cJSONNumber)) != NULL) { + if (jp->valueint < 1 || jp->valueint > MAXSTREAMS) { + ierrno = IENUMSTREAMS; + r = -1; + goto done; + } + test->numstreams = jp->valueint; + } @@

if ((jp = iperfcJSONGetObjectItemType(j, "len", cJSONNumber)) != NULL)

test->settings->blksize = jp->valueint; + if ((jp = iperfcJSONGetObjectItemType(j, "len", cJSONNumber)) != NULL) { + int blksize = jp->valueint; + if ((test->protocol->id != Pudp && (blksize <= 0 || blksize > MAXBLOCKSIZE)) || + (test->protocol->id == Pudp && + blksize > 0 && + (blksize < MINUDPBLOCKSIZE || blksize > MAXUDPBLOCKSIZE))) { + ierrno = (test->protocol->id == Pudp) ? IEUDPBLOCKSIZE : IEBLOCKSIZE; + r = -1; + goto done; + } + test->settings->blksize = blksize; + } @@ +done: cJSONDelete(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

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

In the Linux kernel, the following vulnerability has been resolved:

tcp: correct handling of extreme memory squeeze

Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.

Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.

However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.

The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SOPEEK or SORCVBUF on the socket.

The following excerpt of a logging session, with own comments added, shows more in detail what is happening:

// tcpv4rcv(->) // tcprcvestablished(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcpinput.c/tcpdataqueue()/5257 ==== [5201<->39222]: tcpdataqueue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKBDROPREASONPROTOMEM [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcpdataqueue(<-) [5201<->39222]: tcptransmitskb(->) [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpselectwindow(->) [5201<->39222]: (inetcsk(sk)->icskack.pending & ICSKACKNOMEM) ? --> TRUE [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] returning 0 [5201<->39222]: tcpselectwindow(<-) [5201<->39222]: ADVERTISING WIN 0, ACKSEQ: 265600160 [5201<->39222]: [tcptransmitskb(<-) [5201<->39222]: tcprcvestablished(<-) [5201<->39222]: tcpv4rcv(<-)

// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcvwnd and tp->rcvwup accordingly, which means // we unconditionally shrink the window.

[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 0, winnow = 131184, 2 winnow = 262368] [5201<->39222]: [newwin >= (2 winnow) ? --> timetoack = 0] [5201<->39222]: NOT calling tcpsendack() [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpcleanuprbuf(<-) [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcprecvmsglocked(<-)

// After each read, the algorithm for calculating the new receive // window in tcpcleanuprbuf() finds it is too small to advertise // or to update tp->rcvwnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.

[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 262144, winnow = 131184, 2 winn ---truncated---