linux/fs, branch v2.6.30.4

eCryptfs: parse_tag_3_packet check tag 3 packet encrypted key size (CVE-2009-2407)

2009-07-30T21:40:36Z

commit f151cd2c54ddc7714e2f740681350476cda03a28 upstream. The parse_tag_3_packet function does not check if the tag 3 packet contains a encrypted key size larger than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES. Signed-off-by: Ramon de Carvalho Valle [tyhicks@linux.vnet.ibm.com: Added printk newline and changed goto to out_free] Signed-off-by: Tyler Hicks Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

eCryptfs: Check Tag 11 literal data buffer size (CVE-2009-2406)

2009-07-30T21:40:35Z

commit 6352a29305373ae6196491e6d4669f301e26492e upstream. Tag 11 packets are stored in the metadata section of an eCryptfs file to store the key signature(s) used to encrypt the file encryption key. After extracting the packet length field to determine the key signature length, a check is not performed to see if the length would exceed the key signature buffer size that was passed into parse_tag_11_packet(). Thanks to Ramon de Carvalho Valle for finding this bug using fsfuzzer. Signed-off-by: Tyler Hicks Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

elf: fix one check-after-use

2009-07-30T21:40:14Z

commit e2dbe12557d85d81f4527879499f55681c3cca4f upstream. Check before use it. Signed-off-by: WANG Cong Cc: Alexander Viro Cc: David Howells Acked-by: Roland McGrath Acked-by: James Morris Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

nilfs2: fix disorder in cp count on error during deleting checkpoints

2009-07-30T21:39:50Z

commit d9a0a345ab7a58a30ec38e5bb7401a28714914d2 upstream. This fixes a bug that checkpoint count gets wrong on errors when deleting a series of checkpoints. The count error is persistent since the checkpoint count is stored on disk. Some userland programs refer to the count via ioctl, and this bugfix is needed to prevent malfunction of such programs. Signed-off-by: Jiro SEKIBA Signed-off-by: Ryusuke Konishi Signed-off-by: Greg Kroah-Hartman

nilfs2: fix incorrect KERN_CRIT messages in case of write failures

2009-07-30T21:39:49Z

commit 4a52df779700080de4afb0436d9dd9188514a69b upstream. In case of write-failure retries, the following KERN_CRIT level messages are mistakenly output by nilfs_dat_commit_start() function: nilfs_dat_commit_start: vbn = 408463, start = 12506, end = 18446744073709551615, pbn = 530210 nilfs_dat_commit_start: vbn = 408515, start = 12506, end = 18446744073709551615, pbn = 530211 nilfs_dat_commit_start: vbn = 408464, start = 12506, end = 18446744073709551615, pbn = 530212 ... This suppresses these messages. Signed-off-by: Ryusuke Konishi Signed-off-by: Greg Kroah-Hartman

nilfs2: fix hang problem of log writer which occurs after write failures

2009-07-30T21:39:48Z

commit 8227b29722fdbac72357aae155d171a5c777670c upstream. Leandro Lucarella gave me a report that nilfs gets stuck after its write function fails. The problem turned out to be caused by bugs which leave writeback flag on pages. This fixes the problem by ensuring to clear the writeback flag in error path. Reported-by: Leandro Lucarella Signed-off-by: Ryusuke Konishi Signed-off-by: Greg Kroah-Hartman

nilfs2: remove unlikely directive causing mis-conversion of error code

2009-07-30T21:39:47Z

commit 0cfae3d8795f388f9de78adb0171520d19da77e9 upstream. The following error code handling in nilfs_segctor_write() function wrongly converted negative error codes to a truth value (i.e. 1): err = unlikely(err) ? : res; which originaly meant to be err = err ? : res; This mis-conversion caused that write or sync functions receive the unexpected error code. This fixes the bug by removing the unlikely directive. Signed-off-by: Ryusuke Konishi Signed-off-by: Greg Kroah-Hartman

block: fix sg SG_DXFER_TO_FROM_DEV regression

2009-07-30T21:39:45Z

commit ecb554a846f8e9d2a58f6d6c118168a63ac065aa upstream. I overlooked SG_DXFER_TO_FROM_DEV support when I converted sg to use the block layer mapping API (2.6.28). Douglas Gilbert explained SG_DXFER_TO_FROM_DEV: http://www.spinics.net/lists/linux-scsi/msg37135.html = The semantics of SG_DXFER_TO_FROM_DEV were: - copy user space buffer to kernel (LLD) buffer - do SCSI command which is assumed to be of the DATA_IN (data from device) variety. This would overwrite some or all of the kernel buffer - copy kernel (LLD) buffer back to the user space. The idea was to detect short reads by filling the original user space buffer with some marker bytes ("0xec" it would seem in this report). The "resid" value is a better way of detecting short reads but that was only added this century and requires co-operation from the LLD. = This patch changes the block layer mapping API to support this semantics. This simply adds another field to struct rq_map_data and enables __bio_copy_iov() to copy data from user space even with READ requests. It's better to add the flags field and kills null_mapped and the new from_user fields in struct rq_map_data but that approach makes it difficult to send this patch to stable trees because st and osst drivers use struct rq_map_data (they were converted to use the block layer in 2.6.29 and 2.6.30). Well, I should clean up the block layer mapping API. zhou sf reported this regiression and tested this patch: http://www.spinics.net/lists/linux-scsi/msg37128.html http://www.spinics.net/lists/linux-scsi/msg37168.html Reported-by: zhou sf Tested-by: zhou sf Signed-off-by: FUJITA Tomonori Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

partitions: fix broken uevent_suppress conversion

2009-07-30T21:39:35Z

commit f8c73c790c588fd70fda1632c8927a87b3d31dcd upstream. git commit f67f129e "Driver core: implement uevent suppress in kobject" contains this chunk for fs/partitions/check.c: /* suppress uevent if the disk supresses it */ - if (!ddev->uevent_suppress) + if (!dev_get_uevent_suppress(pdev)) kobject_uevent(&pdev->kobj, KOBJ_ADD); However that should have been - if (!ddev->uevent_suppress) + if (!dev_get_uevent_suppress(ddev)) Signed-off-by: Heiko Carstens Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

cifs: free nativeFileSystem field before allocating a new one

2009-07-30T21:39:24Z

commit 90a98b2f3f3647fb17667768a348b2b219f2a9f7 upstream. ...otherwise, we'll leak this memory if we have to reconnect (e.g. after network failure). Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman