## Ticket: CVE-2026-45232 — rsync off-by-one out-of-bounds stack write

**Advisory**: CVE-2026-45232 (no GHSA) — https://nvd.nist.gov/vuln/detail/CVE-2026-45232
**CVE**: CVE-2026-45232 | **CWE-193** (Off-by-one Error) / **CWE-787** (Out-of-Bounds Write)
**Severity**: Low — NVD CVSS 3.1 base 3.1 (per NVD's own analysis)
**Package**: `rsync` (C, CLI tool) | **Repository**: https://github.com/RsyncProject/rsync (official mirror; upstream also at `git.samba.org/rsync.git`)

### Impact

`rsync` can connect to a remote daemon through an HTTP proxy. The function
`establish_proxy_connection()` in `socket.c` performs an **off-by-one
out-of-bounds write** on a **stack buffer** while handling the proxy server's
`CONNECT` response. A **malicious proxy server** that returns an overlong
`CONNECT` response corrupts memory adjacent to that stack buffer.

The write is a single byte past the buffer end, so impact is limited (NVD rates
the issue **Low**), but it is still out-of-bounds stack corruption driven by
attacker-controlled input.

### Affected / fixed versions

Affected: `rsync` `< 3.4.3`.
Fixed: **`3.4.3`**.

Reproduce on a vulnerable build (**`3.4.2`**) and verify the fix on
**`3.4.3`**.

### Where to look

The advisory data provided does not pin a fix commit. Clone the repository and
inspect the `3.4.2`→`3.4.3` history of `socket.c`:

```bash
git clone https://github.com/RsyncProject/rsync.git
cd rsync && git log v3.4.2..v3.4.3 -- socket.c
```

The fix is expected to correct the buffer indexing / bounds check in
`establish_proxy_connection()` so the `CONNECT` response is parsed without
writing past the stack buffer.

### Reproduction approach

The bug is a single-byte stack overwrite, so build with **`-fstack-protector`
and/or AddressSanitizer** to make it reliably observable as a crash / detector
error rather than silent corruption. No real remote rsync server with data is
needed — only the proxy handshake path is exercised.

1. Build **vulnerable** `rsync 3.4.2` with `-fstack-protector-strong` and/or
   ASan.
2. Stand up a minimal mock HTTP proxy (a small local listener) that returns an
   **overlong `CONNECT` response**.
3. Invoke `rsync` configured to connect through that proxy (e.g. via
   `RSYNC_PROXY`) so `establish_proxy_connection()` parses the overlong
   response.
4. Build **fixed** `rsync 3.4.3` the same way and repeat with the same mock
   proxy.

### Expected result

| Build | Proxied connection, proxy returns overlong `CONNECT` response | Outcome |
|-------|----------------------------------------------------------------|---------|
| `rsync 3.4.2` (vulnerable) | `establish_proxy_connection()` writes one byte past the stack buffer | **stack-smashing abort / ASan stack-buffer-overflow** (non-zero exit) |
| `rsync 3.4.3` (fixed) | response parsed within bounds | **clean** — no abort / no ASan error |

- **Vulnerable indicator**: on `3.4.2`, the run triggers a stack-protector abort
  or an ASan `stack-buffer-overflow` and exits non-zero.
- **Fixed indicator**: on `3.4.3`, the same scenario completes without a
  stack-smashing abort or ASan error.

### Expected artifacts

- `reproduction_steps.sh` — builds both rsync versions (with stack protector /
  ASan), starts the mock proxy, runs the proxied `rsync` invocation against
  each build, and records the outcome.
- `validation_verdict.json` — `verdict: confirmed`, with the vulnerable
  (abort / ASan error) and fixed (clean) indicators captured.
- Logs capturing the rsync output and exit / detector status for `3.4.2` and
  `3.4.3`.