The patch titled
corrupted cramfs filesystems cause kernel oops
has been removed from the -mm tree. Its filename was
corrupted-cramfs-filesystems-cause-kernel-oops.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
Subject: corrupted cramfs filesystems cause kernel oops
From: Phillip Lougher <phillip@xxxxxxxxxxxxxx>
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/
fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause
Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops
is an unchecked corrupted block length field read by cramfs_readpage().
This patch adds a sanity check to cramfs_readpage() which checks that the
block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is
intentional, even though the uncompressed data is not going to be larger
than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than
the original source data. Mkcramfs checks that the compressed size is
always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could
use the original uncompressed data in this case, but it doesn't.
Signed-off-by: Phillip Lougher <phillip@xxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
fs/cramfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN fs/cramfs/inode.c~corrupted-cramfs-filesystems-cause-kernel-oops fs/cramfs/inode.c
--- a/fs/cramfs/inode.c~corrupted-cramfs-filesystems-cause-kernel-oops
+++ a/fs/cramfs/inode.c
@@ -481,6 +481,8 @@ static int cramfs_readpage(struct file *
pgdata = kmap(page);
if (compr_len == 0)
; /* hole */
+ else if (compr_len > (PAGE_CACHE_SIZE << 1))
+ printk(KERN_ERR "cramfs: bad compressed blocksize %u\n", compr_len);
else {
mutex_lock(&read_mutex);
bytes_filled = cramfs_uncompress_block(pgdata,
_
Patches currently in -mm which might be from phillip@xxxxxxxxxxxxxx are
origin.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
