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.)
mark@ebony bash$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
mark@ebony bash$ /sbin/depmod --version
module-init-tools 3.7-pre9
mark@ebony bash$ /sbin/depmod
Segmentation fault
mark@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.
mark@ebony bash$ 3.7.obj/depmod -n > modules.dep && ls -l modules.dep
Segmentation fault
mark@ebony bash$ 3.8.obj/depmod -n > modules.dep && ls -l modules.dep
Segmentation fault
mark@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.
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.)
mark@ebony bash$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
mark@ebony bash$ /sbin/depmod --version
module-init-tools 3.7-pre9
mark@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.
mark@ebony bash$ gdb depmod
GNU gdb 6.8-debian
[...]
(gdb) run
Starting program: .../obj/depmod
Program received signal SIGSEGV, Segmentation fault. ab000, fsize=0, 0x40d610 "__ksymtab_ strings" , secsize= 0x7fffe6d77458, conv=0) elf_core. c:35 b000, 0x40d610 "__ksymtab_ strings" , secsize= 0x7fffe6d77458, conv=0) moduleops_ core.c: 7 moduleops_ core.c: 17 77f8) depmod. c:1288
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=0x7f37de1
secname=
at ../src/
#2 0x0000000000405bf3 in load_section64 (hdr=0x7f37de1a
secname=
at ../src/
#3 0x0000000000405c24 in load_symbols64 (module=0xe31320)
at ../src/
#4 0x0000000000403132 in parse_modules (list=0xe43020)
at ../src/depmod.c:675
#5 0x0000000000404b4a in main (argc=1, argv=0x7fffe6d7
at ../src/
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.
mark@ebony bash$ 3.7.obj/depmod -n > modules.dep && ls -l modules.dep 2.6.28- 13-generic/ updates/ dkms/nvidia. ko
Segmentation fault
mark@ebony bash$ 3.8.obj/depmod -n > modules.dep && ls -l modules.dep
Segmentation fault
mark@ebony bash$ 3.9.obj/depmod -n > modules.dep && ls -l modules.dep
WARNING: Couldn't find symtab and strtab in module /lib/modules/
-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) ... 2.6.28- 13-generic (--configure): image-2. 6.28-13- generic
Running depmod.
Failed to run depmod
dpkg: error processing linux-image-
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
linux-
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.