- 14 Apr, 2015 1 commit
-
-
Jan Kara authored
commit f54e18f1 upstream. Rock Ridge extensions define so called Continuation Entries (CE) which define where is further space with Rock Ridge data. Corrupted isofs image can contain arbitrarily long chain of these, including a one containing loop and thus causing kernel to end in an infinite loop when traversing these entries. Limit the traversal to 32 entries which should be more than enough space to store all the Rock Ridge data. Reported-by:
P J P <ppandit@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Zefan Li <lizefan@huawei.com>
-
- 25 Sep, 2014 1 commit
-
-
Jan Kara authored
commit 410dd3cf upstream. We did not check relocated directory in any way when processing Rock Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL entry pointing to another CL entry leading to possibly unbounded recursion in kernel code and thus stack overflow or deadlocks (if there is a loop created from CL entries). Fix the problem by not allowing CL entry to point to a directory entry with CL entry (such use makes no good sense anyway) and by checking whether CL entry doesn't point to itself. Reported-by:
Chris Evans <cevans@google.com> Signed-off-by:
-
- 02 Nov, 2011 1 commit
-
-
Miklos Szeredi authored
Replace remaining direct i_nlink updates with a new set_nlink() updater function. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Tested-by:
Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
- 22 Jul, 2011 1 commit
-
-
Jan Kara authored
sbi->s_mutex isn't needed for isofs at all so we can just remove it. Generally, since isofs is always mounted read-only, filesystem structure cannot change under us. So buffer_head contents stays constant after it's filled in. That leaves us with possible changes of global data structures. Superblock changes only during filesystem mount (even remount does not change it), inodes are only filled in during reading from disk. So there are no changes of these structures to bother about. Arguments why sbi->s_mutex can be removed at each place: isofs_readdir: Accesses sb, inode, filp, local variables => s_mutex not needed isofs_lookup: Protected by directory's i_mutex. Accesses sb, inode, dentry, local variables => s_mutex not needed rock_ridge_symlink_readpage: Protected by page lock. Accesses sb, inode, local variables => s_mutex not needed. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- 04 Oct, 2010 1 commit
-
-
Arnd Bergmann authored
As in other file systems, we can replace the big kernel lock with a private mutex in isofs. This means we can now access multiple file systems concurrently, but it also means that we serialize readdir and lookup across sleeping operations which previously released the big kernel lock. This should not matter though, as these operations are in practice serialized through the hardware access. The isofs_get_blocks functions now does not take any lock any more, it used to recursively get the BKL. After looking at the code for hours, I convinced myself that it was never needed here anyway, because it only reads constant fields of the inode and writes to a buffer head array that is at this time only visible to the caller. The get_sb and fill_super operations do not need the locking at all because they operate on a file system that is either about to be created or to be destroyed but in either case is not visible to other threads. Signed-off-by:Arnd Bergmann <arnd@arndb.de>
-
- 10 Dec, 2009 1 commit
-
-
Jan Kara authored
Also split and cleanup zisofs_readpage() when we are changing it anyway. Signed-off-by:
-
- 25 Jul, 2008 1 commit
-
-
Adam Greenblatt authored
Some iso9660 images contain files with rockridge data that is either incorrect or incompletely parsed. Prior to commit f2966632 ("[PATCH] rock: handle directory overflows") (included with kernel 2.6.13) the kernel ignored the rockridge data for these files, while still allowing the files to be accessed under their non-rockridge names. That commit inadvertently changed things so that files with invalid rockridge data could not be accessed at all. (I ran across the problem when comparing some old CDs with hard disk copies I had made long ago under kernel 2.4: a few of the files on the hard disk copies were no longer visible on the CDs.) This change reverts to the pre-2.6.13 behavior. Signed-off-by:
Adam Greenblatt <adam.greenblatt@gmail.com> Reviewed-by:
Pekka Enberg <penberg@cs.helsinki.fi> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 07 Feb, 2008 1 commit
-
-
David Howells authored
Stop the ISOFS filesystem from using read_inode(). Make isofs_read_inode() return an error code, and make isofs_iget() pass it on. Signed-off-by:
David Howells <dhowells@redhat.com> Cc: Jan Kara <jack@ucw.cz> Acked-by:
-
- 28 Jun, 2006 1 commit
-
-
Christoph Hellwig authored
Same as with already do with the file operations: keep them in .rodata and prevents people from doing runtime patching. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 22 Jun, 2005 10 commits
-
-
Andrew Morton authored
Handle the case where the variable-sized part of a rock-ridge directory entry overhangs the end of the buffer which we allocated for it. Signed-off-by:
-
Andrew Morton authored
The bug in rock.c is that it's totally trusting of the contents of the directories. If the directory says there's a continuation 10000 bytes into this 4k block then we cheerily poke around in memory we don't own and oops. So change rock_continue() to apply various sanity checks, at least ensuring that the offset+length remain within the bounds for the header part of a struct rock_ridge directory entry. Note that the kernel can still overindex the buffer due to the variable size of the rock-ridge directory entries. We cannot check that in rock_continue() unless we go parse the directory entry's signature and work out its size. Signed-off-by:
-
Andrew Morton authored
Be a bit more standard in comment layout. Signed-off-by:
-
Andrew Morton authored
- remove the MAYBE_CONTINUE macro - kfree(NULL) is OK. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Andrew Morton authored
- Remove the SETUP_ROCK_RIDGE macro. - In rock_ridge_symlink_readpage(), rename raw_inode to raw_de. It points at a directory entry, not an inode. Signed-off-by:
-
Andrew Morton authored
Remove the CHECK_CE macro Signed-off-by:
-
Andrew Morton authored
Remove the CONTINUE_DECLS macro. Signed-off-by:
-
Andrew Morton authored
Remove the CHECK_SP macro. Signed-off-by:
-
Andrew Morton authored
Fix stuff which Lindent got wrong, rework a few deeply-nested blocks. Signed-off-by:
-
Andrew Morton authored
Trying to turn rock.c into something which humans can read so we can fix some bugs. Start out by feeding it through scripts/Lindent. Signed-off-by:
-
- 26 Apr, 2005 1 commit
-
-
Al Viro authored
fs/isofs includes trimmed down to something resembling sanity. Kernel-only parts of linux/iso_fs.h and entire linux/iso_fs_{sb,i}.h moved to fs/isofs/isofs.h. A lot of useless #include in fs/isofs/*.c killed. Signed-off-by:Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
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!
-
