ubeddulla opened a new pull request, #3497: URL: https://github.com/apache/brpc/pull/3497
### What problem does this PR solve? Issue Number: resolve N/A Problem Summary: UbrTrxRecvBlockMode and StartReadv read a chunk's msg_len and cur_index straight from the receive-ring header that the remote peer writes into shared memory, then memcpy msg_len minus cur_index bytes out of the fixed 60-byte payload.inner without checking either value. A peer that sets msg_len above UBR_MSG_PAYLOAD_LEN (60), or cur_index above msg_len so the uint8_t subtraction wraps, makes that copy read past the payload into the adjacent chunk header and neighbouring ring slots. Under ASAN this shows up as a heap-buffer-overflow read of size 255 at 0 bytes after the 64-byte chunk. The send path already caps msg_len at UBR_MSG_PAYLOAD_LEN, so only the receive side was missing the check. ### What is changed and the side effects? Changed: Added IsRecvChunkHeaderValid (msg_len <= UBR_MSG_PAYLOAD_LEN and cur_index <= msg_len) and apply it at both receive sites before the copy, rejecting a malformed chunk with errno=EBADMSG and the same UBRING_ERR the existing pre-checks return. Added a regression test in brpc_ubring_unittest.cpp. Side effects: - Performance effects: one comparison per chunk, negligible. - Breaking backward compatibility: none. Valid chunks (msg_len <= 60, cur_index <= msg_len) behave exactly as before. --- ### 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]
