http: parse the full positive chunk-size range without signed overflow - #832

The overflow guard itself looks correct.

I reproduced the range difference on current trunk: with a 64-bit apr_off_t, trunk accepts through 0x0fffffffffffffff, while this change accepts through 0x7fffffffffffffff. In particular, 0x1000000000000000 is rejected with 413/AH01590 on trunk and passes chunk-size parsing with this patch.

The current three tests also pass on unmodified trunk, so they do not exercise the behavior changed here. Could you add a positive regression case that fails with the old -4 guard and passes with this change, while accounting for the build's apr_off_t width? Using a body-consuming handler such as /h1test/echo would make it possible to distinguish successful chunk-size parsing from the later incomplete-body condition.

The comment above parse_chunk_size() should also be updated: it still describes the old sign-bit overflow path and says the too-many-bits case returns APR_EGENERAL, while that path actually returns APR_ENOSPC.

The remaining ctx->remaining < 0 check is unreachable after the pre-shift guard and can be removed as well.

RFC 9112 requires recipients to handle potentially large hexadecimal chunk sizes without integer-conversion overflow or precision loss; the new pre-shift check preserves that property while extending the accepted range.

Devil's advocate: chunk sizes greater than 16-bit values are... unlikely and anything needing more than 24 bits is pathological. That new test is barely readable to me (a mere human) and the old code worked 100% of the time already. Why?

Plus, the newly unreachable APR_ENOSPC path is going to trip a (future, smarter) compiler/static analyser and some poor engineer will have to explain why it doesn't matter.

This was found with GPT Sol 6 Daybreak Blue (Cyber Security Model) during a run to try to win the zeroday.cloud RCE prize.

I am commiting any non-qualifying fixes it finds. Take that for what it's worth.

• Tyler