iperf3: upgrade to 3.21

[Siva Kannan (shivashanmugam)]

Summary

Upgrades iperf3 in Azure Linux 3.0 from 3.17.1-5 to 3.21-1.

3.0 has been on 3.17.1 since Aug 2024 under security-only servicing. That policy is correct for a stable branch, but it means upstream non-security stability fixes never land — and one of them is currently breaking our own test infrastructure.

Motivation

iperf3 3.16 replaced the single-threaded model with thread-per-stream for -P. At high stream counts the client is terminated by a signal during end-of-test teardown, after the data transfer has already completed, so the final summary is never emitted.

This is reproducing reliably at -P 128 and fails the verify_sriov_interrupts_change SRIOV test on every arm64 image build since 2026-08-19.

Observed in LISA run 734950:

cmd: ['sudo', 'sh', '-c', 'iperf3 -t 120 -c 10.0.0.5 -P 128 -B 10.0.0.4']
[SUM] 118.00-119.00 sec  1.39 GBytes  11.9 Gbits/sec  5617
execution time: 120.623 sec, exit code: -1

Traffic was healthy at ~11.9 Gbits/sec right up to the end. Exit code -1 is paramiko's value when the SSH channel closes with exit-signal rather than exit-status, i.e. the process was killed by a signal. No kernel oops or OOM on either node's serial console — this is a userspace crash in iperf3's own teardown path, not an SRIOV or kernel regression.

Beyond the immediate breakage, the test can never reach its actual assertions (interrupt counts per IRQ, distribution across CPUs), so a genuine kernel interrupt-affinity regression would currently be invisible behind this failure.

Relevant upstream fixes:

Release	Fix
3.18	Three threading segfaults — pthread_cancel on uninitialized thread (#1801), thread recycling (PR #1761), signal handling in threads (PR #1752)
3.19	Additional segfault (#1807)
3.21	End-of-test socket-close race (PR #1990); PTHREAD_CANCEL_ASYNCHRONOUS → DEFERRED (PR #2004)

3.21 is chosen over 3.19.1 because PR #1990 and PR #2004 are in the same failure class as the crash we are hitting.

Patch changes

Dropped — each verified present in the 3.21 source, not assumed from changelogs:

Patch	Upstream in	Verification
CVE-2024-53580.patch	3.18	get_parameters uses iperf_cJSON_GetObjectItemType(...) type-checked access
CVE-2025-54349.patch	3.19.1	decrypt_rsa_message has OPENSSL_malloc(output_buffer_len + 1) and int ret = 0
CVE-2025-54350.patch	3.19.1	Reverse-applies cleanly against 3.21
openssl_encrypt_buffer_size.patch	3.20	encrypt_rsa_message sets encryptedtext_len = output_buffer_len before EVP_PKEY_encrypt
CVE-2026-71218.patch	3.21	JSON_read guards rc == sizeof(nsize) and hsize > 0 && (max_size == 0 || hsize <= max_size)

Retained:

• CVE-2026-71217.patch — upstream PR [main] Adding a missing return in pkggragh.go. #2039 merged 2026-05-20, which postdates the 3.21 release (2026-04-09), so it is still required. Rebased onto pristine upstream commit 494dd377, which applies cleanly to 3.21. The previous downstream version additionally carried a MAX_OMIT_TIME define in iperf.h that 3.21 already has; only the iperf_api.c value-range checks are still needed.
• disablepg.patch — Azure Linux local (-pg removal), still applies cleanly.

Also updated

• iperf3.signatures.json → dd289b6700d3bc33eda7fa3ce6db217d6ca42239edbcb2e7f152bf7bf5c8a5aa
• cgmanifest.json → version and downloadUrl bumped to 3.21

Verification done

• Source tarball downloaded from the exact Source0 URL; sha256 recorded above matches.
• Patch stack applied in spec order (disablepg, then CVE-2026-71217) against a pristine 3.21 extraction — both apply cleanly.
• Post-apply assertions: iperf3_profile_CFLAGS = -g (no -pg), and the get_parameters value-range checks are present.
• Both JSON files validated.

Not yet done — why this is a draft

• No local RPM build. Needs a real make build-packages / container build on x86_64 and aarch64.
• %check runs make check — should be confirmed green on the new version.
• Re-run verify_sriov_interrupts_change on an arm64 image built with this package to confirm the SRIOV test recovers.
• Confirm no consumer depends on libiperf ABI. multiperf was checked and does not link against iperf3, and the only other consumer is this package's own -devel, but worth a second pair of eyes.
• Maintainer call on whether a version rebase is acceptable on 3.0's security-only branch, vs. backporting just the three 3.18 threading commits as 3.17.1-6. I went with the rebase since it also picks up PR [main] [core] Upgrade python-netaddr to 0.8.0 #1990/[main] [core] gcc: Add libasan, liblsan, libtsan, libubsan provides #2004, but I'll switch if the branch policy says otherwise.

/cc @microsoft/azurelinux-maintainers