usecase: two sd cards are being mounted in parallel at same time on
dual core. example modules which are getting loaded is nls_cp437.
While one module is being loaded , it starts creating sysfs files.
meanwhile on other core, modprobe might return saying the module
is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
Experiments done to prove the issue in kmod.
Added sleep in kernel module.c at the place of creation of sysfs files.
Then tried `modprobe nls_cp437` from two different shells.
While the first was still waiting for its completion ,
the second one returned saying the module is built-in.
[ Lucas:
The problem is that the creation of /sys/module/<name> and
/sys/module/<name>/initstate are not atomic. There's a small window in
which the directory exists but the initstate file was still not
created.
Built-in modules can be handled by searching the modules.builtin file.
We actually lose some "modules" that create entries in /sys/modules
(e.g. vt) and are not in modules.builtin file: only those that can be
compiled as module are present in this file.
We enforce mod->builtin to always be up-to-date when
kmod_module_get_initstate() is called. This way if the directory
exists but the initstate doesn't, we can be sure this is because the
module is in the "coming" state, i.e. kernel didn't create the file
yet, but since builtin modules were already handled by checking our
index the only reason for that to happen is that we hit the race
condition.
I also added some tweaks to the patch, so we don't repeat the code for builtin
lookup. ]
A segmentation fault occurs if a module has an empty key attached to
its signature. This is mostly likely due to a corrupted module.
The crash happens because kmod_module_get_info() assumes that
kmod_module_signature_info() returns a signature of at least 1 byte.
The fix is based on a patch from Tobias Stoeckmann
<tobias@stoeckmann.org>, but rather than changing kmod_module_get_info()
to fix the crash, this changes kmod_module_signature_info() to
consider the signature as invalid.
If kmod has been configured with --disable-largefile on a 32 bit
system, off_t will be 32 bit. In that case, the parsed sig_len can
bypass a validation check (it's _unsigned_ 32 bit).
Due to the unlikeliness of people using --disable-largefile, this is
a mere validation fix. With an explicit signed 64 bit cast, there is
no binary change for 99.9% of Linux systems out there. ;)
In function kmod_elf_new, the file size has to be properly validated against
section offset. Currently, the file size is considered valid based on
ELF header size + section header size * section count. That is not sufficient.
In fact, ELF specifies a section header offset, which doesn't have to be the
size of the ELF header. The supplied test cases even cover this.
The correct test is: section offset + section header size * section count
This patch also verifies that this value won't overflow. I don't know a way
to crash a tool due to this bug, because later on the offset check would
prevent out-of-bounds access. An overflow would just mean to access a wrong
part in elf->memory. Yet it's a validation error.
Please note: The file size does not have to be validated against the size
of the ELF header again, elf_identify did this already.
it is possible to overflow uint64_t by summing variables offset and
size up in elf_get_section_info. Thee values are extracted from module
file and are possibly maliciously tampered with.
If offset is in valid range and size very large, the result will
overflow and the size check passes. Later on, this will most likely
lead to a segmentation fault due to accessing uninitialized memory.
Attached please find a proof of concept module, which will trigger
a segmentation fault on modinfo. Tested on amd64:
tobias:~$ modinfo poc.ko
filename: /home/tobias/poc.ko
Segmentation fault
There are more errors of this type in the ELF handling code that will be
fixed in other patches.
Initialize variable to NULL before calling kmod_module_new_from_lookup().
libkmod/libkmod-module.c: In function 'kmod_module_new_from_lookup.part.4.constprop':
libkmod/libkmod-module.c:192:8: warning: 'depmod' may be used uninitialized in this function [-Wmaybe-uninitialized]
list = kmod_list_prepend(list, depmod);
^
libkmod/libkmod-module.c:173:23: note: 'depmod' was declared here
struct kmod_module *depmod;
It has changed in the past, and these days, anyone can get a copy of the
LGPL via the web rather than by post.
Like 657a122 (Remove FSF mailing address) in libabc by Josh Tripplet,
but let the FSF website in which the license can be found.
Just like other source files, keep the index and comments in the source
file rather than the header.
This also removes INDEX_PRIORITY_MIN that was never being used.
libkmod/libkmod-list.c:39:33: warning: unused function 'list_node_next' [-Wunused-function]
static inline struct list_node *list_node_next(const struct list_node *node)
^
libkmod/libkmod-list.c:47:33: warning: unused function 'list_node_prev' [-Wunused-function]
static inline struct list_node *list_node_prev(const struct list_node *node)
^
It doesn't really matter in the end result since the compiler won't
generate any code for it. But let's keep it clean. It wasn't needed
until now, so probably it won't be anymore.
Move underscores() to shared/. It's the same as alias_normalize(), but
it rather operates in place, with the same string being passed.
The difference now that it's in shared/ is that it's a non-logging
function.
This makes us a little bit more verbose: we don't accept partially
correct module and aliases names in kcmdline and in configuration files.
We log an error instead.
The only user outside of libkmod-util is depmod, which really only needs
to get the string for the extension of uncompressed modules. It doesn't
need to access the array itself.
Older systems may not have the be32toh function defined. Check for this
and fall back to checking the endianness and calling bswap_32 directly
if needed. This works on both old and new systems.
[Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>:
address comments raised by Lucas De Marchi [1], update commit message]
[1] http://www.spinics.net/lists/linux-modules/msg01129.html
If a value is added to the hash under a key that already exists the new value
replaces the old value for that key. Since key can be a pointer to data that
is part of value and freed by hash->free_value(), the key must be also
replaced and not only the value. Otherwise key potentially points to freed data.
This information can be found in /lib/modules/`uname -r`/modules.softdep, and
has only recently been exported by the kernel.
Also remove the advice about copying modules.softdep to /lib/modules as it is
not clear how to do this correctly with several kernels installed with
potentially conflicting soft dependencies.
Before we had softdeps, the usual idiom was
install foo /sbin/modprobe bar; /sbin/modprobe --ignore-install foo
ignoring errors from the first modprobe invocation. This also matches
the behavior of module-init-tools' implementation of softdep.
Add --enable-python configure switch so we build the python bindings. We
also pass version.py through SED_PROCESS macro, so the version is kept
in sync with kmod.
Acked-by: Andy Grover <agrover@redhat.com>
