<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/crypto, branch v4.4.228</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.228</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.228'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-05-20T06:11:51Z</updated>
<entry>
<title>gcc-10: avoid shadowing standard library 'free()' in crypto</title>
<updated>2020-05-20T06:11:51Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-05-09T22:58:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5a1dbe631797181cee70c6333bfd77a86c611c19'/>
<id>urn:sha1:5a1dbe631797181cee70c6333bfd77a86c611c19</id>
<content type='text'>
commit 1a263ae60b04de959d9ce9caea4889385eefcc7b upstream.

gcc-10 has started warning about conflicting types for a few new
built-in functions, particularly 'free()'.

This results in warnings like:

   crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]

because the crypto layer had its local freeing functions called
'free()'.

Gcc-10 is in the wrong here, since that function is marked 'static', and
thus there is no chance of confusion with any standard library function
namespace.

But the simplest thing to do is to just use a different name here, and
avoid this gcc mis-feature.

[ Side note: gcc knowing about 'free()' is in itself not the
  mis-feature: the semantics of 'free()' are special enough that a
  compiler can validly do special things when seeing it.

  So the mis-feature here is that gcc thinks that 'free()' is some
  restricted name, and you can't shadow it as a local static function.

  Making the special 'free()' semantics be a function attribute rather
  than tied to the name would be the much better model ]

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>crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async</title>
<updated>2020-03-11T06:51:19Z</updated>
<author>
<name>yangerkun</name>
<email>yangerkun@huawei.com</email>
</author>
<published>2020-03-05T08:57:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a43f5b15cbef47632b5e26ef78e357ff775d7c68'/>
<id>urn:sha1:a43f5b15cbef47632b5e26ef78e357ff775d7c68</id>
<content type='text'>
Nowdays, we trigger a oops:
...
kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] SMP KASAN
...
Call Trace:
 [&lt;ffffffff81a26fb1&gt;] skcipher_recvmsg_async+0x3f1/0x1400 x86/../crypto/algif_skcipher.c:543
 [&lt;ffffffff81a28053&gt;] skcipher_recvmsg+0x93/0x7f0 x86/../crypto/algif_skcipher.c:723
 [&lt;ffffffff823e43a4&gt;] sock_recvmsg_nosec x86/../net/socket.c:702 [inline]
 [&lt;ffffffff823e43a4&gt;] sock_recvmsg x86/../net/socket.c:710 [inline]
 [&lt;ffffffff823e43a4&gt;] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705
 [&lt;ffffffff823e464b&gt;] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787
 [&lt;ffffffff817f479b&gt;] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520
 [&lt;ffffffff817f57c9&gt;] io_submit_one x86/../fs/aio.c:1630 [inline]
 [&lt;ffffffff817f57c9&gt;] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688
 [&lt;ffffffff817f902d&gt;] SYSC_io_submit x86/../fs/aio.c:1713 [inline]
 [&lt;ffffffff817f902d&gt;] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710
 [&lt;ffffffff828b33c3&gt;] tracesys_phase2+0x90/0x95

In skcipher_recvmsg_async, we use '!sreq-&gt;tsg' to determine does we
calloc fail. However, kcalloc may return ZERO_SIZE_PTR, and with this,
the latter sg_init_table will trigger the bug. Fix it be use ZERO_OF_NULL_PTR.

This function was introduced with ' commit a596999b7ddf ("crypto:
algif - change algif_skcipher to be asynchronous")', and has been removed
with 'commit e870456d8e7c ("crypto: algif_skcipher - overhaul memory
management")'.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: yangerkun &lt;yangerkun@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>crypto: api - Fix race condition in crypto_spawn_alg</title>
<updated>2020-02-14T21:29:56Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2019-12-07T14:15:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=aa2862a427df19ada9b182cc86bedd74cdd83815'/>
<id>urn:sha1:aa2862a427df19ada9b182cc86bedd74cdd83815</id>
<content type='text'>
commit 73669cc556462f4e50376538d77ee312142e8a8a upstream.

The function crypto_spawn_alg is racy because it drops the lock
before shooting the dying algorithm.  The algorithm could disappear
altogether before we shoot it.

This patch fixes it by moving the shooting into the locked section.

Fixes: 6bfd48096ff8 ("[CRYPTO] api: Added spawns")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: pcrypt - Do not clear MAY_SLEEP flag in original request</title>
<updated>2020-02-14T21:29:56Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2019-11-29T08:40:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=87bfd2f124d8cd3191dc3810b040c3a931f31399'/>
<id>urn:sha1:87bfd2f124d8cd3191dc3810b040c3a931f31399</id>
<content type='text'>
commit e8d998264bffade3cfe0536559f712ab9058d654 upstream.

We should not be modifying the original request's MAY_SLEEP flag
upon completion.  It makes no sense to do so anyway.

Reported-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Fixes: 5068c7a883d1 ("crypto: pcrypt - Add pcrypt crypto...")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Tested-by: Eric Biggers &lt;ebiggers@kernel.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>
</entry>
<entry>
<title>crypto: api - Check spawn-&gt;alg under lock in crypto_drop_spawn</title>
<updated>2020-02-14T21:29:56Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2019-12-06T05:55:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=63e05d4bee9efe087f4ad5f06a99d3a4f0739777'/>
<id>urn:sha1:63e05d4bee9efe087f4ad5f06a99d3a4f0739777</id>
<content type='text'>
commit 7db3b61b6bba4310f454588c2ca6faf2958ad79f upstream.

We need to check whether spawn-&gt;alg is NULL under lock as otherwise
the algorithm could be removed from under us after we have checked
it and found it to be non-NULL.  This could cause us to remove the
spawn from a non-existent list.

Fixes: 7ede5a5ba55a ("crypto: api - Fix crypto_drop_spawn crash...")
Cc: &lt;stable@vger.kernel.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>
</entry>
<entry>
<title>crypto: pcrypt - Fix user-after-free on module unload</title>
<updated>2020-02-05T13:03:38Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2019-11-19T09:41:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a44a554303213de606340c19d4903472026b85f3'/>
<id>urn:sha1:a44a554303213de606340c19d4903472026b85f3</id>
<content type='text'>
[ Upstream commit 07bfd9bdf568a38d9440c607b72342036011f727 ]

On module unload of pcrypt we must unregister the crypto algorithms
first and then tear down the padata structure.  As otherwise the
crypto algorithms are still alive and can be used while the padata
structure is being freed.

Fixes: 5068c7a883d1 ("crypto: pcrypt - Add pcrypt crypto...")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: af_alg - Use bh_lock_sock in sk_destruct</title>
<updated>2020-02-05T13:03:37Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2019-12-05T05:45:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f6b09fe8365955e5b5343464ca88134471d6184e'/>
<id>urn:sha1:f6b09fe8365955e5b5343464ca88134471d6184e</id>
<content type='text'>
commit 37f96694cf73ba116993a9d2d99ad6a75fa7fdb0 upstream.

As af_alg_release_parent may be called from BH context (most notably
due to an async request that only completes after socket closure,
or as reported here because of an RCU-delayed sk_destruct call), we
must use bh_lock_sock instead of lock_sock.

Reported-by: syzbot+c2f1558d49e25cc36e5e@syzkaller.appspotmail.com
Reported-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Fixes: c840ac6af3f8 ("crypto: af_alg - Disallow bind/setkey/...")
Cc: &lt;stable@vger.kernel.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>
</entry>
<entry>
<title>crypto: tgr192 - fix unaligned memory access</title>
<updated>2020-01-29T09:21:38Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-01-10T20:17:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e6d0ba386d3a010c6385ee14c6a97d0f338422dc'/>
<id>urn:sha1:e6d0ba386d3a010c6385ee14c6a97d0f338422dc</id>
<content type='text'>
[ Upstream commit f990f7fb58ac8ac9a43316f09a48cff1a49dda42 ]

Fix an unaligned memory access in tgr192_transform() by using the
unaligned access helpers.

Fixes: 06ace7a9bafe ("[CRYPTO] Use standard byte order macros wherever possible")
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pcrypt: use format specifier in kobject_add</title>
<updated>2020-01-29T09:21:36Z</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2018-10-27T14:49:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=14bddd38a509551ffb9b6479430aefbebe7602f5'/>
<id>urn:sha1:14bddd38a509551ffb9b6479430aefbebe7602f5</id>
<content type='text'>
[ Upstream commit b1e3874c75ab15288f573b3532e507c37e8e7656 ]

Passing string 'name' as the format specifier is potentially hazardous
because name could (although very unlikely to) have a format specifier
embedded in it causing issues when parsing the non-existent arguments
to these.  Follow best practice by using the "%s" format string for
the string 'name'.

Cleans up clang warning:
crypto/pcrypt.c:397:40: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]

Fixes: a3fb1e330dd2 ("pcrypt: Added sysfs interface to pcrypt")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: user - fix memory leak in crypto_report</title>
<updated>2019-12-21T09:34:58Z</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-10-04T19:29:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5020350fb0012816ee35f7b744ded18bb75ecc1e'/>
<id>urn:sha1:5020350fb0012816ee35f7b744ded18bb75ecc1e</id>
<content type='text'>
commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream.

In crypto_report, a new skb is created via nlmsg_new(). This skb should
be released if crypto_report_alg() fails.

Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&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>
</entry>
</feed>
