GHSA-j9wh-5jmp-2m64
CVE 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