sahvx655-wq opened a new pull request, #3334: URL: https://github.com/apache/brpc/pull/3334
avc_nalu_read_uev decodes an Exp-Golomb ue(v) in two passes. The first loop counts leading-zero bits and correctly stops on stream->empty(), but the second loop then reads leadingZeroBits suffix bits back to back with no such check, and BitStream::read_bit() dereferences its cursor unconditionally (its own comment notes empty() must be checked first). A sequence parameter set whose bitstream ends inside or just after the leading-zero run therefore makes the suffix loop walk off the end of the rbsp buffer. I traced it with a guard-page harness: handing the function a one-byte all-zero bitstream empties the stream in the first loop, leadingZeroBits comes out as 7, and the suffix loop first read_bit() lands on the following PROT_NONE page and takes a SIGBUS. The same bytes reach here from the network via AVCDecoderConfigurationRecord::Create then ParseSPS when an AVC sequence header is parsed. The fix re-checks stream->empty() inside the suffix loop and returns -1 when the data runs out, matching what the leading-zero loop and the sibling avc_nalu_read_bit already do and what every caller already treats as a decode failure. Keeping the bound in the reader covers every Exp-Golomb field in the SPS rather than asking ParseSPS to pre-measure each one. Left as is this is an out-of-bounds read of attacker-controlled length (up to ~30 bits past the buffer) driven by a publisher-supplied sequence header, leaking adjacent memory into the decoded value or crashing the parser. -- 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]
