Hide Forgot
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:
can you install the debuginfo of the package to get a more useful backtrace?
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 ()
changed summary and severity, this is unrelated to the mbr. sfdisk /dev/sda crashes just as well.
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)
Note: sfdisk binary compiled by gcc-3.4 works file on FC4.
it's the new gcc/glibc guard thing which traps overflows. AFAICT this is a real buffer overflow.
I see it now. It's really ugly code. I have to read your report more carefully next time. Thanks for report!
*** Bug 160284 has been marked as a duplicate of this bug. ***
is this being worked on? I can (try to) produce a patch if necessary.
The patch is pretty simple and it will be available in the next util-linux update as soon as possible (this week).
Fixed in FC4 (util-linux-2.12p-9.5) and FC3 (util-linux-2.12a-24.3) updates.
verified.
Created attachment 116622 [details] bug fix patch
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.
Oops, wrong reference. It's the glibc FORTIFY_SOURCE protection triggering here, not mudflap. (-D_FORTIFY_SOURCE=2 compiler option).
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.
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
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