<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.0.58</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.0.58</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.0.58'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-01-11T17:03:38Z</updated>
<entry>
<title>nfs: fix null checking in nfs_get_option_str()</title>
<updated>2013-01-11T17:03:38Z</updated>
<author>
<name>Xi Wang</name>
<email>xi.wang@gmail.com</email>
</author>
<published>2013-01-04T08:22:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=31c4e8cd42eb2f6aedccd13670e113d2ca1db39e'/>
<id>urn:sha1:31c4e8cd42eb2f6aedccd13670e113d2ca1db39e</id>
<content type='text'>
commit e25fbe380c4e3c09afa98bcdcd9d3921443adab8 upstream.

The following null pointer check is broken.

	*option = match_strdup(args);
	return !option;

The pointer `option' must be non-null, and thus `!option' is always false.
Use `!*option' instead.

The bug was introduced in commit c5cb09b6f8 ("Cleanup: Factor out some
cut-and-paste code.").

Signed-off-by: Xi Wang &lt;xi.wang@gmail.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nfsd4: fix oops on unusual readlike compound</title>
<updated>2013-01-11T17:03:38Z</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2012-12-04T23:25:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d6e0c42ccbb489d73ebc3973583474257a028d66'/>
<id>urn:sha1:d6e0c42ccbb489d73ebc3973583474257a028d66</id>
<content type='text'>
commit d5f50b0c290431c65377c4afa1c764e2c3fe5305 upstream.

If the argument and reply together exceed the maximum payload size, then
a reply with a read-like operation can overlow the rq_pages array.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFS: Fix calls to drop_nlink()</title>
<updated>2013-01-11T17:03:38Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-12-14T21:38:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9d53441a95261c71d18938a797eb96f469b9dc09'/>
<id>urn:sha1:9d53441a95261c71d18938a797eb96f469b9dc09</id>
<content type='text'>
commit 1f018458b30b0d5c535c94e577aa0acbb92e1395 upstream.

It is almost always wrong for NFS to call drop_nlink() after removing a
file. What we really want is to mark the inode's attributes for
revalidation, and we want to ensure that the VFS drops it if we're
reasonably sure that this is the final unlink().
Do the former using the usual cache validity flags, and the latter
by testing if inode-&gt;i_nlink == 1, and clearing it in that case.

This also fixes the following warning reported by Neil Brown and
Jeff Layton (among others).

[634155.004438] WARNING:
at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.0/lin [634155.004442]
Hardware name: Latitude E6510 [634155.004577]  crc_itu_t crc32c_intel
snd_hwdep snd_pcm snd_timer snd soundcor [634155.004609] Pid: 13402, comm:
bash Tainted: G        W    3.5.0-36-desktop # [634155.004611] Call Trace:
[634155.004630]  [&lt;ffffffff8100444a&gt;] dump_trace+0xaa/0x2b0
[634155.004641]  [&lt;ffffffff815a23dc&gt;] dump_stack+0x69/0x6f
[634155.004653]  [&lt;ffffffff81041a0b&gt;] warn_slowpath_common+0x7b/0xc0
[634155.004662]  [&lt;ffffffff811832e4&gt;] drop_nlink+0x34/0x40
[634155.004687]  [&lt;ffffffffa05bb6c3&gt;] nfs_dentry_iput+0x33/0x70 [nfs]
[634155.004714]  [&lt;ffffffff8118049e&gt;] dput+0x12e/0x230
[634155.004726]  [&lt;ffffffff8116b230&gt;] __fput+0x170/0x230
[634155.004735]  [&lt;ffffffff81167c0f&gt;] filp_close+0x5f/0x90
[634155.004743]  [&lt;ffffffff81167cd7&gt;] sys_close+0x97/0x100
[634155.004754]  [&lt;ffffffff815c3b39&gt;] system_call_fastpath+0x16/0x1b
[634155.004767]  [&lt;00007f2a73a0d110&gt;] 0x7f2a73a0d10f

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFS: avoid NULL dereference in nfs_destroy_server</title>
<updated>2013-01-11T17:03:37Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-12-13T04:14:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=64b45c804286cb18c50b387169b7da64279bc1ed'/>
<id>urn:sha1:64b45c804286cb18c50b387169b7da64279bc1ed</id>
<content type='text'>
commit f259613a1e4b44a0cf85a5dafd931be96ee7c9e5 upstream.

In rare circumstances, nfs_clone_server() of a v2 or v3 server can get
an error between setting server-&gt;destory (to nfs_destroy_server), and
calling nfs_start_lockd (which will set server-&gt;nlm_host).

If this happens, nfs_clone_server will call nfs_free_server which
will call nfs_destroy_server and thence nlmclnt_done(NULL).  This
causes the NULL to be dereferenced.

So add a guard to only call nlmclnt_done() if -&gt;nlm_host is not NULL.

The other guards there are irrelevant as nlm_host can only be non-NULL
if one of these flags are set - so remove those tests.  (Thanks to Trond
for this suggestion).

This is suitable for any stable kernel since 2.6.25.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>exec: do not leave bprm-&gt;interp on stack</title>
<updated>2013-01-11T17:03:36Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2012-12-20T23:05:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=28278b332bc73f45189939a6c1797cba0eb5879f'/>
<id>urn:sha1:28278b332bc73f45189939a6c1797cba0eb5879f</id>
<content type='text'>
commit b66c5984017533316fd1951770302649baf1aa33 upstream.

If a series of scripts are executed, each triggering module loading via
unprintable bytes in the script header, kernel stack contents can leak
into the command line.

Normally execution of binfmt_script and binfmt_misc happens recursively.
However, when modules are enabled, and unprintable bytes exist in the
bprm-&gt;buf, execution will restart after attempting to load matching
binfmt modules.  Unfortunately, the logic in binfmt_script and
binfmt_misc does not expect to get restarted.  They leave bprm-&gt;interp
pointing to their local stack.  This means on restart bprm-&gt;interp is
left pointing into unused stack memory which can then be copied into the
userspace argv areas.

After additional study, it seems that both recursion and restart remains
the desirable way to handle exec with scripts, misc, and modules.  As
such, we need to protect the changes to interp.

This changes the logic to require allocation for any changes to the
bprm-&gt;interp.  To avoid adding a new kmalloc to every exec, the default
value is left as-is.  Only when passing through binfmt_script or
binfmt_misc does an allocation take place.

For a proof of concept, see DoTest.sh from:

   http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: halfdog &lt;me@halfdog.net&gt;
Cc: P J P &lt;ppandit@redhat.com&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jbd: Fix lock ordering bug in journal_unmap_buffer()</title>
<updated>2012-12-03T20:59:14Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-11-23T13:03:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1c4e871038f17769d943d4473c339171fed70f45'/>
<id>urn:sha1:1c4e871038f17769d943d4473c339171fed70f45</id>
<content type='text'>
commit 25389bb207987b5774182f763b9fb65ff08761c8 upstream.

Commit 09e05d48 introduced a wait for transaction commit into
journal_unmap_buffer() in the case we are truncating a buffer undergoing commit
in the page stradding i_size on a filesystem with blocksize &lt; pagesize. Sadly
we forgot to drop buffer lock before waiting for transaction commit and thus
deadlock is possible when kjournald wants to lock the buffer.

Fix the problem by dropping the buffer lock before waiting for transaction
commit. Since we are still holding page lock (and that is OK), buffer cannot
disappear under us.

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>reiserfs: Protect reiserfs_quota_write() with write lock</title>
<updated>2012-11-26T19:34:56Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-11-13T17:25:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7eebd4fb8bac3b4b69783e9333cf6e383376702d'/>
<id>urn:sha1:7eebd4fb8bac3b4b69783e9333cf6e383376702d</id>
<content type='text'>
commit 361d94a338a3fd0cee6a4ea32bbc427ba228e628 upstream.

Calls into reiserfs journalling code and reiserfs_get_block() need to
be protected with write lock. We remove write lock around calls to high
level quota code in the next patch so these paths would suddently become
unprotected.

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>reiserfs: Move quota calls out of write lock</title>
<updated>2012-11-26T19:34:56Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-11-13T16:05:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2f21676d17f0c67263e87f13859682712b643323'/>
<id>urn:sha1:2f21676d17f0c67263e87f13859682712b643323</id>
<content type='text'>
commit 7af11686933726e99af22901d622f9e161404e6b upstream.

Calls into highlevel quota code cannot happen under the write lock. These
calls take dqio_mutex which ranks above write lock. So drop write lock
before calling back into quota code.

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>reiserfs: Protect reiserfs_quota_on() with write lock</title>
<updated>2012-11-26T19:34:56Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-11-13T15:34:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a7b8408f3c42adc601513bb7b8dae9ef05a1719e'/>
<id>urn:sha1:a7b8408f3c42adc601513bb7b8dae9ef05a1719e</id>
<content type='text'>
commit b9e06ef2e8706fe669b51f4364e3aeed58639eb2 upstream.

In reiserfs_quota_on() we do quite some work - for example unpacking
tail of a quota file. Thus we have to hold write lock until a moment
we call back into the quota code.

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>reiserfs: Fix lock ordering during remount</title>
<updated>2012-11-26T19:34:56Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-11-13T13:55:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=daa88cb107f76cf9b563a2c0c25bbf2f47c67abf'/>
<id>urn:sha1:daa88cb107f76cf9b563a2c0c25bbf2f47c67abf</id>
<content type='text'>
commit 3bb3e1fc47aca554e7e2cc4deeddc24750987ac2 upstream.

When remounting reiserfs dquot_suspend() or dquot_resume() can be called.
These functions take dqonoff_mutex which ranks above write lock so we have
to drop it before calling into quota code.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
