01 Dec, 2016

1 commit

  • The ER records are printed without explicit log level presuming line
    continuation until "\n". After the commit 4bcc595ccd8 (printk:
    reinstate KERN_CONT for printing continuation lines), the ER records are
    printed a character per line.

    Adding KERN_CONT to appropriate printk statements restores the printout
    behavior.

    Signed-off-by: Mike Rapoport
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     

08 May, 2016

1 commit

  • Payloads of NM entries are not supposed to contain NUL. When we run
    into such, only the part prior to the first NUL goes into the
    concatenation (i.e. the directory entry name being encoded by a bunch
    of NM entries). We do stop when the amount collected so far + the
    claimed amount in the current NM entry exceed 254. So far, so good,
    but what we return as the total length is the sum of *claimed*
    sizes, not the actual amount collected. And that can grow pretty
    large - not unlimited, since you'd need to put CE entries in
    between to be able to get more than the maximum that could be
    contained in one isofs directory entry / continuation chunk and
    we are stop once we'd encountered 32 CEs, but you can get about 8Kb
    easily. And that's what will be passed to readdir callback as the
    name length. 8Kb __copy_to_user() from a buffer allocated by
    __get_free_page()

    Cc: stable@vger.kernel.org # 0.98pl6+ (yes, really)
    Signed-off-by: Al Viro

    Al Viro
     

09 Dec, 2015

1 commit

  • kmap() in page_follow_link_light() needed to go - allowing to hold
    an arbitrary number of kmaps for long is a great way to deadlocking
    the system.

    new helper (inode_nohighmem(inode)) needs to be used for pagecache
    symlinks inodes; done for all in-tree cases. page_follow_link_light()
    instrumented to yell about anything missed.

    Signed-off-by: Al Viro

    Al Viro
     

19 Dec, 2014

1 commit

  • We didn't check length of rock ridge ER records before printing them.
    Thus corrupted isofs image can cause us to access and print some memory
    behind the buffer with obvious consequences.

    Reported-and-tested-by: Carl Henrik Lunde
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara

    Jan Kara
     

15 Dec, 2014

1 commit

  • 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
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara

    Jan Kara
     

20 Aug, 2014

1 commit

  • 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.

    CC: stable@vger.kernel.org
    Reported-by: Chris Evans
    Signed-off-by: Jan Kara

    Jan Kara
     

21 Sep, 2012

1 commit


02 Nov, 2011

1 commit


23 Jul, 2011

1 commit

  • 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: Jan Kara
    Signed-off-by: Al Viro

    Jan Kara
     

05 Oct, 2010

1 commit

  • 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 Bergmann
     

10 Dec, 2009

1 commit


26 Jul, 2008

1 commit

  • Some iso9660 images contain files with rockridge data that is either
    incorrect or incompletely parsed. Prior to commit
    f2966632a134e865db3c819346a1dc7d96e05309 ("[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
    Reviewed-by: Pekka Enberg
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adam Greenblatt
     

08 Feb, 2008

1 commit

  • 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
    Cc: Jan Kara
    Acked-by: Christoph Hellwig
    Cc: "Dave Young"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

29 Jun, 2006

1 commit


22 Jun, 2005

10 commits


26 Apr, 2005

1 commit

  • 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
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds