Bento4 v1.6.0-639 was discovered to contain a segmentation violation via the AP4_Processor::ProcessFragments function in mp4encrypt.

**Summary**

Hi, developers of Bento4:  
I tested the binary mp4encrypt with my fuzzer, and a crash incurred—SEGV on unknown address. The following is the details.

**Bug**

Detected SEGV on unknown address in mp4encrypt.

    root@2e47aa8b3277:/fuzz-mp4encrypt-ACBC/mp4encrypt# ./mp4encrypt --method MARLIN-IPMP-ACBC ../out/crashes/id:000000,sig:06,src:000718+000108,op:splice,rep:128,203819180 /dev/null
    WARNING: track ID 1 will not be encrypted
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2391078==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x000000633817 bp 0x7fff9076b400 sp 0x7fff90769aa0 T0)
    ==2391078==The signal is caused by a READ memory access.
    ==2391078==Hint: address points to the zero page.
        #0 0x633817 in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&) (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x633817)
        #1 0x658320 in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x658320)
        #2 0x42128c in main (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x42128c)
        #3 0x7fd8c26f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #4 0x407c99 in _start (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x407c99)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x633817) in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&)
    ==2391078==ABORTING
    
    

**POC**

POC\_mp4encrypt\_203819180.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Jiayuan Zhang (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)

Thank you for your time!

CVE-2023-38666: SEGV on unknown address 0x000000000028 in mp4encrypt · Issue #784 · axiomatic-systems/Bento4

dpic 2021.04.10 has a Heap Buffer Overflow in themakevar() function in dpic.y

Skip to content

**Heap-based Buffer Overflow in the makevar() function**

Hi,

I found a **heap buffer overflow write of size 1** in the makevar() function, in dpic.y on dpic 2021.04.10 (commit: d317e406)

Heap buffer overflow issue: for loop in https://gitlab.com/aplevich/dpic/-/blob/master/dpic.y#L5769 as given below:

    void
    makevar(char *s, int ln, double varval)
    {
      nametype *vn, *lastvar, *namptr;
      int j, tstval;
      for (j = 0; j < ln; j++) { chbuf[chbufi + j] = s[j]; }
      ...

And, as per the code, https://gitlab.com/aplevich/dpic/-/blob/master/main.c#L1777

chbuf = malloc (sizeof (chbufarray)); if (chbuf==NULL){ fatal(9); } the sizeof chbufarray of char datatype is: https://gitlab.com/aplevich/dpic/-/blob/master/dpic.h#L78

    typedef Char chbufarray[CHBUFSIZ + 1];

and upper limit of chbuf buffers is CHBUFSIZ which is of 4095 limit so sizeof (chbufarray) becomes 4096 and while running the executable, the value of chbufi can be seen as 4089 for this test file, so it means any value which is greater than 6 will cause heap buffer overflow write in the makevar() function for loop, in this case.

    if ln (second input parameter of makevar()) is 7:
        chbuf[4089 + 6] = s[6];
        chbuf[4095] = s[6];
    
    if ln is greater than 7 like 8 or 9:
        chbuf[4089 + 7] = s[6];
        which is, chbuf[4096] = s[6]; // heap buffer overflow of write 1 byte

And, as per the code: https://gitlab.com/aplevich/dpic/-/blob/master/dpic.y#L5735 as given below, it can be seen as many makevar() function has second input parameter greater than 7

    void
    mkOptionVars(void)
    {
        makevar("dpicopt", 7, drawmode);
        if (safemode) { i = 1; } else { i = 0; }
        makevar("optsafe", 7, i);
        makevar("optMFpic", 8, MFpic);
        makevar("optMpost", 8, MPost);
        makevar("optPDF", 6, PDF);
        makevar("optPGF", 6, PGF);
        makevar("optPict2e", 9, Pict2e);
        makevar("optPS", 5, PS);
        makevar("optPSfrag", 9, PSfrag);
        makevar("optPSTricks", 11, PSTricks);
        makevar("optSVG", 6, SVG);
        makevar("optTeX", 6, TeX);
        makevar("opttTeX", 7, tTeX);
        makevar("optxfig", 7, xfig);
        ...

    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=20.04
    DISTRIB_CODENAME=focal
    DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

Attaching a reproducer: heap\_bof\_write\_test

the issue can be reproduced by running:

dpic heap_bof_write_test

With ASAN report

    =================================================================
    ==582741==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000001100 at pc 0x000000538ae3 bp 0x7ffead55dc90 sp 0x7ffead55dc88
    WRITE of size 1 at 0x621000001100 thread T0
        #0 0x538ae2 in makevar /home/bsdboy/projects/again/dpic/dpic.y:5769:48
        #1 0x511042 in mkOptionVars /home/bsdboy/projects/again/dpic/dpic.y:5748:5
        #2 0x4de391 in yyparse /home/bsdboy/projects/again/dpic/dpic.y:495:19
        #3 0x4dbcb4 in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #4 0x7f9a899740b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #5 0x41c65d in _start (/home/bsdboy/projects/again/dpic/dpic+0x41c65d)
    
    0x621000001100 is located 0 bytes to the right of 4096-byte region [0x621000000100,0x621000001100)
    allocated by thread T0 here:
        #0 0x4978bd in malloc (/home/bsdboy/projects/again/dpic/dpic+0x4978bd)
        #1 0x4dbb9d in main /home/bsdboy/projects/again/dpic/main.c:1779:11
        #2 0x7f9a899740b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bsdboy/projects/again/dpic/dpic.y:5769:48 in makevar
    Shadow bytes around the buggy address:
      0x0c427fff81d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff81e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff81f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff8200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c427fff8220:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8270: 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
      Shadow gap:              cc
    ==582741==ABORTING

Edited May 09, 2021 by Neeraj Pal

CVE-2021-33388: Heap-based Buffer Overflow in the makevar() function (#8) · Issues · Dwight Aplevich / dpic · GitLab

dpic 2021.04.10 has a use-after-free in thedeletestringbox() function in dpic.y. A different vulnerablility than CVE-2021-32421.

Skip to content

**Heap Use After Free in the deletestringbox() function (different than #7)**

Hi,

While fuzzing dpic 2021.04.10 (commit: d317e406), I found a heap use-after-free in the cmpstring() function, in dpic.y:L5724.

I have already confirmed the previous issue: #7 (closed) and that is already patched but this seems to be similar but not the same with this input test file and in the same deletestringbox() function.

    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=20.04
    DISTRIB_CODENAME=focal
    DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

Attaching a reproducer: heap-uaf-read-test-deletestringbox

the issue can be reproduced by running:

dpic heap-uaf-read-test-deletestringbox

    =================================================================
    ==3692838==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000000060 at pc 0x0000005094cf bp 0x7ffdf2d88ed0 sp 0x7ffdf2d88ec8
    READ of size 8 at 0x60d000000060 thread T0
        #0 0x5094ce in deletestringbox /home/bsdboy/projects/again/dpic/dpic.y:5724:19
        #1 0x4fce1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:2839:4
        #2 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #3 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #4 0x41c3dd in _start (/home/bsdboy/projects/again/dpic/dpic+0x41c3dd)
    
    0x60d000000060 is located 32 bytes inside of 136-byte region [0x60d000000040,0x60d0000000c8)
    freed by thread T0 here:
        #0 0x4973d2 in free (/home/bsdboy/projects/again/dpic/dpic+0x4973d2)
        #1 0x501778 in deletetree /home/bsdboy/projects/again/dpic/dpic.y:3917:12
        #2 0x50989b in deletestringbox /home/bsdboy/projects/again/dpic/dpic.y:5732:3
        #3 0x4fce1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:2839:4
        #4 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #5 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    previously allocated by thread T0 here:
        #0 0x49763d in malloc (/home/bsdboy/projects/again/dpic/dpic+0x49763d)
        #1 0x507b27 in newprim /home/bsdboy/projects/again/dpic/dpic.y:4984:13
        #2 0x4deb1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:892:19
        #3 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #4 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-use-after-free /home/bsdboy/projects/again/dpic/dpic.y:5724:19 in deletestringbox
    Shadow bytes around the buggy address:
      0x0c1a7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c1a7fff8000: fa fa fa fa fa fa fa fa fd fd fd fd[fd]fd fd fd
      0x0c1a7fff8010: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
      0x0c1a7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8050: 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
      Shadow gap:              cc
    ==3692838==ABORTING

CVE-2021-33390: Heap Use After Free in the deletestringbox() function (different than #7) (#10) · Issues · Dwight Aplevich / dpic · GitLab

There is a use-after-free vulnerability in file pdd_simplifier.cpp in Z3 before 4.8.8. It occurs when the solver attempt to simplify the constraints and causes unexpected memory access. It can cause segmentation faults or arbitrary code execution.

Hi, there.

There is a use after free issue that causes segmentation fault using z3.

To reproduce this issue, simply run  
z3 poc.smt2  
z3-uaf\_pdd\_simplified.smt2.zip

OS: Ubuntu 16.06  
commit 6ad261e

Here is the trace reported by ASAN.

    ==42916==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000057aa8 at pc 0x000002126476 bp 0x7ffce1825cf0 sp 0x7ffce1825ce0
    READ of size 8 at 0x603000057aa8 thread T0
        #0 0x2126475 in dd::simplifier::simplify_linear_step(old_ptr_vector<dd::solver::equation>&) ../src/math/grobner/pdd_simplifier.cpp:131
        #1 0x2125e9c in dd::simplifier::simplify_linear_step(bool) ../src/math/grobner/pdd_simplifier.cpp:103
        #2 0x2125862 in dd::simplifier::operator()() ../src/math/grobner/pdd_simplifier.cpp:69
        #3 0x211ffda in dd::solver::simplify() ../src/math/grobner/pdd_solver.cpp:135
        #4 0x211f6af in dd::solver::saturate() ../src/math/grobner/pdd_solver.cpp:93
        #5 0x1e14c8b in nla::core::run_grobner() ../src/math/lp/nla_core.cpp:1403
        #6 0x1e136dd in nla::core::inner_check(bool) ../src/math/lp/nla_core.cpp:1288
        #7 0x1e13ed2 in nla::core::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_core.cpp:1341
        #8 0x1d4dbbd in nla::solver::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_solver.cpp:40
        #9 0xdc9029 in smt::theory_lra::imp::check_nra() (/home/heqing/dependence/z3/build/z3+0xdc9029)
        #10 0xdc1d03 in smt::theory_lra::imp::final_check_eh() ../src/smt/theory_lra.cpp:1753
        #11 0xda83e4 in smt::theory_lra::final_check_eh() ../src/smt/theory_lra.cpp:3976
        #12 0x11bac65 in smt::context::final_check() ../src/smt/smt_context.cpp:3904
        #13 0x11b9c6e in smt::context::bounded_search() ../src/smt/smt_context.cpp:3819
        #14 0x11b73a9 in smt::context::search() ../src/smt/smt_context.cpp:3646
        #15 0x11b4da4 in smt::context::setup_and_check(bool) ../src/smt/smt_context.cpp:3471
        #16 0x112257a in smt::kernel::imp::setup_and_check() ../src/smt/smt_kernel.cpp:108
        #17 0x1121255 in smt::kernel::setup_and_check() ../src/smt/smt_kernel.cpp:292
        #18 0xc496e6 in smt_tactic::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/smt/tactic/smt_tactic.cpp:200
        #19 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #20 0x19def27 in try_for_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:933
        #21 0x19d8ea5 in or_else_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:296
        #22 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #23 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #24 0x19dff24 in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1023
        #25 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #26 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #27 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #28 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #29 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #30 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #31 0x19dff8e in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1025
        #32 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #33 0x19dd595 in unary_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:763
        #34 0x1a0cc80 in exec(tactic&, ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactic.cpp:148
        #35 0x1a0d11b in check_sat(tactic&, ref<goal>&, ref<model>&, labels_vec&, obj_ref<app, ast_manager>&, obj_ref<dependency_manager<ast_manager::expr_dependency_config>::dependency, ast_manager>&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ../src/tactic/tactic.cpp:168
        #36 0x19830fb in check_sat_core2 ../src/solver/tactic2solver.cpp:176
        #37 0x196bcb1 in solver_na2as::check_sat_core(unsigned int, expr* const*) ../src/solver/solver_na2as.cpp:67
        #38 0x19807b0 in combined_solver::check_sat_core(unsigned int, expr* const*) ../src/solver/combined_solver.cpp:246
        #39 0x196a68b in solver::check_sat(unsigned int, expr* const*) ../src/solver/solver.cpp:330
        #40 0x19306d2 in cmd_context::check_sat(unsigned int, expr* const*) ../src/cmd_context/cmd_context.cpp:1581
        #41 0x18bcc6b in smt2::parser::parse_check_sat() ../src/parsers/smt2/smt2parser.cpp:2596
        #42 0x18c0c07 in smt2::parser::parse_cmd() ../src/parsers/smt2/smt2parser.cpp:2938
        #43 0x18c2319 in smt2::parser::operator()() ../src/parsers/smt2/smt2parser.cpp:3130
        #44 0x18a12fe in parse_smt2_commands(cmd_context&, std::istream&, bool, params_ref const&, char const*) ../src/parsers/smt2/smt2parser.cpp:3179
        #45 0x41efab in read_smtlib2_commands(char const*) ../src/shell/smtlib_frontend.cpp:89
        #46 0x415a9e in main ../src/shell/main.cpp:352
        #47 0x7f65a714482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
        #48 0x414808 in _start (/home/heqing/dependence/z3/build/z3+0x414808)
    
    0x603000057aa8 is located 24 bytes inside of 32-byte region [0x603000057a90,0x603000057ab0)
    freed by thread T0 here:
        #0 0x7f65a8044961 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98961)
        #1 0x253bf9c in memory::reallocate(void*, unsigned long) ../src/util/memory_manager.cpp:295
        #2 0x212548d in old_vector<dd::solver::equation*, false, unsigned int>::expand_vector() ../src/util/old_vector.h:87
        #3 0x2124abe in old_vector<dd::solver::equation*, false, unsigned int>::push_back(dd::solver::equation* const&) ../src/util/old_vector.h:419
        #4 0x2129020 in dd::simplifier::add_to_use(dd::solver::equation*, old_vector<old_ptr_vector<dd::solver::equation>, true, unsigned int>&) ../src/math/grobner/pdd_simplifier.cpp:350
        #5 0x2126789 in dd::simplifier::simplify_linear_step(old_ptr_vector<dd::solver::equation>&) ../src/math/grobner/pdd_simplifier.cpp:156
        #6 0x2125e9c in dd::simplifier::simplify_linear_step(bool) ../src/math/grobner/pdd_simplifier.cpp:103
        #7 0x2125862 in dd::simplifier::operator()() ../src/math/grobner/pdd_simplifier.cpp:69
        #8 0x211ffda in dd::solver::simplify() ../src/math/grobner/pdd_solver.cpp:135
        #9 0x211f6af in dd::solver::saturate() ../src/math/grobner/pdd_solver.cpp:93
        #10 0x1e14c8b in nla::core::run_grobner() ../src/math/lp/nla_core.cpp:1403
        #11 0x1e136dd in nla::core::inner_check(bool) ../src/math/lp/nla_core.cpp:1288
        #12 0x1e13ed2 in nla::core::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_core.cpp:1341
        #13 0x1d4dbbd in nla::solver::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_solver.cpp:40
        #14 0xdc9029 in smt::theory_lra::imp::check_nra() (/home/heqing/dependence/z3/build/z3+0xdc9029)
        #15 0xdc1d03 in smt::theory_lra::imp::final_check_eh() ../src/smt/theory_lra.cpp:1753
        #16 0xda83e4 in smt::theory_lra::final_check_eh() ../src/smt/theory_lra.cpp:3976
        #17 0x11bac65 in smt::context::final_check() ../src/smt/smt_context.cpp:3904
        #18 0x11b9c6e in smt::context::bounded_search() ../src/smt/smt_context.cpp:3819
        #19 0x11b73a9 in smt::context::search() ../src/smt/smt_context.cpp:3646
        #20 0x11b4da4 in smt::context::setup_and_check(bool) ../src/smt/smt_context.cpp:3471
        #21 0x112257a in smt::kernel::imp::setup_and_check() ../src/smt/smt_kernel.cpp:108
        #22 0x1121255 in smt::kernel::setup_and_check() ../src/smt/smt_kernel.cpp:292
        #23 0xc496e6 in smt_tactic::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/smt/tactic/smt_tactic.cpp:200
        #24 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #25 0x19def27 in try_for_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:933
        #26 0x19d8ea5 in or_else_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:296
        #27 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #28 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #29 0x19dff24 in cond_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:1023
    
    previously allocated by thread T0 here:
        #0 0x7f65a8044602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
        #1 0x253bdd5 in memory::allocate(unsigned long) ../src/util/memory_manager.cpp:268
        #2 0x21251bc in old_vector<dd::solver::equation*, false, unsigned int>::expand_vector() ../src/util/old_vector.h:65
        #3 0x2124abe in old_vector<dd::solver::equation*, false, unsigned int>::push_back(dd::solver::equation* const&) ../src/util/old_vector.h:419
        #4 0x2129020 in dd::simplifier::add_to_use(dd::solver::equation*, old_vector<old_ptr_vector<dd::solver::equation>, true, unsigned int>&) ../src/math/grobner/pdd_simplifier.cpp:350
        #5 0x21292d0 in dd::simplifier::get_use_list() ../src/math/grobner/pdd_simplifier.cpp:375
        #6 0x21260c2 in dd::simplifier::simplify_linear_step(old_ptr_vector<dd::solver::equation>&) ../src/math/grobner/pdd_simplifier.cpp:112
        #7 0x2125e9c in dd::simplifier::simplify_linear_step(bool) ../src/math/grobner/pdd_simplifier.cpp:103
        #8 0x2125862 in dd::simplifier::operator()() ../src/math/grobner/pdd_simplifier.cpp:69
        #9 0x211ffda in dd::solver::simplify() ../src/math/grobner/pdd_solver.cpp:135
        #10 0x211f6af in dd::solver::saturate() ../src/math/grobner/pdd_solver.cpp:93
        #11 0x1e14c8b in nla::core::run_grobner() ../src/math/lp/nla_core.cpp:1403
        #12 0x1e136dd in nla::core::inner_check(bool) ../src/math/lp/nla_core.cpp:1288
        #13 0x1e13ed2 in nla::core::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_core.cpp:1341
        #14 0x1d4dbbd in nla::solver::check(old_vector<nla::lemma, true, unsigned int>&) ../src/math/lp/nla_solver.cpp:40
        #15 0xdc9029 in smt::theory_lra::imp::check_nra() (/home/heqing/dependence/z3/build/z3+0xdc9029)
        #16 0xdc1d03 in smt::theory_lra::imp::final_check_eh() ../src/smt/theory_lra.cpp:1753
        #17 0xda83e4 in smt::theory_lra::final_check_eh() ../src/smt/theory_lra.cpp:3976
        #18 0x11bac65 in smt::context::final_check() ../src/smt/smt_context.cpp:3904
        #19 0x11b9c6e in smt::context::bounded_search() ../src/smt/smt_context.cpp:3819
        #20 0x11b73a9 in smt::context::search() ../src/smt/smt_context.cpp:3646
        #21 0x11b4da4 in smt::context::setup_and_check(bool) ../src/smt/smt_context.cpp:3471
        #22 0x112257a in smt::kernel::imp::setup_and_check() ../src/smt/smt_kernel.cpp:108
        #23 0x1121255 in smt::kernel::setup_and_check() ../src/smt/smt_kernel.cpp:292
        #24 0xc496e6 in smt_tactic::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/smt/tactic/smt_tactic.cpp:200
        #25 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #26 0x19def27 in try_for_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:933
        #27 0x19d8ea5 in or_else_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:296
        #28 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
        #29 0x19d7aa3 in and_then_tactical::operator()(ref<goal> const&, sref_buffer<goal, 16u>&) ../src/tactic/tactical.cpp:120
    
    SUMMARY: AddressSanitizer: heap-use-after-free ../src/math/grobner/pdd_simplifier.cpp:131 dd::simplifier::simplify_linear_step(old_ptr_vector<dd::solver::equation>&)
    Shadow bytes around the buggy address:
      0x0c0680002f00: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
      0x0c0680002f10: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
      0x0c0680002f20: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
      0x0c0680002f30: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
      0x0c0680002f40: 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 00 00
    =>0x0c0680002f50: fa fa fd fd fd[fd]fa fa 00 00 00 00 fa fa 00 00
      0x0c0680002f60: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
      0x0c0680002f70: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
      0x0c0680002f80: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
      0x0c0680002f90: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
      0x0c0680002fa0: fd fd fd fd fa fa fd fd fd fd fa fa 00 00 00 00
    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
      Heap right redzone:      fb
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack partial redzone:   f4
      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
    ==42916==ABORTING

CVE-2020-19725: use after free in ../src/math/grobner/pdd_simplifier.cpp:131 · Issue #3363 · Z3Prover/z3

Buffer Overflow vulnerability in ExtractorInformation function in streamExtractor.cpp in oggvideotools 0.9.1 allows remaote attackers to run arbitrary code via opening of crafted ogg file.

I use AddressSanitizer to build oggvideotools 0.9.1 and get segment fault as below. I use the command:  
oggLength <testcase>  
The testcase I used is put in the attachment.  
This software can also be installed by command apt install oggvideotools but the version is 0.8a-7, which can also get segment fault with the same testcase.</testcase>

MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
\=================================================================  
\==32390==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e4b8 at pc 0x00000046e493 bp 0x7ffe9af99060 sp 0x7ffe9af99050  
WRITE of size 4 at 0x60600000e4b8 thread T0  
#0 0x46e492 in ExtractorInformation::operator=(ExtractorInformation const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17  
#1 0x4407e2 in StreamConfig::operator=(StreamConfig const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamConfig.h:12  
#2 0x43ea66 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:210  
#3 0x43b0c4 in oggLengthCmd(int, char\*\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#4 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#5 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)  
#6 0x43aa78 in \_start (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x43aa78)</streamconfig,>

0x60600000e4b8 is located 0 bytes to the right of 56-byte region \[0x60600000e480,0x60600000e4b8)  
allocated by thread T0 here:  
#0 0x7f13e0b42532 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99532)  
#1 0x4468b4 in \_\_gnu\_cxx::new\_allocator<streamconfig>::allocate(unsigned long, void const_) /usr/include/c++/5/ext/new\_allocator.h:104  
#2 0x4460b3 in std::allocator\_traits<std::allocator<streamconfig> >::allocate(std::allocator<streamconfig>&, unsigned long) /usr/include/c++/5/bits/alloc\_traits.h:491  
#3 0x4451fd in std::\_Vector\_base<streamconfig, std::allocator<streamconfig=""> >::\_M\_allocate(unsigned long) /usr/include/c++/5/bits/stl\_vector.h:170  
#4 0x443257 in std::vector<streamconfig, std::allocator<streamconfig=""> >::\_M\_default\_append(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x443257)  
#5 0x441d5e in std::vector<streamconfig, std::allocator<streamconfig=""> >::resize(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x441d5e)  
#6 0x43e9a5 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:206  
#7 0x43b0c4 in oggLengthCmd(int, char</streamconfig,></streamconfig,></streamconfig,></streamconfig,></streamconfig></std::allocator<streamconfig>_\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#8 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#9 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)</streamconfig>

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17 ExtractorInformation::operator=(ExtractorInformation const&)  
Shadow bytes around the buggy address:  
0x0c0c7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c0c7fff9c90: 00 00 00 00 00 00 00\[fa\]fa fa fa fa 00 00 00 00  
0x0c0c7fff9ca0: 00 00 05 fa fa fa fa fa fd fd fd fd fd fd fd fa  
0x0c0c7fff9cb0: fa fa fa fa 00 00 00 00 00 00 07 fa fa fa fa fa  
0x0c0c7fff9cc0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd  
0x0c0c7fff9cd0: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 06 fa  
0x0c0c7fff9ce0: fa fa fa fa fd fd fd fd fd fd fd 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  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
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  
\==32390==ABORTING

My system is:  
Description: Ubuntu 16.04.6 LTS  
Release: 16.04

The software information:  
oggvideotools:  
Installed: 0.8a-7  
Candidate: 0.8a-7  
Version table:  
\*\*\* 0.8a-7 500  
500 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial/universe amd64 Packages  
500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages  
100 /var/lib/dpkg/status

ProblemType: Bug  
DistroRelease: Ubuntu 16.04  
Package: oggvideotools 0.8a-7  
ProcVersionSignature: Ubuntu 4.15.0-66.75~16.04.1-generic 4.15.18  
Uname: Linux 4.15.0-66-generic x86\_64  
ApportVersion: 2.20.1-0ubuntu2.21  
Architecture: amd64  
CurrentDesktop: Unity  
Date: Thu Nov 14 19:56:47 2019  
InstallationDate: Installed on 2019-01-24 (293 days ago)  
InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 (20180731)  
SourcePackage: oggvideotools  
UpgradeStatus: No upgrade log present (probably fresh install)

**1 Attachments**

CVE-2020-21724: Ogg Video Tools / Bugs

A Segmentation Fault issue discovered StreamSerializer::extractStreams function in streamSerializer.cpp in oggvideotools 0.9.1 allows remote attackers to cause a denial of service (crash) via opening of crafted ogg file.

Tested in Ubuntu 16.04, 64bit

The tesecase is put in the attachment and the oggvideotools vision is 0.9.1

I use the following command:

./oggLength oggLength\_SEGV

and get:

I use **valgrind** to analysis the bug and get the below information:

\==7902\== Memcheck, a memory error detector
\==7902\== Copyright (C) 2002\-2015, and GNU GPL'd, by Julian Seward et al.
\==7902\== Using Valgrind\-3.11.0 and LibVEX; rerun with -h for copyright info
\==7902\== Command: /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools/install/bin/oggLength /home/wws/Music/Fuzz/cmp/fuzz\_out\_oggvideotools\_oggLength/crashes/id:000025,sig:11,src:000146,op:flip1,pos:5
\==7902\== 
\==7902\== Invalid read of size 8
\==7902\==    at 0x41F650: StreamSerializer::extractStreams() (streamSerializer.cpp:163)
\==7902\==    by 0x4261A2: StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) (streamSerializer.cpp:75)
\==7902\==    by 0x40F6A3: oggLengthCmd(int, char\*\*) (oggLength.cpp:86)
\==7902\==    by 0x40E412: main (oggLength.cpp:136)
\==7902\==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
\==7902\== 
\==7902\== 
\==7902\== Process terminating with default action of signal 11 (SIGSEGV)
\==7902\==  Access not within mapped region at address 0x0
\==7902\==    at 0x41F650: StreamSerializer::extractStreams() (streamSerializer.cpp:163)
\==7902\==    by 0x4261A2: StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) (streamSerializer.cpp:75)
\==7902\==    by 0x40F6A3: oggLengthCmd(int, char\*\*) (oggLength.cpp:86)
\==7902\==    by 0x40E412: main (oggLength.cpp:136)
\==7902\==  If you believe this happened as a result of a stack
\==7902\==  overflow in your program's main thread (unlikely but
\==7902\==  possible), you can try to increase the size of the
\==7902\==  main thread stack using the \--main\-stacksize\= flag.
\==7902\==  The main thread stack size used in this run was 8388608.
\==7902\== 
\==7902\== HEAP SUMMARY:
\==7902\==     in use at exit: 157,974 bytes in 18 blocks
\==7902\==   total heap usage: 22 allocs, 4 frees, 162,629 bytes allocated
\==7902\== 
\==7902\== LEAK SUMMARY:
\==7902\==    definitely lost: 0 bytes in 0 blocks
\==7902\==    indirectly lost: 0 bytes in 0 blocks
\==7902\==      possibly lost: 0 bytes in 0 blocks
\==7902\==    still reachable: 157,974 bytes in 18 blocks
\==7902\==         suppressed: 0 bytes in 0 blocks
\==7902\== Rerun with \--leak\-check\=full to see details of leaked memory
\==7902\== 
\==7902\== For counts of detected and suppressed errors, rerun with: \-v
\==7902\== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

I use **AddressSanitizer** to build oggvideotools, this file can cause SEGV signal in function StreamSerializer::extractStreams() with the following command:

./oggLength oggLength\_SEGV

This is the ASAN information:

ASAN:SIGSEGV
\=================================================================
\==7905\==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000043e4b9 bp 0x7ffe756519d0 sp 0x7ffe75651720 T0)
    #0 0x43e4b8 in StreamSerializer::extractStreams() oggvideotools\-0.9.1/src/main/streamSerializer.cpp:163
    #1 0x43da8f in StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) oggvideotools\-0.9.1/src/main/streamSerializer.cpp:75
    #2 0x43b044 in oggLengthCmd(int, char\*\*) oggvideotools\-0.9.1/src/binaries/oggLength.cpp:86
    #3 0x43b4e5 in main oggvideotools\-0.9.1/src/binaries/oggLength.cpp:136
    #4 0x7f6e840b082f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #5 0x43aa78 in \_start (target\_oggvideotools/install/bin/oggLength+0x43aa78)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
oggvideotools\-0.9.1/src/main/streamSerializer.cpp:163 StreamSerializer::extractStreams()
\==7905\==ABORTING

CVE-2020-21723: Ogg Video Tools / Bugs

An issue was discovered in hwclock.13-v2.27 allows attackers to gain escalated privlidges or execute arbitrary commands via the path parameter when setting the date.

CVE-2020-21583: #786804 - hwclock(8) SUID privilege escalation

Reachable Assertion vulnerability in upx before 4.0.0 allows attackers to cause a denial of service via crafted file passed to the the readx function.

**What's the problem (or question)?**

Assertion \`(unsigned)len <= buf->getSize()' failed in file.cpp:275

upx.out: file.cpp:275: virtual int InputFile::readx(MemBuffer\*, int): Assertion \`(unsigned)len <= buf\-\>getSize()' failed.
Program received signal SIGABRT, Aborted.

    pwndbg> bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff7bcc859 in __GI_abort () at abort.c:79
    #2  0x00007ffff7bcc729 in __assert_fail_base (fmt=0x7ffff7d62588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555555f5618 "(unsigned)len <= buf->getSize()", file=0x5555557067b1 "file.cpp", line=275, function=<optimized out>) at assert.c:92
    #3  0x00007ffff7bddf36 in __GI___assert_fail (assertion=0x5555555f5618 "(unsigned)len <= buf->getSize()", file=0x5555557067b1 "file.cpp", line=275, function=0x5555555f5638 "virtual int InputFile::readx(MemBuffer*, int)") at assert.c:101
    #4  0x000055555558a280 in InputFile::readx(MemBuffer*, int) ()
    #5  0x00005555555c5969 in PackUnix::packExtent(PackUnix::Extent const&, Filter*, OutputFile*, unsigned int, unsigned int) ()
    #6  0x00005555555b4fb2 in PackMachBase<N_Mach::MachClass_64<N_BELE_CTP::LEPolicy> >::pack2(OutputFile*, Filter&) ()
    #7  0x00005555555c4d98 in PackUnix::pack(OutputFile*) ()
    #8  0x00005555555d6028 in Packer::doPack(OutputFile*) ()
    #9  0x00005555555eacd3 in do_one_file(char const*, char*) ()
    #10 0x00005555555eaf8f in do_files(int, int, char**) ()
    #11 0x00005555555973c7 in upx_main(int, char**) ()
    #12 0x000055555557c4e2 in main ()
    #13 0x00007ffff7bce0b3 in __libc_start_main (main=0x55555557c3e0 <main>, argc=2, argv=0x7fffffffe208, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe1f8) at ../csu/libc-start.c:308
    #14 0x000055555557c5fe in _start ()
    

**What should have happened?**

No crash.

**Do you have an idea for a solution?**

No.

**How can we reproduce the issue?**

1.make  
2../src/upx.out ./poc  
poc.zip

**Please tell us details about your environment.**

*   ./upx.out --version  
    upx 4.0.0-git-5d1347a359bb  
    UCL data compression library 1.03  
    zlib data compression library 1.2.11  
    LZMA SDK version 4.43
*   Host Operating System and version: Ubuntu 20.04 focal
*   Host CPU architecture: AMD E  
    poc.zip  
    PYC 7742 64-Core @ 16x 2.25GHz
*   Target Operating System and version: Ubuntu 20.04 focal
*   Target CPU architecture: AMD EPYC 7742 64-Core @ 16x 2.25GHz

CVE-2021-46179: Assertion `(unsigned)len <= buf->getSize()' failed in file.cpp:275 · Issue #545 · upx/upx

An issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service. Note: Vendor states that this to is Defense in Depth at most due to the nature of the issue and the special circumstances required (server must be running particular code locally, code compiled with an old, old version of javac, etc.).

ADDITIONAL SYSTEM INFORMATION :  
OS version:  
Distributor ID: Ubuntu  
Description: Ubuntu 20.04.2 LTS  
Release: 20.04  
Codename: focal

JDK version we used:

openjdk version "17.0.2" 2022-01-18  
OpenJDK Runtime Environment (build 17.0.2+8-86)  
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

openjdk version "18" 2022-03-22  
OpenJDK Runtime Environment (build 18+36-2087)  
OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)

openjdk version "19-ea" 2022-09-20  
OpenJDK Runtime Environment (build 19-ea+13-808)  
OpenJDK 64-Bit Server VM (build 19-ea+13-808, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :  
When we run the test in jdk17.0.2, jdk18 and jdk19-ea, all in compiled mode(with "-Xcomp"), it crashed with the following message. But when run the test in mixed mode or interpreted mode(with "-Xint), it passed successfully.

The error message in compiled mode:

jdk17.0.2:  
\# A fatal error has been detected by the Java Runtime Environment:  
#  
\# SIGSEGV (0xb) at pc=0x00007f0b86b5a37b, pid=32365, tid=32379  
#  
\# JRE version: OpenJDK Runtime Environment (17.0.2+8) (build 17.0.2+8-86)  
\# Java VM: OpenJDK 64-Bit Server VM (17.0.2+8-86, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)  
\# Problematic frame:  
\# V \[libjvm.so+0x52837b\] ciMethodBlocks::make\_block\_at(int)+0x3b  
#  
\# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again  
#  
\# An error report file with more information is saved as:  
\# /home/minghai/hs\_err\_pid32365.log  
#  
\# Compiler replay data is saved as:  
\# /home/minghai/replay\_pid32365.log  
#  
\# If you would like to submit a bug report, please visit:  
\# https://bugreport.java.com/bugreport/crash.jsp

jdk18:  
\# A fatal error has been detected by the Java Runtime Environment:  
#  
\# SIGSEGV (0xb) at pc=0x00007f9a003d800b, pid=32250, tid=32263  
#  
\# JRE version: OpenJDK Runtime Environment (18.0+36) (build 18+36-2087)  
\# Java VM: OpenJDK 64-Bit Server VM (18+36-2087, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)  
\# Problematic frame:  
\# V \[libjvm.so+0x54b00b\] ciTypeFlow::get\_block\_for(int, ciTypeFlow::JsrSet\*, ciTypeFlow::CreateOption)+0x2b  
#  
\# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again  
#  
\# An error report file with more information is saved as:  
\# /home/minghai/hs\_err\_pid32250.log  
#  
\# Compiler replay data is saved as:  
\# /home/minghai/replay\_pid32250.log  
#  
\# If you would like to submit a bug report, please visit:  
\# https://bugreport.java.com/bugreport/crash.jsp

jdk19-ea:  
\# A fatal error has been detected by the Java Runtime Environment:  
#  
\# SIGSEGV (0xb) at pc=0x00007f96f291b1fb, pid=32319, tid=32332  
#  
\# JRE version: OpenJDK Runtime Environment (19.0+13) (build 19-ea+13-808)  
\# Java VM: OpenJDK 64-Bit Server VM (19-ea+13-808, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)  
\# Problematic frame:  
\# V \[libjvm.so+0x5571fb\] ciTypeFlow::get\_block\_for(int, ciTypeFlow::JsrSet\*, ciTypeFlow::CreateOption)+0x2b  
#  
\# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again  
#  
\# An error report file with more information is saved as:  
\# /home/minghai/hs\_err\_pid32319.log  
#  
\# Compiler replay data is saved as:  
\# /home/minghai/replay\_pid32319.log  
#  
\# If you would like to submit a bug report, please visit:  
\# https://bugreport.java.com/bugreport/crash.jsp

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :  
1\. extract the bug.zip  
2\. in dictionary "bug", run command:  
java -cp ./bugFiles:./util:./junit.jar:./hamcrest.jar:./target/classes:./target/test-classes org.junit.runner.JUnitCore com.alibaba.fastjson.deserializer.issue1463.TestIssue1463

you may add "-Xcomp" or "-Xint" to get different results.

EXPECTED VERSUS ACTUAL BEHAVIOR :  
EXPECTED -  
The result should be the same since the program are the same, no matter in compiled mode, mixed mode or interpreted mode.  
ACTUAL -  
When run in compiled mode(with "-Xcomp"), it crashed. But when run in mixed mode or interpreted mode(with -Xint), it passed successfully.

\---------- BEGIN SOURCE ----------  
to be attached in bug.zip  
\---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :  
run the command without -Xcomp or with -Xint

FREQUENCY : always

CVE-2022-40433: C2: segmentation fault in ciMethodBlocks::make_block_at(int)

Open Redirect vulnerability in Horizon Web Dashboard 19.4.0 thru 20.1.4 via the success_url parameter.

The "success\_url" param is used when updating the project snapshot and it lacks sanitizing the input URL that allows an attacker to redirect the user to another website.

For instance, the URL below will redirect you to https://hacker.com:

https://xxx.com/project/snapshots/a54c1d97-d354-4171-9602-52fdf0949e83/update/?success\_url=https://hacker.com

The attacker can send this link to the user and when they click on the "Update" button the request and response will look like this:

\[+\] Request

POST /project/snapshots/a54c1d97-d354-4171-9602-52fdf0949e83/update/?success\_url=https%3A%2F%2Fhacker.coom HTTP/1.1  
Host: xxx.com  
Cookie: \_ga\_0CPB5J3KQB=GS1.1.1656302247.2.0.1656302247.0; \_ga=GA1.1.2043123211.1656300031; login\_region=default; login\_domain=""; theme=default; sessionid=yl7fjfh7dhpwduodbxb4mjxng46qowgh; csrftoken=j5WQq7woP7OJGKnbTAa6cbQ8zyEgUhWjIZRu4vDMNgbFbNIl5bAe7V2PESYSbUYI; recent\_project=dfcf9f80229f400a9e7ac53782be9e39  
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:91.0) Gecko/20100101 Firefox/91.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,\*/\*;q=0.8  
Accept-Language: en-US,en;q=0.5  
<======\=======\=======\>SNIP<=\=======\=======\=====>

csrfmiddlewaretoken=9wp8nOC21UvAGFxqG0qa1DjRsdKg26P0yqkM1cJqZ3SwbISASBQiWnvyxx4SjJRp&name=snapshot+for+%3Cscript%3Ealert%281%29%3C%2Fscript%3E+%22+%27%5Cu0022%C3%A2%5Cx04&description=

\[+\] Response

HTTP/1.1 302 Found  
date: Tue, 12 Jul 2022 10:14:38 GMT  
server: Apache/2.4.41 (Ubuntu)  
location: https://hacker.com  
content-length: 0  
x-horizon-location: https://hacker.com  
x-frame-options: SAMEORIGIN  
vary: Accept-Language,Cookie  
content-language: en  
<======\=======\=======\>SNIP<=\=======\=======\=====>

Impact: The attacker can trick redirect users to the cloned website to steal information, a so-called Phishing Attack.

CWE-601: URL Redirection to Untrusted Site ('Open Redirect')  
http://cwe.mitre.org/data/definitions/601.html

I have tested it on OpenStack Xena so the Horizon dashboard could be between version 20.0.0 to 20.1.2. I haven't tested the bug on other versions.  
Unfortunately, I have discovered this bug when pen-testing a black box project so I do not have the log file. Hope my information helps you to understand the bug.

Tag

#ubuntu