commit afdbf8e6f881bda6cfe8c8c8c46f2167db8b0b05
author Chema Gonzalez <chemag@fb.com> Wed Jun 24 17:05:22 2020
committer Commit Bot <commit-bot@chromium.org> Wed Jun 24 21:54:45 2020
tree c8079e22f4258751e997028226e2dba9f73ed4ce
parent 603cc3a31e832565829a578b05036bd9def54796

H264: Fix stap-a-to-annex-b loop over-read

While converting the aggregated (stap-a) packet transform packet
framing input into an annex-b framing copy, the two loops (both the
required size calculation and the stap-a-to-annex-b copy) may
over-read the input buffer.

In both buffers, `nalu_ptr` follows the input (stap-a) buffer, which
is located in `data`, and whose length is `data_size`. Buffer is read
until `nalu_ptr` reaches the end of the buffer. Issues is that the 5th
line in the loop:

```
    uint16_t segment_length = nalu_ptr[0] << 8 | nalu_ptr[1];
```

This line accesses `nalu_ptr[1]`, which needs to be protected in
the loop condition. Let's assume `data_size = 4`, and that we restart
the loop with `nalu_ptr = data + 3`. The condition of the loop does
hold (`nalu_ptr = data + 3 < data + data_size`), but the 5th line
will access to `data[3+1] = data[4]`, which is an over-read.

Tested:

```
$ ninja -C out/Default
$ out/Default/modules_unittests --gtest_filter=PacketBuffer*:H264*:RtpPacketizerH264Test*:VideoRtpDepacketizerH264Test*:TestH264SpsPpsTracker* --logs
...
[  PASSED  ] 97 tests.
```

Change-Id: I8b8aaf7d12b0bb154430b8922f099cd49e684762
Bug: webrtc:11698
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177140
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Niklas Enbom <niklas.enbom@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31561}