Thank you for your contribution! Sashiko AI review found 2 potential issue(s) 
to consider:
- [High] Missing alignment for `.initcall.modnames` section causes unaligned 
pointer reads and potential kernel crashes during early boot.
- [Low] The Rust `module!` macro generates invalid code by dereferencing a 
dynamically sized slice `[u8]` into a fixed-size array `[u8; N]`.
--

commit 828a4fa4f29a0a3c5aba9065f4ba35eb845dddef
Author: Aaron Tomlin <[email protected]>

module: Extend module_blacklist parameter to built-in modules

This commit extends the module_blacklist command-line parameter to apply to
built-in modules. It achieves this by creating a new .initcall.modnames
section to map initcalls to module names, intercepting blacklisted builtin
initcalls during early boot.

> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index b2988aa12f664..7490278b7a2df 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -734,7 +734,8 @@
>       EARLYCON_TABLE()                                                \
>       LSM_TABLE()                                                     \
>       EARLY_LSM_TABLE()                                               \
> -     KUNIT_INIT_TABLE()
> +     KUNIT_INIT_TABLE()                                              \
> +     BOUNDED_SECTION_BY(.initcall.modnames, _initcall_modnames)

[Severity: High]
Does this section declaration need an alignment constraint? Without a preceding
. = ALIGN(8); or similar, the __start_initcall_modnames label might capture
the unaligned location counter before padding is inserted by the linker.

When iterating over this section during early boot in do_initcall_level(),
could the kernel read padding bytes as garbage pointers, breaking the
builtin module blacklist feature or causing an unaligned memory access panic?

[ ... ]

> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index bc7027f8dbb2c..a96157598197f 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
[ ... ]
> @@ -591,6 +594,20 @@ pub extern "C" fn cleanup_module() {
>                  #[cfg(CONFIG_HAVE_ARCH_PREL32_RELOCATIONS)]
>                  ::core::arch::global_asm!(#global_asm);
>  
> +                #[cfg(not(MODULE))]
> +                #[used(compiler)]
> +                #[link_section = ".init.rodata"]
> +                static #ident_modname_str: [u8; #name_len] = 
> *#name_cstr.to_bytes_with_nul();

[Severity: Low]
Will this cause a compilation failure for built-in Rust modules?

It attempts to initialize a fixed-size array by dereferencing a dynamically
sized slice returned by to_bytes_with_nul(). This could break the build when
CONFIG_MODULES=n or when a Rust module is configured as built-in.

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to