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.
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.