<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/crypto, branch v3.10.23</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST</title>
<updated>2013-12-08T15:29:26+00:00</updated>
<author>
<name>Shawn Landden</name>
<email>shawn@churchofgit.com</email>
</author>
<published>2013-11-25T06:36:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86a243440a102e315438c6faf57881796533528d'/>
<id>86a243440a102e315438c6faf57881796533528d</id>
<content type='text'>
[ Upstream commit d3f7d56a7a4671d395e8af87071068a195257bf6 ]

Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST, similar to
MSG_MORE.

algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
and need to see the new flag as identical to MSG_MORE.

This fixes sendfile() on AF_ALG.

v3: also fix udp

Reported-and-tested-by: Shawn Landden &lt;shawnlandden@gmail.com&gt;
Cc: Tom Herbert &lt;therbert@google.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Original-patch: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Shawn Landden &lt;shawn@churchofgit.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 d3f7d56a7a4671d395e8af87071068a195257bf6 ]

Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST, similar to
MSG_MORE.

algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
and need to see the new flag as identical to MSG_MORE.

This fixes sendfile() on AF_ALG.

v3: also fix udp

Reported-and-tested-by: Shawn Landden &lt;shawnlandden@gmail.com&gt;
Cc: Tom Herbert &lt;therbert@google.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Original-patch: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Shawn Landden &lt;shawn@churchofgit.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>net: rework recvmsg handler msg_name and msg_namelen logic</title>
<updated>2013-12-08T15:29:25+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-11-21T02:14:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f73d7fde99d702cba6a05062c27605a6eef1b78'/>
<id>2f73d7fde99d702cba6a05062c27605a6eef1b78</id>
<content type='text'>
[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]

This patch now always passes msg-&gt;msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size &lt;= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg-&gt;msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys-&gt;msg_namelen == 0)
	msg-&gt;msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller &lt;davem@davemloft.net&gt;
Suggested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&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 f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]

This patch now always passes msg-&gt;msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size &lt;= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg-&gt;msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys-&gt;msg_namelen == 0)
	msg-&gt;msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller &lt;davem@davemloft.net&gt;
Suggested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&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>X.509: Remove certificate date checks</title>
<updated>2013-12-04T18:57:33+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-06-18T16:40:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d8f0a31aa3ccf94e1902ff6c0c68410e3b68ecca'/>
<id>d8f0a31aa3ccf94e1902ff6c0c68410e3b68ecca</id>
<content type='text'>
commit 124df926090b32a998483f6e43ebeccdbe5b5302 upstream.

Remove the certificate date checks that are performed when a certificate is
parsed.  There are two checks: a valid from and a valid to.  The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
cc: Alexander Holler &lt;holler@ahsoftware.de&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 124df926090b32a998483f6e43ebeccdbe5b5302 upstream.

Remove the certificate date checks that are performed when a certificate is
parsed.  There are two checks: a valid from and a valid to.  The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
cc: Alexander Holler &lt;holler@ahsoftware.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ansi_cprng - Fix off by one error in non-block size request</title>
<updated>2013-11-29T19:11:40+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-09-17T12:33:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d8a7dd7122d411662e7ccf9986070fbe2ac2aeb2'/>
<id>d8a7dd7122d411662e7ccf9986070fbe2ac2aeb2</id>
<content type='text'>
commit 714b33d15130cbb5ab426456d4e3de842d6c5b8a upstream.

Stephan Mueller reported to me recently a error in random number generation in
the ansi cprng. If several small requests are made that are less than the
instances block size, the remainder for loop code doesn't increment
rand_data_valid in the last iteration, meaning that the last bytes in the
rand_data buffer gets reused on the subsequent smaller-than-a-block request for
random data.

The fix is pretty easy, just re-code the for loop to make sure that
rand_data_valid gets incremented appropriately

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Reported-by: Stephan Mueller &lt;stephan.mueller@atsec.com&gt;
CC: Stephan Mueller &lt;stephan.mueller@atsec.com&gt;
CC: Petr Matousek &lt;pmatouse@redhat.com&gt;
CC: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Luis Henriques &lt;luis.henriques@canonical.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 714b33d15130cbb5ab426456d4e3de842d6c5b8a upstream.

Stephan Mueller reported to me recently a error in random number generation in
the ansi cprng. If several small requests are made that are less than the
instances block size, the remainder for loop code doesn't increment
rand_data_valid in the last iteration, meaning that the last bytes in the
rand_data buffer gets reused on the subsequent smaller-than-a-block request for
random data.

The fix is pretty easy, just re-code the for loop to make sure that
rand_data_valid gets incremented appropriately

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Reported-by: Stephan Mueller &lt;stephan.mueller@atsec.com&gt;
CC: Stephan Mueller &lt;stephan.mueller@atsec.com&gt;
CC: Petr Matousek &lt;pmatouse@redhat.com&gt;
CC: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Luis Henriques &lt;luis.henriques@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: api - Fix race condition in larval lookup</title>
<updated>2013-09-27T00:18:01+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2013-09-08T04:33:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=139653e11c9eec4d5eff614e688d6bec99b78d7f'/>
<id>139653e11c9eec4d5eff614e688d6bec99b78d7f</id>
<content type='text'>
commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.

crypto_larval_lookup should only return a larval if it created one.
Any larval created by another entity must be processed through
crypto_larval_wait before being returned.

Otherwise this will lead to a larval being killed twice, which
will most likely lead to a crash.

Reported-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&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 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.

crypto_larval_lookup should only return a larval if it created one.
Any larval created by another entity must be processed through
crypto_larval_wait before being returned.

Otherwise this will lead to a larval being killed twice, which
will most likely lead to a crash.

Reported-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: sanitize argument for format string</title>
<updated>2013-07-13T18:42:26+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-07-03T22:01:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c231b9d04be757bd8a9953737ed2c22ffb987f49'/>
<id>c231b9d04be757bd8a9953737ed2c22ffb987f49</id>
<content type='text'>
commit 1c8fca1d92e14859159a82b8a380d220139b7344 upstream.

The template lookup interface does not provide a way to use format
strings, so make sure that the interface cannot be abused accidentally.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&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 1c8fca1d92e14859159a82b8a380d220139b7344 upstream.

The template lookup interface does not provide a way to use format
strings, so make sure that the interface cannot be abused accidentally.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&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>
<entry>
<title>crypto: algboss - Hold ref count on larval</title>
<updated>2013-06-25T11:15:17+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2013-06-25T11:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=939e17799619e31331d2433041196529515a86a6'/>
<id>939e17799619e31331d2433041196529515a86a6</id>
<content type='text'>
On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
&gt; After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
&gt; sctp: fix NULL pointer dereference in socket destruction"), I ran into
&gt; the following NULL pointer dereference in the crypto subsystem with
&gt; the same reproducer, easily hit each time:
&gt; 
&gt; BUG: unable to handle kernel NULL pointer dereference at (null)
&gt; IP: [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt; PGD 0
&gt; Oops: 0000 [#1] SMP
&gt; Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
&gt; CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF            3.10.0-rc5+ #1
&gt; Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
&gt; task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
&gt; RIP: 0010:[&lt;ffffffff81070321&gt;]  [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt; RSP: 0018:ffff88007b7cde08  EFLAGS: 00010082
&gt; RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
&gt; RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
&gt; RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
&gt; R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
&gt; R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
&gt; FS:  0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
&gt; CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
&gt; CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
&gt; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
&gt; Stack:
&gt;  ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
&gt;  0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
&gt;  ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
&gt; Call Trace:
&gt;  [&lt;ffffffff81227670&gt;] ? crypto_alloc_pcomp+0x20/0x20
&gt;  [&lt;ffffffff810722b7&gt;] complete_all+0x47/0x60
&gt;  [&lt;ffffffff81227708&gt;] cryptomgr_probe+0x98/0xc0
&gt;  [&lt;ffffffff81227670&gt;] ? crypto_alloc_pcomp+0x20/0x20
&gt;  [&lt;ffffffff8106760e&gt;] kthread+0xce/0xe0
&gt;  [&lt;ffffffff81067540&gt;] ? kthread_freezable_should_stop+0x70/0x70
&gt;  [&lt;ffffffff815450dc&gt;] ret_from_fork+0x7c/0xb0
&gt;  [&lt;ffffffff81067540&gt;] ? kthread_freezable_should_stop+0x70/0x70
&gt; Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
&gt;       4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
&gt; RIP  [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt;  RSP &lt;ffff88007b7cde08&gt;
&gt; CR2: 0000000000000000
&gt; ---[ end trace b495b19270a4d37e ]---
&gt; 
&gt; My assumption is that the following is happening: the minimal SCTP
&gt; tool runs under ``echo 1 &gt; /proc/sys/net/sctp/auth_enable'', hence
&gt; it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
&gt; It forks itself, heavily allocates, binds, listens and waits in
&gt; accept on sctp sockets, and then randomly kills some of them (no
&gt; need for an actual client in this case to hit this). Then, again,
&gt; allocating, binding, etc, and then killing child processes.
&gt; 
&gt; The problem that might be happening here is that cryptomgr requests
&gt; the module to probe/load through cryptomgr_schedule_probe(), but
&gt; before the thread handler cryptomgr_probe() returns, we return from
&gt; the wait_for_completion_interruptible() function and probably already
&gt; have cleared up larval, thus we run into a NULL pointer dereference
&gt; when in cryptomgr_probe() complete_all() is being called.
&gt; 
&gt; If we wait with wait_for_completion() instead, this panic will not
&gt; occur anymore. This is valid, because in case a signal is pending,
&gt; cryptomgr_probe() returns from probing anyway with properly calling
&gt; complete_all().

The use of wait_for_completion_interruptible is intentional so that
we don't lock up the thread if a bug causes us to never wake up.

This bug is caused by the helper thread using the larval without
holding a reference count on it.  If the helper thread completes
after the original thread requesting for help has gone away and
destroyed the larval, then we get the crash above.

So the fix is to hold a reference count on the larval.

Cc: &lt;stable@vger.kernel.org&gt; # 3.6+
Reported-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Tested-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
&gt; After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
&gt; sctp: fix NULL pointer dereference in socket destruction"), I ran into
&gt; the following NULL pointer dereference in the crypto subsystem with
&gt; the same reproducer, easily hit each time:
&gt; 
&gt; BUG: unable to handle kernel NULL pointer dereference at (null)
&gt; IP: [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt; PGD 0
&gt; Oops: 0000 [#1] SMP
&gt; Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
&gt; CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF            3.10.0-rc5+ #1
&gt; Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
&gt; task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
&gt; RIP: 0010:[&lt;ffffffff81070321&gt;]  [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt; RSP: 0018:ffff88007b7cde08  EFLAGS: 00010082
&gt; RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
&gt; RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
&gt; RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
&gt; R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
&gt; R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
&gt; FS:  0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
&gt; CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
&gt; CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
&gt; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
&gt; Stack:
&gt;  ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
&gt;  0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
&gt;  ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
&gt; Call Trace:
&gt;  [&lt;ffffffff81227670&gt;] ? crypto_alloc_pcomp+0x20/0x20
&gt;  [&lt;ffffffff810722b7&gt;] complete_all+0x47/0x60
&gt;  [&lt;ffffffff81227708&gt;] cryptomgr_probe+0x98/0xc0
&gt;  [&lt;ffffffff81227670&gt;] ? crypto_alloc_pcomp+0x20/0x20
&gt;  [&lt;ffffffff8106760e&gt;] kthread+0xce/0xe0
&gt;  [&lt;ffffffff81067540&gt;] ? kthread_freezable_should_stop+0x70/0x70
&gt;  [&lt;ffffffff815450dc&gt;] ret_from_fork+0x7c/0xb0
&gt;  [&lt;ffffffff81067540&gt;] ? kthread_freezable_should_stop+0x70/0x70
&gt; Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
&gt;       4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
&gt; RIP  [&lt;ffffffff81070321&gt;] __wake_up_common+0x31/0x90
&gt;  RSP &lt;ffff88007b7cde08&gt;
&gt; CR2: 0000000000000000
&gt; ---[ end trace b495b19270a4d37e ]---
&gt; 
&gt; My assumption is that the following is happening: the minimal SCTP
&gt; tool runs under ``echo 1 &gt; /proc/sys/net/sctp/auth_enable'', hence
&gt; it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
&gt; It forks itself, heavily allocates, binds, listens and waits in
&gt; accept on sctp sockets, and then randomly kills some of them (no
&gt; need for an actual client in this case to hit this). Then, again,
&gt; allocating, binding, etc, and then killing child processes.
&gt; 
&gt; The problem that might be happening here is that cryptomgr requests
&gt; the module to probe/load through cryptomgr_schedule_probe(), but
&gt; before the thread handler cryptomgr_probe() returns, we return from
&gt; the wait_for_completion_interruptible() function and probably already
&gt; have cleared up larval, thus we run into a NULL pointer dereference
&gt; when in cryptomgr_probe() complete_all() is being called.
&gt; 
&gt; If we wait with wait_for_completion() instead, this panic will not
&gt; occur anymore. This is valid, because in case a signal is pending,
&gt; cryptomgr_probe() returns from probing anyway with properly calling
&gt; complete_all().

The use of wait_for_completion_interruptible is intentional so that
we don't lock up the thread if a bug causes us to never wake up.

This bug is caused by the helper thread using the larval without
holding a reference count on it.  If the helper thread completes
after the original thread requesting for help has gone away and
destroyed the larval, then we get the crash above.

So the fix is to hold a reference count on the larval.

Cc: &lt;stable@vger.kernel.org&gt; # 3.6+
Reported-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Tested-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: blowfish - disable AVX2 implementation</title>
<updated>2013-06-05T08:33:23+00:00</updated>
<author>
<name>Jussi Kivilinna</name>
<email>jussi.kivilinna@iki.fi</email>
</author>
<published>2013-06-02T16:51:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=edb7c7cdba90c3fb2339e51c15d21982bdf72fdc'/>
<id>edb7c7cdba90c3fb2339e51c15d21982bdf72fdc</id>
<content type='text'>
It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
workload (tested on Core i5-4570) and causes blowfish-avx2 to be significantly
slower than blowfish-amd64. So disable the AVX2 implementation to avoid
performance regressions.

Signed-off-by: Jussi Kivilinna &lt;jussi.kivilinna@iki.fi&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
workload (tested on Core i5-4570) and causes blowfish-avx2 to be significantly
slower than blowfish-amd64. So disable the AVX2 implementation to avoid
performance regressions.

Signed-off-by: Jussi Kivilinna &lt;jussi.kivilinna@iki.fi&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: twofish - disable AVX2 implementation</title>
<updated>2013-06-05T08:33:22+00:00</updated>
<author>
<name>Jussi Kivilinna</name>
<email>jussi.kivilinna@iki.fi</email>
</author>
<published>2013-06-02T16:51:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ef91f21a66826cf1003bb7b3c51ac2de4c28182'/>
<id>3ef91f21a66826cf1003bb7b3c51ac2de4c28182</id>
<content type='text'>
It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
workload (tested on Core i5-4570) and causes twofish_avx2 to be significantly
slower than twofish_avx. So disable the AVX2 implementation to avoid
performance regressions.

Signed-off-by: Jussi Kivilinna &lt;jussi.kivilinna@iki.fi&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
workload (tested on Core i5-4570) and causes twofish_avx2 to be significantly
slower than twofish_avx. So disable the AVX2 implementation to avoid
performance regressions.

Signed-off-by: Jussi Kivilinna &lt;jussi.kivilinna@iki.fi&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux</title>
<updated>2013-05-05T17:58:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-05-05T17:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f8ce1faf55955de62e0a12e330c6d9a526071f65'/>
<id>f8ce1faf55955de62e0a12e330c6d9a526071f65</id>
<content type='text'>
Pull mudule updates from Rusty Russell:
 "We get rid of the general module prefix confusion with a binary config
  option, fix a remove/insert race which Never Happens, and (my
  favorite) handle the case when we have too many modules for a single
  commandline.  Seriously, the kernel is full, please go away!"

* tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  modpost: fix unwanted VMLINUX_SYMBOL_STR expansion
  X.509: Support parse long form of length octets in Authority Key Identifier
  module: don't unlink the module until we've removed all exposure.
  kernel: kallsyms: memory override issue, need check destination buffer length
  MODSIGN: do not send garbage to stderr when enabling modules signature
  modpost: handle huge numbers of modules.
  modpost: add -T option to read module names from file/stdin.
  modpost: minor cleanup.
  genksyms: pass symbol-prefix instead of arch
  module: fix symbol versioning with symbol prefixes
  CONFIG_SYMBOL_PREFIX: cleanup.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull mudule updates from Rusty Russell:
 "We get rid of the general module prefix confusion with a binary config
  option, fix a remove/insert race which Never Happens, and (my
  favorite) handle the case when we have too many modules for a single
  commandline.  Seriously, the kernel is full, please go away!"

* tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  modpost: fix unwanted VMLINUX_SYMBOL_STR expansion
  X.509: Support parse long form of length octets in Authority Key Identifier
  module: don't unlink the module until we've removed all exposure.
  kernel: kallsyms: memory override issue, need check destination buffer length
  MODSIGN: do not send garbage to stderr when enabling modules signature
  modpost: handle huge numbers of modules.
  modpost: add -T option to read module names from file/stdin.
  modpost: minor cleanup.
  genksyms: pass symbol-prefix instead of arch
  module: fix symbol versioning with symbol prefixes
  CONFIG_SYMBOL_PREFIX: cleanup.
</pre>
</div>
</content>
</entry>
</feed>
