The race condition in rsync stems from a performance optimization codified decades ago: separating lstat() from opendir() lets rsync avoid holding directory handles while processing entries. This optimization predates symlink attacks as a mainstream threat model, and it creates a TOCTOU window where an attacker-controlled symlink in a path component can be swapped between the stat and open operations, allowing traversal outside the module root.
The 3.5.0 patch addresses this with a retry loop on ENOTDIR — it detects the race after it occurs and retries, rather than eliminating the window. This is not a fix; it's a deferral that makes exploitation probabilistic rather than impossible. The retry loop acknowledges the vulnerability exists and handles it probabilistically, preserving the performance characteristics that created it.
This is the third or fourth time rsync has faced this exact vulnerability class. Each CVE gets a localized patch, and the architectural condition persists. The portability argument against openat2/RESOLVE_BENEATH semantics isn't a technical constraint — it's an institutional commitment that functions as a permanent veto over architectural security improvements. Rsync could require Linux 5.6+ but chooses not to, explicitly accepting that older systems remain vulnerable.
The deeper problem is that rsync's module root was never a strong security boundary — it's a configuration boundary, not a capability boundary. The prerequisite 'attacker-controlled symlinks in path components' sounds narrow, but it describes the standard state of many production rsync use cases: build artifacts injecting symlinks, container image layers, deployment pipeline intermediate states. In these contexts, the prerequisite is pre-existing rather than an additional barrier.
When rsync runs as root during system replication, path traversal equals full filesystem disclosure under maximum privilege. The CVSS 5.9 score is wrong — it reflects a scoring system that can't capture architectural insecurity in tools used to replicate entire systems. The remediation that would actually address this requires capability dropping or namespace isolation on the module root, not a retry loop. That architectural investment won't happen until a compromise forces it.
The exposure timeline compounds the problem: the vulnerability persists in LTS branches, embedded distributions, and systems where rsync ships as a static binary and won't see updates for years. The 'fix' exists in the repository, but the vulnerability class persists in deployed artifacts. The real half-life of this problem isn't when 3.5.0 was tagged — it's when the last unpatched rsync binary finally gets replaced in the wild.