kwiberg: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I've found the bug, or at least tracked it closer to its lair. In WebRtcIlbcfix_GetCbVec, near the end (https://cs.chromium.org/chromium/src/third_party/webrtc/modules/audio_coding/codecs/ilbc/get_cd_vec.c?rcl=1471447605&l=96), there's first a call to WebRtcSpl_FilterMAFastQ12 which writes to the first cbveclen + 5 elements of the previously uninitialized stack array tempbuff2, followed by a call to WebRtcIlbcfix_CreateAugmentedVec which reads all SUBL + 5 elements of tempbuff2.
In our unit tests, cbveclen is always equal to SUBL when we execute this code, but in this fuzzer run, cbveclen is 18 and SUBL is 40. So we read uninitialized memory from tempbuff2, and crash a while later when the outcome of a branch depends on the contents of that memory.
I haven't tracked down why cbveclen == SUBL in the unit tests but not in this fuzzer run, so I don't yet know what the actual problem is.
Comment 1 by mmoroz@chromium.org
, Jun 3 2016Components: Blink>WebRTC>Audio
Labels: Pri-2
Owner: pbos@chromium.org