FS#34193 - [dosfstools] dosfslabel fails with buffer overflow when labelling partition

Attached to Project: Arch Linux
Opened by Eduard Bopp (aepsil0n) - Thursday, 07 March 2013, 11:26 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 31 May 2013, 16:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description:

When trying to label a FAT32 partition on a USB stick of mine, I encountered the problem that dosfslabel fails upon detection of a buffer overflow. This has already been found yesterday on Debian (seedebian-bugs-dist@lists.debian.org/msg1104605.html"> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1104605.html). Downgrading dosfstools to 3.0.15-1 does solve the problem.


Additional info:

Terminal log:

root@omega # cfdisk /dev/sdc
root@omega # mkfs.vfat -F32 /dev/sdc1
root@omega # dosfslabel /dev/sdc1 USB_STICK
*** buffer overflow detected ***: dosfslabel terminated
======= Backtrace: =========
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f73331f68c7]
/usr/lib/libc.so.6(+0xfc9a0)[0x7f73331f49a0]
/usr/lib/libc.so.6(+0xfbe29)[0x7f73331f3e29]
/usr/lib/libc.so.6(_IO_default_xsputn+0x89)[0x7f73331702e9]
/usr/lib/libc.so.6(_IO_vfprintf+0xdf)[0x7f733313ebdf]
/usr/lib/libc.so.6(__vsprintf_chk+0x97)[0x7f73331f3ec7]
/usr/lib/libc.so.6(__sprintf_chk+0x7d)[0x7f73331f3e0d]
dosfslabel[0x404718]
dosfslabel[0x402958]
dosfslabel[0x4013eb]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f7333119a15]
dosfslabel[0x4015ed]
======= Memory map: ========
00400000-0040c000 r-xp 00000000 08:13 530702 /sbin/dosfslabel
0060b000-0060c000 r--p 0000b000 08:13 530702 /sbin/dosfslabel
0060c000-0060d000 rw-p 0000c000 08:13 530702 /sbin/dosfslabel
0060d000-0060f000 rw-p 00000000 00:00 0
01f9d000-01fbe000 rw-p 00000000 00:00 0 [heap]
7f7331884000-7f7331899000 r-xp 00000000 08:13 393063 /usr/lib/libgcc_s.so.1
7f7331899000-7f7331a98000 ---p 00015000 08:13 393063 /usr/lib/libgcc_s.so.1
7f7331a98000-7f7331a99000 rw-p 00014000 08:13 393063 /usr/lib/libgcc_s.so.1
7f7331a99000-7f73330f8000 rw-p 00000000 00:00 0
7f73330f8000-7f733329c000 r-xp 00000000 08:13 392484 /usr/lib/libc-2.17.so
7f733329c000-7f733349b000 ---p 001a4000 08:13 392484 /usr/lib/libc-2.17.so
7f733349b000-7f733349f000 r--p 001a3000 08:13 392484 /usr/lib/libc-2.17.so
7f733349f000-7f73334a1000 rw-p 001a7000 08:13 392484 /usr/lib/libc-2.17.so
7f73334a1000-7f73334a5000 rw-p 00000000 00:00 0
7f73334a5000-7f73334c6000 r-xp 00000000 08:13 392532 /usr/lib/ld-2.17.so
7f733368f000-7f7333692000 rw-p 00000000 00:00 0
7f73336c5000-7f73336c6000 rw-p 00000000 00:00 0
7f73336c6000-7f73336c7000 r--p 00021000 08:13 392532 /usr/lib/ld-2.17.so
7f73336c7000-7f73336c8000 rw-p 00022000 08:13 392532 /usr/lib/ld-2.17.so
7f73336c8000-7f73336c9000 rw-p 00000000 00:00 0
7fff4a28b000-7fff4a2ac000 rw-p 00000000 00:00 0 [stack]
7fff4a361000-7fff4a362000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)


Steps to reproduce:

Take a USB medium (or supposedly any other, though I haven't tested this), create an MSDOS partition table with a FAT32 partition and label it using dosfslabel.

# cfdisk /dev/sdx
# mkfs.vfat -F32 /dev/sdx1
# dosfslabel /dev/sdx1 USB_STICK

(as outlined here: https://wiki.archlinux.org/index.php/USB_Installation_Media#How_to_restore_the_USB_drive)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 31 May 2013, 16:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.0.17-1
Comment by Torin (Archimaredes) - Thursday, 07 March 2013, 18:50 GMT
I can confirm this. I made a 2 GiB partition on my main hard drive, formatted it to FAT32 (also tested with FAT16, same result) and suffered the same problem.

Log:

*** buffer overflow detected ***: dosfslabel terminated
======= Backtrace: =========
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f1e65d8b8c7]
/usr/lib/libc.so.6(+0xfc9a0)[0x7f1e65d899a0]
/usr/lib/libc.so.6(+0xfbe29)[0x7f1e65d88e29]
/usr/lib/libc.so.6(_IO_default_xsputn+0x89)[0x7f1e65d052e9]
/usr/lib/libc.so.6(_IO_vfprintf+0xdf)[0x7f1e65cd3bdf]
/usr/lib/libc.so.6(__vsprintf_chk+0x97)[0x7f1e65d88ec7]
/usr/lib/libc.so.6(__sprintf_chk+0x7d)[0x7f1e65d88e0d]
dosfslabel[0x404718]
dosfslabel[0x402958]
dosfslabel[0x4013eb]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f1e65caea15]
dosfslabel[0x4015ed]
======= Memory map: ========
00400000-0040c000 r-xp 00000000 08:05 2883688 /sbin/dosfslabel
0060b000-0060c000 r--p 0000b000 08:05 2883688 /sbin/dosfslabel
0060c000-0060d000 rw-p 0000c000 08:05 2883688 /sbin/dosfslabel
0060d000-0060f000 rw-p 00000000 00:00 0
01e3c000-01e5d000 rw-p 00000000 00:00 0 [heap]
7f1e65479000-7f1e6548e000 r-xp 00000000 08:05 137402 /usr/lib/libgcc_s.so.1
7f1e6548e000-7f1e6568d000 ---p 00015000 08:05 137402 /usr/lib/libgcc_s.so.1
7f1e6568d000-7f1e6568e000 rw-p 00014000 08:05 137402 /usr/lib/libgcc_s.so.1
7f1e6568e000-7f1e65c8d000 rw-p 00000000 00:00 0
7f1e65c8d000-7f1e65e31000 r-xp 00000000 08:05 133243 /usr/lib/libc-2.17.so
7f1e65e31000-7f1e66030000 ---p 001a4000 08:05 133243 /usr/lib/libc-2.17.so
7f1e66030000-7f1e66034000 r--p 001a3000 08:05 133243 /usr/lib/libc-2.17.so
7f1e66034000-7f1e66036000 rw-p 001a7000 08:05 133243 /usr/lib/libc-2.17.so
7f1e66036000-7f1e6603a000 rw-p 00000000 00:00 0
7f1e6603a000-7f1e6605b000 r-xp 00000000 08:05 133285 /usr/lib/ld-2.17.so
7f1e66226000-7f1e66229000 rw-p 00000000 00:00 0
7f1e6625a000-7f1e6625b000 rw-p 00000000 00:00 0
7f1e6625b000-7f1e6625c000 r--p 00021000 08:05 133285 /usr/lib/ld-2.17.so
7f1e6625c000-7f1e6625d000 rw-p 00022000 08:05 133285 /usr/lib/ld-2.17.so
7f1e6625d000-7f1e6625e000 rw-p 00000000 00:00 0
7fff302f0000-7fff30311000 rw-p 00000000 00:00 0 [stack]
7fff303ff000-7fff30400000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

Reproduction:

# mkdosfs -F 32 /dev/sdx1
# dosfslabel /dev/sdx1 TEST_LABEL
Comment by Kirill Voronin (dearboy) - Thursday, 18 April 2013, 20:18 GMT
Confirm it on two same installations.
I don't know why, but when I reinserted my usb flash drive, it appeared in Nautilus as unnamed disk and after it I successfully changed label.
Log:
*** buffer overflow detected ***: dosfslabel terminated
======= Backtrace: =========
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7fe254275e77]
/usr/lib/libc.so.6(+0xf9080)[0x7fe254274080]
/usr/lib/libc.so.6(+0xf85a9)[0x7fe2542735a9]
/usr/lib/libc.so.6(_IO_default_xsputn+0x89)[0x7fe2541f1189]
/usr/lib/libc.so.6(_IO_vfprintf+0xd4)[0x7fe2541c1384]
/usr/lib/libc.so.6(__vsprintf_chk+0x88)[0x7fe254273638]
/usr/lib/libc.so.6(__sprintf_chk+0x7d)[0x7fe25427358d]
dosfslabel[0x404718]
dosfslabel[0x402958]
dosfslabel[0x4013eb]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fe25419ca15]
dosfslabel[0x4015ed]
======= Memory map: ========
00400000-0040c000 r-xp 00000000 08:02 2097245 /sbin/dosfslabel
0060b000-0060c000 r--p 0000b000 08:02 2097245 /sbin/dosfslabel
0060c000-0060d000 rw-p 0000c000 08:02 2097245 /sbin/dosfslabel
0060d000-0060f000 rw-p 00000000 00:00 0
00dfa000-00e1b000 rw-p 00000000 00:00 0 [heap]
7fe253d7b000-7fe253d90000 r-xp 00000000 08:02 4593878 /usr/lib/libgcc_s.so.1
7fe253d90000-7fe253f90000 ---p 00015000 08:02 4593878 /usr/lib/libgcc_s.so.1
7fe253f90000-7fe253f91000 rw-p 00015000 08:02 4593878 /usr/lib/libgcc_s.so.1
7fe253f91000-7fe25417b000 rw-p 00000000 00:00 0
7fe25417b000-7fe25431e000 r-xp 00000000 08:02 4589698 /usr/lib/libc-2.17.so
7fe25431e000-7fe25451e000 ---p 001a3000 08:02 4589698 /usr/lib/libc-2.17.so
7fe25451e000-7fe254522000 r--p 001a3000 08:02 4589698 /usr/lib/libc-2.17.so
7fe254522000-7fe254524000 rw-p 001a7000 08:02 4589698 /usr/lib/libc-2.17.so
7fe254524000-7fe254528000 rw-p 00000000 00:00 0
7fe254528000-7fe254549000 r-xp 00000000 08:02 4589740 /usr/lib/ld-2.17.so
7fe254637000-7fe25472f000 rw-p 00000000 00:00 0
7fe254748000-7fe254749000 rw-p 00000000 00:00 0
7fe254749000-7fe25474a000 r--p 00021000 08:02 4589740 /usr/lib/ld-2.17.so
7fe25474a000-7fe25474b000 rw-p 00022000 08:02 4589740 /usr/lib/ld-2.17.so
7fe25474b000-7fe25474c000 rw-p 00000000 00:00 0
7fff8b66b000-7fff8b68c000 rw-p 00000000 00:00 0 [stack]
7fff8b7c6000-7fff8b7c8000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Comment by Jens G (Thah) - Wednesday, 22 May 2013, 16:29 GMT
Tested and confirmed with USB card reader and SDHC card on x86_64.

Bug is present in version 3.0.16-(1|2); v3.0.15-1 is unaffected.
Comment by Tobias Powalowski (tpowa) - Thursday, 30 May 2013, 16:53 GMT
Is this still valid for 3.0.17?
Comment by Jens G (Thah) - Friday, 31 May 2013, 16:45 GMT
It seems to be fixed in v3.0.17 (at least for me).

Loading...