All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: ojeda@kernel.org, linux-modules@vger.kernel.org
Subject: Re: [PATCH v10 1/2] module: Extend module_blacklist parameter to built-in modules
Date: Thu, 03 Sep 2026 19:13:02 +0000	[thread overview]
Message-ID: <20260903191303.5A14B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260903185557.183224-2-atomlin@atomlin.com>

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 <atomlin@atomlin.com>

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/20260903185557.183224-1-atomlin@atomlin.com?part=1

  reply	other threads:[~2026-09-03 19:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 18:55 [PATCH v10 0/2] module: Extend module_blacklist parameter to built-in modules Aaron Tomlin
2026-09-03 18:55 ` [PATCH v10 1/2] " Aaron Tomlin
2026-09-03 19:13   ` sashiko-bot [this message]
2026-09-04 14:34     ` Aaron Tomlin
2026-09-06 13:39       ` Gary Guo
2026-09-06 15:07         ` Aaron Tomlin
2026-09-03 20:23   ` Aaron Tomlin
2026-09-03 18:55 ` [PATCH v10 2/2] module: Rename module_blacklist to module_denylist Aaron Tomlin
2026-09-03 19:07   ` sashiko-bot
2026-09-04 15:13     ` Aaron Tomlin
2026-09-09  1:35   ` kernel test robot
2026-09-03 20:29 ` [PATCH v10 0/2] module: Extend module_blacklist parameter to built-in modules Andrew Morton
2026-09-04 14:59   ` Aaron Tomlin
2026-09-06  0:28     ` Andrew Morton
2026-09-06  9:56       ` Arnd Bergmann
2026-09-06 12:33         ` Gary Guo
2026-09-06 14:08         ` Aaron Tomlin
2026-09-09 13:22           ` Alice Ryhl
2026-09-10  1:32             ` Aaron Tomlin
2026-09-06 13:15       ` Aaron Tomlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260903191303.5A14B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atomlin@atomlin.com \
    --cc=linux-modules@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.