Skip to content

GHSA-j9wh-5jmp-2m64 on CTRL-OS 26.05

Aliases: GHSA-j9wh-5jmp-2m64, CVE-2026-70462

Packages: rsync

Status: Plausible

Advisory Information

A malicious peer sends an MSG_IO_TIMEOUT value that the receiving side folds into its own timeout arithmetic, where the multiplication overflows a signed int. The resulting deadline computation is undefined behaviour: depending on build and compiler semantics it hangs (a negative poll timeout means "wait forever"), spins, or floods keepalives -- in every case defeating the very mechanism meant to bound a stalled transfer.

MSG_IO_TIMEOUT is accepted only by the connecting client (server and generator roles reject it), which is why this is AV:N/PR:N/UI:R.

The same message carried a second defect on the same boundary, reported separately by Leonid Bugaev: a non-positive value was accepted and disabled the receiver's own I/O timeout outright, so a peer could suppress it rather than overflow it (pre-existing since 2009). Both are covered here -- the value is now rejected when non-positive and capped when large.

The reporter demonstrated the spin under -fwrapv / -fno-strict-overflow; at -O2 the compiler's assumptions happened to mask it, which is precisely why the overflow must be prevented rather than relied upon. Fixed by capping the peer-supplied value on receipt and making set_io_timeout()'s arithmetic overflow-safe. A regression test builds the affected translation unit with -fwrapv so the guard is exercised, not optimised away.

Affected: 3.1.0 through 3.4.4 (the MSG_IO_TIMEOUT message entered in 3.1.0)

Fixed in: 3.5.0 (cap the peer value on receipt; overflow-safe arithmetic)

Reporter: Z3R0S! (z3r0s6)

Tests: msg-io-timeout-overflow, msg-io-timeout-zero

Updates

2026-08-14 16:57 CEST

Metadata changes:

  • Status for package rsync: “Plausible”

2026-08-14 16:55 CEST

Metadata changes:

  • Status for package rsync: “New”