<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs, branch v3.4.25</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>tcp: fix MSG_SENDPAGE_NOTLAST logic</title>
<updated>2013-01-11T17:07:14+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-01-06T18:21:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c87b45599a4e0d8741abeb85d1d8d5f0c1fb13be'/>
<id>c87b45599a4e0d8741abeb85d1d8d5f0c1fb13be</id>
<content type='text'>
[ Upstream commit ae62ca7b03217be5e74759dc6d7698c95df498b3 ]

commit 35f9c09fe9c72e (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag : MSG_SENDPAGE_NOTLAST meant to be set on all
frags but the last one for a splice() call.

The condition used to set the flag in pipe_to_sendpage() relied on
splice() user passing the exact number of bytes present in the pipe,
or a smaller one.

But some programs pass an arbitrary high value, and the test fails.

The effect of this bug is a lack of tcp_push() at the end of a
splice(pipe -&gt; socket) call, and possibly very slow or erratic TCP
sessions.

We should both test sd-&gt;total_len and fact that another fragment
is in the pipe (pipe-&gt;nrbufs &gt; 1)

Many thanks to Willy for providing very clear bug report, bisection
and test programs.

Reported-by: Willy Tarreau &lt;w@1wt.eu&gt;
Bisected-by: Willy Tarreau &lt;w@1wt.eu&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ae62ca7b03217be5e74759dc6d7698c95df498b3 ]

commit 35f9c09fe9c72e (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag : MSG_SENDPAGE_NOTLAST meant to be set on all
frags but the last one for a splice() call.

The condition used to set the flag in pipe_to_sendpage() relied on
splice() user passing the exact number of bytes present in the pipe,
or a smaller one.

But some programs pass an arbitrary high value, and the test fails.

The effect of this bug is a lack of tcp_push() at the end of a
splice(pipe -&gt; socket) call, and possibly very slow or erratic TCP
sessions.

We should both test sd-&gt;total_len and fact that another fragment
is in the pipe (pipe-&gt;nrbufs &gt; 1)

Many thanks to Willy for providing very clear bug report, bisection
and test programs.

Reported-by: Willy Tarreau &lt;w@1wt.eu&gt;
Bisected-by: Willy Tarreau &lt;w@1wt.eu&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfs: fix null checking in nfs_get_option_str()</title>
<updated>2013-01-11T17:06:56+00:00</updated>
<author>
<name>Xi Wang</name>
<email>xi.wang@gmail.com</email>
</author>
<published>2013-01-04T08:22:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=042cf2fb1d2ac4b4b27b2ccc4ac317a2f53df3c3'/>
<id>042cf2fb1d2ac4b4b27b2ccc4ac317a2f53df3c3</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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfsd: avoid permission checks on EXCLUSIVE_CREATE replay</title>
<updated>2013-01-11T17:06:55+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-12-07T20:40:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=59d6ce4370c17dbd3db789740a036f158e8ba9a0'/>
<id>59d6ce4370c17dbd3db789740a036f158e8ba9a0</id>
<content type='text'>
commit 7007c90fb9fef593b4aeaeee57e6a6754276c97c upstream.

With NFSv4, if we create a file then open it we explicit avoid checking
the permissions on the file during the open because the fact that we
created it ensures we should be allow to open it (the create and the
open should appear to be a single operation).

However if the reply to an EXCLUSIVE create gets lots and the client
resends the create, the current code will perform the permission check -
because it doesn't realise that it did the open already..

This patch should fix this.

Note that I haven't actually seen this cause a problem.  I was just
looking at the code trying to figure out a different EXCLUSIVE open
related issue, and this looked wrong.

(Fix confirmed with pynfs 4.0 test OPEN4--bfields)

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
[bfields: use OWNER_OVERRIDE and update for 4.1]
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7007c90fb9fef593b4aeaeee57e6a6754276c97c upstream.

With NFSv4, if we create a file then open it we explicit avoid checking
the permissions on the file during the open because the fact that we
created it ensures we should be allow to open it (the create and the
open should appear to be a single operation).

However if the reply to an EXCLUSIVE create gets lots and the client
resends the create, the current code will perform the permission check -
because it doesn't realise that it did the open already..

This patch should fix this.

Note that I haven't actually seen this cause a problem.  I was just
looking at the code trying to figure out a different EXCLUSIVE open
related issue, and this looked wrong.

(Fix confirmed with pynfs 4.0 test OPEN4--bfields)

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
[bfields: use OWNER_OVERRIDE and update for 4.1]
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfsd4: fix oops on unusual readlike compound</title>
<updated>2013-01-11T17:06:55+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2012-12-04T23:25:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4cbb3d03810a50cb5d9eab0a6cfe3152a65911f2'/>
<id>4cbb3d03810a50cb5d9eab0a6cfe3152a65911f2</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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfsd: fix v4 reply caching</title>
<updated>2013-01-11T17:06:55+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2012-11-16T20:22:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=12c93e196764a2092f35b30a1e924a5071f164ee'/>
<id>12c93e196764a2092f35b30a1e924a5071f164ee</id>
<content type='text'>
commit 57d276d71aef7d8305ff002a070cb98deb2edced upstream.

Very embarassing: 1091006c5eb15cba56785bd5b498a8d0b9546903 "nfsd: turn
on reply cache for NFSv4" missed a line, effectively leaving the reply
cache off in the v4 case.  I thought I'd tested that, but I guess not.

This time, wrote a pynfs test to confirm it works.

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 57d276d71aef7d8305ff002a070cb98deb2edced upstream.

Very embarassing: 1091006c5eb15cba56785bd5b498a8d0b9546903 "nfsd: turn
on reply cache for NFSv4" missed a line, effectively leaving the reply
cache off in the v4 case.  I thought I'd tested that, but I guess not.

This time, wrote a pynfs test to confirm it works.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>nfs: fix wrong object type in lockowner_slab</title>
<updated>2013-01-11T17:06:55+00:00</updated>
<author>
<name>Yanchuan Nian</name>
<email>ycnian@gmail.com</email>
</author>
<published>2012-10-24T06:44:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aa8dc4af9a1ed18d71da58e883bb8260ba47afb5'/>
<id>aa8dc4af9a1ed18d71da58e883bb8260ba47afb5</id>
<content type='text'>
commit 3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece upstream.

The object type in the cache of lockowner_slab is wrong, and it is
better to fix it.

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece upstream.

The object type in the cache of lockowner_slab is wrong, and it is
better to fix it.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>NFS: Fix calls to drop_nlink()</title>
<updated>2013-01-11T17:06:54+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-12-14T21:38:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0d965378563d9e73e52b11fcd8576a90f071b2af'/>
<id>0d965378563d9e73e52b11fcd8576a90f071b2af</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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>NFS: avoid NULL dereference in nfs_destroy_server</title>
<updated>2013-01-11T17:06:54+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-12-13T04:14:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1627e18aed860a61cc740e9ec9883c63059ae2a3'/>
<id>1627e18aed860a61cc740e9ec9883c63059ae2a3</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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>NFS: Add sequence_priviliged_ops for nfs4_proc_sequence()</title>
<updated>2013-01-11T17:06:54+00:00</updated>
<author>
<name>Bryan Schumaker</name>
<email>bjschuma@netapp.com</email>
</author>
<published>2012-11-12T21:55:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d1967aac70c3eaf8f93710035b313904deabf6a9'/>
<id>d1967aac70c3eaf8f93710035b313904deabf6a9</id>
<content type='text'>
commit 6bdb5f213c4344324f600dde885f25768fbd14db upstream.

If I mount an NFS v4.1 server to a single client multiple times and then
run xfstests over each mountpoint I usually get the client into a state
where recovery deadlocks.  The server informs the client of a
cb_path_down sequence error, the client then does a
bind_connection_to_session and checks the status of the lease.

I found that bind_connection_to_session sets the NFS4_SESSION_DRAINING
flag on the client, but this flag is never unset before
nfs4_check_lease() reaches nfs4_proc_sequence().  This causes the client
to deadlock, halting all NFS activity to the server.  nfs4_proc_sequence()
is only called by the state manager, so I can change it to run in privileged
mode to bypass the NFS4_SESSION_DRAINING check and avoid the deadlock.

Signed-off-by: Bryan Schumaker &lt;bjschuma@netapp.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6bdb5f213c4344324f600dde885f25768fbd14db upstream.

If I mount an NFS v4.1 server to a single client multiple times and then
run xfstests over each mountpoint I usually get the client into a state
where recovery deadlocks.  The server informs the client of a
cb_path_down sequence error, the client then does a
bind_connection_to_session and checks the status of the lease.

I found that bind_connection_to_session sets the NFS4_SESSION_DRAINING
flag on the client, but this flag is never unset before
nfs4_check_lease() reaches nfs4_proc_sequence().  This causes the client
to deadlock, halting all NFS activity to the server.  nfs4_proc_sequence()
is only called by the state manager, so I can change it to run in privileged
mode to bypass the NFS4_SESSION_DRAINING check and avoid the deadlock.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>exec: do not leave bprm-&gt;interp on stack</title>
<updated>2013-01-11T17:06:30+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2012-12-20T23:05:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7361a9019ff8d45dc835f987ccefbbeb4f560f09'/>
<id>7361a9019ff8d45dc835f987ccefbbeb4f560f09</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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
</feed>
