mkexfatfs crash regression in v1.1.0

[Alexey Chernyak]

Hi,

There is a memory de-allocation regression that happened between v1.0.1 of mkexfatfs and v1.1.0 that makes it crash when using the -s option.

Here's the comparison of running the same command with 2 different versions:

# mkexfatfs -n foo -s 32 /dev/sde1
mkexfatfs 1.0.1
Creating... done.
Flushing... done.
File system created successfully.

# dumpexfat /dev/sde1
dumpexfat 1.0.1
Volume label                     foo
Volume serial number      0xa512e26f
FS version                       1.0
Sector size                      512
Cluster size                   16384
Sectors count             2930277153
Free sectors              2929539104
Clusters count              91548800
Free clusters               91548097
First sector                       0
FAT first sector                 128
FAT sectors count             715424
First cluster sector          715552
Root directory cluster           702
Volume state                  0x0000
FATs count                         1
Drive number                    0x80
Allocated space                   0%



Here's the same command with v1.1.0:

# mkexfatfs -n foo -s 32 /dev/sde1        
mkexfatfs 1.1.0
Creating... *** Error in `mkexfatfs': free(): invalid next size (fast): 0x00000000013d7030 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x72a9f)[0x7f7464914a9f]
/lib64/libc.so.6(+0x77eee)[0x7f7464919eee]
/lib64/libc.so.6(+0x78c26)[0x7f746491ac26]
mkexfatfs[0x40158a]
mkexfatfs[0x401b79]
mkexfatfs[0x4012c8]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f74648c3ad5]
mkexfatfs[0x40135d]
======= Memory map: ========
00400000-0040b000 r-xp 00000000 08:03 240442                             /usr/bin/mkexfatfs
0060a000-0060b000 r--p 0000a000 08:03 240442                             /usr/bin/mkexfatfs
0060b000-0060d000 rw-p 0000b000 08:03 240442                             /usr/bin/mkexfatfs
013d7000-013f8000 rw-p 00000000 00:00 0                                  [heap]
7f746468c000-7f74646a1000 r-xp 00000000 08:03 397421                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
7f74646a1000-7f74648a0000 ---p 00015000 08:03 397421                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
7f74648a0000-7f74648a1000 r--p 00014000 08:03 397421                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
7f74648a1000-7f74648a2000 rw-p 00015000 08:03 397421                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
7f74648a2000-7f7464a2d000 r-xp 00000000 08:03 1335496                    /lib64/libc-2.20.so
7f7464a2d000-7f7464c2d000 ---p 0018b000 08:03 1335496                    /lib64/libc-2.20.so
7f7464c2d000-7f7464c31000 r--p 0018b000 08:03 1335496                    /lib64/libc-2.20.so
7f7464c31000-7f7464c33000 rw-p 0018f000 08:03 1335496                    /lib64/libc-2.20.so
7f7464c33000-7f7464c37000 rw-p 00000000 00:00 0
7f7464c37000-7f7464c58000 r-xp 00000000 08:03 1335664                    /lib64/ld-2.20.so
7f7464dfc000-7f7464dff000 rw-p 00000000 00:00 0
7f7464e54000-7f7464e57000 rw-p 00000000 00:00 0
7f7464e57000-7f7464e58000 r--p 00020000 08:03 1335664                    /lib64/ld-2.20.so
7f7464e58000-7f7464e59000 rw-p 00021000 08:03 1335664                    /lib64/ld-2.20.so
7f7464e59000-7f7464e5a000 rw-p 00000000 00:00 0
7fff5cbbf000-7fff5cbe0000 rw-p 00000000 00:00 0                          [stack]
7fff5cbfc000-7fff5cbfe000 r--p 00000000 00:00 0                          [vvar]
7fff5cbfe000-7fff5cc00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted


Cheers,
Alexey

[Andrew Nayenko]

Hi Alexey,

I've fixed this in trunk (r416). Thanks for a good bugreport!

--
Andrew Nayenko <res...@gmail.com>