I used to work on a non-RHEL Red Hat product. Every bug needed a whole lot of work after the code was written. A QE person would need to test it, often needing

I used to work on a non-RHEL Red Hat product. Every bug needed a whole lot of work after the code was written. A QE person would need to test it, often needing dev assistance to understand what even needed testing. A docs person would need to determine what docs needed to be written, again with dev assistance, and for security stuff a ProdSec person would also be involved. It also took at least 10 minutes to discuss a bug like this in bug triage meeting, involving at least 10 people. Some bugs needed a lot more discussion than that. Red Hat's process incredibly expensive and decisions are primarily made based on how it affects the customer. Iperf3 is a relatively obscure tool from a general RHEL user perspective. While the vulnerability may be serious from the perspective of iperf3, a Red Hat customer won't be running it on the public internet for long periods of time. Most iperf3 usage I've seen was in dedicated test environments. Practically, this won't be exploitable, and if so, iperf3 will crash, nothing more will happen according to the bug. Is it great? No, it isn't. But an often-overlooked part of open source is how much work it takes to merge a PR. I've had cases on hobby projects when it took way more work to merge it than to write it.