<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/crypto, branch v5.4.244</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.244</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.244'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-05-17T09:35:42Z</updated>
<entry>
<title>crypto: drbg - Only fail when jent is unavailable in FIPS mode</title>
<updated>2023-05-17T09:35:42Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-03-28T03:35:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=01993768b3e771c93a4e151628211ab4c7fd4cff'/>
<id>urn:sha1:01993768b3e771c93a4e151628211ab4c7fd4cff</id>
<content type='text'>
[ Upstream commit 686cd976b6ddedeeb1a1fb09ba53a891d3cc9a03 ]

When jent initialisation fails for any reason other than ENOENT,
the entire drbg fails to initialise, even when we're not in FIPS
mode.  This is wrong because we can still use the kernel RNG when
we're not in FIPS mode.

Change it so that it only fails when we are in FIPS mode.

Fixes: 57225e679788 ("crypto: drbg - Use callback API for random readiness")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Reviewed-by: Stephan Mueller &lt;smueller@chronox.de&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: drbg - make drbg_prepare_hrng() handle jent instantiation errors</title>
<updated>2023-05-17T09:35:42Z</updated>
<author>
<name>Nicolai Stange</name>
<email>nstange@suse.de</email>
</author>
<published>2021-11-15T14:18:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b21c7e28e80128d1f66ff080fdb089235704d153'/>
<id>urn:sha1:b21c7e28e80128d1f66ff080fdb089235704d153</id>
<content type='text'>
[ Upstream commit 559edd47cce4cc407d606b4d7f376822816fd4b8 ]

Now that drbg_prepare_hrng() doesn't do anything but to instantiate a
jitterentropy crypto_rng instance, it looks a little odd to have the
related error handling at its only caller, drbg_instantiate().

Move the handling of jitterentropy allocation failures from
drbg_instantiate() close to the allocation itself in drbg_prepare_hrng().

There is no change in behaviour.

Signed-off-by: Nicolai Stange &lt;nstange@suse.de&gt;
Reviewed-by: Stephan Müller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: 686cd976b6dd ("crypto: drbg - Only fail when jent is unavailable in FIPS mode")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>asymmetric_keys: log on fatal failures in PE/pkcs7</title>
<updated>2023-04-20T10:07:36Z</updated>
<author>
<name>Robbie Harwood</name>
<email>rharwood@redhat.com</email>
</author>
<published>2023-02-20T17:12:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a652c30fa2ba5ac18a09e9697dafff29c11ff9cd'/>
<id>urn:sha1:a652c30fa2ba5ac18a09e9697dafff29c11ff9cd</id>
<content type='text'>
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]

These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place.  Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
appropriate dyndbg parameters (since lockdown blocks debugfs).

Accordingly, upgrade all pr_debug() before fatal error into pr_warn().

Signed-off-by: Robbie Harwood &lt;rharwood@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
cc: Eric Biederman &lt;ebiederm@xmission.com&gt;
cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
cc: kexec@lists.infradead.org
Link: https://lore.kernel.org/r/20230220171254.592347-3-rharwood@redhat.com/ # v2
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>verify_pefile: relax wrapper length check</title>
<updated>2023-04-20T10:07:36Z</updated>
<author>
<name>Robbie Harwood</name>
<email>rharwood@redhat.com</email>
</author>
<published>2023-02-20T17:12:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5809dbacc431df22aaa906a1b340f84d69bb6767'/>
<id>urn:sha1:5809dbacc431df22aaa906a1b340f84d69bb6767</id>
<content type='text'>
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]

The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal.  Therefore, the field is not required
to be an 8-byte multiple in the first place.

Accordingly, pesign has not performed this alignment since version
0.110.  This causes kexec failure on pesign'd binaries with "PEFILE:
Signature wrapper len wrong".  Update the comment and relax the check.

Signed-off-by: Robbie Harwood &lt;rharwood@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
cc: Eric Biederman &lt;ebiederm@xmission.com&gt;
cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
cc: kexec@lists.infradead.org
Link: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-attribute-certificate-table-image-only
Link: https://github.com/rhboot/pesign
Link: https://lore.kernel.org/r/20230220171254.592347-2-rharwood@redhat.com/ # v2
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: rsa-pkcs1pad - Use akcipher_request_complete</title>
<updated>2023-03-11T15:43:41Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-31T08:02:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c4d8c23efed675ffad3e61839fd0a518076ff24b'/>
<id>urn:sha1:c4d8c23efed675ffad3e61839fd0a518076ff24b</id>
<content type='text'>
[ Upstream commit 564cabc0ca0bdfa8f0fc1ae74b24d0a7554522c5 ]

Use the akcipher_request_complete helper instead of calling the
completion function directly.  In fact the previous code was buggy
in that EINPROGRESS was never passed back to the original caller.

Fixes: 3d5b1ecdea6f ("crypto: rsa - RSA padding algorithm")
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: seqiv - Handle EBUSY correctly</title>
<updated>2023-03-11T15:43:39Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-13T10:27:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=63551e4b7cbcd9914258827699eb2cb6ed6e4a16'/>
<id>urn:sha1:63551e4b7cbcd9914258827699eb2cb6ed6e4a16</id>
<content type='text'>
[ Upstream commit 32e62025e5e52fbe4812ef044759de7010b15dbc ]

As it is seqiv only handles the special return value of EINPROGERSS,
which means that in all other cases it will free data related to the
request.

However, as the caller of seqiv may specify MAY_BACKLOG, we also need
to expect EBUSY and treat it in the same way.  Otherwise backlogged
requests will trigger a use-after-free.

Fixes: 0a270321dbf9 ("[CRYPTO] seqiv: Add Sequence Number IV Generator")
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: essiv - Handle EBUSY correctly</title>
<updated>2023-03-11T15:43:39Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-13T10:24:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c61e7d182ee3f3f5ecf18a2964e303d49c539b52'/>
<id>urn:sha1:c61e7d182ee3f3f5ecf18a2964e303d49c539b52</id>
<content type='text'>
[ Upstream commit b5a772adf45a32c68bef28e60621f12617161556 ]

As it is essiv only handles the special return value of EINPROGERSS,
which means that in all other cases it will free data related to the
request.

However, as the caller of essiv may specify MAY_BACKLOG, we also need
to expect EBUSY and treat it in the same way.  Otherwise backlogged
requests will trigger a use-after-free.

Fixes: be1eb7f78aa8 ("crypto: essiv - create wrapper template...")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Acked-by: Ard Biesheuvel &lt;ardb@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: essiv - remove redundant null pointer check before kfree</title>
<updated>2023-03-11T15:43:39Z</updated>
<author>
<name>Chen Wandun</name>
<email>chenwandun@huawei.com</email>
</author>
<published>2019-11-16T06:51:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bfef5e3e73757025c72ccd5d8424cc92424151ab'/>
<id>urn:sha1:bfef5e3e73757025c72ccd5d8424cc92424151ab</id>
<content type='text'>
[ Upstream commit e18036da5c23530994faf7243b592e581f1efed2 ]

kfree has taken null pointer check into account. so it is safe to
remove the unnecessary check.

Signed-off-by: Chen Wandun &lt;chenwandun@huawei.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: b5a772adf45a ("crypto: essiv - Handle EBUSY correctly")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: tcrypt - Fix multibuffer skcipher speed test mem leak</title>
<updated>2023-01-18T10:41:19Z</updated>
<author>
<name>Zhang Yiqun</name>
<email>zhangyiqun@phytium.com.cn</email>
</author>
<published>2022-11-16T09:24:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=89e3f7324a383d7e9857d3962b5d721f5a20f192'/>
<id>urn:sha1:89e3f7324a383d7e9857d3962b5d721f5a20f192</id>
<content type='text'>
[ Upstream commit 1aa33fc8d4032227253ceb736f47c52b859d9683 ]

In the past, the data for mb-skcipher test has been allocated
twice, that means the first allcated memory area is without
free, which may cause a potential memory leakage. So this
patch is to remove one allocation to fix this error.

Fixes: e161c5930c15 ("crypto: tcrypt - add multibuf skcipher...")
Signed-off-by: Zhang Yiqun &lt;zhangyiqun@phytium.com.cn&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: akcipher - default implementation for setting a private key</title>
<updated>2022-10-26T11:22:45Z</updated>
<author>
<name>Ignat Korchagin</name>
<email>ignat@cloudflare.com</email>
</author>
<published>2022-08-31T18:37:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=95c4e20adc3ea00d1594a2a05d9b187ed12ffa8e'/>
<id>urn:sha1:95c4e20adc3ea00d1594a2a05d9b187ed12ffa8e</id>
<content type='text'>
[ Upstream commit bc155c6c188c2f0c5749993b1405673d25a80389 ]

Changes from v1:
  * removed the default implementation from set_pub_key: it is assumed that
    an implementation must always have this callback defined as there are
    no use case for an algorithm, which doesn't need a public key

Many akcipher implementations (like ECDSA) support only signature
verifications, so they don't have all callbacks defined.

Commit 78a0324f4a53 ("crypto: akcipher - default implementations for
request callbacks") introduced default callbacks for sign/verify
operations, which just return an error code.

However, these are not enough, because before calling sign the caller would
likely call set_priv_key first on the instantiated transform (as the
in-kernel testmgr does). This function does not have a default stub, so the
kernel crashes, when trying to set a private key on an akcipher, which
doesn't support signature generation.

I've noticed this, when trying to add a KAT vector for ECDSA signature to
the testmgr.

With this patch the testmgr returns an error in dmesg (as it should)
instead of crashing the kernel NULL ptr dereference.

Fixes: 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks")
Signed-off-by: Ignat Korchagin &lt;ignat@cloudflare.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>
</feed>
