<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/crypto/ahash.c, branch linux-4.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.14.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.14.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-03-23T13:35:18Z</updated>
<entry>
<title>crypto: hash - set CRYPTO_TFM_NEED_KEY if -&gt;setkey() fails</title>
<updated>2019-03-23T13:35:18Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2019-01-07T02:47:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a48ec7084ed70f0d1877ded8bc2b2844a5beb29'/>
<id>urn:sha1:3a48ec7084ed70f0d1877ded8bc2b2844a5beb29</id>
<content type='text'>
commit ba7d7433a0e998c902132bd47330e355a1eaa894 upstream.

Some algorithms have a -&gt;setkey() method that is not atomic, in the
sense that setting a key can fail after changes were already made to the
tfm context.  In this case, if a key was already set the tfm can end up
in a state that corresponds to neither the old key nor the new key.

It's not feasible to make all -&gt;setkey() methods atomic, especially ones
that have to key multiple sub-tfms.  Therefore, make the crypto API set
CRYPTO_TFM_NEED_KEY if -&gt;setkey() fails and the algorithm requires a
key, to prevent the tfm from being used until a new key is set.

Note: we can't set CRYPTO_TFM_NEED_KEY for OPTIONAL_KEY algorithms, so
-&gt;setkey() for those must nevertheless be atomic.  That's fine for now
since only the crc32 and crc32c algorithms set OPTIONAL_KEY, and it's
not intended that OPTIONAL_KEY be used much.

[Cc stable mainly because when introducing the NEED_KEY flag I changed
 AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
 previously didn't have this problem.  So these "incompletely keyed"
 states became theoretically accessible via AF_ALG -- though, the
 opportunities for causing real mischief seem pretty limited.]

Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key")
Cc: stable@vger.kernel.org
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: ahash - fix another early termination in hash walk</title>
<updated>2019-03-23T13:35:10Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2019-02-01T07:51:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=09024fed4e52b7cfef8721584c4d8658f65fa151'/>
<id>urn:sha1:09024fed4e52b7cfef8721584c4d8658f65fa151</id>
<content type='text'>
commit 77568e535af7c4f97eaef1e555bf0af83772456c upstream.

Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and
"michael_mic", fail the improved hash tests because they sometimes
produce the wrong digest.  The bug is that in the case where a
scatterlist element crosses pages, not all the data is actually hashed
because the scatterlist walk terminates too early.  This happens because
the 'nbytes' variable in crypto_hash_walk_done() is assigned the number
of bytes remaining in the page, then later interpreted as the number of
bytes remaining in the scatterlist element.  Fix it.

Fixes: 900a081f6912 ("crypto: ahash - Fix early termination in hash walk")
Cc: stable@vger.kernel.org
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: ahash - Fix early termination in hash walk</title>
<updated>2018-04-08T12:26:31Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2018-03-26T00:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c3657fd0c15f54437fc16cc4b838574970a8fa05'/>
<id>urn:sha1:c3657fd0c15f54437fc16cc4b838574970a8fa05</id>
<content type='text'>
commit 900a081f6912a8985dc15380ec912752cb66025a upstream.

When we have an unaligned SG list entry where there is no leftover
aligned data, the hash walk code will incorrectly return zero as if
the entire SG list has been processed.

This patch fixes it by moving onto the next page instead.

Reported-by: Eli Cooper &lt;elicooper@gmx.com&gt;
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: hash - prevent using keyed hashes without setting key</title>
<updated>2018-02-16T19:23:00Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2018-01-03T19:16:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2f00eb27908895b46e807b632b53824d0844012f'/>
<id>urn:sha1:2f00eb27908895b46e807b632b53824d0844012f</id>
<content type='text'>
commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.

Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding.  Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated using
"hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
via a (potentially exploitable) stack buffer overflow.

A while ago, this problem was solved for AF_ALG by pairing each hash
transform with a 'has_key' bool.  However, there are still other places
in the kernel where userspace can specify an arbitrary hash algorithm by
name, and the kernel uses it as unkeyed hash without checking whether it
is really unkeyed.  Examples of this include:

    - KEYCTL_DH_COMPUTE, via the KDF extension
    - dm-verity
    - dm-crypt, via the ESSIV support
    - dm-integrity, via the "internal hash" mode with no key given
    - drbd (Distributed Replicated Block Device)

This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
privileges to call.

Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
-&gt;crt_flags of each hash transform that indicates whether the transform
still needs to be keyed or not.  Then, make the hash init, import, and
digest functions return -ENOKEY if the key is still needed.

The new flag also replaces the 'has_key' bool which algif_hash was
previously using, thereby simplifying the algif_hash implementation.

Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
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: hash - introduce crypto_hash_alg_has_setkey()</title>
<updated>2018-02-16T19:22:59Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2018-01-03T19:16:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b8b32e2e68f0a3dd67edb34710964dc3e67bdf3b'/>
<id>urn:sha1:b8b32e2e68f0a3dd67edb34710964dc3e67bdf3b</id>
<content type='text'>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.

Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns.  Add it.

Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.

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: hash - add crypto_(un)register_ahashes()</title>
<updated>2017-08-22T06:54:52Z</updated>
<author>
<name>Rabin Vincent</name>
</author>
<published>2017-08-10T12:53:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f7473c524cc4f875dcd9397ec9a6ec039bd08b6'/>
<id>urn:sha1:6f7473c524cc4f875dcd9397ec9a6ec039bd08b6</id>
<content type='text'>
There are already helpers to (un)register multiple normal
and AEAD algos.  Add one for ahashes too.

Signed-off-by: Lars Persson &lt;larper@axis.com&gt;
Signed-off-by: Rabin Vincent &lt;rabinv@axis.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: ahash - Fix EINPROGRESS notification callback</title>
<updated>2017-04-10T11:09:18Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2017-04-10T09:27:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ef0579b64e93188710d48667cb5e014926af9f1b'/>
<id>urn:sha1:ef0579b64e93188710d48667cb5e014926af9f1b</id>
<content type='text'>
The ahash API modifies the request's callback function in order
to clean up after itself in some corner cases (unaligned final
and missing finup).

When the request is complete ahash will restore the original
callback and everything is fine.  However, when the request gets
an EBUSY on a full queue, an EINPROGRESS callback is made while
the request is still ongoing.

In this case the ahash API will incorrectly call its own callback.

This patch fixes the problem by creating a temporary request
object on the stack which is used to relay EINPROGRESS back to
the original completion function.

This patch also adds code to preserve the original flags value.

Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: Replaced gcc specific attributes with macros from compiler.h</title>
<updated>2017-01-12T16:24:39Z</updated>
<author>
<name>Gideon Israel Dsouza</name>
</author>
<published>2016-12-31T15:56:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d8c34b949d8c9f61e099e00f22770e400adf2b76'/>
<id>urn:sha1:d8c34b949d8c9f61e099e00f22770e400adf2b76</id>
<content type='text'>
Continuing from this commit: 52f5684c8e1e
("kernel: use macros from compiler.h instead of __attribute__((...))")

I submitted 4 total patches. They are part of task I've taken up to
increase compiler portability in the kernel. I've cleaned up the
subsystems under /kernel /mm /block and /security, this patch targets
/crypto.

There is &lt;linux/compiler.h&gt; which provides macros for various gcc specific
constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
instances of gcc specific attributes with the right macros for the crypto
subsystem.

I had to make one additional change into compiler-gcc.h for the case when
one wants to use this: __attribute__((aligned) and not specify an alignment
factor. From the gcc docs, this will result in the largest alignment for
that data type on the target machine so I've named the macro
__aligned_largest. Please advise if another name is more appropriate.

Signed-off-by: Gideon Israel Dsouza &lt;gidisrael@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: ahash - Add padding in crypto_ahash_extsize</title>
<updated>2016-07-01T15:45:03Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2016-06-29T10:03:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2495cf25f60e085b35beb9b215235dfe1ca4f200'/>
<id>urn:sha1:2495cf25f60e085b35beb9b215235dfe1ca4f200</id>
<content type='text'>
The function crypto_ahash_extsize did not include padding when
computing the tfm context size.  This patch fixes this by using
the generic crypto_alg_extsize helper.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: hash - Fix page length clamping in hash walk</title>
<updated>2016-05-05T06:27:04Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2016-05-04T09:52:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=13f4bb78cf6a312bbdec367ba3da044b09bf0e29'/>
<id>urn:sha1:13f4bb78cf6a312bbdec367ba3da044b09bf0e29</id>
<content type='text'>
The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
walk-&gt;pg and walk-&gt;offset when this happens.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
