linux/fs, branch v3.2.53

ecryptfs: Fix memory leakage in keystore.c

2013-11-28T14:02:04Z

commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream. In 'decrypt_pki_encrypted_session_key' function: Initializes 'payload' pointer and releases it on exit. Signed-off-by: Geyslan G. Bem Signed-off-by: Tyler Hicks [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

vfs: allow O_PATH file descriptors for fstatfs()

2013-11-28T14:02:03Z

commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream. Olga reported that file descriptors opened with O_PATH do not work with fstatfs(), found during further development of ksh93's thread support. There is no reason to not allow O_PATH file descriptors here (fstatfs is very much a path operation), so use "fdget_raw()". See commit 55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'") for a very similar issue reported for fstat() by the same team. Reported-and-tested-by: ольга крыжановская Acked-by: Al Viro Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: use fget_raw() not fdget_raw()] Signed-off-by: Ben Hutchings

ext4: fix memory leak in xattr

2013-11-28T14:02:03Z

commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream. If we take the 2nd retry path in ext4_expand_extra_isize_ea, we potentionally return from the function without having freed these allocations. If we don't do the return, we over-write the previous allocation pointers, so we leak either way. Spotted with Coverity. [ Fixed by tytso to set is and bs to NULL after freeing these pointers, in case in the retry loop we later end up triggering an error causing a jump to cleanup, at which point we could have a double free bug. -- Ted ] Signed-off-by: Dave Jones Signed-off-by: "Theodore Ts'o" Reviewed-by: Eric Sandeen Signed-off-by: Ben Hutchings

jfs: fix error path in ialloc

2013-11-28T14:02:00Z

commit 8660998608cfa1077e560034db81885af8e1e885 upstream. If insert_inode_locked() fails, we shouldn't be calling unlock_new_inode(). Signed-off-by: Dave Kleikamp Tested-by: Michael L. Semon Signed-off-by: Ben Hutchings

ext3: return 32/64-bit dir name hash according to usage type

2013-11-28T14:01:59Z

commit d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06 upstream. This is based on commit d1f5273e9adb40724a85272f248f210dc4ce919a ext4: return 32/64-bit dir name hash according to usage type by Fan Yong Traditionally ext2/3/4 has returned a 32-bit hash value from llseek() to appease NFSv2, which can only handle a 32-bit cookie for seekdir() and telldir(). However, this causes problems if there are 32-bit hash collisions, since the NFSv2 server can get stuck resending the same entries from the directory repeatedly. Allow ext3 to return a full 64-bit hash (both major and minor) for telldir to decrease the chance of hash collisions. This patch does implement a new ext3_dir_llseek op, because with 64-bit hashes, nfs will attempt to seek to a hash "offset" which is much larger than ext3's s_maxbytes. So for dx dirs, we call generic_file_llseek_size() with the appropriate max hash value as the maximum seekable size. Otherwise we just pass through to generic_file_llseek(). Patch-updated-by: Bernd Schubert Patch-updated-by: Eric Sandeen (blame us if something is not correct) Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings

nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)

2013-11-28T14:01:59Z

commit 06effdbb49af5f6c7d20affaec74603914acc768 upstream. Use 32-bit or 64-bit llseek() hashes for directory offsets depending on the NFS version. NFSv2 gets 32-bit hashes only. NOTE: This patch got rather complex as Christoph asked to set the filp->f_mode flag in the open call or immediatly after dentry_open() in nfsd_open() to avoid races. Personally I still do not see a reason for that and in my opinion FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it follows directly after nfsd_open() without a chance of races. Signed-off-by: Bernd Schubert Signed-off-by: "Theodore Ts'o" Acked-by: J. Bruce Fields Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings

nfsd: rename 'int access' to 'int may_flags' in nfsd_open()

2013-11-28T14:01:58Z

commit 999448a8c0202d8c41711c92385323520644527b upstream. Just rename this variable, as the next patch will add a flag and 'access' as variable name would not be correct any more. Signed-off-by: Bernd Schubert Signed-off-by: "Theodore Ts'o" Acked-by: J. Bruce Fields Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings

ext4: return 32/64-bit dir name hash according to usage type

2013-11-28T14:01:58Z

commit d1f5273e9adb40724a85272f248f210dc4ce919a upstream. Traditionally ext2/3/4 has returned a 32-bit hash value from llseek() to appease NFSv2, which can only handle a 32-bit cookie for seekdir() and telldir(). However, this causes problems if there are 32-bit hash collisions, since the NFSv2 server can get stuck resending the same entries from the directory repeatedly. Allow ext4 to return a full 64-bit hash (both major and minor) for telldir to decrease the chance of hash collisions. This still needs integration on the NFS side. Patch-updated-by: Bernd Schubert (blame me if something is not correct) Signed-off-by: Fan Yong Signed-off-by: Andreas Dilger Signed-off-by: Bernd Schubert Signed-off-by: "Theodore Ts'o" Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings

ext4: avoid hang when mounting non-journal filesystems with orphan list

2013-10-26T20:06:13Z

commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream. When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) -js: This is a fix for CVE-2013-2015. Signed-off-by: "Theodore Ts'o" Reviewed-by: Zheng Liu Acked-by: Jan Kara Signed-off-by: Jiri Slaby Signed-off-by: Ben Hutchings

isofs: Refuse RW mount of the filesystem instead of making it RO

2013-10-26T20:06:12Z

commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream. Refuse RW mount of isofs filesystem. So far we just silently changed it to RO mount but when the media is writeable, block layer won't notice this change and thus will think device is used RW and will block eject button of the drive. That is unexpected by users because for non-writeable media eject button works just fine. Userspace mount(8) command handles this just fine and retries mounting with MS_RDONLY set so userspace shouldn't see any regression. Plus any tool mounting isofs is likely confronted with the case of read-only media where block layer already refuses to mount the filesystem without MS_RDONLY set so our behavior shouldn't be anything new for it. Reported-by: Hui Wang Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings