On Thu, Sep 03, 2026 at 07:07:35PM +0000, [email protected] wrote:
> commit 2df01653b8cde06423a15fc161d3df5e8eddbdba
> Author: Aaron Tomlin <[email protected]>
>
> module: Rename module_blacklist to module_denylist
>
> This patch renames the module_blacklist boot parameter and internal
> variables to module_denylist, keeping the old parameter as a deprecated
> legacy alias. Internal symbols and log messages are also updated to
> reflect the new nomenclature.
>
> > diff --git a/init/main.c b/init/main.c
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1347,17 +1347,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))
> > return true;
>
> [Severity: High]
> This isn't a bug introduced by this patch, but it appears the renamed
> module_is_denylisted() function retains a pre-existing logic issue.
>
> Does the exact memory comparison here break denylisting for module names
> containing hyphens?
>
> Since the kernel build system converts module names to use underscores
> internally (e.g. "my_module"), if an administrator passes a module name
> with a hyphen on the command line (like "module_denylist=my-module"),
> the strict memcmp() will fail to match the hyphen to the underscore.
>
> This would allow an explicitly denylisted module to load, which could
> defeat the administrative mitigation for buggy or malicious modules.
> Is there a string comparison utility we should use here instead to treat
> hyphens and underscores interchangeably?
Since the build system converts module names to underscores internally,
passing hyphenated names on the command line
(e.g., "module_blacklist=my-module") currently fails to match due to the
strict memcmp(), allowing the module to load.
The kernel already provides parameqn() in <linux/moduleparam.h>, which
treats '-' and '_' interchangeably. Using parameqn(module_name, p, len)
resolves this directly.
Since this issue dates back to commit be7de5f91fdc ("modules: Add kernel
parameter to blacklist modules") in Linux 4.8, I will split this out into a
separate prerequisite patch with a Fixes: tag and CC stable, placing it as
patch 1/3 in the series.
Kind regards,
--
Aaron Tomlin
