Re: [PATCH] kprobes: skip non-symbol addresses in kprobe_add_ksym_blacklist()

[Jianpeng Chang <jianpeng.chang.cn@windriver.com>]

在 2026/4/28 下午5:43, Masami Hiramatsu (Google) 写道:
> CAUTION: This email comes from a non Wind River email account! Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
> 
> Hi,
> 
> On Mon, 27 Apr 2026 15:35:44 +0800 Jianpeng Chang
> <jianpeng.chang.cn@windriver.com> wrote:
> 
>> When kprobe_add_area_blacklist() iterates through a section like 
>> .kprobes.text, the start address may not correspond to a named
>> symbol. On ARM64 with CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS=y
>> (introduced by commit baaf553d3bc3 ("arm64: Implement 
>> HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")), the compiler flag -
>> fpatchable-function-entry=4,2 inserts 2 NOPs before each function
>> entry point for ftrace call_ops. These pre-function NOPs sit at
>> the section base address, before the first named function symbol.
>> The compiler emits a $x mapping symbol at offset 0x00 to mark the
>> start of code, but find_kallsyms_symbol() ignores mapping symbols.
>> 
>> Without CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS (e.g. defconfig), no 
>> pre-function NOPs are inserted, the first function starts at
>> offset 0x00, and the bug does not trigger.
>> 
>> This only affects modules that have a .kprobes.text section (i.e.
>> those using the __kprobes annotation). Modules using
>> NOKPROBE_SYMBOL() instead (like kretprobe_example.ko) blacklist
>> exact function addresses via the _kprobe_blacklist section and are
>> not affected.
>> 
>> For kprobe_example.ko on ARM64 with -fpatchable-function-
>> entry=4,2, the .kprobes.text section layout is:
>> 
>> offset 0x00: $x + 2 NOPs    (mapping symbol + ftrace preamble) 
>> offset 0x08: handler_post   (64 bytes) offset 0x50: handler_pre
>> (68 bytes)
> 
> Ah, OK. It is for __kprobes attribute. I recommend user to use
> NOKPROBE_SYMBOL() but I understand the situation.
> 
>> 
>> kprobe_add_area_blacklist() starts iterating from the section base 
>> address (offset 0x00), which only has the $x mapping symbol. 
>> kprobe_add_ksym_blacklist() then calls
>> kallsyms_lookup_size_offset() for this address, which goes
>> through:
>> 
>> kallsyms_lookup_size_offset() -> module_address_lookup() ->
>> find_kallsyms_symbol()
>> 
>> find_kallsyms_symbol() scans all module symbols to find the
>> closest preceding symbol.
>> 
>> Since no named text symbol exists at offset 0x00, 
>> find_kallsyms_symbol() picks __UNIQUE_ID_vermagic (a .modinfo
>> symbol whose address is in the temporary image) as the "best"
>> match. The computed "size" = next_text_symbol - modinfo_symbol
>> spans across these two unrelated memory regions, creating a
>> blacklist entry with a bogus range of tens of terabytes.
>> 
>> Whether this causes a visible failure depends on address
>> randomization, here is what happens on Raspberry Pi 4/5:
>> 
>> - On RPi5, the bogus size was ~35 TB. start + size stayed within 
>> 64-bit range, so the blacklist entry covered the entire kernel 
>> text. register_kprobe() in the module's own init function failed 
>> with -EINVAL.
>> 
>> - On RPi4, the bogus size was ~75 TB. start + size overflowed 64
>> bits and wrapped to a small address near zero. The range check
>> (addr >= start && addr < end) then failed because end wrapped
>> around, so the bogus entry was accidentally harmless and kprobes
>> worked by luck.
>> 
>> The same bug exists on both machines, but randomization determines
>> whether the integer overflow masks it or not.
>> 
>> Fix this by checking the offset returned by
>> kallsyms_lookup_size_offset(). A non-zero offset means the address
>> is not at a symbol boundary, so skip forward to the next symbol
>> instead of creating a blacklist entry with a wrong size.
>> 
>> Fixes: baaf553d3bc3 ("arm64: Implement
>> HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") Signed-off-by: Jianpeng Chang
>> <jianpeng.chang.cn@windriver.com> --- Hi,
>> 
>> This patch skips non-symbol addresses, fixes the bogus blacklist
>> entry, but leaves the NOP gap at the start of .kprobes.text
>> unblacklisted.
> 
> That is OK because those NOPs are not executed in kprobe handler.
> 
>> 
>> We can continue alloc the ent without return to add the gap to 
>> blacklist, or do some more works to add the gap to the first
>> symbol in blacklist. I'm not sure if is this necessary, or is
>> there a better way?
> 
> Are there any compiler option or attribute to avoid inserting these 
> NOPs to the specific section? (like notrace?)
> 
> Also, as you can see there is an alias symbol whose size is 0. and 
> in that case, we move the entry + 1 and call
> kprobe_add_ksym_blacklist() again. Thus, the offset becomes 1.
> Please make sure it is correctly handled.
> 
Regarding the alias symbol concern: kallsyms_lookup_size_offset() 
computes size as the distance to the next different-address symbol, not 
from ELF st_size. I tested with a module containing alias symbols in 
.kprobes.text (created via __attribute__((alias))), and the lookup 
returned a correct size with offset=0 — the if (ret == 0) ret = 1 path 
was never triggered.

That said, #define __kprobes notrace __section(".kprobes.text") is a 
cleaner fix. The NOPs in .kprobes.text are unnecessary since these 
functions should never be traced by ftrace. I've tested this on RPi5 — 
the bug is resolved and all .kprobes.text functions are correctly 
blacklisted. I'll send the notrace approach in v2.

Thanks,
Jianpeng> Thanks,
> 
>> 
>> Thanks, Jianpeng
>> 
>> kernel/kprobes.c | 4 ++++ 1 file changed, 4 insertions(+)
>> 
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c index
>> bfc89083daa9..be700fb03198 100644 --- a/kernel/kprobes.c> +++ b/
>> kernel/kprobes.c @@ -2503,6 +2503,10 @@ int
>> kprobe_add_ksym_blacklist(unsigned long entry) !
>> kallsyms_lookup_size_offset(entry, &size, &offset)) return -
>> EINVAL;
>> 
>> +     /* Not on a symbol boundary -- skip to the next symbol */ 
>> +     if (offset) +             return (int)(size - offset); + ent
>> = kmalloc_obj(*ent); if (!ent) return -ENOMEM; -- 2.54.0
>> 
> 
> 
> -- Masami Hiramatsu (Google) <mhiramat@kernel.org>