Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Heap-buffer-overflow in sse-motion.cc: ff_hevc_put_hevc_epel_pixels_8_sse #337

Open
fdu-sec opened this issue Oct 10, 2022 · 5 comments
Open

Heap-buffer-overflow in sse-motion.cc: ff_hevc_put_hevc_epel_pixels_8_sse #337

fdu-sec opened this issue Oct 10, 2022 · 5 comments
Labels
could not reproduce

Comments

@fdu-sec
Copy link

fdu-sec commented Oct 10, 2022

Description

Heap-buffer-overflow (/libde265/build/libde265/liblibde265.so+0x262cc1) in ff_hevc_put_hevc_epel_pixels_8_sse(short*, long, unsigned char const*, long, int, int, int, int, short*)

Version

$ ./dec265 -h
 dec265  v1.0.8
--------------
usage: dec265 [options] videofile.bin
The video file must be a raw bitstream, or a stream with NAL units (option -n).

options:
  -q, --quiet       do not show decoded image
  -t, --threads N   set number of worker threads (0 - no threading)
  -c, --check-hash  perform hash check
  -n, --nal         input is a stream with 4-byte length prefixed NAL units
  -f, --frames N    set number of frames to process
  -o, --output      write YUV reconstruction
  -d, --dump        dump headers
  -0, --noaccel     do not use any accelerated code (SSE)
  -v, --verbose     increase verbosity level (up to 3 times)
  -L, --no-logging  disable logging
  -B, --write-bytestream FILENAME  write raw bytestream (from NAL input)
  -m, --measure YUV compute PSNRs relative to reference YUV
  -T, --highest-TID select highest temporal sublayer to decode
      --disable-deblocking   disable deblocking filter
      --disable-sao          disable sample-adaptive offset filter
  -h, --help        show help

Replay

git clone https://github.com/strukturag/libde265.git
cd libde265
mkdir build
cd build
cmake ../ -DCMAKE_CXX_FLAGS="-fsanitize=address"
make -j$(nproc)
./dec265/dec265 poc3

ASAN

WARNING: end_of_sub_stream_one_bit not set to 1 when it should be
=================================================================
==53283==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d000058440 at pc 0x7fad91709cc2 bp 0x7fff77a7c980 sp 0x7fff77a7c970
READ of size 8 at 0x62d000058440 thread T0
    #0 0x7fad91709cc1 in ff_hevc_put_hevc_epel_pixels_8_sse(short*, long, unsigned char const*, long, int, int, int, int, short*) (/libde265/build/libde265/liblibde265.so+0x262cc1)
    #1 0x7fad9161df7e in acceleration_functions::put_hevc_epel(short*, long, void const*, long, int, int, int, int, short*, int) const (/libde265/build/libde265/liblibde265.so+0x176f7e)
    #2 0x7fad9161fd75 in void mc_chroma<unsigned short>(base_context const*, seq_parameter_set const*, int, int, int, int, short*, int, unsigned short const*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x178d75)
    #3 0x7fad91610b2d in generate_inter_prediction_samples(base_context*, slice_segment_header const*, de265_image*, int, int, int, int, int, int, int, PBMotion const*) (/libde265/build/libde265/liblibde265.so+0x169b2d)
    #4 0x7fad9161d90f in decode_prediction_unit(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x17690f)
    #5 0x7fad916592d9 in read_coding_unit(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b22d9)
    #6 0x7fad9165b250 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4250)
    #7 0x7fad9165b091 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4091)
    #8 0x7fad9165b091 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4091)
    #9 0x7fad9165b091 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4091)
    #10 0x7fad91652726 in read_coding_tree_unit(thread_context*) (/libde265/build/libde265/liblibde265.so+0x1ab726)
    #11 0x7fad9165b9ea in decode_substream(thread_context*, bool, bool) (/libde265/build/libde265/liblibde265.so+0x1b49ea)
    #12 0x7fad9165d70f in read_slice_segment_data(thread_context*) (/libde265/build/libde265/liblibde265.so+0x1b670f)
    #13 0x7fad915bc6d2 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) (/libde265/build/libde265/liblibde265.so+0x1156d2)
    #14 0x7fad915bcec1 in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) (/libde265/build/libde265/liblibde265.so+0x115ec1)
    #15 0x7fad915bbc0f in decoder_context::decode_some(bool*) (/libde265/build/libde265/liblibde265.so+0x114c0f)
    #16 0x7fad915bb93d in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) (/libde265/build/libde265/liblibde265.so+0x11493d)
    #17 0x7fad915be43e in decoder_context::decode_NAL(NAL_unit*) (/libde265/build/libde265/liblibde265.so+0x11743e)
    #18 0x7fad915beab3 in decoder_context::decode(int*) (/libde265/build/libde265/liblibde265.so+0x117ab3)
    #19 0x7fad915a5e95 in de265_decode (/libde265/build/libde265/liblibde265.so+0xfee95)
    #20 0x561919dedbc9 in main (/libde265/build/dec265/dec265+0x6bc9)
    #21 0x7fad910d7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    #22 0x561919deb9b9 in _start (/libde265/build/dec265/dec265+0x49b9)

0x62d000058440 is located 48 bytes to the right of 32784-byte region [0x62d000050400,0x62d000058410)
allocated by thread T0 here:
    #0 0x7fad91ace790 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdf790)
    #1 0x7fad915f71cb in ALLOC_ALIGNED(unsigned long, unsigned long) (/libde265/build/libde265/liblibde265.so+0x1501cb)
    #2 0x7fad915f799d in de265_image_get_buffer(void*, de265_image_spec*, de265_image*, void*) (/libde265/build/libde265/liblibde265.so+0x15099d)
    #3 0x7fad915f9d1a in de265_image::alloc_image(int, int, de265_chroma, std::shared_ptr<seq_parameter_set const>, bool, decoder_context*, long, void*, bool) (/libde265/build/libde265/liblibde265.so+0x152d1a)
    #4 0x7fad915de0cc in decoded_picture_buffer::new_image(std::shared_ptr<seq_parameter_set const>, decoder_context*, long, void*, bool) (/libde265/build/libde265/liblibde265.so+0x1370cc)
    #5 0x7fad915bf824 in decoder_context::generate_unavailable_reference_picture(seq_parameter_set const*, int, bool) (/libde265/build/libde265/liblibde265.so+0x118824)
    #6 0x7fad915c2332 in decoder_context::process_reference_picture_set(slice_segment_header*) (/libde265/build/libde265/liblibde265.so+0x11b332)
    #7 0x7fad915c5d70 in decoder_context::process_slice_segment_header(slice_segment_header*, de265_error*, long, nal_header*, void*) (/libde265/build/libde265/liblibde265.so+0x11ed70)
    #8 0x7fad915bb246 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) (/libde265/build/libde265/liblibde265.so+0x114246)
    #9 0x7fad915be43e in decoder_context::decode_NAL(NAL_unit*) (/libde265/build/libde265/liblibde265.so+0x11743e)
    #10 0x7fad915beab3 in decoder_context::decode(int*) (/libde265/build/libde265/liblibde265.so+0x117ab3)
    #11 0x7fad915a5e95 in de265_decode (/libde265/build/libde265/liblibde265.so+0xfee95)
    #12 0x561919dedbc9 in main (/libde265/build/dec265/dec265+0x6bc9)
    #13 0x7fad910d7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/libde265/build/libde265/liblibde265.so+0x262cc1) in ff_hevc_put_hevc_epel_pixels_8_sse(short*, long, unsigned char const*, long, int, int, int, int, short*)
Shadow bytes around the buggy address:
  0x0c5a80003030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c5a80003040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c5a80003050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c5a80003060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c5a80003070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c5a80003080: 00 00 fa fa fa fa fa fa[fa]fa fa fa fa fa fa fa
  0x0c5a80003090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c5a800030a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c5a800030b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c5a800030c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c5a800030d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==53283==ABORTING

POC

https://github.com/FDU-Sec/poc/blob/main/libde265/poc3

Environment

Ubuntu 16.04
Clang 10.0.1
gcc 5.5

Credit

Peng Deng (Fudan University)
coldtobi pushed a commit to coldtobi/libde265 that referenced this issue Dec 12, 2022
Try to mitigate asan failures.
97dd153 
See strukturag#345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (strukturag#337)
- poc7-1 (strukturag#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (strukturag#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (strukturag#345) CVE-2022-43249
- poc12 (strukturag#346)
- poc13 (strukturag#347) CVE-2022-43252
- poc16 (strukturag#350)
This was referenced Dec 12, 2022
Open
Closed
@coldtobi
Copy link

According to Debian this is CVE-2022-43235

coldtobi pushed a commit to coldtobi/libde265 that referenced this issue Dec 12, 2022
Use the sps from the image
36391cd 
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See strukturag#345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  strukturag#336 - CVE-2022-43238
 - poc4  strukturag#338 - CVE-2022-43241
 - poc6-1, poc6-2 strukturag#340 - CVE-2022-43242
 - poc7-1, poc7-2  strukturag#341 - CVE-2022-43239
 - poc8-1 strukturag#342 - CVE-2022-43244
 - poc9-3 strukturag#343 - CVE-2022-43236
 - poc10-2, poc10-3 strukturag#344 - CVE-2022-43237
 - poc16 strukturag#350
 - poc19 strukturag#353

The following are still failing if only this patch is
applied, but they stop failing if strukturag#365 is applied as well, but will
still fail with ONLY strukturag#365 applied (IOW, both are needed)

 - poc1  strukturag#335 - CVE-2022-43240
 - poc3  strukturag#337 - CVE-2022-43235
 - poc5   strukturag#339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  strukturag#343 - CVE-2022-43236
 - poc14  strukturag#348 - CVE-2022-43253
 - poc15  strukturag#349 - CVE-2022-43248
 - poc17-1, poc17-2  strukturag#351
 - poc18 strukturag#352 - CVE-2022-43245
@coldtobi coldtobi mentioned this issue Dec 12, 2022
Open
@farindk
Copy link
Contributor

farindk commented Jan 24, 2023

I couldn't reproduce this (Ubuntu 16.04.7, GCC 5.4.0). Tried at v1.0.8 and c96962c.

@farindk
Copy link
Contributor

farindk commented Jan 25, 2023

@coldtobi Since I apparently cannot reproduce the original issue in my setups, could you please verify that the issue is fixed?

@coldtobi
Copy link

I can't reproduce this exact issue either… (Bisecting finds some old commit ~1.0.4 which triggers asan, but that is a complete different backtrace.)

@dougnazar
Copy link

I think I'm seeing this issue (on a regular basis, security camera feed). As near as I can tell, this happens if it tries to do an accelerated put_hevc_epel() from a block that is smaller than 8 in width and is near to the end of a plane allocation. _mm_unpacklo_epi8() reads in 8-byte chunks and in my case it was working on a 4x4 block at the end of the plane. Let me know if you need any more info.

ff_hevc_put_hevc_epel_pixels_8_sse variables:

y = 3, height = 4, x = 0, width = 4
src = (uint8_t *) 0x7fffc857cffc "\204\204\204\204"<error: Cannot access memory at address 0x7fffc857d000>

mc_chroma variables:

xIntOffsC = 1276, yIntOffsC = 716, nPbWC = 4, nPbHC = 4, ref = 0x7fffc849c000, ref_stride = 1280

Reference Image Info:

chroma_format = de265_chroma_420, width = 2560, height = 1440, chroma_width = 1280, chroma_height = 720, stride = 2560, chroma_stride = 1280, BitDepth_Y = 8, BitDepth_C = 8,  SubWidthC = 2, SubHeightC = 2

Backtrace:

#0  ff_hevc_put_hevc_epel_pixels_8_sse (dst=0x7fffcfffaaf0, dststride=8, _src=<optimized out>, srcstride=1280, width=4, height=4, mx=0, my=0, mcbuffer=0x0) at sse-motion.cc:1002
#1  0x00007ffff4084682 in acceleration_functions::put_hevc_epel (this=this@entry=0x7fffd004dda0, dst=dst@entry=0x7fffcfffaac0, dststride=dststride@entry=8, src=<optimized out>,
    srcstride=srcstride@entry=1280, width=<optimized out>, height=4, mx=0, my=0, mcbuffer=0x0, bit_depth=8) at ../libde265/acceleration.h:296
#2  0x00007ffff4085537 in mc_chroma<unsigned char> (ctx=ctx@entry=0x7fffd004dcf0, sps=sps@entry=0x7fffd006e1e0, mv_x=<optimized out>, mv_y=<optimized out>, xP=xP@entry=2552, yP=yP@entry=1432,
    out=0x7fffcfffaac0, out_stride=8, ref=0x7fffc849c000 '\203' <repeats 55 times>, "\202\200", '\177' <repeats 14 times>, "\200\200", '\201' <repeats 110 times>, "\200\177", '~' <repeats 15 times>...,
    ref_stride=1280, nPbWC=4, nPbHC=4, bit_depth_C=8) at motion.cc:205
#3  0x00007ffff4083aae in generate_inter_prediction_samples (ctx=ctx@entry=0x7fffd004dcf0, shdr=shdr@entry=0x7fffd0068960, img=img@entry=0x7fffd00267e0, xC=xC@entry=2552, yC=yC@entry=1432, xB=xB@entry=0,
    yB=0, nCS=8, nPbW=8, nPbH=8, vi=0x7fffcfffeb5c) at motion.cc:420
#4  0x00007ffff40844a6 in decode_prediction_unit (ctx=0x7fffd004dcf0, shdr=0x7fffd0068960, img=0x7fffd00267e0, motion=..., xC=xC@entry=2552, yC=yC@entry=1432, xB=0, yB=0, nCS=8, nPbW=8, nPbH=8, partIdx=0)
    at motion.cc:2176
#5  0x00007ffff4091cbc in read_coding_unit (tctx=tctx@entry=0x7fffd0657988, x0=x0@entry=2552, y0=y0@entry=1432, log2CbSize=log2CbSize@entry=3, ctDepth=ctDepth@entry=2) at slice.cc:4314
#6  0x00007ffff40928ac in read_coding_quadtree (tctx=0x7fffd0657988, x0=2552, y0=1432, log2CbSize=3, ctDepth=2) at slice.cc:4652
#7  0x00007ffff4092831 in read_coding_quadtree (tctx=0x7fffd0657988, x0=2544, y0=1424, log2CbSize=4, ctDepth=<optimized out>) at slice.cc:4645
#8  0x00007ffff4092831 in read_coding_quadtree (tctx=tctx@entry=0x7fffd0657988, x0=x0@entry=2528, y0=y0@entry=1408, log2CbSize=5, ctDepth=ctDepth@entry=0) at slice.cc:4645
#9  0x00007ffff409298f in read_coding_tree_unit (tctx=tctx@entry=0x7fffd0657988) at slice.cc:2861
#10 0x00007ffff4092c6c in decode_substream (tctx=tctx@entry=0x7fffd0657988, block_wpp=block_wpp@entry=false, first_independent_substream=<optimized out>) at slice.cc:4741
#11 0x00007ffff4092e3a in thread_task_slice_segment::work (this=0x7fffd004b090) at slice.cc:4940
#12 0x00007ffff40986ce in worker_thread (pool_ptr=0x7fffd004e728) at threads.cc:233
#13 0x00007ffff7b66b4a in ?? () from /lib64/libc.so.6
#14 0x00007ffff7be965c in ?? () from /lib64/libc.so.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
could not reproduce
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@farindk @dougnazar @coldtobi @fdu-sec