unicorn-engine/unicorn

Crash when emulating mips in 2.1.3

Opened this issue · 5 comments

peace-maker commented

This crashes unicorn 2.1.3 and was fine before:

# from pwnlib.asm import asm
# code = asm('''
# move $t9, $gp
# move $t7, $ra
# jalr $t9
# addiu $t8, $zero, 0x10
# ''', arch='mips', endian='little')
code = b'%\xc8\x80\x03%x\xe0\x03\t\xf8 \x03\x10\x00\x18$'

import unicorn
address = 0x1000
uc = unicorn.Uc(unicorn.UC_ARCH_MIPS, unicorn.UC_MODE_32)

uc.mem_map(address, 0x1000)
uc.mem_write(address, code)

ctx = uc.context_save()
for i, pc in enumerate(range(address, address + len(code), 4)):
    uc.context_restore(ctx)
    try:
        uc.emu_start(pc, until=-1, count=5)
    except unicorn.UcError as error:
        print(error)

pwntools CI crashed due to this.

wtdcode commented

Your observation is correct.

Fixed in 0bb1bbd

  • ❤️3
Arusekk commented

This occurrs again with unicorn 2.1.4, and can be reproduced with the exact same code:

$ strace -enone -es=SEGV -k python3.13 test.py
Invalid memory read (UC_ERR_READ_UNMAPPED)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(temp_load+0x95) [0x870635]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(tcg_gen_code_mipsel+0x1ed8) [0x879638]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(tb_gen_code_mipsel+0x159) [0x8a0f69]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(cpu_exec_mipsel+0x507) [0x883bf7]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(resume_all_vcpus_mipsel+0x99) [0x848c49]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(uc_emu_start+0x10d) [0x3c4dad]
 > /usr/lib64/libffi.so.8.2.0() [0xa056]
 > /usr/lib64/libffi.so.8.2.0() [0x8ff1]
 > /usr/lib64/libffi.so.8.2.0(ffi_call+0x13e) [0x990e]
 > /usr/lib/python3.13/lib-dynload/_ctypes.cpython-313-x86_64-linux-gnu.so() [0x1d0fe]
 > /usr/lib/python3.13/lib-dynload/_ctypes.cpython-313-x86_64-linux-gnu.so() [0x15b0c]
 > /usr/lib64/libpython3.13.so.1.0(_PyObject_MakeTpCall+0x84) [0x25d684]
 > /usr/lib64/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x841e) [0x3ec33e]
 > /usr/lib64/libpython3.13.so.1.0(PyEval_EvalCode+0x165) [0x3f2f95]
 > /usr/lib64/libpython3.13.so.1.0() [0x46377a]
 > /usr/lib64/libpython3.13.so.1.0() [0x463ad7]
 > /usr/lib64/libpython3.13.so.1.0() [0x465d57]
 > /usr/lib64/libpython3.13.so.1.0() [0x466360]
 > /usr/lib64/libpython3.13.so.1.0(Py_RunMain+0xa26) [0x496236]
 > /usr/lib64/libpython3.13.so.1.0(Py_BytesMain+0x56) [0x496a46]
 > /lib64/libc.so.6() [0x2760b]
 > /lib64/libc.so.6(__libc_start_main+0x8a) [0x276ba]
 > /usr/bin/python3.13(_start+0x25) [0x735]
+++ killed by SIGSEGV +++

git bisect suggests the change is introduced with 7f48b1d (which took back the helpful change 0bb1bbd).

wtdcode commented

Really?! I probably missed a unit test for this.

wtdcode commented

Anyway, sorry for the regression and I will make a new release as soon as possible.

  • ❤️2
Arusekk commented

No problem, we are all humans after all. For the time being, we will exclude the affected version in our dependency requirements.

  • 👍1