Bug 169003 - Kudzu segfaults with 'NETWORK' class probing and ndiswrapper
Kudzu segfaults with 'NETWORK' class probing and ndiswrapper
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-09-21 20:24 EDT by Daniel de Kok
Modified: 2014-03-16 22:56 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.2.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-22 00:28:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel de Kok 2005-09-21 20:24:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3)

Description of problem:
Kudzu segfaults when ndiswrapper is used, because the tmp->driver pointer is not checked before using it in sortNetDevices. Wireless cards that are not suppported through normal Linux drivers, but that are supported through ndiswrapper are not available through modules.alias, and do not have the driver field filled in.

(Even if this was the case it would probably be a good idea to check the pointer anyway?)

Version-Release number of selected component (if applicable):
kudzu CVS (HEAD)

How reproducible:

Steps to Reproduce:
1. kudzu -p -c NETWORK

Actual Results:  # kudzu -p -c NETWORK
Segmentation fault

# gdb kudzu
(gdb) run -p -c NETWORK
Starting program: /home/daniel/libranet-newsvn/libranet/trunk/packages/kudzu/kudzu -p -c NETWORK

Program received signal SIGSEGV, Segmentation fault.
0xb7f081b0 in strcmp () from /lib/tls/libc.so.6
(gdb) bt full
#0  0xb7f081b0 in strcmp () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x0804f685 in sortNetDevices (devs=0x8121048) at kudzu.c:296
        cur = (struct device *) 0x811ee98
        next = (struct device *) 0x811ee98
        tmp = (struct device *) 0x811ef38
        modulename = 0x811efb0 "8139too"
#2  0x080516c4 in probeDevices (probeClass=CLASS_NETWORK, probeBus=-9, 
    probeFlags=1) at kudzu.c:846
        devices = (struct device *) 0x0
        devlist = (struct device **) 0x8150078
        numDevs = 3
        bus = 20
        x = 3
        index = 0
        cl = CLASS_UNSPEC
        logLevel = 7

Expected Results:  # kudzu -p -c NETWORK
class: NETWORK
bus: PCI
detached: 0
device: eth
desc: "Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC"
vendorId: 10ec
deviceId: 8180
subVendorId: 10ec
subDeviceId: 8180
pciType: 1
pcidom:    0
pcibus:  0
pcidev:  b
pcifn:  0

(Left out other NETWORK class devices.)

Additional info:

Diff that fixes this:

Index: kudzu.c
RCS file: /usr/local/CVS/kudzu/kudzu.c,v
retrieving revision 1.147
diff -b -u -r1.147 kudzu.c
--- kudzu.c     19 Sep 2005 18:29:43 -0000      1.147
+++ kudzu.c     22 Sep 2005 00:13:45 -0000
@@ -293,7 +293,7 @@
                if (!next || next->type != CLASS_NETWORK) return;
                tmp = next->next;
                while (tmp && tmp->type == CLASS_NETWORK) {
-                       if (!strcmp(tmp->driver,modulename)) {
+                       if (tmp->driver && !strcmp(tmp->driver,modulename)) {
                                next->next = tmp->next;
                                tmp->next = cur->next;
                                cur->next = tmp;
Comment 1 Bill Nottingham 2005-09-22 00:28:58 EDT
Thanks, I keep missing them.

Will be fixed in 1.2.8-1
Comment 2 Bill Nottingham 2005-09-22 00:30:39 EDT
Note: you'll want to check modulename too.
Comment 3 Daniel de Kok 2005-09-22 02:46:21 EDT
Good point, thanks!
Comment 4 Bill Nottingham 2005-09-22 12:01:54 EDT
I did a source code audit - 1.2.8-1 should have all cases of this fixed.

Note You need to log in before you can comment on or make changes to this bug.