#53 Uninitialized data in xattr table

[Ben Beasley]

On the latest git version (1cef7377738b5ff7c003f5aae8aeae28c8679d40), Valgrind shows that the "unused" field in the squashfs_xattr_table structure is not initialized when writing out the xattr information. This happens anytime xattr support is not disabled.

==6367== Memcheck, a memory error detector
==6367== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6367== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6367== Command: squashfs-code/squashfs-tools/mksquashfs foo foo.img -processors 1
==6367== 
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on foo.img, block size 131072.

==6367== Syscall param write(buf) points to uninitialised byte(s)
==6367==    at 0x3984C0E05D: ??? (in /usr/lib64/libpthread-2.17.so)
==6367==    by 0x4035B7: write_bytes (mksquashfs.c:558)
==6367==    by 0x403741: write_destination (mksquashfs.c:588)
==6367==    by 0x406184: generic_write_table (mksquashfs.c:1584)
==6367==    by 0x41F722: write_xattrs (xattr.c:461)
==6367==    by 0x40DABC: write_filesystem_tables (mksquashfs.c:4635)
==6367==    by 0x410F6E: main (mksquashfs.c:5533)
==6367==  Address 0x7feffeaac is on thread 1's stack
==6367==  Uninitialised value was created by a stack allocation
==6367==    at 0x41F514: write_xattrs (xattr.c:411)
==6367==

It would probably be best not to write out uninitialized memory to the file, although there may be no real impact unless this field is used in the future. The attached patch would zero-initialize this field, just as mksquashfs.c already initializes the unused field in the fragment table.