linux-kernel - Re: [tip: objtool/core] objtool: Fix segfault on unknown alternatives

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: <3be480e7-8baf-4196-baf4-b9c29f8ef491@oracle.com>
Date: Mon, 1 Dec 2025 21:44:42 +0100
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>,
        tip-bot2 for Ingo Molnar <tip-bot2@...utronix.de>
Cc: alexandre.chartre@...cle.com, linux-tip-commits@...r.kernel.org,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        x86@...nel.org
Subject: Re: [tip: objtool/core] objtool: Fix segfault on unknown alternatives



On 12/1/25 21:05, Josh Poimboeuf wrote:
> On Mon, Dec 01, 2025 at 09:52:51AM +0000, tip-bot2 for Ingo Molnar wrote:
>> The following commit has been merged into the objtool/core branch of tip:
>>
>> Commit-ID:     6ec33db1aaf06a76fb063610e668f8e12f32ebbf
>> Gitweb:        https://git.kernel.org/tip/6ec33db1aaf06a76fb063610e668f8e12f32ebbf
>> Author:        Ingo Molnar <mingo@...nel.org>
>> AuthorDate:    Mon, 01 Dec 2025 10:42:27 +01:00
>> Committer:     Ingo Molnar <mingo@...nel.org>
>> CommitterDate: Mon, 01 Dec 2025 10:42:27 +01:00
>>
>> objtool: Fix segfault on unknown alternatives
>>
>> So 'objtool --link -d vmlinux.o' gets surprised by this endbr64+endbr64 pattern
>> in ___bpf_prog_run():
>>
>> 	___bpf_prog_run:
>> 	1e7680:  ___bpf_prog_run+0x0                                                     push   %r12
>> 	1e7682:  ___bpf_prog_run+0x2                                                     mov    %rdi,%r12
>> 	1e7685:  ___bpf_prog_run+0x5                                                     push   %rbp
>> 	1e7686:  ___bpf_prog_run+0x6                                                     xor    %ebp,%ebp
>> 	1e7688:  ___bpf_prog_run+0x8                                                     push   %rbx
>> 	1e7689:  ___bpf_prog_run+0x9                                                     mov    %rsi,%rbx
>> 	1e768c:  ___bpf_prog_run+0xc                                                     movzbl (%rbx),%esi
>> 	1e768f:  ___bpf_prog_run+0xf                                                     movzbl %sil,%edx
>> 	1e7693:  ___bpf_prog_run+0x13                                                    mov    %esi,%eax
>> 	1e7695:  ___bpf_prog_run+0x15                                                    mov    0x0(,%rdx,8),%rdx
>> 	1e769d:  ___bpf_prog_run+0x1d                                                    jmp    0x1e76a2 <__x86_indirect_thunk_rdx>
> 
> The problem is actually that indirect jump.  That's a jump table (not to
> be confused with a jump *label*) which is an objtool "alt" type which
> the disas code doesn't seem to know about yet.
> 
> They're used for C indirect goto (___bpf_prog_run) and switch
> statements.  The latter are currently disabled in most x86 configs via
> -fno-jump-tables.
> 
> They're indirect jumps with a known set of jump targets.  It should be
> possible to graphically display the possible targets with lines and
> arrows, something similar to "objdump -d --visualize-jumps".
> 
> If the code isn't expecting that "alt" type, it might explode in other
> ways.  So at least for now, those alts need to at least be recognized
> and ignored.

I think the problem is with add_jump_table() which creates a struct alternative
but doesn't set the type. So it defaults to 0 which is ALT_TYPE_INSTRUCTIONS and
then it fails because an alt_group is expected with this type.

A quick fix is probably to define a new alt_type ALT_TYPE_UNKNOWN = 0 and have
disas ignore this type of alternative. I will work on a fix.

Thanks,

alex.