summaryrefslogtreecommitdiff
path: root/fs/cramfs
AgeCommit message (Collapse)Author
2007-01-09corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)Phillip Lougher
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@lougher.org.uk> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-06[PATCH] cramfs mounts provide corrupted content since 2.6.15Dave Johnson
Fix handling of cramfs images created by util-linux containing empty regular files. Images created by cramfstools 1.x were ok. Fill out inode contents in cramfs_iget5_set() instead of get_cramfs_inode() to prevent issues if cramfs_iget5_test() is called with I_LOCK|I_NEW still set. Signed-off-by: Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com> Cc: Olaf Hering <olh@suse.de> Cc: Chris Mason <mason@suse.com> Cc: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10[PATCH] fs/cramfs/uncompress.c should #include <linux/cramfs_fs.h>Adrian Bunk
Every file should #include the header with the prototypes of the global functions it is offering. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07[PATCH] fix cramfs making duplicate entries in inode cacheDave Johnson
Every time cramfs_lookup() is called to lookup and inode for a dentry, get_cramfs_inode() will allocate a new inode without checking to see if that inode already exists in the inode cache. This is fine the first time, but if the dentry cache entry(ies) associated with that inode are aged out, but the inode entry is not aged out (which can be quite common if the inode has buffer cache linked to it), cramfs_lookup() will be called again and another inode will be allocated and added to the inode cache creating a duplicate in the inode cache. The big issue here is that the buffers associated with each inode cache entry are not shared between the duplicates! The older inode entries are now orphaned as no dentry points to it and won't be freed until the buffer cache assoicated with them are first freed. The newest entry will have to create all new buffer cache for each part of its file as the old buffer cache is now orphaned as well. Patch below fixes this by making get_cramfs_inode() use the inode cache before blindly creating a new entry every time. This eliminates the duplicate inodes and duplicate buffer cache. Cc: Phillip Lougher <phillip@lougher.demon.co.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!