Bug 678487

Summary: Running fcoeadm -i ethx before loading fcoe module stack displays "fcoeadm: free(): invalid pointer
Product: Red Hat Enterprise Linux 6 Reporter: Miroslav Vadkerti <mvadkert>
Component: fcoe-utilsAssignee: Petr Šabata <psabata>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: jzeleny, ohudlick, rvokal, syeghiay
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: fcoe-utils-1.0.17-4.el6 Doc Type: Bug Fix
Doc Text:
Cause Running 'fcoeadm' without FCoE stack loaded. Consequence 'fcoeadm' tool tries to free an unallocated pointer, normally used to store sysfs directory structure. Fix Only free the pointer if it was successfully allocated. Result 'fcoeadm' now free()'s its memory properly.
Story Points: ---
Clone Of: 503165 Environment:
Last Closed: 2011-05-19 14:20:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Do not free if scandir() fails none

Comment 1 Miroslav Vadkerti 2011-02-18 08:18:08 UTC
I can reproduce this on latest fcoe-utils-1.0.17-3.el6:


# fcoeadm -i eth0
*** glibc detected *** fcoeadm: double free or corruption (out): 0x000000300000df00 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3000475676]
fcoeadm[0x403cf7]
fcoeadm[0x403d41]
fcoeadm[0x401d54]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x300041ec5d]
fcoeadm[0x401519]
======= Memory map: ========
00400000-00406000 r-xp 00000000 fd:00 2382238                            /usr/sbin/fcoeadm
00605000-00606000 rw-p 00005000 fd:00 2382238                            /usr/sbin/fcoeadm
01485000-014a6000 rw-p 00000000 00:00 0                                  [heap]
3000000000-300001e000 r-xp 00000000 fd:00 2228619                        /lib64/ld-2.12.so
300021d000-300021e000 r--p 0001d000 fd:00 2228619                        /lib64/ld-2.12.so
300021e000-300021f000 rw-p 0001e000 fd:00 2228619                        /lib64/ld-2.12.so
300021f000-3000220000 rw-p 00000000 00:00 0 
3000400000-3000575000 r-xp 00000000 fd:00 2228620                        /lib64/libc-2.12.so
3000575000-3000775000 ---p 00175000 fd:00 2228620                        /lib64/libc-2.12.so
3000775000-3000779000 r--p 00175000 fd:00 2228620                        /lib64/libc-2.12.so
3000779000-300077a000 rw-p 00179000 fd:00 2228620                        /lib64/libc-2.12.so
300077a000-300077f000 rw-p 00000000 00:00 0 
3000800000-3000802000 r-xp 00000000 fd:00 2228622                        /lib64/libdl-2.12.so
3000802000-3000a02000 ---p 00002000 fd:00 2228622                        /lib64/libdl-2.12.so
3000a02000-3000a03000 r--p 00002000 fd:00 2228622                        /lib64/libdl-2.12.so
3000a03000-3000a04000 rw-p 00003000 fd:00 2228622                        /lib64/libdl-2.12.so
7fa45150b000-7fa451521000 r-xp 00000000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451521000-7fa451720000 ---p 00016000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451720000-7fa451721000 rw-p 00015000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451721000-7fa451724000 rw-p 00000000 00:00 0 
7fa451724000-7fa45172a000 r-xp 00000000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa45172a000-7fa451929000 ---p 00006000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa451929000-7fa45192a000 rw-p 00005000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa45193b000-7fa45193c000 rw-p 00000000 00:00 0 
7fff6f097000-7fff6f0ac000 rw-p 00000000 00:00 0                          [stack]
7fff6f178000-7fff6f179000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

Comment 2 Petr Šabata 2011-02-18 09:22:51 UTC
I cannot reproduce this issue with fcoe-utils-1.0.17-3.el6.x86_64.
I'm removing the dependency on bug #503165 since even if I could reproduce this, it wouldn't be related.

Comment 3 Marcela Mašláňová 2011-02-18 11:48:06 UTC
It was reproduced. Acked.

Comment 5 Petr Šabata 2011-02-18 13:01:06 UTC
Fixed in CVS tag fcoe-utils-1.0.17-4.el6

Comment 7 Petr Šabata 2011-02-18 13:38:44 UTC
Created attachment 479502 [details]
Do not free if scandir() fails

Comment 9 Petr Šabata 2011-05-09 14:15:02 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    Running 'fcoeadm' without FCoE stack loaded.
Consequence
    'fcoeadm' tool tries to free an unallocated pointer, normally used to
    store sysfs directory structure.
Fix
    Only free the pointer if it was successfully allocated.
Result
    'fcoeadm' now free()'s its memory properly.

Comment 10 errata-xmlrpc 2011-05-19 14:20:24 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0743.html