<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/crypto, branch v5.4.250</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.250</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.250'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-06-21T13:44:08Z</updated>
<entry>
<title>KEYS: asymmetric: Copy sig and digest in public_key_verify_signature()</title>
<updated>2023-06-21T13:44:08Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-12-08T09:56:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7f3bb75a0484b5035b02bce36d43c876fda9d6be'/>
<id>urn:sha1:7f3bb75a0484b5035b02bce36d43c876fda9d6be</id>
<content type='text'>
[ Upstream commit c3d03e8e35e005e1a614e51bb59053eeb5857f76 ]

Commit ac4e97abce9b8 ("scatterlist: sg_set_buf() argument must be in linear
mapping") checks that both the signature and the digest reside in the
linear mapping area.

However, more recently commit ba14a194a434c ("fork: Add generic vmalloced
stack support") made it possible to move the stack in the vmalloc area,
which is not contiguous, and thus not suitable for sg_set_buf() which needs
adjacent pages.

Always make a copy of the signature and digest in the same buffer used to
store the key and its parameters, and pass them to sg_init_one(). Prefer it
to conditionally doing the copy if necessary, to keep the code simple. The
buffer allocated with kmalloc() is in the linear mapping area.

Cc: stable@vger.kernel.org # 4.9.x
Fixes: ba14a194a434 ("fork: Add generic vmalloced stack support")
Link: https://lore.kernel.org/linux-integrity/Y4pIpxbjBdajymBJ@sol.localdomain/
Suggested-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<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>
</feed>
