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

An issue was discovered in open-mpi hwloc 2.1.0 allows attackers to cause a denial of service or other unspecified impacts via glibc-cpuset in topology-linux.c.

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.

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

Closed

ash1852 opened this issue

Aug 31, 2022

· 3 comments

**Comments**

Hi, I found a potential null pointer dereference bug in the project source code of hwloc, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the green text represents some additional information to help understanding when the steps occur and the file path can be seen in the blue framed section.

Although the code shown is for version 2.1.0, this potential bug is still present in the current version

setsize \= CPU\_ALLOC\_SIZE(last+1);

plinux\_set \= CPU\_ALLOC(last+1);

CPU\_ZERO\_S(setsize, plinux\_set);

  
would you can help to check if this bug is true?thank you!

Hello  
Yes, there are likely many corner cases like where we don't check allocation return values. Similar issue in hwloc\_linux\_set\_tid\_cpubind(), hwloc\_linux\_find\_kernel\_nr\_cpus() and hwloc\_linux\_get\_tid\_cpubind(), hwloc\_linux\_set\_thread\_cpubind(), hwloc\_linux\_get\_thread\_cpubind().  
The (bad) rational is that other things will go wrong before this one will trigger a crash. Feel free to send a fix :)

 bgoglin changed the title A potential bug of NPD potential NULL glibc-cpuset dereferences in topology-linux.c

Aug 31, 2022

CVE-2022-47022 was assigned to this issue.

I didn't have any involvement in the assignment, posting here for visibility.

Thanks for the reminder, I forgot about this, I am pushing the fix to master and all stable branches.

bgoglin added a commit that referenced this issue

Aug 24, 2023

CVE-2022-47022: potential NULL glibc-cpuset dereferences in topology-linux.c · Issue #544 · open-mpi/hwloc

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

Buffer Overflow vulnerability in WritePCXImage function in pcx.c in GraphicsMagick 1.4 allows remote attackers to cause a denial of service via converting of crafted image file to pcx format.

Hi, I found a heap-buffer-overflow in WritePCXImage at pcx.c:1255  
I tested it in GraphicsMagick 1.4  
how to reproduce :

ASAN LOG

\==14178\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0x6030000000c0 at pc 0x0000028f29c0 bp 0x7ffec5056070 sp 0x7ffec5056068
WRITE of size 1 at 0x6030000000c0 thread T0
    #0 0x28f29bf in WritePCXImage /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1255:17
    #1 0x8e5c7e in WriteImage /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2245:14
    #2 0x8eac18 in WriteImages /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2404:21
    #3 0x615be6 in ConvertImageCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:6135:11
    #4 0x72e875 in MagickCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:8880:17
    #5 0x810c5c in GMCommandSingle /home/suhwan/project/graphicsmagick\-code/magick/command.c:17412:10
    #6 0x80ba1e in GMCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:17465:16
    #7 0x7ff6e5aa2b96 in \_\_libc\_start\_main (/lib/x86\_64\-linux\-gnu/libc.so.6+0x21b96)
    #8 0x424239 in \_start (/home/suhwan/project/fuzz\-input\-validate/test/bin/gm+0x424239)

0x6030000000c0 is located 0 bytes to the right of 32\-byte region \[0x6030000000a0,0x6030000000c0)
allocated by thread T0 here:
    #0 0x4cc083 in \_\_interceptor\_malloc /tmp/final/llvm.src/projects/compiler\-rt/lib/asan/asan\_malloc\_linux.cc:146:3
    #1 0x28ddf2c in WritePCXImage /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1172:16
    #2 0x8e5c7e in WriteImage /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2245:14
    #3 0x8eac18 in WriteImages /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2404:21

SUMMARY: AddressSanitizer: heap\-buffer\-overflow /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1255:17 in WritePCXImage
Shadow bytes around the buggy address:
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff8000: fa fa fd fd fd fd fa fa 00 00 00 fa fa fa 00 00
\=>0x0c067fff8010: 05 fa fa fa 00 00 00 00\[fa\]fa fa fa fa fa fa fa
  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8060: 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
\==14178\==ABORTING

GraphicsMagick 1.4 snapshot-20191225 Q8 http://www.GraphicsMagick.org/  
Copyright (C) 2002-2019 GraphicsMagick Group.  
Additional copyrights and licenses apply to this software.  
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:  
Native Thread Safe yes  
Large Files (> 32 bit) yes  
Large Memory (> 32 bit) yes  
BZIP yes  
DPS no  
FlashPix no  
FreeType yes  
Ghostscript (Library) no  
JBIG yes  
JPEG-2000 no  
JPEG yes  
Little CMS yes  
Loadable Modules no  
Solaris mtmalloc no  
OpenMP yes (201107 "3.1")  
PNG yes  
TIFF yes  
TRIO no  
Solaris umem no  
WebP no  
WMF no  
X11 yes  
XML yes  
ZLIB yes

Host type: x86\_64-pc-linux-gnu

CVE-2020-21679: GraphicsMagick / Bugs / #619 heap-buffer-overflow in WritePCXImage

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

A Use After Free vulnerability in Fedora Linux kernel 5.9.0-rc9 allows attackers to obatin sensitive information via vgacon_invert_region() function.

Submitted by Zhang Xiaoxu on March 4, 2020, 2:24 a.m.

**Details**

**Not browsing as part of any series.**

**Commit Message****Patch hide | download patch | download mbox**

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index de7b8382aba9..998b0de1812f 100644
\--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1316,6 +1316,9 @@  static int vgacon\_font\_get(struct vc\_data \*c, struct console\_font \*font)
 static int vgacon\_resize(struct vc\_data \*c, unsigned int width,
 			 unsigned int height, unsigned int user)
 {
+	if ((width << 1) \* height > vga\_vram\_size)
+		return -EINVAL;
+
 	if (width % 2 || width > screen\_info.orig\_video\_cols ||
 	    height > (screen\_info.orig\_video\_lines \* vga\_default\_font\_height)/
 	    c->vc\_font.height)

**Comments**

CVE-2020-27418: [v4] vgacon: Fix a UAF in vgacon_invert_region

An issue was discovered in spice-server spice-server-0.14.0-6.el7_6.1.x86_64 of Redhat's VDI product. There is a security vulnerablility that can restart KVMvirtual machine without any authorization. It is not yet known if there will be other other effects.

**Spice-Security-Issues**

I found a security issue on spice Server when I was fuzzing Spice server.

**Introduce**

A handshake is required before the spice-server and spice-client can establish communication, spice-client will send a request containing some information that the server needs. This TCP request requires only host and port. So I constructed a malformed TCP packet that caused the vm to crash and the QEMu-KVM process to be restarted.

**How to run**

#1. Send a malformed TCP packet(Observe the packets intercepted by Wirshark)  #2. check qemu-kvm process && kvm instance state

Before sending a malformed TCP packet  
  After sending a malformed TCP packet  

#3. Check libvirt's log that the virtual machine crashed  #4. Observe the virtual machine through virt-manage, found that the virtual machine has been restarted 

**Vulnerability Code**

Code Address: https://gitlab.freedesktop.org/spice/spice/-/blob/master/server/red-stream.cpp  
Function：async\_read\_handler Description: The function async\_READ\_handler caused a deadlock while processing the data stream. 

**Related component version**

Centos: Linux version 3.10.0-957.10.2.el7.x86\_64  
Qemu-kvm: QEMU emulator version 2.10.0(qemu-kvm-ev-2.10.0-21.el7\_5.7.1)  
Spice-server rpm: spice-server-0.14.0-6.el7\_6.1.x86\_64

CVE-2020-23793: GitHub - zelat/spice-security-issues

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.

The core of the XZ Utils compression code is based on LZMA SDK, but it has been modified quite a lot to be suitable for XZ Utils. The primary compression algorithm is currently LZMA2, which is used inside the .xz container format. With typical files, XZ Utils create 30 % smaller output than gzip and 15 % smaller output than bzip2.

XZ Utils consist of several components:

*   liblzma is a compression library with an API similar to that of zlib.
*   xz is a command line tool with syntax similar to that of gzip.
*   xzdec is a decompression-only tool smaller than the full-featured xz tool.
*   A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.
*   Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils.

While liblzma has a zlib-like API, liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API.

**Documentation**

Man page with a keyword index: xz(1)

Doxygen-generated liblzma API documentation is also included in the source packages since XZ Utils 5.4.2.

**Source code**

Versions 5.2.12, 5.4.3, and later have been signed with Jia Tan's OpenPGP key. The older files have been signed with Lasse Collin's OpenPGP key.

See the NEWS file for a summary of changes between versions.

**Stable**

5.4.4 was released on 2023-08-02. A minor bug fix release 5.2.12 to the old stable branch was made on 2023-05-04. This is probably the last release in the 5.2.x series.

XZ Utils releases are hosted on GitHub and thus some of the links below redirect to the XZ Utils release section on GitHub. Release files are also available in the XZ Utils files section on Sourceforge.

xz-5.4.4.tar.gz (2808 KiB) signature  
xz-5.4.4.tar.bz2 (2116 KiB) signature  
xz-5.4.4.tar.zst (1680 KiB) signature  
xz-5.4.4.tar.xz (1623 KiB) signature

Probably the last release of the old stable branch:

xz-5.2.12.tar.gz (2140 KiB) signature  
xz-5.2.12.tar.bz2 (1593 KiB) signature  
xz-5.2.12.tar.zst (1317 KiB) signature  
xz-5.2.12.tar.xz (1275 KiB) signature

**Development**

The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release.

There currently are no development releases.

**Old versions**

Source and binary packages of old XZ Utils releases are available on a separate page.

**Git repository**

The primary repository is on GitHub:

git clone https://github.com/tukaani-project/xz

It is mirrored with some delay to git.tukaani.org:

git clone https://git.tukaani.org/xz.git

Gitweb

Branches:

*   **master**: the latest development code
*   **v5.4**: fixes for the next 5.4.x release
*   **v5.2**: fixes for the next 5.2.x release
*   **v5.0**: fixes for the next 5.0.x release (unmaintained)

Building the code from the git repository requires GNU Autotools. Here are the _minimum_ versions that should work with XZ Utils; using the latest versions is strongly recommended:

*   Autoconf 2.69
*   Automake 1.12
*   gettext 0.19.6 (Note: autopoint depends on cvs!)
*   Libtool 2.4

The following are optional dependencies. The autogen.sh script will fail if they are missing but autogen.sh takes command line arguments to disable these dependencies.

*   po4a is needed for translated documentation (man pages). To build without po4a, use --no-po4a with autogen.sh.
*   Doxygen is needed to generate liblzma API documentation. To build without Doxygen, use --no-doxygen with autogen.sh.

**Security issues****xzgrep CVE-2022-1271, ZDI-CAN-16587**

A patch to fix a security vulnerability in xzgrep (CVE-2022-1271, ZDI-CAN-16587) was made public on 2022-04-07. The patch applies to 4.999.9beta to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

It is a severe issue if an attacker can control the filenames that are given on the xzgrep command line. The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative. For more information, see the detailed description in the patch file linked below.

xzgrep-ZDI-CAN-16587.patch  
xzgrep-ZDI-CAN-16587.patch.sig

**Bindings****Python**

Python 3.3 includes bindings for liblzma. A backport of these bindings are available for Python 2 in the backports.lzma package.

lzmaffi is another Python binding which adds random-access decompression support.

The original Python 2 binding for liblzma is PylibLZMA.

**Perl**

Perl bindings for liblzma: IO-Compress-Lzma and Compress-Raw-Lzma.

**Haskell**

Haskell bindings.

**Delphi and Free Pascal**

Bindings and example programs for Delphi and Free Pascal are available here.

**Pre-built binaries**

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn't make sense to provide links to all those here. Instead, binaries or links to websites providing binaries are listed here only for operating systems that don't have well-known repositories where users would get software like this.

If you have a website that provides up-to-date XZ Utils binaries for an operating system that meets the the criteria above, let me know and I will include a link here. Note that I won't host the binaries themselves without a good reason.

**Windows**

The Windows version of XZ Utils includes binaries for 32-bit and 64-bit x86. The binaries only depend on msvcrt.dll, which is available on Windows 98 and later out of the box.

*   Command line tools: xz, xzdec, lzmadec, lzmainfo
*   Shared (DLL) and static liblzma, required C header files, and liblzma.def to create import libraries for non-GNU toolchains (no import library is needed with GNU toolchain)
*   Documentation is in plain text (UTF-8) format. The man pages of the command line tools are included also as PDF.

5.2.10, 5.2.11, or 5.2.12 do not have anything significant for Windows so only 5.2.9 is here. 5.4.x builds are not provided for now.

xz-5.2.9-windows.zip (1473 KiB) signature  
xz-5.2.9-windows.7z (708 KiB) signature

**DOS**

The DOS version of XZ Utils includes only the xz command line tool and some documentation. The xz tool should work e.g. on FreeDOS (also in DOSEMU), MS-DOS, and Windows 95/98/98SE/ME. This doesn't necessarily work in DOSBox at all, and at least some problems are expected under Windows XP Command Prompt (signal handling doesn't work).

Since the DOS version is naturally going to get very little testing, it is recommended to use the Windows version instead of the DOS version if you need xz under Windows 98 or later. It is likely that that the DOS version will be updated only occasionally.

5.2.0 and later have experimental support for 8.3 filenames. See xz-dos.txt in the binary package or dos/README.txt in the source package for details.

xz-5.4.0-dos.zip (277 KiB) signature

The package includes some copylefted code from DJGPP and CWSDPMI. The relevant source code is available from their home pages, and copies are also available below.

djlsr205.zip (2000 KiB)  
djtst205.zip (1061 KiB)  
csdpmi7s.zip (88 KiB)

Juan Manuel Guerrero has made a more complete port of XZ Utils to DOS. It also has support for short file names (8.3), but the naming method is different from the one found in 5.2.0 and later. It is available from DJGPP mirrors under /current/v2apps (e.g. xz-500b.zip for 5.0.0 binaries).

**Supported platforms**

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. The compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If you have additions or corrections, please email them to me.

*   GNU/Linux (GCC, Clang, ICC, IBM XL C)
*   GNU/HURD (GCC)
*   DragonflyBSD (GCC)
*   FreeBSD (GCC, Clang)
*   MirBSD (GCC)
*   NetBSD (GCC)
*   OpenBSD (Clang, GCC)
*   MINIX 3 (GCC) \[1\]
*   Haiku (GCC4)
*   Mac OS X (GCC)
*   Solaris 8, 9, 10, 11 (GCC, Sun Studio) \[3\]
*   Solaris 2.6, 7 (GCC)
*   HP-UX (GCC, HP ANSI C) \[2\]
*   Tru64 (GCC, Compaq C compiler) \[1\]
*   IRIX (MIPSpro) \[1\]
*   AIX (GCC, IBM XL C)
*   z/OS (IBM XL C)
*   QNX (compilers?)
*   OpenVMS (HP C compiler) \[1\]
*   OpenVOS 17 (GCC)
*   SCO OpenServer 5.0.7 (GCC 3.4.6, 4.2.4) \[4\]
*   Windows 95 and later (GCC/MinGW, GCC/MinGW-w64, GCC/Cygwin, GCC/Interix, Visual Studio (VS can only build liblzma)) \[1\]
*   OS/2, eComStation (GCC)
*   DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) \[1\]

\[1\] See also the platform-specific notes in the INSTALL file.

\[2\] 2010-09-22: HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there are no problems.

\[3\] On Solaris 8 and 9 one may need to pass ac\_cv\_prog\_cc\_c99= to configure if using Sun Studio.

\[4\] Use --disable-threads when running configure.

**Licensing**

The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts.

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.

CVE-2020-22916: XZ Utils

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.

Tag

#linux