Bug 159418

Summary: sfdisk unusable - crashes immediately on invocation
Product: Red Hat Enterprise Linux 4 Reporter: Avi Kivity <avi>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: chris.ricker, hno, oliva, steven
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-669 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 16:53:49 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:
Bug Depends On:    
Bug Blocks: 156320, 156322    
Attachments:
Description Flags
bug fix patch none

Description Avi Kivity 2005-06-02 15:17:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko)

Description of problem:
running sfdisk on a zeroed block device or file overflows some buffer or 
other: 
 
[root@nero ~]# dd < /dev/zero > empty count=50 
50+0 records in 
50+0 records out 
[root@nero ~]# sfdisk empty 
Warning: empty is not a block device 
Disk empty: cannot get geometry 
 
Disk empty: 0 cylinders, 0 heads, 0 sectors/track 
 
sfdisk: ERROR: sector 0 does not have an msdos signature 
 empty: unrecognized partition table type 
Old situation: 
No partitions found 
Input in the following format; absent fields get a default value. 
<start> <size> <type [E,S,L,X,hex]> <bootable [-,*]> <c,h,s> <c,h,s> 
Usually you only need to specify <start> and <size> (and perhaps <type>). 
 
   empty1 :*** buffer overflow detected ***: sfdisk terminated 
======= Backtrace: ========= 
/lib/i686/nosegneg/libc.so.6(__chk_fail+0x41)[0x85bb95] 
sfdisk[0x804c563] 
sfdisk[0x804d805] 
sfdisk[0x804eaba] 
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xc6)[0x78fde6] 
sfdisk[0x8048dc1] 
======= Memory map: ======== 
002d7000-002d8000 r-xp 002d7000 00:00 0 
00396000-0039f000 r-xp 00000000 fd:00 
9043979    /lib/libgcc_s-4.0.0-20050520.so.1 
0039f000-003a0000 rwxp 00009000 fd:00 
9043979    /lib/libgcc_s-4.0.0-20050520.so.1 
0075d000-00777000 r-xp 00000000 fd:00 9043970    /lib/ld-2.3.5.so 
00777000-00778000 r-xp 00019000 fd:00 9043970    /lib/ld-2.3.5.so 
00778000-00779000 rwxp 0001a000 fd:00 9043970    /lib/ld-2.3.5.so 
0077b000-008a2000 r-xp 00000000 fd:00 
9043985    /lib/i686/nosegneg/libc-2.3.5.so 
008a2000-008a4000 r-xp 00127000 fd:00 
9043985    /lib/i686/nosegneg/libc-2.3.5.so 
008a4000-008a6000 rwxp 00129000 fd:00 
9043985    /lib/i686/nosegneg/libc-2.3.5.so 
008a6000-008a8000 rwxp 008a6000 00:00 0 
08048000-08053000 r-xp 00000000 fd:00 15794347   /sbin/sfdisk 
08053000-08054000 rw-p 0000b000 fd:00 15794347   /sbin/sfdisk 
08054000-0805e000 rw-p 08054000 00:00 0 
0818a000-081ab000 rw-p 0818a000 00:00 0          [heap] 
b7dc4000-b7dca000 r--s 00000000 fd:00 
7471407    /usr/lib/gconv/gconv-modules.cache 
b7dca000-b7dcb000 rw-p b7dca000 00:00 0 
b7dcb000-b7fcb000 r--p 00000000 fd:00 
7413560    /usr/lib/locale/locale-archive 
b7fcb000-b7fcc000 rw-p b7fcb000 00:00 0 
b7fd4000-b7fd5000 rw-p b7fd4000 00:00 0 
bfd53000-bfed5000 rw-p bfd53000 00:00 0          [stack] 
Aborted 
 

Version-Release number of selected component (if applicable):
util-linux-2.12p-9.3

How reproducible:
Always

Steps to Reproduce:
1. create an empty file (using it as a loopback block device works as well) 
2. run sfdisk file (or sfdisk /dev/loop0) 
 
   

Actual Results:  crash 

Expected Results:  no crash  

Additional info:

Comment 1 Arjan van de Ven 2005-06-06 09:11:42 UTC
can you install the debuginfo of the package to get a more useful backtrace?

Comment 2 Avi Kivity 2005-06-06 11:03:56 UTC
it's a bit sparse due to optimization. the __chk_fail() is inside and inlined 
fgets(), which might have been called from read_stdin(): 
 
    /* read a line from stdin */ 
    lp = fgets(line+2, linesize, stdin);  
 
shouldn't that be linesize-2? 
 
#0  0x00aef402 in __kernel_vsyscall () 
#1  0x007a31fc in raise () from /lib/libc.so.6 
#2  0x007a4958 in abort () from /lib/libc.so.6 
#3  0x007d82ea in __libc_message () from /lib/libc.so.6 
#4  0x00859415 in __chk_fail () from /lib/libc.so.6 
#5  0x0804c563 in read_partition (dev=0xbfa53c24 "/tmp/empty", interactive=1, 
pno=0, ep=0x0, z=0x80587c0) 
    at /usr/include/bits/stdio2.h:106 
#6  0x0804d805 in do_fdisk (dev=0xbfa53c24 "/tmp/empty") at sfdisk.c:2287 
#7  0x0804eaba in main (argc=2, argv=0xbfa51e24) at sfdisk.c:2685 
#8  0x0078fde6 in __libc_start_main () from /lib/libc.so.6 
#9  0x08048dc1 in _start () 
 

Comment 3 Avi Kivity 2005-06-06 11:09:21 UTC
changed summary and severity, this is unrelated to the mbr. 
 
sfdisk /dev/sda crashes just as well. 

Comment 4 Karel Zak 2005-06-06 12:21:01 UTC
I can reproduce it in FC4. But if I rebuild same .src.rpm in FC3 it doens't crash.

  FC4: crashes     (glibc-2.3.5-9)
  FC3: works file  (glibc-2.3.5-0.fc3.1, gcc-3.4.3-22.fc3)


Comment 5 Karel Zak 2005-06-06 12:25:28 UTC
Note: sfdisk binary compiled by gcc-3.4 works file on FC4.

Comment 6 Avi Kivity 2005-06-06 12:30:07 UTC
it's the new gcc/glibc guard thing which traps overflows. AFAICT this is a 
real buffer overflow. 

Comment 7 Karel Zak 2005-06-06 12:37:17 UTC
I see it now. It's really ugly code. I have to read your report more carefully
next time. Thanks for report!

Comment 8 Karel Zak 2005-06-15 10:54:47 UTC
*** Bug 160284 has been marked as a duplicate of this bug. ***

Comment 9 Avi Kivity 2005-06-15 12:44:02 UTC
is this being worked on? I can (try to) produce a patch if necessary. 

Comment 10 Karel Zak 2005-06-15 13:20:29 UTC
The patch is pretty simple and it will be available in the next util-linux
update as soon as possible (this week).

Comment 12 Karel Zak 2005-06-17 09:26:04 UTC
Fixed in FC4 (util-linux-2.12p-9.5) and FC3 (util-linux-2.12a-24.3) updates.

Comment 13 Avi Kivity 2005-06-19 15:14:31 UTC
verified. 

Comment 17 Karel Zak 2005-07-11 20:39:00 UTC
Created attachment 116622 [details]
bug fix patch

Comment 20 Henrik Nordstrom 2005-08-30 22:40:02 UTC
Is RHEL 3 using the gcc based buffer overflow protections (mudflap) enabled by
default on FC4 packages? It is not enabled on FC3 packages I think.

The error will go unnoticed if this option is not enabled in the compiler flags
when the binary was build as without the overflow protection instrumentation the
potential misuse of the input buffer is not noticed. The actual error as such is
mostly harmless as sfdisk is rarely given untrusted data as input.

It is also possible (but not very likely) the error only shows up in later
versions of sfdisk. The original report was on util-linux-2.12p-9.3 while you
tested util-linux-2.11y-31.6.

Comment 21 Henrik Nordstrom 2005-08-30 22:49:39 UTC
Oops, wrong reference. It's the glibc FORTIFY_SOURCE protection triggering here,
not mudflap. (-D_FORTIFY_SOURCE=2 compiler option).

Comment 22 Karel Zak 2005-08-31 09:32:51 UTC
Yes, the original buffer overflow was detected in FC4 by new glibc. But the code
with bug in sfdisk is __same__ in FC4 and RHEL3|4. So the fix of this code in
RHEL is really good prevension.

It's really clear and pretty visible. See the patch:

  -    lp = fgets(line+2, linesize, stdin);
  +    lp = fgets(line+2, linesize-2, stdin);

See also "QE ack" comment #16. I can show you this buffer overflow by gdb, but
it's extra work if we already know that the bug is there.

Comment 25 Red Hat Bugzilla 2005-09-28 15:55:01 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 the 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-2005-626.html


Comment 26 Red Hat Bugzilla 2005-10-05 16:53:49 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 the 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-2005-669.html