CVE-2026-45232: Verified Repro With Script Download

Summary

CVE-2026-45232 is an off-by-one out-of-bounds stack write vulnerability in the rsync utility. The bug resides in establish_proxy_connection() within socket.c. When rsync connects through an HTTP proxy (configured via RSYNC_PROXY), it reads the proxy's CONNECT response into a 1024-byte stack buffer. If the proxy returns an overlong response (1023+ bytes without a newline terminator), post-loop null-termination logic writes one byte past the buffer's end, corrupting adjacent stack memory.

Impact

• Package: rsync (C CLI tool)
• Affected versions: < 3.4.2
• Fixed version: 3.4.3
• Risk level: Low (NVD CVSS 3.1 base 3.1)
• Consequences: A malicious or MITM'd HTTP proxy can trigger a single-byte stack overwrite, potentially leading to a crash or undefined behavior. The overwritten byte is always a null terminator (\0), and the attacker does not control the offset, limiting exploitability.

Root Cause

In socket.c, establish_proxy_connection() declares a stack buffer char buffer[1024] and reads the proxy response one byte at a time into buffer[0] through buffer[1022]. The loop condition is cp < &buffer[sizeof buffer - 1].

If no newline arrives before the buffer is filled, cp is left at &buffer[1023] (the last valid index). The post-loop code then executes:

if (*cp != '\n')
    cp++;
*cp-- = '\0';

Because *cp was never written by the loop (it contains stale stack data), the if is usually true, so cp++ advances past the array to &buffer[1024]. The subsequent *cp = '\0' writes one byte out of bounds.

Fix commit: a5fc5ebe7a8ef1aa72f6e344599f97fd4427ecba ("socket: reject over-long proxy response line")

The fix:

1. Increases the buffer size to PROXY_BUF_SIZE + 1 (1025 bytes) for safe null-termination
2. Adds an explicit check: if cp == &buffer[PROXY_BUF_SIZE - 1], reject with "proxy response line too long" instead of writing past the buffer
3. Correctly null-terminates within bounds for shorter responses

Reproduction Steps

1. repro/reproduction_steps.sh clones the rsync repository, checks out v3.4.2 (vulnerable) and v3.4.3 (fixed), and builds both with AddressSanitizer (-fsanitize=address).
2. It starts a minimal Python TCP mock proxy that binds to a local ephemeral port, accepts one connection, reads the CONNECT request headers, and sends exactly 1023 bytes of 'X' with no newline terminator.
3. It runs rsync via RSYNC_PROXY=127.0.0.1:<port> against each build.
4. Expected behavior:
   • v3.4.2 (vulnerable): AddressSanitizer reports stack-buffer-overflow at establish_proxy_connection (socket.c:95), and rsync aborts.
   • v3.4.3 (fixed): rsync prints "proxy response line too long" and exits with error code 10 (non-zero but no crash).

Evidence

• Log files:
  • logs/rsync_v3.4.2_proxy.log — ASan output for the vulnerable build
  • logs/rsync_v3.4.3_proxy.log — stderr for the fixed build
• ASan excerpt (vulnerable build):

  ==7440==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f747c600940
  WRITE of size 1 at 0x7f747c600940 thread T0
      #0 establish_proxy_connection /tmp/.../rsync/socket.c:95
      ...
  Memory access at offset 2368 overflows this variable
      [1344, 2368) 'buffer' (line 55)
  

• Fixed build excerpt:

  proxy response line too long
  rsync error: error in socket IO (code 10) at clientserver.c(141) [Receiver=3.4.3]
  

• Runtime manifest: repro/runtime_manifest.json records build versions, exit codes, ASan excerpt, payload size (1023 bytes), and confirmation flags.

Recommendations / Next Steps

1. Upgrade to rsync >= 3.4.3 to obtain the bounds-check fix.
2. Network controls: Restrict proxy configurations (RSYNC_PROXY) to trusted infrastructure to reduce exposure to malicious proxies.
3. Testing: The upstream test testsuite/proxy-response-line-too-long.test should be included in CI to prevent regression.
4. Build hardening: Compile with -fstack-protector-strong and ASan in QA pipelines to detect similar stack overwrites early.

Additional Notes

• Idempotency: The reproduction script was run twice consecutively; both runs produced identical ASan crashes on v3.4.2 and clean rejection on v3.4.3.
• Payload specifics: 1023 bytes of 'X' without a newline is the exact boundary that triggers the off-by-one. A shorter payload does not trigger the bug; a newline-terminated payload exits the read loop early.
• Build environment: Tested on x86_64-pc-linux-gnu with GCC and AddressSanitizer. The bug is architecture-agnostic, but ASan makes the one-byte overwrite reliably observable.