On 03/10/2026 20:56, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s)
> to consider:
> - [Medium] bpf: btf: Unvalidated zero-size allocation triggers WARN_ON_ONCE
> in vmalloc_user
> - [Low] bpf: btf: Linkage fails for sha256 when CONFIG_DEBUG_INFO_BTF_INLINE=m
> --
>
> commit de2bb52fc001c93d461a0839a26e550f67f5ecc2
> Author: Alan Maguire <[email protected]>
>
> kbuild, btf: Expose vmlinux inline BTF through sysfs
>
> This commit introduces support for embedded and module-delivered vmlinux
> inline BTF payloads, making them available via sysfs. It also sets up deferred
> binding for a module-provided .BTF.inline section.
>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 134b15a44625e..24abfff1ddc3c 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -432,6 +438,19 @@ config DEBUG_INFO_BTF_MODULES
>> help
>> Generate compact split BTF type information for kernel modules.
>>
>> +config DEBUG_INFO_BTF_INLINE
>> + tristate "Provide information about inline sites in BTF"
>> + default n
>> + depends on DEBUG_INFO_BTF && PAHOLE_HAS_INLINE && SYSFS
>> + select DEBUG_INFO_BTF_MODULES if MODULES
>> + select CRYPTO_LIB_SHA256
>
> [Severity: Low]
> Does this cause a linkage failure when CONFIG_DEBUG_INFO_BTF_INLINE is built
> as a module?
>
> Because this is a tristate, selecting CRYPTO_LIB_SHA256 here means it will
> evaluate to 'm' if the inline feature is configured as a module.
>
> However, the crypto library is called directly from the built-in core kernel
> object kernel/bpf/btf.c:
>
> kernel/bpf/btf.c:btf_verify_link() {
> ...
> sha256(data, data_size, actual_digest);
> ...
> }
>
> A built-in object cannot resolve a symbol exported by a loadable module,
> which will result in an 'undefined reference to sha256' error at build time.
>
Given that CONFIG_BPF (not tristate) also selects CRYPTO_LIB_SHA256
(making it y) we can simply drop the above select.
>> + help
>> + Generate information about inline sites in .BTF.inline sections.
>
> [ ... ]
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 0630675377aaa..732ba06846675 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>
> [ ... ]
>
>> @@ -9015,21 +9016,122 @@ static DEFINE_MUTEX(btf_module_mutex);
>> +static int btf_module_handle_vmlinux_inline(const struct module *mod)
>> +{
>> + void *data = NULL;
>> +
>> + if (!vmlinux_inline_link || strcmp(mod->name,
>> vmlinux_inline_link->module_name))
>> + return -ENOENT;
>> +
>> + data = vmalloc_user(mod->btf_inline_data_size);
>
> [Severity: Medium]
> Could this trigger a WARN_ON_ONCE splat in the memory allocation paths?
>
> If a user with CAP_SYS_MODULE loads a module matching
> vmlinux_inline_link->module_name, but the module has no .BTF.inline section
> (or its size is exactly 0), mod->btf_inline_data_size will be set to 0.
>
> Calling vmalloc_user(0) here happens before the size is validated against
> link->btf_size, which causes a kernel warning in __vmalloc_node_range_noprof.
yeah, we need size checks here prior to vmalloc_user().
