REDHAT-BUG-2460984: Input Validation

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