This bug is not fixed in Jaunty. module-init-tools 3.7 (or 3.7preANYTHING) doesn't contain a complete fix for the problem. depmod module-init-tools 3.7-pre9 still crashes in strcmp with SIGSEGV for me on Januty when I have a broken module present. (The module is a truncated DKMS module, I don't know how it happened and it doesn't really matter either, it's just a good testcase for this bug.)
m...@ebony bash$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 9.04 Release: 9.04 Codename: jaunty m...@ebony bash$ /sbin/depmod --version module-init-tools 3.7-pre9 m...@ebony bash$ /sbin/depmod Segmentation fault Great. For this demonstration, I pulled the current source from |bzr checkout http://bazaar.launchpad.net/~ubuntu-core-dev/module-init-tools/ubuntu| (which is actually based on 3.8) and confirmed that the bug is present. m...@ebony bash$ gdb depmod GNU gdb 6.8-debian [...] (gdb) run Starting program: .../obj/depmod Program received signal SIGSEGV, Segmentation fault. 0x00007f37de8676a0 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0x00007f37de8676a0 in strcmp () from /lib/libc.so.6 #1 0x000000000040a7ec in get_section64 (file=0x7f37de1ab000, fsize=0, secname=0x40d610 "__ksymtab_strings", secsize=0x7fffe6d77458, conv=0) at ../src/elf_core.c:35 #2 0x0000000000405bf3 in load_section64 (hdr=0x7f37de1ab000, secname=0x40d610 "__ksymtab_strings", secsize=0x7fffe6d77458, conv=0) at ../src/moduleops_core.c:7 #3 0x0000000000405c24 in load_symbols64 (module=0xe31320) at ../src/moduleops_core.c:17 #4 0x0000000000403132 in parse_modules (list=0xe43020) at ../src/depmod.c:675 #5 0x0000000000404b4a in main (argc=1, argv=0x7fffe6d777f8) at ../src/depmod.c:1288 Therefore, this problem would still be present in Karmic as it stands now. The real problem here is that upstream module-init-tools does not do proper bounds checking prior to 3.9. Look at load_section in 3.7/moduleops_core.c. It assumes that the ELF file is as big as it needs to be, which is not a safe assumption. In 3.8/moduleops_core.c, load_section calls to elf_core.c's get_section, which introduces the possibility for bounds checking, but it is bypassed because load_section always passes 0 for |fsize|. Finally, in 3.9/elfops_core.c, load_section passes the entire module struct to get_section, which now always enforces bounds checking to ensure that it doesn't attempt to read unmapped memory beyond the end of the file. m...@ebony bash$ 3.7.obj/depmod -n > modules.dep && ls -l modules.dep Segmentation fault m...@ebony bash$ 3.8.obj/depmod -n > modules.dep && ls -l modules.dep Segmentation fault m...@ebony bash$ 3.9.obj/depmod -n > modules.dep && ls -l modules.dep WARNING: Couldn't find symtab and strtab in module /lib/modules/2.6.28-13-generic/updates/dkms/nvidia.ko -rw-r--r-- 1 mark mark 1822960 2009-07-07 23:18 modules.dep That warning (non-fatal) is far more useful than crashing without producing a modules.dep file. With the "broken" (3.7 or 3.8) depmod, I was suffering through this on every apt-get invocation: Setting up linux-image-2.6.28-13-generic (2.6.28-13.45) ... Running depmod. Failed to run depmod dpkg: error processing linux-image-2.6.28-13-generic (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: linux-image-2.6.28-13-generic E: Sub-process /usr/bin/dpkg returned an error code (1) This essentially left the system in an indeterminate and potentially unstable state. With a "fixed" (3.9) depmod, a warning would be produced, but the broken module would not cause any further problems for the rest of the system aside from being unusable itself. I recommend shipping module-init-tools 3.9 with Karmic to alleviate these problems. ** Changed in: module-init-tools (Ubuntu) Status: Fix Released => Incomplete ** Changed in: module-init-tools (Ubuntu) Status: Incomplete => New -- [apport] depmod crashed with SIGSEGV in strcmp() https://bugs.launchpad.net/bugs/99547 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
