1619431 - Possible use of uninitialized memory in vp8_rd_pick_inter_mode

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Daniel Veditz [:dveditz]]

+++ This bug was initially created as a clone of Bug #1614250 +++

----------- 3 -----------

Possible use of uninitialized memory in vp8_rd_pick_inter_mode
(https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1738)

unsigned char *plane[4][3];
(https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1770)
get_predictor_pointers(cpi, plane, recon_yoffset, recon_uvoffset);
(https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1806)
---> entering get_predictor_pointers
---> (https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.h#82)
---> cpi->ref_frame_flags & VP8_LAST_FRAME // assume false
---> cpi->ref_frame_flags & VP8_GOLD_FRAME // assume false
---> cpi->ref_frame_flags & VP8_ALTR_FRAME // assume false
Return from function, no interveneing assignment to plane
if (x->e_mbd.mode_info_context->mbmi.ref_frame)
x->e_mbd.pre.y_buffer = plane[this_ref_frame][0]; <-- plane or this_ref_frame
(https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1848)

More detail: there are only three ref_frame_type flags availble, the ones
listed above (https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vpx/vp8.h#101)
So this bug can only be true if ref_frame_flags can be false

Comment 1

[Jean-Yves Avenard [:jya]]

Same as the bug 1619432.
Is this an actual issue with the running code, or just a static analyser warning that only test the method without context?

Anyhow, I'm not familiar with the vp8 software encoder. redirecting

Comment 2

[mlfbrown]

These are static warnings. I had to look through 400 of Firefox's old Clang warnings for a something separate, so I figured I should write up the ones that seemed maybe possible in practice. My apologies.

Comment 3

[Dan Minor [:dminor]]

With the update to libvpx 1.8.2 (Bug 1525393, landed Feb 28th), it looks like plane is now properly initialized: https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1770. I think this can be closed as a dupe or a worksforme.

Comment 4

[:Gijs (he/him)]

(In reply to Dan Minor [:dminor] from comment #3)

With the update to libvpx 1.8.2 (Bug 1525393, landed Feb 28th), it looks like plane is now properly initialized: https://searchfox.org/mozilla-central/source/media/libvpx/libvpx/vp8/encoder/rdopt.c#1770. I think this can be closed as a dupe or a worksforme.

Was this vulnerability actually one that would affect Firefox? If so, should bug 1525393 make it into 74 before release? If we dupe this over, we're effectively publicizing that a sec bug got fixed in this update that 68 and 74 won't have...

Comment 5

[Dan Minor [:dminor]]

I'm not familiar enough with libvpx to know if this is a theoretical or actual vulnerability. I think it would be risky to uplift the libvpx library update to 74, in case it exposes other problems. I have a list of things found by coverity in the update that I need to go through to see if there is anything serious. If there is, I think we'd want time to fix that on Nightly.

I thought the changes in https://github.com/mozilla-bteam/bmo/pull/1463 made it safe to dupe security bugs to non-security bugs, but I don't know for sure, which is why I didn't resolve this bug.

Comment 6

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Sounds like bug 1525393 fixes this. Using the depends field since it's not clear if marking as a dupe exposes bug 1525393 as relating to sec.

Comment 7

[Daniel Veditz [:dveditz]]

Because this got fixed by upstream changes without knowing about this specific issue it does not qualify for a bug bounty.