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;
It was not saving _modules in modules and thus all check were falling in
the fallback "consider a success if module is not in the list". Also the
name check wasn't right: replace with streq().
The parsing could be better implemented, but this is left for later.
If we are accessing a file inside the build directory we should really
not trap the path. Right now this isn't important because we never do
such accesses. However it will be needed when gcov is integrated because
it dumps files to the same place where the binaries are located.
Tobias Stoeckmann
Lucas De Marchi
Caio Marcelo de Oliveira Filho