Bug 16528

Summary: Segfault in depmod -- module-init-tools 3.12
Product: Other Reporter: Mark Hatle (mark.hatle)
Component: module-init-toolsAssignee: other_module-init-tools (other_module-init-tools)
Status: RESOLVED OBSOLETE    
Severity: high CC: alan, mark.hatle
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.34 Subsystem:
Regression: No Bisected commit-id:

Description Mark Hatle 2010-08-06 05:09:24 UTC
I ran into a segfault using the latest module-init-tools in a cross development 
project.  I was running depmod on a 2.6.18 RHEL 5.1 system, targeting an ia32 system running 2.6.34.

I was able to track down the problem to the output_pci_table function.

The pci_table has a bad address in it.  Looks a bit like junk.  Tracing things 
back in elfops_core.c:fetch_tables, the memset of the tables is never done 
because strings and syms are both empty.  (I believe the modules I'm running 
against have been stripped in some way.)

Tracing back further to depmod.c:grab_module, it appears that the new = 
malloc(...) setups up things, but never clears the memory that was just allocated.

As a quick hack I added a memset to clear memory:

  static struct module *grab_module(const char *dirname, const char *filename)
  {
          struct module *new;

          new = NOFAIL(malloc(sizeof(*new)
                              + strlen(dirname?:"") + 1 + strlen(filename) + 1));
+        memset(new, 0x00, sizeof(*new) + strlen(dirname?:"") + 1 + 
strlen(filename) + 1);
          if (dirname)
                  sprintf(new->pathname, "%s/%s", dirname, filename);
          else

Things now appear to be working as expected, no segfaults, no unusual behavior.

I don't understand enough about whats going on to determine if the memset in 
elfops_core is in the wrong place (should be moved before the if), or if my hack 
is potentially the right solution.