Bug 159418 - sfdisk unusable - crashes immediately on invocation
sfdisk unusable - crashes immediately on invocation
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
: 160284 (view as bug list)
Depends On:
Blocks: 156320 156322
  Show dependency treegraph
 
Reported: 2005-06-02 11:17 EDT by Avi Kivity
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2005-669
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 12:53:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bug fix patch (359 bytes, patch)
2005-07-11 16:39 EDT, Karel Zak
no flags Details | Diff

  None (edit)
Description Avi Kivity 2005-06-02 11:17:46 EDT
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 05:11:42 EDT
can you install the debuginfo of the package to get a more useful backtrace?
Comment 2 Avi Kivity 2005-06-06 07:03:56 EDT
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 07:09:21 EDT
changed summary and severity, this is unrelated to the mbr. 
 
sfdisk /dev/sda crashes just as well. 
Comment 4 Karel Zak 2005-06-06 08:21:01 EDT
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 08:25:28 EDT
Note: sfdisk binary compiled by gcc-3.4 works file on FC4.
Comment 6 Avi Kivity 2005-06-06 08:30:07 EDT
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 08:37:17 EDT
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 06:54:47 EDT
*** Bug 160284 has been marked as a duplicate of this bug. ***
Comment 9 Avi Kivity 2005-06-15 08:44:02 EDT
is this being worked on? I can (try to) produce a patch if necessary. 
Comment 10 Karel Zak 2005-06-15 09:20:29 EDT
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 05:26:04 EDT
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 11:14:31 EDT
verified. 
Comment 17 Karel Zak 2005-07-11 16:39:00 EDT
Created attachment 116622 [details]
bug fix patch
Comment 20 Henrik Nordstrom 2005-08-30 18:40:02 EDT
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 18:49:39 EDT
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 05:32:51 EDT
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 11:55:01 EDT
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 12:53:49 EDT
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

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