c-ares / c-ares / 28529475594

90%

Build Type

push

github

Committed by web-flow

Commit Message

fix: prevent undefined-behavior left shift in ares_calc_query_timeout() (#1151)

## Summary

Fixes #1144.

`ares_calc_query_timeout()` left-shifts `timeplus` by `rounds` without
bounding the exponent. When a query is requeued 64+ times for a single
server (persistent connection failures with `num_servers == 1`),
`rounds` reaches 64 and `timeplus <<= 64` invokes undefined behavior on
a 64-bit `size_t` (C11 §6.5.7¶3).

The existing `channel->maxtimeout` clamp runs **after** the shift and
cannot prevent the UB.

## Fix

Saturate `timeplus` to `SIZE_MAX` when:
- `rounds >= sizeof(timeplus) * CHAR_BIT` (shift width ≥ type width),
**or**
- `timeplus > (SIZE_MAX >> rounds)` (shift would overflow).

The subsequent `maxtimeout` clamp then normalizes the value as before,
preserving retry-timeout semantics.

## Verification

Tested with UBSan-instrumented build (`-fsanitize=undefined`) at base
commit `46b7f689`:
- **Before**: `src/lib/ares_process.c:1156:14: runtime error: shift
exponent 64 is too large for 64-bit type 'size_t' (aka 'unsigned long')`
- **After**: No UBSan findings; harness exits cleanly (exit code 0)

Pre/post validation matrix:
| Check | Pre-patch | Post-patch |
|-------|-----------|------------|
| Build | exit 0 | exit 0 |
| Reproducer exit | exit 1 (UB triggered) | exit 0 (clean) |
| UBSan shift error | present | absent |

Reproducer: configure c-ares with a single non-responsive DNS server
(`127.0.0.1:53` with nothing listening), set `opts.tries >= 65`,
`opts.timeout = opts.maxtimeout = 1`. After 64 connection-failure
requeues through the `read_conn_packets → handle_conn_error →
ares_requeue_query → ares_send_query → ares_calc_query_timeout` path,
the UB fires without this patch.

Signed-off-by:  Song Li (@SongTonyLi)

Coverage Stats

3 of 4 new or added lines in 1 file covered. (75.0%)

1 existing line in 1 file now uncovered.

22923 of 25005 relevant lines covered (91.67%)

12965.81 hits per line