+dalecurtis for triage

Do you have a reproduction case for this crash that you can share?

This is behind the enable av1 decoder flag (only available on canary/dev), but +aom folks for triage.

Thanks. It's not clear to me that this would have security implications but it's hard to say without understanding the cause.

johannkoenig@ and tomfinegan@, friendly ping?

This is flagged as a potential security bug, is there anyone with time to have a look?

Johann is OoO this week, and I won't have cycles to dig into this until early next week due to ongoing AV1 specification work. 

Reaching this code requires enabling a flag that's disabled by default. It sounds like the delayed investigation should be acceptable here. Does this need immediate attention? I can reach out to teammates and request assistance if it's felt that this is truly urgent.

Thanks, and sorry for the delayed response.

Thanks, I'll assign to you for now then, and yes if this is default-disabled then it can wait until next week.

I am setting security flags based on it being a memory corruption on write, but that can be revisited after more analysis.

I'm attaching an IVF which triggers it with UBSAN aomdec (from the test-20170915 branch that Chromium uses).

Chrome cannot read IVF, or only in unit tests apparently.

https://cs.chromium.org/chromium/src/media/filters/BUILD.gn?l=238&rcl=069039783c0cf6442af273fb02e10bcb25a41b2e

Although the raw stream can probably be manually muxed into WebM for regular Chrome consumption somehow.

$ ./aomdec 816336.ivf -o 816336.y4m

aom_dsp/x86/loopfilter_sse2.c:288:3: runtime error: store to misaligned address 0x7f8567434b96 for type 'int', which requires 4 byte alignment
0x7f8567434b96: note: pointer points here
 80 80 80 80 80 80  80 7f 7f 7f 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00
             ^ 
    #0 0x84186a in aom_lpf_vertical_4_sse2 aom/aom_dsp/x86/loopfilter_sse2.c:288:27
    #1 0x6a97f9 in av1_filter_block_plane_vert aom/av1/common/av1_loopfilter.c:3080:13
    #2 0x6a8db0 in av1_loop_filter_rows aom/av1/common/av1_loopfilter.c:3366:9
    #3 0x6aaa40 in av1_loop_filter_frame aom/av1/common/av1_loopfilter.c:3493:3
    #4 0x6530ab in decode_tiles aom/av1/decoder/decodeframe.c:3826:3
    #5 0x64779d in av1_decode_frame aom/av1/decoder/decodeframe.c:5377:19
    #6 0x67eef1 in av1_receive_compressed_data aom/av1/decoder/decoder.c:382:3
    #7 0x643ac5 in frame_worker_hook aom/av1/av1_dx_iface.c:373:31
    #8 0x6936f3 in execute aom/aom_util/aom_thread.c:134:27
    #9 0x64241b in decode_one aom/av1/av1_dx_iface.c:548:5
    #10 0x634553 in decoder_decode aom/av1/av1_dx_iface.c:734:15
    #11 0x62cf8e in aom_codec_decode aom/aom/src/aom_decoder.c:113:11
    #12 0x4fb27f in main_loop aom/aomdec.c:781:13
    #13 0x4f9206 in main aom/aomdec.c:1065:49
    #14 0x7f856ab4df44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
    #15 0x420cab in _start (aom/aomdec+0x420cab)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior aom_dsp/x86/loopfilter_sse2.c:288:3 in 

Deleted: 816336.ivf 84 bytes

816336.ivf 84 bytes Download

Another unrelated complaint from UBSAN.

av1/decoder/decoder.c:521:53: runtime error: left shift of 207 by 24 places cannot be represented in type 'int'
    #0 0x683e4a in av1_parse_superframe_index aom/av1/decoder/decoder.c:521:53
    #1 0x633cf2 in decoder_decode aom/av1/av1_dx_iface.c:654:9
    #2 0x62cf8e in aom_codec_decode aom/aom/src/aom_decoder.c:113:11
    #3 0x4fb27f in main_loop aom/aomdec.c:781:13
    #4 0x4f9206 in main aom/aomdec.c:1065:49
    #5 0x7f272dea1f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
    #6 0x420cab in _start (aom/aomdec+0x420cab)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior av1/decoder/decoder.c:521:53 in 

Deleted: 816336.ivf 81 bytes

816336.ivf 81 bytes Download

Given that this is behind a flag I don't plan on investigating issues such as this. There have been huge amounts of changes since this pre-release snapshot was checked in and we are running a variety of sanitizers upstream that people are starting to pay attention to.

In addition, I don't believe unaligned stores are a security issue, only a performance one.

Deferring to Johann on this:
- Upstream changes since the snapshot make backports infeasible. (Over 2400)
- This is behind a flag and AV1 content availability is extremely limited.

In addition to the above I'm confused by the addition of the Security_Severity-High label on this issue. Is there a known exploit going around that uses unaligned stores as an attack vector?

Marking WontFix.

Re #10: The shift doesn't seem related to the unaligned store. However, superframes no longer exist in AV1, so that should be considered WontFix as well since both issues will be invalidated when the bitstream is finalized and the pre-release bitstream version of the library is replaced by something more current.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot