linux-stable.git/kernel/module/main.c, branch v7.2.4

module: validate string table section types

2026-09-07T15:36:59+00:00

commit 9a5ff45689329835f874cefe5174e577d141d423 upstream.

In elf_validity_cache_sechdrs, section sizes and offsets are validated,
unless the section type is SHT_NULL or SHT_NOBITS.

Later, elf_validity_cache_secstrings and elf_validity_cache_index_str
access the section name table (.shstrtab) and symbol string table
(.strtab) headers without first ensuring that their types are
SHT_STRTAB. If a section type is SHT_NULL or SHT_NOBITS, sh_offset has
not been validated and may reference out-of-bounds memory when
dereferenced in elf_validity_cache_secstrings or
elf_validity_cache_strtab.

Validate that both string section headers are of type SHT_STRTAB before
caching them.

Cc: stable@vger.kernel.org
Signed-off-by: Thiébaud Weksteen 
Reviewed-by: Aaron Tomlin 
Reviewed-by: Petr Pavlu 
Signed-off-by: Petr Pavlu 
Signed-off-by: Greg Kroah-Hartman

module: Simplify warning on positive returns from module_init()

2026-04-04T00:04:48+00:00

It should now be rare to trigger this warning - it doesn't need to be so
verbose. Make it follow the usual style in the module loading code.

For the same reason, drop the dump_stack().

Suggested-by: Petr Pavlu 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Aaron Tomlin 
Reviewed-by: Petr Pavlu 
Reviewed-by: Daniel Gomez 
Signed-off-by: Sami Tolvanen

module: Override -EEXIST module return

2026-04-04T00:04:42+00:00

The -EEXIST errno is reserved by the module loading functionality. When
userspace calls [f]init_module(), it expects a -EEXIST to mean that the
module is already loaded in the kernel. If module_init() returns it,
that is not true anymore.

Override the error when returning to userspace: it doesn't make sense to
change potentially long error propagation call chains just because it's
will end up as the return of module_init().

Closes: https://lore.kernel.org/all/aKLzsAX14ybEjHfJ@orbyte.nwl.cc/
Cc: Greg Kroah-Hartman 
Cc: Aaron Tomlin 
Cc: Petr Pavlu 
Cc: Daniel Gomez 
Cc: Phil Sutter 
Cc: Christophe Leroy 
Signed-off-by: Lucas De Marchi 
[Sami: Fixed a typo.]
Signed-off-by: Sami Tolvanen

module: deprecate usage of *_gpl sections in module loader

2026-03-31T23:42:52+00:00

The *_gpl section are not being used populated by modpost anymore. Hence
the module loader doesn't need to find and process these sections in
modules.

This patch also simplifies symbol finding logic in module loader since
*_gpl sections don't have to be searched anymore.

Signed-off-by: Siddharth Nayyar 
Reviewed-by: Petr Pavlu 
Signed-off-by: Sami Tolvanen

module: use kflagstab instead of *_gpl sections

2026-03-31T23:42:52+00:00

Read kflagstab section for vmlinux and modules to determine whether
kernel symbols are GPL only.

This patch eliminates the need for fragmenting the ksymtab for infering
the value of GPL-only symbol flag, henceforth stop populating *_gpl
versions of the ksymtab and kcrctab in modpost.

Signed-off-by: Siddharth Nayyar 
Reviewed-by: Petr Pavlu 
Signed-off-by: Sami Tolvanen

module: expose imported namespaces via sysfs

2026-03-19T22:24:55+00:00

Add /sys/module/*/import_ns to expose imported namespaces for
currently loaded modules. The file contains one namespace per line and
only exists for modules that import at least one namespace.

Previously, the only way for userspace to inspect the symbol
namespaces a module imports is to locate the .ko on disk and invoke
modinfo(8) to decompress/parse the metadata. The kernel validated
namespaces at load time, but it was otherwise discarded.

Exposing this data via sysfs provides a runtime mechanism to verify
which namespaces are being used by modules. For example, this allows
userspace to audit driver API access in Android GKI, which uses symbol
namespaces to restrict vendor drivers from using specific kernel
interfaces (e.g., direct filesystem access).

Signed-off-by: Nicholas Sielicki 
[Sami: Updated the commit message to explain motivation.]
Signed-off-by: Sami Tolvanen

module: Fix freeing of charp module parameters when CONFIG_SYSFS=n

2026-03-18T21:43:18+00:00

When setting a charp module parameter, the param_set_charp() function
allocates memory to store a copy of the input value. Later, when the module
is potentially unloaded, the destroy_params() function is called to free
this allocated memory.

However, destroy_params() is available only when CONFIG_SYSFS=y, otherwise
only a dummy variant is present. In the unlikely case that the kernel is
configured with CONFIG_MODULES=y and CONFIG_SYSFS=n, this results in
a memory leak of charp values when a module is unloaded.

Fix this issue by making destroy_params() always available when
CONFIG_MODULES=y. Rename the function to module_destroy_params() to clarify
that it is intended for use by the module loader.

Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs")
Signed-off-by: Petr Pavlu 
Signed-off-by: Sami Tolvanen

module: Fix kernel panic when a symbol st_shndx is out of bounds

2026-02-23T19:37:28+00:00

The module loader doesn't check for bounds of the ELF section index in
simplify_symbols():

       for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
		const char *name = info->strtab + sym[i].st_name;

		switch (sym[i].st_shndx) {
		case SHN_COMMON:

		[...]

		default:
			/* Divert to percpu allocation if a percpu var. */
			if (sym[i].st_shndx == info->index.pcpu)
				secbase = (unsigned long)mod_percpu(mod);
			else
  /** HERE --> **/		secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
			sym[i].st_value += secbase;
			break;
		}
	}

A symbol with an out-of-bounds st_shndx value, for example 0xffff
(known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic:

  BUG: unable to handle page fault for address: ...
  RIP: 0010:simplify_symbols+0x2b2/0x480
  ...
  Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHN_XINDEX or
when it is corrupted.

Add a bounds check in simplify_symbols() to validate that st_shndx is
within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant
discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

Signed-off-by: Ihor Solodrai 
Reviewed-by: Daniel Gomez 
Reviewed-by: Petr Pavlu 
Signed-off-by: Sami Tolvanen

module: Remove duplicate freeing of lockdep classes

2026-02-23T17:44:54+00:00

In the error path of load_module(), under the free_module label, the
code calls lockdep_free_key_range() to release lock classes associated
with the MOD_DATA, MOD_RODATA and MOD_RO_AFTER_INIT module regions, and
subsequently invokes module_deallocate().

Since commit ac3b43283923 ("module: replace module_layout with
module_memory"), the module_deallocate() function calls free_mod_mem(),
which releases the lock classes as well and considers all module
regions.

Attempting to free these classes twice is unnecessary. Remove the
redundant code in load_module().

Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
Signed-off-by: Petr Pavlu 
Reviewed-by: Daniel Gomez 
Reviewed-by: Aaron Tomlin 
Acked-by: Song Liu 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Sami Tolvanen

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using

    git grep -l '\