qemu-cris segfaults upon loading userspace binary

Bug #1909770 reported by ON7WPI
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

I am on commit 65a3c5984074313602fb5f61cc5f464abfb020c7 (latest as far as I know). I compiled qemu with --enable-debug.

I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get

gdb-peda$ bt
#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6
#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000,
    prot=0x3) at ../linux-user/elfload.c:1865
#2 0x0000564a2f7bff65 in load_elf_image (
    image_name=0x7fffe9f5703d "./basic", image_fd=0x3,
    info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0,
    bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001")
    at ../linux-user/elfload.c:2801
#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920,
    info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104
#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3,
    filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0,
    envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0,
    bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147
#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78,
    envp=0x7fffe9f54ea0) at ../linux-user/main.c:808
#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6
#7 0x0000564a2f786cee in _start ()

Or as a full backtrace:
gdb-peda$ bt full
#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000,
    prot=0x3) at ../linux-user/elfload.c:1865
        host_start = 0x92134
        host_map_start = 0x93000
        host_end = 0x94000
#2 0x0000564a2f7bff65 in load_elf_image (
    image_name=0x7fffe9f5703d "./basic", image_fd=0x3,
    info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0,
    bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001")
    at ../linux-user/elfload.c:2801
        vaddr = 0x82134
        vaddr_em = 0x82140
        vaddr_len = 0x2000
        vaddr_po = 0x134
        vaddr_ps = 0x82000
        vaddr_ef = 0x82134
        elf_prot = 0x3
        eppnt = 0x7fffe9f54974
        ehdr = 0x7fffe9f54920
        phdr = 0x7fffe9f54954
        load_addr = 0x80000
        load_bias = 0x0
        loaddr = 0x80000
        hiaddr = 0x1082140
        error = 0x80000
        i = 0x1
        retval = 0x273d2e9c
        prot_exec = 0x4
        err = 0x0
        __func__ = "load_elf_image"
#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920,
    info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104
        interp_info = {
          load_bias = 0x0,
          load_addr = 0x0,
          start_code = 0x0,
          end_code = 0x0,
          start_data = 0x0,
          end_data = 0x0,
          start_brk = 0x0,
          brk = 0x0,
          reserve_brk = 0x0,
          start_mmap = 0x0,
          start_stack = 0x0,
          stack_limit = 0x0,
          entry = 0x0,
          code_offset = 0x0,
          data_offset = 0x0,
          saved_auxv = 0x0,
          auxv_len = 0x0,
          arg_start = 0x0,
          arg_end = 0x0,
          arg_strings = 0x0,
          env_strings = 0x0,
          file_string = 0x0,
          elf_flags = 0x0,
          personality = 0x0,
          alignment = 0x0,
          loadmap_addr = 0x0,
          nsegs = 0x0,
          loadsegs = 0x0,
          pt_dynamic_addr = 0x0,
          interpreter_loadmap_addr = 0x0,
          interpreter_pt_dynamic_addr = 0x0,
          other_info = 0x0,
          note_flags = 0x0
        }
        elf_ex = {
          e_ident = "|\214\t1\000\000\000\000\262\002\356_\000\000\000",
          e_type = 0x8c7c,
          e_machine = 0x3109,
          e_version = 0x0,
          e_entry = 0x5fee02b2,
          e_phoff = 0x0,
          e_shoff = 0x31098c7c,
          e_flags = 0x0,
          e_ehsize = 0x0,
          e_phentsize = 0x0,
          e_phnum = 0x0,
          e_shentsize = 0x0,
          e_shnum = 0x0,
          e_shstrndx = 0x0
        }
        elf_interpreter = 0x0
        scratch = 0x7f272a358021 <read+97> "H\213D$\bH\203\304(\303\017\037D"
#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3,
    filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0,
    envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0,
    bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147
        retval = 0x400
#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78,
    envp=0x7fffe9f54ea0) at ../linux-user/main.c:808
        regs1 = {
          orig_r10 = 0x0,
          r0 = 0x0,
          r1 = 0x0,
          r2 = 0x0,
          r3 = 0x0,
          r4 = 0x0,
          r5 = 0x0,
          r6 = 0x0,
          r7 = 0x0,
          r8 = 0x0,
          r9 = 0x0,
          r10 = 0x0,
          r11 = 0x0,
          r12 = 0x0,
          r13 = 0x0,
          acr = 0x0,
          srs = 0x0,
          mof = 0x0,
          spc = 0x0,
          ccs = 0x0,
          srp = 0x0,
          erp = 0x0,
          exs = 0x0,
          eda = 0x0
        }
        regs = 0x7fffe9f54860
        info1 = {
          load_bias = 0x0,
          load_addr = 0x80000,
          start_code = 0x80000,
          end_code = 0x80133,
          start_data = 0xffffffff,
          end_data = 0x0,
          start_brk = 0x0,
          brk = 0x80133,
          reserve_brk = 0x1000000,
          start_mmap = 0x80000000,
          start_stack = 0x0,
          stack_limit = 0x0,
          entry = 0x80106,
          code_offset = 0x0,
          data_offset = 0x0,
          saved_auxv = 0x0,
          auxv_len = 0x0,
          arg_start = 0x0,
          arg_end = 0x0,
          arg_strings = 0x0,
          env_strings = 0x0,
          file_string = 0x0,
          elf_flags = 0x0,
          personality = 0x0,
          alignment = 0x2000,
          loadmap_addr = 0x0,
          nsegs = 0x2,
          loadsegs = 0x0,
          pt_dynamic_addr = 0x0,
          interpreter_loadmap_addr = 0x0,
          interpreter_pt_dynamic_addr = 0x0,
          other_info = 0x0,
          note_flags = 0x0
        }
        info = 0x7fffe9f547c0
        bprm = {
          buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\002\000L\000\001\000\000\000\006\001\b\000\064\000\000\000\264\006\000\000\000\000\000\000\064\000 \000\003\000(\000\016\000\r\000\001\000\000\000\000\000\000\000\000\000\b\000\000\000\b\000\063\001\000\000\063\001\000\000\005\000\000\000\000 \000\000\001\000\000\000\064\001\000\000\064!\b\000\064!\b\000\000\000\000\000\f\000\000\000\006\000\000\000\000 \000\000\004\000\000\000\224\000\000\000\224\000\b\000\224\000\b\000$\000\000\000$\000\000\000\004\000\000\000\004\000\000\000\004\000\000\000\024\000\000\000\003\000\000\000GNU\000PH\017'i\204\231\070e\000\247\376\211\230\236\336Nf7\372\204\342\356\213n\206\214\342\374\201\352\253\370\201\353\273"...,
          p = 0x0,
          fd = 0x3,
          e_uid = 0x3e8,
          e_gid = 0x3d9,
          argc = 0x1,
          envc = 0x43,
          argv = 0x564a2f9f3cc0,
          envp = 0x564a2fa12600,
          filename = 0x7fffe9f5703d "./basic",
          core_dump = 0x0
        }
        ts = 0x564a2fa25400
        env = 0x564a2fa24a08
        cpu = 0x564a2fa1c730
        optind = 0x3
        target_environ = 0x564a2fa12600
        wrk = 0x7fffe9f550b8
        target_argv = 0x564a2f9f3cc0
        target_argc = 0x1
        i = 0x1
        ret = 0x7fff
        execfd = 0x3
        log_mask = 0x0
        max_reserved_va = 0xffffe000
#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#7 0x0000564a2f786cee in _start ()
No symbol table info available.

The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it.

Revision history for this message
ON7WPI (on7wpi) wrote :
  • basic Edit (2.2 KiB, application/octet-stream)
ON7WPI (on7wpi)
tags: added: linux-user
Revision history for this message
Peter Maydell (pmaydell) wrote :

Sounds like it's probably the bug where we don't correctly handle ELF BSS segments which have no content in the file at all (ie they're just "zero this memory" with no content). If so, this patch (currently in review) will fix it:
https://<email address hidden>/
and you could also work around it by making sure your guest binary has some r/w data so it doesn't have a segment that's purely BSS.

Revision history for this message
ON7WPI (on7wpi) wrote :

That did indeed fix it, thank you!

Revision history for this message
Thomas Huth (th-huth) wrote : Moved bug report

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/123

Changed in qemu:
status: New → Expired
Revision history for this message
Thomas Huth (th-huth) wrote :

ON7WPI: Is QEMU version 6.0 now working fine for you?

Revision history for this message
ON7WPI (on7wpi) wrote :

Yes, this is working for me now. The binary still crashes, but I think that's a problem in my code instead of QEMU.

Revision history for this message
Thomas Huth (th-huth) wrote :

Ok, thanks for the confirmation!

Changed in qemu:
status: Expired → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.