If you're running rsync 3.0.1 through 3.5.0, you have an off-by-one heap corruption vulnerability in argument vector construction. The bug: read_args() allocates argv with exactly the element count needed for arguments, treating the NULL terminator as a conceptual requirement rather than an actual array slot. When argument count exactly fills the allocation, the NULL write corrupts the heap metadata or object immediately following argv in memory.
What makes this nuanced rather than a straightforward critical is the trigger condition. The vulnerability activates only on exact-buffer-fill, meaning most production deployments likely ran vulnerable binaries for years without ever hitting the fault condition. Whether you can reliably trigger this through a malicious rsync server depends on how rsync's protocol constructs arguments—if argument generation deterministically produces full-buffer conditions, exploitability is high; if it requires unusual configurations, the practical risk may be lower than CVSS 8.2 suggests. Test your specific rsync usage pattern before escalating urgency based on CVSS alone.
Examine the 3.5.0 fix before treating this as closed. A one-line +1 allocation patch addresses the symptom but leaves the underlying discipline gap intact if other argument-generation paths weren't audited. Check whether the commit includes a broader pattern search or whether similar off-by-one risks remain in argument construction code elsewhere in rsync.
The tooling lesson: fuzzing pipelines that exercise file data and exclusion patterns may never have touched argument marshaling—the specific coverage gap, not a generic failure to make C programmers more defensive. Prioritize fuzzing argument construction paths in similarly stable, rarely-touched infrastructure code where allocation assumptions have calcified.