linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a20LXgEQkYSpbFFrJs1mdg19W72dp3pbebH9Pkpib2g-g@mail.gmail.com>
Date:   Thu, 3 Dec 2020 14:56:07 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     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: objtool crashes with some clang produced .o files

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.

        Arnd

Download attachment "integrated-as.o" of type "application/x-object" (920 bytes)

Download attachment "gnu-as.o" of type "application/x-object" (1184 bytes)