<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/isofs, branch linux-3.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.17.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.17.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2015-01-08T18:27:47Z</updated>
<entry>
<title>isofs: Fix unchecked printing of ER records</title>
<updated>2015-01-08T18:27:47Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2014-12-18T16:26:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b9d0cf5f7efe4a060ae1487ea25c008681aff056'/>
<id>urn:sha1:b9d0cf5f7efe4a060ae1487ea25c008681aff056</id>
<content type='text'>
commit 4e2024624e678f0ebb916e6192bd23c1f9fdf696 upstream.

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 &lt;chlunde@ping.uio.no&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>isofs: Fix infinite looping over CE entries</title>
<updated>2015-01-08T18:27:44Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2014-12-15T13:22:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=486aa789eadcf44ed87f972b209299c516454693'/>
<id>urn:sha1:486aa789eadcf44ed87f972b209299c516454693</id>
<content type='text'>
commit f54e18f1b831c92f6512d2eedb224cd63d607d3d 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 &lt;ppandit@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>isofs: Fix unbounded recursion when processing relocated directories</title>
<updated>2014-08-19T16:29:30Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2014-08-17T09:49:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=410dd3cf4c9b36f27ed4542ee18b1af5e68645a4'/>
<id>urn:sha1:410dd3cf4c9b36f27ed4542ee18b1af5e68645a4</id>
<content type='text'>
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 &lt;cevans@google.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>initramfs: support initramfs that is bigger than 2GiB</title>
<updated>2014-08-08T22:57:26Z</updated>
<author>
<name>Yinghai Lu</name>
</author>
<published>2014-08-08T21:23:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d97b07c54f34e88352ebe676beb798c8f59ac588'/>
<id>urn:sha1:d97b07c54f34e88352ebe676beb798c8f59ac588</id>
<content type='text'>
Now with 64bit bzImage and kexec tools, we support ramdisk that size is
bigger than 2g, as we could put it above 4G.

Found compressed initramfs image could not be decompressed properly.  It
turns out that image length is int during decompress detection, and it
will become &lt; 0 when length is more than 2G.  Furthermore, during
decompressing len as int is used for inbuf count, that has problem too.

Change len to long, that should be ok as on 32 bit platform long is
32bits.

Tested with following compressed initramfs image as root with kexec.
	gzip, bzip2, xz, lzma, lzop, lz4.
run time for populate_rootfs():
   size        name       Nehalem-EX  Westmere-EX  Ivybridge-EX
 9034400256 root_img     :   26s           24s          30s
 3561095057 root_img.lz4 :   28s           27s          27s
 3459554629 root_img.lzo :   29s           29s          28s
 3219399480 root_img.gz  :   64s           62s          49s
 2251594592 root_img.xz  :  262s          260s         183s
 2226366598 root_img.lzma:  386s          376s         277s
 2901482513 root_img.bz2 :  635s          599s

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Rashika Kheria &lt;rashika.kheria@gmail.com&gt;
Cc: Josh Triplett &lt;josh@joshtriplett.org&gt;
Cc: Kyungsik Lee &lt;kyungsik.lee@lge.com&gt;
Cc: P J P &lt;ppandit@redhat.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Cc: "Daniel M. Weeks" &lt;dan@danweeks.net&gt;
Cc: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Cc: Jan Beulich &lt;JBeulich@suse.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs</title>
<updated>2014-04-08T00:59:17Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-04-08T00:59:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a7963eb7f4c4b5df84d5dd5083734278ad75bafb'/>
<id>urn:sha1:a7963eb7f4c4b5df84d5dd5083734278ad75bafb</id>
<content type='text'>
Pull ext3 improvements, cleanups, reiserfs fix from Jan Kara:
 "various cleanups for ext2, ext3, udf, isofs, a documentation update
  for quota, and a fix of a race in reiserfs readdir implementation"

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  reiserfs: fix race in readdir
  ext2: acl: remove unneeded include of linux/capability.h
  ext3: explicitly remove inode from orphan list after failed direct io
  fs/isofs/inode.c add __init to init_inodecache()
  ext3: Speedup WB_SYNC_ALL pass
  fs/quota/Kconfig: Update filesystems
  ext3: Update outdated comment before ext3_ordered_writepage()
  ext3: Update PF_MEMALLOC handling in ext3_write_inode()
  ext2/3: use prandom_u32() instead of get_random_bytes()
  ext3: remove an unneeded check in ext3_new_blocks()
  ext3: remove unneeded check in ext3_ordered_writepage()
  fs: Mark function as static in ext3/xattr_security.c
  fs: Mark function as static in ext3/dir.c
  fs: Mark function as static in ext2/xattr_security.c
  ext3: Add __init macro to init_inodecache
  ext2: Add __init macro to init_inodecache
  udf: Add __init macro to init_inodecache
  fs: udf: parse_options: blocksize check
</content>
</entry>
<entry>
<title>fs: push sync_filesystem() down to the file system's remount_fs()</title>
<updated>2014-03-13T14:14:33Z</updated>
<author>
<name>Theodore Ts'o</name>
</author>
<published>2014-03-13T14:14:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=02b9984d640873b7b3809e63f81a0d7e13496886'/>
<id>urn:sha1:02b9984d640873b7b3809e63f81a0d7e13496886</id>
<content type='text'>
Previously, the no-op "mount -o mount /dev/xxx" operation when the
file system is already mounted read-write causes an implied,
unconditional syncfs().  This seems pretty stupid, and it's certainly
documented or guaraunteed to do this, nor is it particularly useful,
except in the case where the file system was mounted rw and is getting
remounted read-only.

However, it's possible that there might be some file systems that are
actually depending on this behavior.  In most file systems, it's
probably fine to only call sync_filesystem() when transitioning from
read-write to read-only, and there are some file systems where this is
not needed at all (for example, for a pseudo-filesystem or something
like romfs).

Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Cc: linux-fsdevel@vger.kernel.org
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Artem Bityutskiy &lt;dedekind1@gmail.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Evgeniy Dushistov &lt;dushistov@mail.ru&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Cc: Anders Larsen &lt;al@alarsen.net&gt;
Cc: Phillip Lougher &lt;phillip@squashfs.org.uk&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Mikulas Patocka &lt;mikulas@artax.karlin.mff.cuni.cz&gt;
Cc: Petr Vandrovec &lt;petr@vandrovec.name&gt;
Cc: xfs@oss.sgi.com
Cc: linux-btrfs@vger.kernel.org
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: codalist@coda.cs.cmu.edu
Cc: linux-ext4@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: fuse-devel@lists.sourceforge.net
Cc: cluster-devel@redhat.com
Cc: linux-mtd@lists.infradead.org
Cc: jfs-discussion@lists.sourceforge.net
Cc: linux-nfs@vger.kernel.org
Cc: linux-nilfs@vger.kernel.org
Cc: linux-ntfs-dev@lists.sourceforge.net
Cc: ocfs2-devel@oss.oracle.com
Cc: reiserfs-devel@vger.kernel.org
</content>
</entry>
<entry>
<title>fs/isofs/inode.c add __init to init_inodecache()</title>
<updated>2014-03-12T21:52:39Z</updated>
<author>
<name>Fabian Frederick</name>
</author>
<published>2014-03-10T21:01:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b3b749b7ac6ae675f249d3d5ad5851433657f3ad'/>
<id>urn:sha1:b3b749b7ac6ae675f249d3d5ad5851433657f3ad</id>
<content type='text'>
init_inodecache is only called by __init init_iso9660_fs

Signed-off-by: Fabian Frederick &lt;fabf@skynet.be&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>isofs: don't pass dentry to isofs_hash{i,}_common()</title>
<updated>2013-10-25T03:34:59Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2013-09-29T22:09:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=966c1f75f8e1e8e44d8277f7cc3598f6abbdda2f'/>
<id>urn:sha1:966c1f75f8e1e8e44d8277f7cc3598f6abbdda2f</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>isofs: Refuse RW mount of the filesystem instead of making it RO</title>
<updated>2013-07-31T20:14:50Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2013-07-25T09:49:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=17b7f7cf58926844e1dd40f5eb5348d481deca6a'/>
<id>urn:sha1:17b7f7cf58926844e1dd40f5eb5348d481deca6a</id>
<content type='text'>
Refuse RW mount of isofs filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.

Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
tool mounting isofs is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.

Reported-by: Hui Wang &lt;hui.wang@canonical.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>Don't pass inode to -&gt;d_hash() and -&gt;d_compare()</title>
<updated>2013-06-29T08:57:36Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2013-05-21T22:22:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da53be12bbb4fabbe2e9f6f908de0cf478b5161d'/>
<id>urn:sha1:da53be12bbb4fabbe2e9f6f908de0cf478b5161d</id>
<content type='text'>
Instances either don't look at it at all (the majority of cases) or
only want it to find the superblock (which can be had as dentry-&gt;d_sb).
A few cases that want more are actually safe with dentry-&gt;d_inode -
the only precaution needed is the check that it hadn't been replaced with
NULL by rmdir() or by overwriting rename(), which case should be simply
treated as cache miss.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
