Rename modinfo_jonsmodules() to test_modinfo_signature(): now this test
is responsible only for the signed modules.
The other tests use specific flags to modinfo in order to print only
one field, so we can filter out those fields that are expect to change
if the module is recompiled.
This is for convenience for development and testing since we don't want
to needlessly cross-compile the modules. There's a README file
explaining the building process for those who want to update them.
These files are compiled from their respective .c and thus have LPGL
license.
If we were expecting output on stdout or stderr but the test didn't
produce any, we were incorrectly assuming the test was successful.
Now test on exit if there was activity on the monitored fd. If there
was, check also if the file size to check for output is > 0 for the
cases in which we want to assert there was no activity on certain fd.
This adds the needed infra to cross-compile modules so we can test them
in our testsuite. Right now we are only compiling mod-simple.ko for x86,
x86_64 and sparc64.
The makefiles are organized in a way it's easy to force a rebuild of a
module by calling the Makefile.arch directly and that allows the rule in
Makefile to not trigger in case we want to ship the modules
pre-compiled.
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.
Use _builtin_uaddll_overflow/_builtin_uaddl_overflow when available,
abstracting the type to use it with uint64_t.
Otherwise fallback to the implementation as added in 67466f2 ("Prevent
offset + size overflow.").
This also adds the tests for this new helper in the testsuite.
In order to let us use "#if HAVE__BUILTIN_*" without checking if it's
actually define, make sure we define it to 0 in config.h when the
function is not available.
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.
We need to let these instructions in kmod to be the last executed ones.
Otherwise the subdirectory containing the modules could propagate up the
time access.
Instead of shipping pre-compiled module, this prepares the build system
to be able to compile the necessary modules from module-playground. This
preparations starts by replacing md5.ko with our own dummy
mod-simple.ko, built from source. It works by copying the modules to
their final location while preparing the rootfs.
Some tests cover internal API that wasn't used
elsewhere. The choice here was to test and keep the
list implementation complete instead of removing it.
This reverts commit 27bcc9111b.
Let the distro decide about this flag. It's relatively recent and
doesn't work well with gcc 4.[678] making the testsuite to fail.
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;
Lucas De Marchi
Tobias Stoeckmann
Caio Marcelo de Oliveira Filho