Re: [PATCH v6 2/2] module: Rename module_blacklist to module_denylist

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The module denylist/blacklist fails to block modules if the command-line parameter uses a hyphen while the internal module name uses an underscore.
--

--- Patch [2]: [PATCH v6 2/2] module: Rename module_blacklist to module_denylist ---
commit e8f656a2a563ecf3826a9353c13ab68af8069728
Author: Aaron Tomlin <atomlin@atomlin.com>

module: Rename module_blacklist to module_denylist

This patch renames the module_blacklist parameter to module_denylist while
keeping the old parameter as a legacy alias. It also marks the old parameter
as deprecated in the documentation and updates internal symbol names.

> diff --git a/init/main.c b/init/main.c
> --- a/init/main.c
> +++ b/init/main.c
[ ... ]
> @@ -1368,17 +1368,17 @@ static inline void do_trace_initcall_level(const char *level)
[ ... ]
> -bool __init_or_module module_is_blacklisted(const char *module_name)
> +bool __init_or_module module_is_denylisted(const char *module_name)
>  {
>  	const char *p;
>  	size_t len;
>  
> -	if (!module_blacklist)
> +	if (!module_denylist)
>  		return false;
>  
> -	for (p = module_blacklist; *p; p += len) {
> +	for (p = module_denylist; *p; p += len) {
>  		len = strcspn(p, ",");
>  		if (strlen(module_name) == len && !memcmp(module_name, p, len))

[Severity: High]
This isn't a bug introduced by this patch, but does this strict byte-by-byte
comparison fail to account for the kernel's inherent hyphen-to-underscore
normalization in module names?

When an administrator specifies a module name containing a hyphen in the
module_denylist= parameter (e.g., usb-storage), the internal module name
will typically contain an underscore (e.g., usb_storage) because the kernel
build system automatically normalizes them.

Since memcmp() is used here in module_is_denylisted(), won't the comparison
fail, allowing the explicitly blocked module to load and bypassing the
intended security mechanism?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718190121.378314-1-atomlin@atomlin.com?part=2