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

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

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

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 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

p7zip 16.02 was discovered to contain a heap-buffer-overflow vulnerability via the function NArchive::NZip::CInArchive::FindCd(bool) at CPP/7zip/Archive/Zip/ZipIn.cpp.

*   Summary
*   Files
*   Reviews
*   Support
*   Tickets ▾
    *   Bugs
    *   Support Requests
    *   Patches
    *   Feature Requests
*   Discussion

Menu ▾ ▴

Status: open

Owner: nobody

Labels: None

Priority: 5

Updated: 2022-12-09

Created: 2022-12-09

Private: No

**Description**

Heap-buffer-overflow in CPP/7zip/Archive/Zip/ZipIn.cpp:1116 in NArchive::NZip::CInArchive::FindCd(bool)

**Verison**

$ ./7za   
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,64 CPUs x64)

**Replay**

./7za t poc.zip

**POC**

https://github.com/17ssDP/fuzzer\_crashes/raw/main/zip/poc.zip

**ASAN**

$./7zatpoc.zip

7-Zip(a)[64]16.02:Copyright(c)1999-2016IgorPavlov:2016-05-21
p7zipVersion16.02(locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64bits,64CPUsx64)

Scanningthedriveforarchives:
1file,4340bytes(5KiB)

Testingarchive:poc.zip
=================================================================
==65213==ERROR:AddressSanitizer:heap-buffer-overflowonaddress0x6210000000ffatpc0x55b8f9dd0731bp0x7ffd13599890sp0x7ffd13599880
READofsize4at0x6210000000ffthreadT0
#00x55b8f9dd0730inNArchive::NZip::CInArchive::FindCd(bool)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1116
#10x55b8f9dd5f00inNArchive::NZip::CInArchive::ReadVols()../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1578
#20x55b8f9e01d9binNArchive::NZip::CInArchive::Open(IInStream*,unsignedlonglongconst*,IArchiveOpenCallback*,CObjectVector<NArchive::NZip::CItemEx>&)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:2135
#30x55b8f9d4c294inNArchive::NZip::CHandler::Open(IInStream*,unsignedlonglongconst*,IArchiveOpenCallback*)../../../../CPP/7zip/Archive/Zip/ZipHandler.cpp:474
#40x55b8fa46890binCArc::OpenStream2(COpenOptionsconst&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:1878
#50x55b8fa47fb6ainCArc::OpenStream(COpenOptionsconst&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:2901
#60x55b8fa481451inCArc::OpenStreamOrFile(COpenOptions&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:2993
#70x55b8fa48437ainCArchiveLink::Open(COpenOptions&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3169
#80x55b8fa48ccf5inCArchiveLink::Open2(COpenOptions&,IOpenCallbackUI*)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3292
#90x55b8fa48f2a5inCArchiveLink::Open3(COpenOptions&,IOpenCallbackUI*)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3356
#100x55b8fa409e7einExtract(CCodecs*,CObjectVector<COpenType>const&,CRecordVector<int>const&,CObjectVector<UString>&,CObjectVector<UString>&,NWildcard::CCensorNodeconst&,CExtractOptionsconst&,IOpenCallbackUI*,IExtractCallbackUI*,IHashCalc*,UString&,CDecompressStat&)../../../../CPP/7zip/UI/Common/Extract.cpp:362
#110x55b8fa5cc0b6inMain2(int,char**)../../../../CPP/7zip/UI/Console/Main.cpp:923
#120x55b8f9819ef8inmain../../../../CPP/7zip/UI/Console/MainAr.cpp:66
#130x7fa675178c86in__libc_start_main(/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#140x55b8f981c069in_start(/home/p7zip/7za+0x41069)

0x6210000000ffislocated1bytestotheleftof4340-byteregion[0x621000000100,0x6210000011f4)
allocated by thread T0 here:
    #0 0x7fa675e6c608 in operator new[](unsignedlong)(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
#10x55b8f9dce590inCObjArray<unsignedchar>::CObjArray(unsignedlong)../../../../CPP/7zip/Archive/Zip/../../../Common/MyBuffer.h:141
#20x55b8f9dce590inNArchive::NZip::CInArchive::FindCd(bool)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1066

SUMMARY:AddressSanitizer:heap-buffer-overflow../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1116inNArchive::NZip::CInArchive::FindCd(bool)
Shadowbytesaroundthebuggyaddress:
0x0c427fff7fc0:00000000000000000000000000000000
0x0c427fff7fd0:00000000000000000000000000000000
0x0c427fff7fe0:00000000000000000000000000000000
0x0c427fff7ff0:00000000000000000000000000000000
0x0c427fff8000:fafafafafafafafafafafafafafafafa
=>0x0c427fff8010:fafafafafafafafafafafafafafafa[fa]
0x0c427fff8020:00000000000000000000000000000000
0x0c427fff8030:00000000000000000000000000000000
0x0c427fff8040:00000000000000000000000000000000
0x0c427fff8050:00000000000000000000000000000000
0x0c427fff8060:00000000000000000000000000000000
Shadowbytelegend(oneshadowbyterepresents8applicationbytes):
Addressable:00
Partiallyaddressable:01020304050607
Heapleftredzone:fa
Freedheapregion:fd
Stackleftredzone:f1
Stackmidredzone:f2
Stackrightredzone:f3
Stackafterreturn:f5
Stackuseafterscope:f8
Globalredzone:f9
Globalinitorder:f6
Poisonedbyuser:f7
Containeroverflow:fc
Arraycookie:ac
Intraobjectredzone:bb
ASaninternal:fe
Leftallocaredzone:ca
Rightallocaredzone:cb
==65213==ABORTING

**Environment**

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2022-47069: p7zip / Bugs / #241 Heap-buffer-overflow in ZipIn.cpp:1116

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 was discovered in function zzip_disk_entry_to_file_header in mmapped.c in zziplib 0.13.69, which will lead to a denial-of-service.

POC:  
zip\_poc.zip

There exisits one invalid memroy access issue in zzip\_disk\_entry\_to\_file\_header in mmapped.c in zziplib 0.13.69, which will lead to a denial-of-service. This bug can be triggered by the executable unzzip-mem.

$ unzzip-mem $poc

**ASAN:SIGSEGV**

\==8254==ERROR: AddressSanitizer: SEGV on unknown address 0x1772507f (pc 0xb772ff16 sp 0xbfce6a10 bp 0x0101db82 T0)  
#0 0xb772ff15 in zzip\_disk\_entry\_to\_file\_header /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/zzip/../../zzip/mmapped.c:272  
#1 0xb77390d8 in zzip\_mem\_entry\_new /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/zzip/../../zzip/memdisk.c:201  
#2 0xb77390d8 in zzip\_mem\_disk\_load /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/zzip/../../zzip/memdisk.c:160  
#3 0xb77386c7 in zzip\_mem\_disk\_open /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/zzip/../../zzip/memdisk.c:94  
#4 0x80ce02e in unzzip\_cat /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/bins/../../bins/unzzipcat-mem.c:72  
#5 0x80d0fae in unzzip\_extract /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/bins/../../bins/unzzipcat-mem.c:143  
#6 0x80cd5f0 in main /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/bins/../../bins/unzzip.c:187  
#7 0xb74d7af2 (/lib/i386-linux-gnu/libc.so.6+0x19af2)  
#8 0x80caa74 in \_start (/home/rookie/asan/zziplib-master/build/bin/unzzip-mem+0x80caa74)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /home/rookie/asan/zziplib-master/i686-pc-linux-gnu/zzip/../../zzip/mmapped.c:272 zzip\_disk\_entry\_to\_file\_header  
\==8254==ABORTING

CVE-2020-18770: one invalid memroy access issue in zzip_disk_entry_to_file_header in mmapped.c · Issue #69 · gdraheim/zziplib

A NULL pointer dereference was discovered in SExpressionWasmBuilder::makeBlock in wasm/wasm-s-parser.c in Binaryen 1.38.26. A crafted wasm input can cause a segmentation fault, leading to denial-of-service, as demonstrated by wasm-as.

Hi, there.

A Heap-buffer-overflow problem was discovered in wasm::WasmBinaryBuilder::visitBlock(wasm::Block\*) function in simple\_ast.h in /src/wasm/wasm-binary.cpp, as distributed in Binaryen 1.38.26. A crafted wasm input can cause segment faults and I have confirmed them with address sanitizer too.

Here are the POC files. Please use "./wasm-opt $POC" to reproduce the error.  
POC.zip

git log

    commit 153ba18ba99dc4dcef29a61e1e586af3df8d921d (HEAD -> master, tag: version_65, origin/master, origin/HEAD)
    Author: Alon Zakai <alonzakai@gmail.com>
    Date:   Mon Jan 28 11:32:19 2019 -0800
    
        Handle EM_ASM/EM_JS in LLVM wasm backend O0 output (#1888)
    
        See emscripten-core/emscripten#7928 - we have been optimizing all wasms until now, and noticed this when the wasm object file path did not do so. When not optimizing, our methods of handling EM_ASM and EM_JS fail since the patterns are different.
    
        Specifically, for EM_ASM we hunt for emscripten_asm_const(X, where X is a constant, but without opts it may be a get of a local. For EM_JS, the function body may not just contain a const, but a block with a set of the const and a return of a get later.
    
        This adds logic to track gets and sets in basic blocks, which is sufficient to handle this.
    

The ASAN dumps the stack trace as follows:

    =================================================================
    ==10623==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e000000456 at pc 0x55961cae7862 bp 0x7ffd73795210 sp 0x7ffd73795200
    READ of size 1 at 0x60e000000456 thread T0
        #0 0x55961cae7861 in wasm::WasmBinaryBuilder::visitBlock(wasm::Block*) /binaryen/src/wasm/wasm-binary.cpp:1805
        #1 0x55961cad63bc in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) /binaryen/src/wasm/wasm-binary.cpp:1687
        #2 0x55961cada7fa in wasm::WasmBinaryBuilder::skipUnreachableCode() /binaryen/src/wasm/wasm-binary.cpp:1417
        #3 0x55961cadba97 in wasm::WasmBinaryBuilder::processExpressions() /binaryen/src/wasm/wasm-binary.cpp:1392
        #4 0x55961cae7f6e in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) /binaryen/src/wasm/wasm-binary.cpp:1846
        #5 0x55961caf83d2 in wasm::WasmBinaryBuilder::visitIf(wasm::If*) /binaryen/src/wasm/wasm-binary.cpp:1871
        #6 0x55961cad3bb0 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) /binaryen/src/wasm/wasm-binary.cpp:1688
        #7 0x55961cada7fa in wasm::WasmBinaryBuilder::skipUnreachableCode() /binaryen/src/wasm/wasm-binary.cpp:1417
        #8 0x55961cadba97 in wasm::WasmBinaryBuilder::processExpressions() /binaryen/src/wasm/wasm-binary.cpp:1392
        #9 0x55961cae7f6e in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) /binaryen/src/wasm/wasm-binary.cpp:1846
        #10 0x55961caf83d2 in wasm::WasmBinaryBuilder::visitIf(wasm::If*) /binaryen/src/wasm/wasm-binary.cpp:1871
        #11 0x55961cad3bb0 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) /binaryen/src/wasm/wasm-binary.cpp:1688
        #12 0x55961cada7fa in wasm::WasmBinaryBuilder::skipUnreachableCode() /binaryen/src/wasm/wasm-binary.cpp:1417
        #13 0x55961cadba97 in wasm::WasmBinaryBuilder::processExpressions() /binaryen/src/wasm/wasm-binary.cpp:1392
        #14 0x55961cae7f6e in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) /binaryen/src/wasm/wasm-binary.cpp:1846
        #15 0x55961caed21f in wasm::WasmBinaryBuilder::readFunctions() /binaryen/src/wasm/wasm-binary.cpp:1129
        #16 0x55961caf597f in wasm::WasmBinaryBuilder::read() /binaryen/src/wasm/wasm-binary.cpp:678
        #17 0x55961cba18f7 in wasm::ModuleReader::readBinary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) /binaryen/src/wasm/wasm-io.cpp:52
        #18 0x55961cba7d97 in wasm::ModuleReader::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) /binaryen/src/wasm/wasm-io.cpp:71
        #19 0x55961c764faf in main /binaryen/src/tools/wasm-opt.cpp:144
        #20 0x7fce29513b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
        #21 0x55961c77ec39 in _start (/binaryen/build/bin/wasm-opt+0x1c5c39)
    
    0x60e000000456 is located 0 bytes to the right of 150-byte region [0x60e0000003c0,0x60e000000456)
    allocated by thread T0 here:
        #0 0x7fce2a302458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
        #1 0x55961df084ef in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /usr/include/c++/7/ext/new_allocator.h:111
        #2 0x55961df084ef in std::allocator_traits<std::allocator<char> >::allocate(std::allocator<char>&, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:436
        #3 0x55961df084ef in std::_Vector_base<char, std::allocator<char> >::_M_allocate(unsigned long) /usr/include/c++/7/bits/stl_vector.h:172
        #4 0x55961df084ef in std::_Vector_base<char, std::allocator<char> >::_M_create_storage(unsigned long) /usr/include/c++/7/bits/stl_vector.h:187
        #5 0x55961df084ef in std::_Vector_base<char, std::allocator<char> >::_Vector_base(unsigned long, std::allocator<char> const&) /usr/include/c++/7/bits/stl_vector.h:138
        #6 0x55961df084ef in std::vector<char, std::allocator<char> >::vector(unsigned long, char const&, std::allocator<char> const&) /usr/include/c++/7/bits/stl_vector.h:297
        #7 0x55961df084ef in std::vector<char, std::allocator<char> > wasm::read_file<std::vector<char, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, wasm::Flags::BinaryOption, wasm::Flags::DebugOption) /binaryen/src/support/file.cpp:42
        #8 0x55961cb9fbf2 in wasm::ModuleReader::readBinary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) /binaryen/src/wasm/wasm-io.cpp:44
        #9 0x55961cba7d97 in wasm::ModuleReader::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) /binaryen/src/wasm/wasm-io.cpp:71
        #10 0x55961c764faf in main /binaryen/src/tools/wasm-opt.cpp:144
        #11 0x7fce29513b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /binaryen/src/wasm/wasm-binary.cpp:1805 in wasm::WasmBinaryBuilder::visitBlock(wasm::Block*)
    Shadow bytes around the buggy address:
      0x0c1c7fff8030: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      0x0c1c7fff8040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff8050: fd fd fd fa fa fa fa fa fa fa fa fa 00 00 00 00
      0x0c1c7fff8060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 fa
      0x0c1c7fff8070: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x0c1c7fff8080: 00 00 00 00 00 00 00 00 00 00[06]fa fa fa fa fa
      0x0c1c7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff80d0: 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
    ==10623==ABORTING

CVE-2020-18378: Heap-buffer-overflow in /src/wasm/wasm-binary.cpp in wasm::WasmBinaryBuilder::visitBlock(wasm::Block*) in Binaryen 1.38.26 · Issue #1900 · WebAssembly/binaryen

Tag

#linux