<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-obmc-linux/crypto, branch v4.18.19</title>
<subtitle>Talos™ II Linux sources for OpenBMC</subtitle>
<id>https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v4.18.19</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v4.18.19'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/'/>
<updated>2018-11-13T19:12:42+00:00</updated>
<entry>
<title>crypto: speck - remove Speck</title>
<updated>2018-11-13T19:12:42+00:00</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2018-08-07T06:22:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=2016e63b769222b66b9de83edf345348c0d2f2d1'/>
<id>urn:sha1:2016e63b769222b66b9de83edf345348c0d2f2d1</id>
<content type='text'>
commit 578bdaabd015b9b164842c3e8ace9802f38e7ecc upstream.

These are unused, undesired, and have never actually been used by
anybody. The original authors of this code have changed their mind about
its inclusion. While originally proposed for disk encryption on low-end
devices, the idea was discarded [1] in favor of something else before
that could really get going. Therefore, this patch removes Speck.

[1] https://marc.info/?l=linux-crypto-vger&amp;m=153359499015659

Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Acked-by: Eric Biggers &lt;ebiggers@google.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.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: aegis/generic - fix for big endian systems</title>
<updated>2018-11-13T19:12:42+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2018-10-01T08:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d4c47d9cf347ee13a2fb799dd8900caac586d38d'/>
<id>urn:sha1:d4c47d9cf347ee13a2fb799dd8900caac586d38d</id>
<content type='text'>
commit 4a34e3c2f2f48f47213702a84a123af0fe21ad60 upstream.

Use the correct __le32 annotation and accessors to perform the
single round of AES encryption performed inside the AEGIS transform.
Otherwise, tcrypt reports:

  alg: aead: Test 1 failed on encryption for aegis128-generic
  00000000: 6c 25 25 4a 3c 10 1d 27 2b c1 d4 84 9a ef 7f 6e
  alg: aead: Test 1 failed on encryption for aegis128l-generic
  00000000: cd c6 e3 b8 a0 70 9d 8e c2 4f 6f fe 71 42 df 28
  alg: aead: Test 1 failed on encryption for aegis256-generic
  00000000: aa ed 07 b1 96 1d e9 e6 f2 ed b5 8e 1c 5f dc 1c

Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
Cc: &lt;stable@vger.kernel.org&gt; # v4.18+
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Reviewed-by: Ondrej Mosnacek &lt;omosnace@redhat.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: morus/generic - fix for big endian systems</title>
<updated>2018-11-13T19:12:42+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2018-10-01T08:36:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=805fd900bda2b7e7d147aed506e892e67b6f0aac'/>
<id>urn:sha1:805fd900bda2b7e7d147aed506e892e67b6f0aac</id>
<content type='text'>
commit 5a8dedfa3276e88c5865f265195d63d72aec3e72 upstream.

Omit the endian swabbing when folding the lengths of the assoc and
crypt input buffers into the state to finalize the tag. This is not
necessary given that the memory representation of the state is in
machine native endianness already.

This fixes an error reported by tcrypt running on a big endian system:

  alg: aead: Test 2 failed on encryption for morus640-generic
  00000000: a8 30 ef fb e6 26 eb 23 b0 87 dd 98 57 f3 e1 4b
  00000010: 21
  alg: aead: Test 2 failed on encryption for morus1280-generic
  00000000: 88 19 1b fb 1c 29 49 0e ee 82 2f cb 97 a6 a5 ee
  00000010: 5f

Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations")
Cc: &lt;stable@vger.kernel.org&gt; # v4.18+
Reviewed-by: Ondrej Mosnacek &lt;omosnace@redhat.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.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: tcrypt - fix ghash-generic speed test</title>
<updated>2018-11-13T19:12:42+00:00</updated>
<author>
<name>Horia Geantă</name>
<email>horia.geanta@nxp.com</email>
</author>
<published>2018-09-12T13:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=c00600a96550216a4b6a6c77c2c641691d4aa1a6'/>
<id>urn:sha1:c00600a96550216a4b6a6c77c2c641691d4aa1a6</id>
<content type='text'>
commit 331351f89c36bf7d03561a28b6f64fa10a9f6f3a upstream.

ghash is a keyed hash algorithm, thus setkey needs to be called.
Otherwise the following error occurs:
$ modprobe tcrypt mode=318 sec=1
testing speed of async ghash-generic (ghash-generic)
tcrypt: test  0 (   16 byte blocks,   16 bytes per update,   1 updates):
tcrypt: hashing failed ret=-126

Cc: &lt;stable@vger.kernel.org&gt; # 4.6+
Fixes: 0660511c0bee ("crypto: tcrypt - Use ahash")
Tested-by: Franck Lenormand &lt;franck.lenormand@nxp.com&gt;
Signed-off-by: Horia Geantă &lt;horia.geanta@nxp.com&gt;
Acked-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.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: lrw - Fix out-of bounds access on counter overflow</title>
<updated>2018-11-13T19:12:42+00:00</updated>
<author>
<name>Ondrej Mosnacek</name>
<email>omosnace@redhat.com</email>
</author>
<published>2018-09-13T08:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=6aa3369f176858ca4900320bddbd4d5d5722e09b'/>
<id>urn:sha1:6aa3369f176858ca4900320bddbd4d5d5722e09b</id>
<content type='text'>
commit fbe1a850b3b1522e9fc22319ccbbcd2ab05328d2 upstream.

When the LRW block counter overflows, the current implementation returns
128 as the index to the precomputed multiplication table, which has 128
entries. This patch fixes it to return the correct value (127).

Fixes: 64470f1b8510 ("[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow block cipher mode")
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.20+
Reported-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Ondrej Mosnacek &lt;omosnace@redhat.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: skcipher - Fix -Wstringop-truncation warnings</title>
<updated>2018-10-03T23:59:03+00:00</updated>
<author>
<name>Stafford Horne</name>
<email>shorne@gmail.com</email>
</author>
<published>2018-06-25T12:45:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d08aa810ddd189e2e8e84b1a0ce09621dfd35cd1'/>
<id>urn:sha1:d08aa810ddd189e2e8e84b1a0ce09621dfd35cd1</id>
<content type='text'>
[ Upstream commit cefd769fd0192c84d638f66da202459ed8ad63ba ]

As of GCC 9.0.0 the build is reporting warnings like:

    crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
    crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation]
      strncpy(rblkcipher.geniv, alg-&gt;cra_ablkcipher.geniv ?: "&lt;default&gt;",
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       sizeof(rblkcipher.geniv));
       ~~~~~~~~~~~~~~~~~~~~~~~~~

This means the strnycpy might create a non null terminated string.  Fix this by
explicitly performing '\0' termination.

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Cc: Eric Biggers &lt;ebiggers3@gmail.com&gt;
Cc: Nick Desaulniers &lt;nick.desaulniers@gmail.com&gt;
Signed-off-by: Stafford Horne &lt;shorne@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>evm: Don't deadlock if a crypto algorithm is unavailable</title>
<updated>2018-09-26T06:39:36+00:00</updated>
<author>
<name>Matthew Garrett</name>
<email>mjg59@google.com</email>
</author>
<published>2018-06-08T21:57:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=6a69ccd2ec68a39c92643e2c24ef0bbc988af2e4'/>
<id>urn:sha1:6a69ccd2ec68a39c92643e2c24ef0bbc988af2e4</id>
<content type='text'>
[ Upstream commit e2861fa71641c6414831d628a1f4f793b6562580 ]

When EVM attempts to appraise a file signed with a crypto algorithm the
kernel doesn't have support for, it will cause the kernel to trigger a
module load. If the EVM policy includes appraisal of kernel modules this
will in turn call back into EVM - since EVM is holding a lock until the
crypto initialisation is complete, this triggers a deadlock. Add a
CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
in the EVM case in order to fail gracefully with an error message
instead of deadlocking.

Signed-off-by: Matthew Garrett &lt;mjg59@google.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Replace magic for trusting the secondary keyring with #define</title>
<updated>2018-09-09T08:32:30+00:00</updated>
<author>
<name>Yannik Sembritzki</name>
<email>yannik@sembritzki.me</email>
</author>
<published>2018-08-16T13:05:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=54fb49e87c233a5ee7f7b5a29243a0489b5ae9ae'/>
<id>urn:sha1:54fb49e87c233a5ee7f7b5a29243a0489b5ae9ae</id>
<content type='text'>
commit 817aef260037f33ee0f44c17fe341323d3aebd6d upstream.

Replace the use of a magic number that indicates that verify_*_signature()
should use the secondary keyring with a symbol.

Signed-off-by: Yannik Sembritzki &lt;yannik@sembritzki.me&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
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: skcipher - fix crash flushing dcache in error path</title>
<updated>2018-08-17T19:03:49+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2018-07-23T17:54:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=744ff5f0dc609e818e3ece7790ec4eff7fe3e9af'/>
<id>urn:sha1:744ff5f0dc609e818e3ece7790ec4eff7fe3e9af</id>
<content type='text'>
commit 8088d3dd4d7c6933a65aa169393b5d88d8065672 upstream.

scatterwalk_done() is only meant to be called after a nonzero number of
bytes have been processed, since scatterwalk_pagedone() will flush the
dcache of the *previous* page.  But in the error case of
skcipher_walk_done(), e.g. if the input wasn't an integer number of
blocks, scatterwalk_done() was actually called after advancing 0 bytes.
This caused a crash ("BUG: unable to handle kernel paging request")
during '!PageSlab(page)' on architectures like arm and arm64 that define
ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE, provided that the input was
page-aligned as in that case walk-&gt;offset == 0.

Fix it by reorganizing skcipher_walk_done() to skip the
scatterwalk_advance() and scatterwalk_done() if an error has occurred.

This bug was found by syzkaller fuzzing.

Reproducer, assuming ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE:

	#include &lt;linux/if_alg.h&gt;
	#include &lt;sys/socket.h&gt;
	#include &lt;unistd.h&gt;

	int main()
	{
		struct sockaddr_alg addr = {
			.salg_type = "skcipher",
			.salg_name = "cbc(aes-generic)",
		};
		char buffer[4096] __attribute__((aligned(4096))) = { 0 };
		int fd;

		fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
		bind(fd, (void *)&amp;addr, sizeof(addr));
		setsockopt(fd, SOL_ALG, ALG_SET_KEY, buffer, 16);
		fd = accept(fd, NULL, NULL);
		write(fd, buffer, 15);
		read(fd, buffer, 15);
	}

Reported-by: Liu Chao &lt;liuchao741@huawei.com&gt;
Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: skcipher - fix aligning block size in skcipher_copy_iv()</title>
<updated>2018-08-17T19:03:49+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2018-07-23T16:57:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d5cceea6dda72f96fc6b23593bcfbc8821554fd5'/>
<id>urn:sha1:d5cceea6dda72f96fc6b23593bcfbc8821554fd5</id>
<content type='text'>
commit 0567fc9e90b9b1c8dbce8a5468758e6206744d4a upstream.

The ALIGN() macro needs to be passed the alignment, not the alignmask
(which is the alignment minus 1).

Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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