Red Hat Bugzilla – Bug 190938
kudzu - sefault in module_upgrade
Last modified: 2014-03-16 22:59:39 EDT
Description of problem: The last kernel update caused the following: /var/tmp/rpm-tmp.82525: line 6: 6771 Segmentation fault /usr/sbin/module_upgrade 2.6.16-1.2111_FC5 Running the last line by itself indeed consistently segfaults. Tail of 'strace' output shows this: open("/etc/modprobe.conf", O_RDONLY) = 3 stat64("/etc/modprobe.conf", {st_mode=S_IFREG|0644, st_size=956, ...}) = 0 read(3, "# Note: for use under 2.4, chang"..., 956) = 956 close(3) = 0 open("/etc/sysconfig/network-scripts/ifcfg-eth0", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=99, ...}) = 0 read(3, "DEVICE=eth0\nBOOTPROTO=static\n# B"..., 99) = 99 close(3) = 0 open("/etc/sysconfig/network-scripts/ifcfg-eth0:0", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=100, ...}) = 0 read(3, "DEVICE=eth0:0\nBOOTPROTO=static\n#"..., 100) = 100 close(3) = 0 open("/etc/sysconfig/network-scripts/ifcfg-eth1", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=83, ...}) = 0 read(3, "DEVICE=eth1\nBOOTPROTO=static\nIPA"..., 83) = 83 close(3) = 0 open("/etc/sysconfig/network-scripts/ifcfg-lo", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=254, ...}) = 0 read(3, "DEVICE=lo\nIPADDR=127.0.0.1\nNETMA"..., 254) = 254 close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ The system in question is updated through few generations and /etc/sysconfig/network-scripts/ifcfg-lo looks as follows: DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) BROADCAST=127.255.255.255 ONBOOT=yes NAME=loopback Whatever is in that file segfaulting looks a tad extreme. A full strace output attached. Version-Release number of selected component (if applicable): kudzu-1.2.34.3-1 How reproducible: every time
Created attachment 128696 [details] strace output for 'module_upgrade'
Can you get a gdb backtrace?
> Can you get a gdb backtrace? I was afraid that you will ask. :-) (gdb) r Starting program: /usr/sbin/module_upgrade Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xd87000 Program received signal SIGSEGV, Segmentation fault. 0x00acbaba in strcmp () from /lib/libc.so.6 (gdb) bt #0 0x00acbaba in strcmp () from /lib/libc.so.6 #1 0x0804ae1c in main (argc=1768122485, argv=0x6463682d) at module_upgrade.c:252 #2 0x00a777e4 in __libc_start_main () from /lib/libc.so.6 #3 0x0804a4b1 in _start () (gdb) f 1 #1 0x0804ae1c in main (argc=1768122485, argv=0x6463682d) at module_upgrade.c:252 252 if (!strcmp(l->newnames[i], tmpdev->driver)) { (gdb) l 247 snprintf(alias, 64, "usb-controller%d",x); 248 else 249 snprintf(alias, 64, "usb-controller");250 for (tmpdev = devs[0]; tmpdev; tmpdev = tmpdev->next) 251 for (i=0; l->newnames[i]; i++) 252 if (!strcmp(l->newnames[i], tmpdev->driver)) { 253 addAlias(cf,alias, tmpdev->driver, CM_REPLACE); 254 changed++; 255 openlog("kudzu",0,LOG_USER);256 syslog(LOG_NOTICE,"changed %s alias from %s to %s", (gdb) print l $1 = (struct listent *) 0x8bfa0a8 (gdb) print i No symbol "i" in current context. (gdb) p tmpdev $2 = (struct device *) 0x8c20758 (gdb) p l->newnames[0] $3 = 0x8bfa0e0 "uhci-hcd" (gdb) p l->newnames[1] $4 = 0x0 (gdb) p tmpdev->driver $5 = 0x0 (gdb) p devs[0] $6 = (struct device *) 0x8c20758 (gdb) p *$6 $11 = {next = 0x8c20500, index = 0, type = CLASS_OTHER, bus = BUS_PCI, device = 0x0, driver = 0x0, desc = 0x8c207b8 "Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100)", detached = 0, classprivate = 0x0, newDevice = 0x804fda0 <pciNewDevice>, freeDevice = 0x804fc90 <pciFreeDevice>, writeDevice = 0x804ff60 <pciWriteDevice>, compareDevice = 0x804fe80 <pciCompareDevice>} Hm, looks like that there is no provision for tmpdev->driver ending up as NULL. Legitimate?
Created attachment 128761 [details] patch for this issue Wow, you've got a really old alias there. The check is in the code for everything but usb; not sure why it was left out (nor why this would suddenly trigger on the new kernel).
Fixed in 1.2.35-1.
> Wow, you've got a really old alias there. You mean in /etc/modprobe.conf? I really cannot tell you why. This is a system which went through a number of updates. The most recent one from FC3 to FC5.
Just to confirm, you did have: alias usb-controllerX {usb-uhci|uhci|usb-ohci}?
Yes, indeed, there is a line alias usb-controller usb-uhci in /etc/modprobe.conf
*** Bug 193112 has been marked as a duplicate of this bug. ***
*** Bug 193472 has been marked as a duplicate of this bug. ***