linux-kernel - Re: objtool crashes with some clang produced .o files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKwvOdn79V-jaTH0mEtKyc-O+=Hj22bGtjKkZ1jriY2YABj-Lw@mail.gmail.com>
Date:   Thu, 10 Dec 2020 15:35:45 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: objtool crashes with some clang produced .o files

On Thu, Dec 3, 2020 at 5:56 AM Arnd Bergmann <arnd@...nel.org> wrote:
>
> I see occasional randconfig builds failing on x86 with clang-11
> and clang-12 when objtool crashes with a segmentation fault.
>
> The simplest test case I managed to create is
>
> $ echo "__SCK__tp_func_cdev_update() { __SCT__tp_func_cdev_update(); }" > file.c
> $ clang-12 -c file.c -O2 -fno-asynchronous-unwind-tables
> $ ./tools/objtool/objtool orc generate  file.o
> Segmentation fault (core dumped)
> $ clang-12 -S file.c -O2 -fno-asynchronous-unwind-tables -o-
> .text
> .file "file.c"
> .globl __SCK__tp_func_cdev_update      # -- Begin function
> __SCK__tp_func_cdev_update
> .p2align 4, 0x90
> .type __SCK__tp_func_cdev_update,@function
> __SCK__tp_func_cdev_update:             # @__SCK__tp_func_cdev_update
> # %bb.0:
> xorl %eax, %eax
> jmp __SCT__tp_func_cdev_update      # TAILCALL
> .Lfunc_end0:
> .size __SCK__tp_func_cdev_update, .Lfunc_end0-__SCK__tp_func_cdev_update
>                                         # -- End function
> .ident "Ubuntu clang version
> 12.0.0-++20201129052612+ce134da4b18-1~exp1~20201129163253.238"
> .section ".note.GNU-stack","",@progbits
> .addrsig
>
> The behavior seems to depend on the specific symbol names, and it only happens
> for the integrated assembler, not the GNU assembler.
>
> Attaching both .o files for reference.

Thanks for the report.

(gdb) r orc generate file.o
Starting program: /android0/linux-next/tools/objtool/objtool orc generate file.o

Program received signal SIGSEGV, Segmentation fault.
0x000000000040d7d3 in elf_rebuild_rela_reloc_section (sec=0xc24e30,
nr=<optimized out>) at elf.c:880
880                     relocs[idx].r_info =
GELF_R_INFO(reloc->sym->idx, reloc->type);
(gdb) bt
#0  0x000000000040d7d3 in elf_rebuild_rela_reloc_section
(sec=0xc24e30, nr=<optimized out>) at elf.c:880
#1  elf_rebuild_reloc_section (elf=<optimized out>,
sec=sec@...ry=0xc24e30) at elf.c:901
#2  0x00000000004049b6 in create_static_call_sections (file=0x41f478
<file>) at check.c:520
#3  check (file=0x41f478 <file>) at check.c:2918
#4  0x000000000040b97c in cmd_orc (argc=<optimized out>,
argv=0x7fffffffda98) at builtin-orc.c:47
#5  0x000000000040dce9 in handle_internal_command (argc=argc@...ry=3,
argv=argv@...ry=0x7fffffffda90) at objtool.c:128
#6  0x000000000040dbff in main (argc=3, argv=0x7fffffffda90) at objtool.c:151
(gdb) p reloc
$1 = (struct reloc *) 0xc24fd0
(gdb) p *reloc
$2 = {list = {next = 0xc25070, prev = 0xc24eb8}, hash = {next = 0x0,
pprev = 0xc25080}, {rela = {r_offset = 0, r_info = 0, r_addend = 0},
rel = {r_offset = 0, r_info = 0}},
  sec = 0xc24e30, sym = 0x0, offset = 0, type = 2, addend = 2, idx =
0, jump_table_start = false}

So reloc->sym was NULL.

(gdb) p *sec
$2 = {list = {next = 0x7ffff559e068, prev = 0xc23bf0}, hash = {next =
0x0, pprev = 0x7ffff65d60d8}, name_hash = {next = 0x0, pprev =
0x7ffff6dd6888}, sh = {sh_name = 147, sh_type = 4,
    sh_flags = 64, sh_addr = 0, sh_offset = 0, sh_size = 48, sh_link =
7, sh_info = 8, sh_addralign = 8, sh_entsize = 24}, symbol_tree =
{rb_node = 0x0}, symbol_list = {next = 0xc24ea8,
    prev = 0xc24ea8}, reloc_list = {next = 0xc24fd0, prev = 0xc25070},
base = 0xc23bf0, reloc = 0x0, sym = 0x0, data = 0xc23db0, name =
0xc24f60 ".rela.static_call_sites", idx = 9,
  len = 0, changed = true, text = false, rodata = false, noinstr = false}

So .rela.static_call_sites was the problematic section.

(gdb) b tools/objtool/check.c:475
(gdb) r orc generate file.o
Breakpoint 1, create_static_call_sections (file=0x41f478 <file>) at check.c:475
475                     reloc->sym = insn->sec->sym;
(gdb) p insn->sec->sym
$4 = (struct symbol *) 0x0
(gdb) p insn->sec->name
$5 = 0xc22d26 ".text"

So some instruction in .text that contained a relocation for, we could
not determine a symbol for?  I'm curious why we're even in this loop
though, since we didn't do anything related to static calls...is
`file->static_call_list` not populated correctly? Is the final else
case from `add_jump_destinations` perhaps being hit and adding nodes
to file->static_call_list incorrectly?
-- 
Thanks,
~Nick Desaulniers