sahvx655-wq opened a new pull request, #3366:
URL: https://github.com/apache/brpc/pull/3366

   While reading FLV tags off a playback buffer I traced a stream that came 
back as one oversized message with the rest of the buffer swallowed. The 
DataSize in a video/audio tag header is a 3-byte field read straight off the 
wire in FlvReader::Read; the code then consumes the single 
VideoTagHeader/AudioTagHeader byte and cuts `msg_size - 1` body bytes. When 
DataSize is 0 that subtraction wraps to 0xFFFFFFFF (msg_size is uint32_t), so 
cutn() drains everything left in the buffer into one message and desyncs every 
tag after it. A malicious or corrupt HTTP-FLV source can trigger it with a 
single 15-byte tag.
   
   Reject DataSize of 0 with EINVAL before any bytes are consumed, since a 
valid audio/video tag always carries at least the one-byte codec header that 
the reader immediately reads. The guard sits next to the msg_size read so the 
underflow can never reach cutn(), and the same fix is applied to both the video 
and audio readers. Added a regression test that feeds a zero-DataSize tag and 
checks the reader errors without draining the buffer.


-- 
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]

Reply via email to