linux-kernel - Re: [PATCH] riscv: fix KUnit test_kprobes crash when building with Clang

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

Message-ID: <875xawwttq.fsf@yellow.woof>
Date: Wed, 26 Nov 2025 19:08:01 +0100
From: Nam Cao <namcao@...utronix.de>
To: 许佳凯 <xujiakai2025@...as.ac.cn>,
 linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Cc: Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
 Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>
Subject: Re: [PATCH] riscv: fix KUnit test_kprobes crash when building with
 Clang

Nam Cao <namcao@...utronix.de> writes:
> 许佳凯 <xujiakai2025@...as.ac.cn> writes:
>> Clang misaligns the test_kprobes_addresses and test_kprobes_functions
>> arrays, or does not export local labels by default. Both can cause
>> kmalloc_array() allocation errors and KUnit failures.
>>
>> This patch fixes the issue by:
>> - Adding .section .rodata to explicitly place arrays in the read-only data segment.
>> - Adding .align 3 to align arrays to 8 bytes.
>> - Adding .globl to probe labels to ensure symbols are visible.
>
> We do not have to make it exactly the same as building with GCC, right?
> Only moving the arrays to .rodata seems sufficient to fix the issue, but
> I cannot explain why yet.
>
> What I observed is that with CONFIG_RELOCATABLE=y, the kernel's
> .rela.dyn section, which holds the relocation entries for the two
> arrays, have incorrect addresses (they are all incorrectly offset by 6
> bytes for my build). The kernel uses these relocation information to
> fill the arrays during boot, and fill them at wrong addresses.
>
> I smell a linker problem, but more investigation needed...

I sent my findings to LLVM folks:
https://github.com/llvm/llvm-project/issues/168308#issuecomment-3582596694

I suspect linker problem. But let's see what LLVM people think.

Nam