<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/crypto, branch v6.1.20</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.20</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.20'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-03-10T08:33:03+00:00</updated>
<entry>
<title>crypto: rsa-pkcs1pad - Use akcipher_request_complete</title>
<updated>2023-03-10T08:33:03+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-31T08:02:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf7cf7d1d4c7fc85c928ddfb5ac30ed2deea0317'/>
<id>urn:sha1:cf7cf7d1d4c7fc85c928ddfb5ac30ed2deea0317</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: xts - Handle EBUSY correctly</title>
<updated>2023-03-10T08:32:57+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-22T08:07:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57c3e1d63b63dc0841d41df729297cd7c1c35808'/>
<id>urn:sha1:57c3e1d63b63dc0841d41df729297cd7c1c35808</id>
<content type='text'>
[ Upstream commit 51c082514c2dedf2711c99d93c196cc4eedceb40 ]

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

However, as the caller of xts 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: 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing")
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: seqiv - Handle EBUSY correctly</title>
<updated>2023-03-10T08:32:56+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-13T10:27:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d497e8b200a175094e0ac252ed878add39b8771'/>
<id>urn:sha1:4d497e8b200a175094e0ac252ed878add39b8771</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-10T08:32:56+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-01-13T10:24:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a006aa3eedb8bfd6fe317c3cfe9c86ffe76b2385'/>
<id>urn:sha1:a006aa3eedb8bfd6fe317c3cfe9c86ffe76b2385</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>KEYS: asymmetric: Fix ECDSA use via keyctl uapi</title>
<updated>2023-03-10T08:32:45+00:00</updated>
<author>
<name>Denis Kenzior</name>
<email>denkenz@gmail.com</email>
</author>
<published>2022-08-26T14:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c77d664ab8e39086cd4ecffa8fd00651cf553ad0'/>
<id>urn:sha1:c77d664ab8e39086cd4ecffa8fd00651cf553ad0</id>
<content type='text'>
[ Upstream commit 10de7b54293995368c52d9aa153f3e7a359f04a1 ]

When support for ECDSA keys was added, constraints for data &amp; signature
sizes were never updated.  This makes it impossible to use such keys via
keyctl API from userspace.

Update constraint on max_data_size to 64 bytes in order to support
SHA512-based signatures. Also update the signature length constraints
per ECDSA signature encoding described in RFC 5480.

Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>use less confusing names for iov_iter direction initializers</title>
<updated>2023-02-09T10:28:04+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2022-09-16T00:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a1909510387ddf6c2bf58836dc844f66e8a9efb'/>
<id>urn:sha1:5a1909510387ddf6c2bf58836dc844f66e8a9efb</id>
<content type='text'>
[ Upstream commit de4eda9de2d957ef2d6a8365a01e26a435e958cb ]

READ/WRITE proved to be actively confusing - the meanings are
"data destination, as used with read(2)" and "data source, as
used with write(2)", but people keep interpreting those as
"we read data from it" and "we write data to it", i.e. exactly
the wrong way.

Call them ITER_DEST and ITER_SOURCE - at least that is harder
to misinterpret...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Stable-dep-of: 6dd88fd59da8 ("vhost-scsi: unbreak any layout for response")
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>2022-12-31T12:32:34+00:00</updated>
<author>
<name>Zhang Yiqun</name>
<email>zhangyiqun@phytium.com.cn</email>
</author>
<published>2022-11-16T09:24:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=314398bc1014d9d407ef3c03f4c864607a066382'/>
<id>urn:sha1:314398bc1014d9d407ef3c03f4c864607a066382</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: cryptd - Use request context instead of stack for sub-request</title>
<updated>2022-12-31T12:32:33+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2022-11-11T09:59:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5be6724f222890f407d499e2d3daa2dfa7bfcc8'/>
<id>urn:sha1:b5be6724f222890f407d499e2d3daa2dfa7bfcc8</id>
<content type='text'>
[ Upstream commit 3a58c231172537f7b0e19d93ed33decd04f80eab ]

cryptd is buggy as it tries to use sync_skcipher without going
through the proper sync_skcipher interface.  In fact it doesn't
even need sync_skcipher since it's already a proper skcipher and
can easily access the request context instead of using something
off the stack.

Fixes: 36b3875a97b8 ("crypto: cryptd - Remove VLA usage of skcipher")
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: tcrypt - fix return value for multiple subtests</title>
<updated>2022-12-31T12:32:30+00:00</updated>
<author>
<name>Robert Elliott</name>
<email>elliott@hpe.com</email>
</author>
<published>2022-09-30T21:40:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b5bc00a59efb3e74edeecc7b0b5c8983f87149f'/>
<id>urn:sha1:7b5bc00a59efb3e74edeecc7b0b5c8983f87149f</id>
<content type='text'>
[ Upstream commit 65c92cbb3f2365627a10cf97560d51e88fb4e588 ]

When a test mode invokes multiple tests (e.g., mode 0 invokes modes
1 through 199, and mode 3 tests three block cipher modes with des),
don't keep accumulating the return values with ret += tcrypt_test(),
which results in a bogus value if more than one report a nonzero
value (e.g., two reporting -2 (-ENOENT) end up reporting -4 (-EINTR)).
Instead, keep track of the minimum return value reported by any
subtest.

Fixes: 4e033a6bc70f ("crypto: tcrypt - Do not exit on success in fips mode")
Signed-off-by: Robert Elliott &lt;elliott@hpe.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>
<entry>
<title>treewide: use get_random_bytes() when possible</title>
<updated>2022-10-11T23:42:58+00:00</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2022-10-05T15:49:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=197173db990cad244221ba73c43b1df6170ae278'/>
<id>urn:sha1:197173db990cad244221ba73c43b1df6170ae278</id>
<content type='text'>
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. This was done as a basic find and replace.

Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Reviewed-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt; # powerpc
Acked-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
</content>
</entry>
</feed>
