* [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests
@ 2026-08-28 9:32 Linmao Li
2026-08-28 19:25 ` Frank Li
0 siblings, 1 reply; 6+ messages in thread
From: Linmao Li @ 2026-08-28 9:32 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx,
linux-arm-kernel, linux-kernel, Linmao Li
Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them.
When such a request reaches the worker, last_out_len remains zero. The
CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned
value when updating the IV, causing the offset to underflow. On
decryption, the resulting source address precedes aes_in_buf.
Return success before enqueueing zero-length requests. This avoids the
invalid source access and leaves the IV unchanged for a no-op.
Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
drivers/crypto/mxs-dcp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index 133ebc998236..60794b4d49fa 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb)
struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req);
int ret;
+ if (!req->cryptlen)
+ return 0;
+
if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced))
return mxs_dcp_block_fallback(req, enc);
base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
--
2.25.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests 2026-08-28 9:32 [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests Linmao Li @ 2026-08-28 19:25 ` Frank Li 2026-08-31 12:42 ` Linmao Li 0 siblings, 1 reply; 6+ messages in thread From: Frank Li @ 2026-08-28 19:25 UTC (permalink / raw) To: Linmao Li Cc: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx, linux-arm-kernel, linux-kernel On Fri, Aug 28, 2026 at 05:32:09PM +0800, Linmao Li wrote: > [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them. Any document show it? if return 0 when cryptelen, it is async, no call crypto_request_complete. Frank > When such a request reaches the worker, last_out_len remains zero. The > CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned > value when updating the IV, causing the offset to underflow. On > decryption, the resulting source address precedes aes_in_buf. > > Return success before enqueueing zero-length requests. This avoids the > invalid source access and leaves the IV unchanged for a no-op. > > Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues") > Signed-off-by: Linmao Li <lilinmao@kylinos.cn> > --- > drivers/crypto/mxs-dcp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c > index 133ebc998236..60794b4d49fa 100644 > --- a/drivers/crypto/mxs-dcp.c > +++ b/drivers/crypto/mxs-dcp.c > @@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb) > struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); > int ret; > > + if (!req->cryptlen) > + return 0; > + > if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced)) > return mxs_dcp_block_fallback(req, enc); > > > base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f > -- > 2.25.1 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests 2026-08-28 19:25 ` Frank Li @ 2026-08-31 12:42 ` Linmao Li 2026-08-31 15:01 ` Frank Li 0 siblings, 1 reply; 6+ messages in thread From: Linmao Li @ 2026-08-31 12:42 UTC (permalink / raw) To: Frank Li Cc: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx, linux-arm-kernel, linux-kernel 在 2026/8/29 3:25, Frank Li 写道: > On Fri, Aug 28, 2026 at 05:32:09PM +0800, Linmao Li wrote: >> [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them. > Any document show it? if return 0 when cryptelen, it is async, no > call crypto_request_complete. Yes. CRYPTO_ALG_ASYNC means that the implementation may complete a request asynchronously, not that every request must do so. A return value of 0 indicates synchronous completion. Only -EINPROGRESS and -EBUSY cause crypto_wait_req() to wait for the completion callback. The existing fallback path relies on the same semantics. There is also a direct precedent in commit 8a4e047c6cc0 ("crypto: marvell/cesa - Handle zero-length skcipher requests"). Marvell CESA registers asynchronous skcipher algorithms but handles a zero-length request with: if (!req->cryptlen) return 0; Thanks, Linmao > > Frank > >> When such a request reaches the worker, last_out_len remains zero. The >> CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned >> value when updating the IV, causing the offset to underflow. On >> decryption, the resulting source address precedes aes_in_buf. >> >> Return success before enqueueing zero-length requests. This avoids the >> invalid source access and leaves the IV unchanged for a no-op. >> >> Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues") >> Signed-off-by: Linmao Li <lilinmao@kylinos.cn> >> --- >> drivers/crypto/mxs-dcp.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c >> index 133ebc998236..60794b4d49fa 100644 >> --- a/drivers/crypto/mxs-dcp.c >> +++ b/drivers/crypto/mxs-dcp.c >> @@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb) >> struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); >> int ret; >> >> + if (!req->cryptlen) >> + return 0; >> + >> if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced)) >> return mxs_dcp_block_fallback(req, enc); >> >> >> base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f >> -- >> 2.25.1 >> >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests 2026-08-31 12:42 ` Linmao Li @ 2026-08-31 15:01 ` Frank Li 2026-09-01 3:05 ` Linmao Li 0 siblings, 1 reply; 6+ messages in thread From: Frank Li @ 2026-08-31 15:01 UTC (permalink / raw) To: Linmao Li Cc: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx, linux-arm-kernel, linux-kernel On Mon, Aug 31, 2026 at 08:42:20PM +0800, Linmao Li wrote: > [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > 在 2026/8/29 3:25, Frank Li 写道: > > On Fri, Aug 28, 2026 at 05:32:09PM +0800, Linmao Li wrote: > > > [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them. > > Any document show it? if return 0 when cryptelen, it is async, no > > call crypto_request_complete. > Yes. CRYPTO_ALG_ASYNC means that the implementation may complete a > request asynchronously, not that every request must do so. > > A return value of 0 indicates synchronous completion. Only > -EINPROGRESS and -EBUSY cause crypto_wait_req() to wait for the > completion callback. The existing fallback path relies on the same > semantics. > > There is also a direct precedent in commit 8a4e047c6cc0 > ("crypto: marvell/cesa - Handle zero-length skcipher requests"). > Marvell CESA registers asynchronous skcipher algorithms but handles a > zero-length request with: > > if (!req->cryptlen) > return 0; Thanks, but still not answer my question, Any document show "Zero-length skcipher requests are valid no-ops", why not API direct return 0, instead of pass to every driver to check it. I suppose it should be checked before call driver's callback. Frank > > > Thanks, > Linmao > > > > > Frank > > > > > When such a request reaches the worker, last_out_len remains zero. The > > > CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned > > > value when updating the IV, causing the offset to underflow. On > > > decryption, the resulting source address precedes aes_in_buf. > > > > > > Return success before enqueueing zero-length requests. This avoids the > > > invalid source access and leaves the IV unchanged for a no-op. > > > > > > Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues") > > > Signed-off-by: Linmao Li <lilinmao@kylinos.cn> > > > --- > > > drivers/crypto/mxs-dcp.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c > > > index 133ebc998236..60794b4d49fa 100644 > > > --- a/drivers/crypto/mxs-dcp.c > > > +++ b/drivers/crypto/mxs-dcp.c > > > @@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb) > > > struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); > > > int ret; > > > > > > + if (!req->cryptlen) > > > + return 0; > > > + > > > if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced)) > > > return mxs_dcp_block_fallback(req, enc); > > > > > > > > > base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f > > > -- > > > 2.25.1 > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests 2026-08-31 15:01 ` Frank Li @ 2026-09-01 3:05 ` Linmao Li 2026-09-01 19:07 ` Frank Li 0 siblings, 1 reply; 6+ messages in thread From: Linmao Li @ 2026-09-01 3:05 UTC (permalink / raw) To: Frank Li Cc: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx, linux-arm-kernel, linux-kernel 在 2026/8/31 23:01, Frank Li 写道: > On Mon, Aug 31, 2026 at 08:42:20PM +0800, Linmao Li wrote: >> [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> 在 2026/8/29 3:25, Frank Li 写道: >>> On Fri, Aug 28, 2026 at 05:32:09PM +0800, Linmao Li wrote: >>>> [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them. >>> Any document show it? if return 0 when cryptelen, it is async, no >>> call crypto_request_complete. >> Yes. CRYPTO_ALG_ASYNC means that the implementation may complete a >> request asynchronously, not that every request must do so. >> >> A return value of 0 indicates synchronous completion. Only >> -EINPROGRESS and -EBUSY cause crypto_wait_req() to wait for the >> completion callback. The existing fallback path relies on the same >> semantics. >> >> There is also a direct precedent in commit 8a4e047c6cc0 >> ("crypto: marvell/cesa - Handle zero-length skcipher requests"). >> Marvell CESA registers asynchronous skcipher algorithms but handles a >> zero-length request with: >> >> if (!req->cryptlen) >> return 0; > Thanks, but still not answer my question, > > Any document show "Zero-length skcipher requests are valid no-ops", why > not API direct return 0, instead of pass to every driver to check it. > > I suppose it should be checked before call driver's callback. You are right; I could not find an explicit Crypto API document defining the zero-length behavior, so the wording "valid no-ops" was too broad. With the current API, simply returning 0 in the core for every zero-length request would change XTS semantics, since the generic XTS implementation returns -EINVAL. MXS-DCP only implements ECB and CBC here, whose generic implementations currently return 0. Handling it in the driver therefore matches existing behavior; centralizing this would require algorithm-specific length information. I agree that the commit message should describe this as existing ECB/CBC behavior rather than a general skcipher API rule. Thanks, Linmao > > Frank > >> >> Thanks, >> Linmao >> >>> Frank >>> >>>> When such a request reaches the worker, last_out_len remains zero. The >>>> CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned >>>> value when updating the IV, causing the offset to underflow. On >>>> decryption, the resulting source address precedes aes_in_buf. >>>> >>>> Return success before enqueueing zero-length requests. This avoids the >>>> invalid source access and leaves the IV unchanged for a no-op. >>>> >>>> Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues") >>>> Signed-off-by: Linmao Li <lilinmao@kylinos.cn> >>>> --- >>>> drivers/crypto/mxs-dcp.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c >>>> index 133ebc998236..60794b4d49fa 100644 >>>> --- a/drivers/crypto/mxs-dcp.c >>>> +++ b/drivers/crypto/mxs-dcp.c >>>> @@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb) >>>> struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); >>>> int ret; >>>> >>>> + if (!req->cryptlen) >>>> + return 0; >>>> + >>>> if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced)) >>>> return mxs_dcp_block_fallback(req, enc); >>>> >>>> >>>> base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f >>>> -- >>>> 2.25.1 >>>> >>>> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests 2026-09-01 3:05 ` Linmao Li @ 2026-09-01 19:07 ` Frank Li 0 siblings, 0 replies; 6+ messages in thread From: Frank Li @ 2026-09-01 19:07 UTC (permalink / raw) To: Linmao Li Cc: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Leonard Crestez, Radu Solea, Franck LENORMAND, linux-crypto, imx, linux-arm-kernel, linux-kernel On Tue, Sep 01, 2026 at 11:05:30AM +0800, Linmao Li wrote: > > 在 2026/8/31 23:01, Frank Li 写道: > > On Mon, Aug 31, 2026 at 08:42:20PM +0800, Linmao Li wrote: > > > [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > 在 2026/8/29 3:25, Frank Li 写道: > > > > On Fri, Aug 28, 2026 at 05:32:09PM +0800, Linmao Li wrote: > > > > > [You don't often get email from lilinmao@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > > > > > Zero-length skcipher requests are valid no-ops, but MXS-DCP queues them. > > > > Any document show it? if return 0 when cryptelen, it is async, no > > > > call crypto_request_complete. > > > Yes. CRYPTO_ALG_ASYNC means that the implementation may complete a > > > request asynchronously, not that every request must do so. > > > > > > A return value of 0 indicates synchronous completion. Only > > > -EINPROGRESS and -EBUSY cause crypto_wait_req() to wait for the > > > completion callback. The existing fallback path relies on the same > > > semantics. > > > > > > There is also a direct precedent in commit 8a4e047c6cc0 > > > ("crypto: marvell/cesa - Handle zero-length skcipher requests"). > > > Marvell CESA registers asynchronous skcipher algorithms but handles a > > > zero-length request with: > > > > > > if (!req->cryptlen) > > > return 0; > > Thanks, but still not answer my question, > > > > Any document show "Zero-length skcipher requests are valid no-ops", why > > not API direct return 0, instead of pass to every driver to check it. > > > > I suppose it should be checked before call driver's callback. > You are right; I could not find an explicit Crypto API document defining > the zero-length behavior, so the wording "valid no-ops" was too broad. > > With the current API, simply returning 0 in the core for every > zero-length request would change XTS semantics, since the generic XTS > implementation returns -EINVAL. MXS-DCP only implements ECB and CBC > here, whose generic implementations currently return 0. Handling it in > the driver therefore matches existing behavior; centralizing this would > require algorithm-specific length information. > > I agree that the commit message should describe this as existing ECB/CBC > behavior rather than a general skcipher API rule. Okay Frank > > Thanks, > Linmao > > > > Frank > > > > > > > > Thanks, > > > Linmao > > > > > > > Frank > > > > > > > > > When such a request reaches the worker, last_out_len remains zero. The > > > > > CBC completion path then subtracts AES_BLOCK_SIZE from this unsigned > > > > > value when updating the IV, causing the offset to underflow. On > > > > > decryption, the resulting source address precedes aes_in_buf. > > > > > > > > > > Return success before enqueueing zero-length requests. This avoids the > > > > > invalid source access and leaves the IV unchanged for a no-op. > > > > > > > > > > Fixes: fadd7a6e616b ("crypto: mxs-dcp - Fix AES issues") > > > > > Signed-off-by: Linmao Li <lilinmao@kylinos.cn> > > > > > --- > > > > > drivers/crypto/mxs-dcp.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c > > > > > index 133ebc998236..60794b4d49fa 100644 > > > > > --- a/drivers/crypto/mxs-dcp.c > > > > > +++ b/drivers/crypto/mxs-dcp.c > > > > > @@ -473,6 +473,9 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb) > > > > > struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); > > > > > int ret; > > > > > > > > > > + if (!req->cryptlen) > > > > > + return 0; > > > > > + > > > > > if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced)) > > > > > return mxs_dcp_block_fallback(req, enc); > > > > > > > > > > > > > > > base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f > > > > > -- > > > > > 2.25.1 > > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-01 19:07 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-08-28 9:32 [PATCH] crypto: mxs-dcp: handle zero-length skcipher requests Linmao Li 2026-08-28 19:25 ` Frank Li 2026-08-31 12:42 ` Linmao Li 2026-08-31 15:01 ` Frank Li 2026-09-01 3:05 ` Linmao Li 2026-09-01 19:07 ` Frank Li
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox