ubeddulla opened a new pull request, #3379: URL: https://github.com/apache/brpc/pull/3379
### What problem does this PR solve? Issue Number: Problem Summary: `DecodeInteger` keeps consuming HPACK continuation octets while `tmp < MAX_HPACK_INTEGER`. A run of `0x80` octets carries a zero payload, so `tmp` never grows and that guard never trips, while the shift amount `m` keeps climbing; once `m` reaches 64 the `<< m` on a `uint64_t` is undefined behavior. UBSan reports `shift exponent 70 is too large for 64-bit type`. It is reachable from any HTTP/2 or gRPC peer via a crafted HEADERS frame whose index is encoded as `0xFF` followed by continuation octets. ### What is changed and the side effects? Changed: Reject the over-long encoding once `m` reaches 32, before the shift can leave the type width. A valid integer below `MAX_HPACK_INTEGER` needs only a handful of continuation octets, so no well-formed input is turned away. A regression test in `brpc_hpack_unittest.cpp` decodes `0xFF` plus a long run of `0x80` and checks it is rejected. Side effects: - Performance effects: one extra comparison per continuation octet, no measurable change. - Breaking backward compatibility: none. --- ### Check List: - Please make sure your changes are compilable. - When providing us with a new feature, it is best to add related tests. - Please follow [Contributor Covenant Code of Conduct](https://github.com/apache/brpc/blob/master/CODE_OF_CONDUCT.md). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
