[patch 31/50] corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)
-stable review patch. If anyone has any objections, please let us know.
--
From: Phillip Lougher <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Date: Thu, 7 Dec 2006 04:37:20 + (-0800)
Subject: [patch 31/50] [PATCH] corrupted cramfs filesystems cause kernel oops
X-Git-Tag: v2.6.20-rc1
X-Git-Url:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8bb0269160df2a60764013994d0bc5165406cf4a
fs/cramfs/inode.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.19.1.orig/fs/cramfs/inode.c
+++ linux-2.6.19.1/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(_mutex);
bytes_filled = cramfs_uncompress_block(pgdata,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 31/50] corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)
-stable review patch. If anyone has any objections, please let us know.
--
From: Phillip Lougher [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
Date: Thu, 7 Dec 2006 04:37:20 + (-0800)
Subject: [patch 31/50] [PATCH] corrupted cramfs filesystems cause kernel oops
X-Git-Tag: v2.6.20-rc1
X-Git-Url:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8bb0269160df2a60764013994d0bc5165406cf4a
fs/cramfs/inode.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.19.1.orig/fs/cramfs/inode.c
+++ linux-2.6.19.1/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,
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
