<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/crypto, branch v4.8.16</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.8.16</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.8.16'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-12-15T16:50:36+00:00</updated>
<entry>
<title>crypto: rsa - Add Makefile dependencies to fix parallel builds</title>
<updated>2016-12-15T16:50:36+00:00</updated>
<author>
<name>David Michael</name>
<email>david.michael@coreos.com</email>
</author>
<published>2016-11-29T19:15:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=762c9bb16fced1d84b446fa7b73fee0f977b400d'/>
<id>urn:sha1:762c9bb16fced1d84b446fa7b73fee0f977b400d</id>
<content type='text'>
commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream.

Both asn1 headers are included by rsa_helper.c, so rsa_helper.o
should explicitly depend on them.

Signed-off-by: David Michael &lt;david.michael@coreos.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Tuomas Tynkkynen &lt;tuomas@tuxera.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: mcryptd - Check mcryptd algorithm compatibility</title>
<updated>2016-12-15T16:50:35+00:00</updated>
<author>
<name>tim</name>
<email>tim.c.chen@linux.intel.com</email>
</author>
<published>2016-12-05T19:46:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfef274e4dae76cdee275b5985c85758e346e825'/>
<id>urn:sha1:bfef274e4dae76cdee275b5985c85758e346e825</id>
<content type='text'>
commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream.

Algorithms not compatible with mcryptd could be spawned by mcryptd
with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name
construct.  This causes mcryptd to crash the kernel if an arbitrary
"alg" is incompatible and not intended to be used with mcryptd.  It is
an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally.
But such algorithms must be used internally and not be exposed.

We added a check to enforce that only internal algorithms are allowed
with mcryptd at the time mcryptd is spawning an algorithm.

Link: http://marc.info/?l=linux-crypto-vger&amp;m=148063683310477&amp;w=2
Reported-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tim Chen &lt;tim.c.chen@linux.intel.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>
<entry>
<title>X.509: Fix double free in x509_cert_parse() [ver #3]</title>
<updated>2016-12-02T08:10:32+00:00</updated>
<author>
<name>Andrey Ryabinin</name>
<email>aryabinin@virtuozzo.com</email>
</author>
<published>2016-11-24T13:23:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9030deb21f29d96160cf376355ce47ac98fb6e45'/>
<id>urn:sha1:9030deb21f29d96160cf376355ce47ac98fb6e45</id>
<content type='text'>
commit 2b95fda2c4fcb6d6625963f889247538f247fce0 upstream.

We shouldn't free cert-&gt;pub-&gt;key in x509_cert_parse() because
x509_free_certificate() also does this:
	BUG: Double free or freeing an invalid pointer
	...
	Call Trace:
	 [&lt;ffffffff81896c20&gt;] dump_stack+0x63/0x83
	 [&lt;ffffffff81356571&gt;] kasan_object_err+0x21/0x70
	 [&lt;ffffffff81356ed9&gt;] kasan_report_double_free+0x49/0x60
	 [&lt;ffffffff813561ad&gt;] kasan_slab_free+0x9d/0xc0
	 [&lt;ffffffff81350b7a&gt;] kfree+0x8a/0x1a0
	 [&lt;ffffffff81844fbf&gt;] public_key_free+0x1f/0x30
	 [&lt;ffffffff818455d4&gt;] x509_free_certificate+0x24/0x90
	 [&lt;ffffffff818460bc&gt;] x509_cert_parse+0x2bc/0x300
	 [&lt;ffffffff81846cae&gt;] x509_key_preparse+0x3e/0x330
	 [&lt;ffffffff818444cf&gt;] asymmetric_key_preparse+0x6f/0x100
	 [&lt;ffffffff8178bec0&gt;] key_create_or_update+0x260/0x5f0
	 [&lt;ffffffff8178e6d9&gt;] SyS_add_key+0x199/0x2a0
	 [&lt;ffffffff821d823b&gt;] entry_SYSCALL_64_fastpath+0x1e/0xad
	Object at ffff880110bd1900, in cache kmalloc-512 size: 512
	....
	Freed:
	PID = 2579
	[&lt;ffffffff8104283b&gt;] save_stack_trace+0x1b/0x20
	[&lt;ffffffff813558f6&gt;] save_stack+0x46/0xd0
	[&lt;ffffffff81356183&gt;] kasan_slab_free+0x73/0xc0
	[&lt;ffffffff81350b7a&gt;] kfree+0x8a/0x1a0
	[&lt;ffffffff818460a3&gt;] x509_cert_parse+0x2a3/0x300
	[&lt;ffffffff81846cae&gt;] x509_key_preparse+0x3e/0x330
	[&lt;ffffffff818444cf&gt;] asymmetric_key_preparse+0x6f/0x100
	[&lt;ffffffff8178bec0&gt;] key_create_or_update+0x260/0x5f0
	[&lt;ffffffff8178e6d9&gt;] SyS_add_key+0x199/0x2a0
	[&lt;ffffffff821d823b&gt;] entry_SYSCALL_64_fastpath+0x1e/0xad

Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: gcm - Fix IV buffer size in crypto_gcm_setkey</title>
<updated>2016-10-31T11:02:09+00:00</updated>
<author>
<name>Ondrej Mosnáček</name>
<email>omosnacek@gmail.com</email>
</author>
<published>2016-09-23T08:47:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c1ea6c6313b6b7bb20e3b184f9a7c99209e6220'/>
<id>urn:sha1:9c1ea6c6313b6b7bb20e3b184f9a7c99209e6220</id>
<content type='text'>
commit 50d2e6dc1f83db0563c7d6603967bf9585ce934b upstream.

The cipher block size for GCM is 16 bytes, and thus the CTR transform
used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
the code currently reserves only 8 bytes for the IV, causing
an out-of-bounds access in the CTR transform. This patch fixes
the issue by setting the size of the IV buffer to 16 bytes.

Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
Signed-off-by: Ondrej Mosnacek &lt;omosnacek@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>
<entry>
<title>crypto: ghash-generic - move common definitions to a new header file</title>
<updated>2016-10-22T10:40:25+00:00</updated>
<author>
<name>Marcelo Cerri</name>
<email>marcelo.cerri@canonical.com</email>
</author>
<published>2016-09-28T16:42:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e15e0b849d93b6afdad89a0894e985d63b69212e'/>
<id>urn:sha1:e15e0b849d93b6afdad89a0894e985d63b69212e</id>
<content type='text'>
commit a397ba829d7f8aff4c90af3704573a28ccd61a59 upstream.

Move common values and types used by ghash-generic to a new header file
so drivers can directly use ghash-generic as a fallback implementation.

Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Signed-off-by: Marcelo Cerri &lt;marcelo.cerri@canonical.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>
<entry>
<title>async_pq_val: fix DMA memory leak</title>
<updated>2016-10-22T10:40:24+00:00</updated>
<author>
<name>Justin Maggard</name>
<email>jmaggard10@gmail.com</email>
</author>
<published>2016-10-04T20:17:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dfca701b1084eb3a5ab806088ff5008039f71ce7'/>
<id>urn:sha1:dfca701b1084eb3a5ab806088ff5008039f71ce7</id>
<content type='text'>
commit c84750906b4818d4929fbf73a4ae6c113b94f52b upstream.

Add missing dmaengine_unmap_put(), so we don't OOM during RAID6 sync.

Fixes: 1786b943dad0 ("async_pq_val: convert to dmaengine_unmap_data")
Signed-off-by: Justin Maggard &lt;jmaggard@netgear.com&gt;
Reviewed-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: rsa-pkcs1pad - Handle leading zero for decryption</title>
<updated>2016-09-22T09:42:08+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-09-22T09:04:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0cf43f509f72128196e23f5ade7e512a72152cc6'/>
<id>urn:sha1:0cf43f509f72128196e23f5ade7e512a72152cc6</id>
<content type='text'>
As the software RSA implementation now produces fixed-length
output, we need to eliminate leading zeros in the calling code
instead.

This patch does just that for pkcs1pad decryption while signature
verification was fixed in an earlier patch.

Fixes: 9b45b7bba3d2 ("crypto: rsa - Generate fixed-length output")
Reported-by: Mat Martineau &lt;mathew.j.martineau@linux.intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: skcipher - Fix blkcipher walk OOM crash</title>
<updated>2016-09-13T10:44:57+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-09-13T06:43:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=acdb04d0b36769b3e05990c488dc74d8b7ac8060'/>
<id>urn:sha1:acdb04d0b36769b3e05990c488dc74d8b7ac8060</id>
<content type='text'>
When we need to allocate a temporary blkcipher_walk_next and it
fails, the code is supposed to take the slow path of processing
the data block by block.  However, due to an unrelated change
we instead end up dereferencing the NULL pointer.

This patch fixes it by moving the unrelated bsize setting out
of the way so that we enter the slow path as inteded.

Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
Cc: stable@vger.kernel.org
Reported-by: xiakaixu &lt;xiakaixu@huawei.com&gt;
Reported-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Tested-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
</content>
</entry>
<entry>
<title>crypto: echainiv - Replace chaining with multiplication</title>
<updated>2016-09-13T10:44:57+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-09-07T10:42:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=53a5d5ddccf849dbc27a8c1bba0b43c3a45fb792'/>
<id>urn:sha1:53a5d5ddccf849dbc27a8c1bba0b43c3a45fb792</id>
<content type='text'>
The current implementation uses a global per-cpu array to store
data which are used to derive the next IV.  This is insecure as
the attacker may change the stored data.

This patch removes all traces of chaining and replaces it with
multiplication of the salt and the sequence number.

Fixes: a10f554fa7e0 ("crypto: echainiv - Add encrypted chain IV...")
Cc: stable@vger.kernel.org
Reported-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: cryptd - initialize child shash_desc on import</title>
<updated>2016-09-07T13:04:36+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2016-09-01T13:25:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0bd2223594a4dcddc1e34b15774a3a4776f7749e'/>
<id>urn:sha1:0bd2223594a4dcddc1e34b15774a3a4776f7749e</id>
<content type='text'>
When calling .import() on a cryptd ahash_request, the structure members
that describe the child transform in the shash_desc need to be initialized
like they are when calling .init()

Cc: stable@vger.kernel.org
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
