public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
To: Wesley Atwell <atwellwea@gmail.com>
Cc: <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
	<terrelln@fb.com>, <dsterba@suse.com>,
	<suman.kumar.chakraborty@intel.com>,
	<linux-crypto@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crypto: zstd - fix segmented acomp streaming paths
Date: Thu, 19 Mar 2026 22:43:44 +0000	[thread overview]
Message-ID: <abx7522F7DLyBauU@gcabiddu-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <20260309082051.2087363-1-atwellwea@gmail.com>

On Mon, Mar 09, 2026 at 02:20:51AM -0600, Wesley Atwell wrote:
> The zstd acomp implementation does not correctly handle segmented
> source and destination walks.
> 
> The compression path advances the destination walk by the full
> segment length rather than the bytes actually produced, and it only
> calls zstd_end_stream() once even though the streaming API requires it
> to be called until it returns 0.  With segmented destinations this can
> leave buffered output behind and misaccount the walk progress.
> 
> The decompression path has the same destination accounting issue, and
> it stops when the source walk is exhausted even if
> zstd_decompress_stream() has not yet reported that the frame is fully
> decoded and flushed.  That can report success too early for segmented
> requests and incomplete frames.
> 
> Fix both streaming paths by advancing destination segments by actual
> output bytes, refilling destination segments as needed, draining
> zstd_end_stream() until completion, and continuing to flush buffered
> decompression output after the source walk is exhausted.  Return
> -EINVAL if decompression cannot finish once the input has been fully
> consumed.
> 
> Fixes: f5ad93ffb541 ("crypto: zstd - convert to acomp")
> Assisted-by: Codex:GPT-5
> Signed-off-by: Wesley Atwell <atwellwea@gmail.com>
> ---
> Local validation:
> - built bzImage with CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y
> - exercised segmented zstd acomp requests using temporary local testmgr scaffolding
> - booted under virtme and verified zstd-generic selftest passed in /proc/crypto
> 
>  crypto/zstd.c | 228 ++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 156 insertions(+), 72 deletions(-)
> 
> diff --git a/crypto/zstd.c b/crypto/zstd.c
> index 556f5d2bdd5f..3e19da1fed22 100644
> --- a/crypto/zstd.c
> +++ b/crypto/zstd.c
> @@ -94,18 +94,30 @@ static int zstd_compress_one(struct acomp_req *req, struct zstd_ctx *ctx,
>  	return 0;
>  }
>  
> +static int zstd_acomp_next_dst(struct acomp_walk *walk, zstd_out_buffer *outbuf)
> +{
> +	unsigned int dcur = acomp_walk_next_dst(walk);
> +
> +	if (!dcur)
> +		return -ENOSPC;
> +
> +	outbuf->pos = 0;
> +	outbuf->dst = walk->dst.virt.addr;
> +	outbuf->size = dcur;
> +
> +	return 0;
> +}
> +
>  static int zstd_compress(struct acomp_req *req)
>  {
>  	struct crypto_acomp_stream *s;
> -	unsigned int pos, scur, dcur;
> +	unsigned int scur;
>  	unsigned int total_out = 0;
> -	bool data_available = true;
>  	zstd_out_buffer outbuf;
>  	struct acomp_walk walk;
>  	zstd_in_buffer inbuf;
>  	struct zstd_ctx *ctx;
> -	size_t pending_bytes;
> -	size_t num_bytes;
> +	size_t remaining;
>  	int ret;
>  
>  	s = crypto_acomp_lock_stream_bh(&zstd_streams);
> @@ -115,66 +127,87 @@ static int zstd_compress(struct acomp_req *req)
>  	if (ret)
>  		goto out;
>  
> +	ret = zstd_acomp_next_dst(&walk, &outbuf);
> +	if (ret)
> +		goto out;
> +
>  	ctx->cctx = zstd_init_cstream(&ctx->params, 0, ctx->wksp, ctx->wksp_size);
>  	if (!ctx->cctx) {
>  		ret = -EINVAL;
>  		goto out;
>  	}
>  
> -	do {
> -		dcur = acomp_walk_next_dst(&walk);
> -		if (!dcur) {
> -			ret = -ENOSPC;
> +	for (;;) {
> +		scur = acomp_walk_next_src(&walk);
> +		if (outbuf.size == req->dlen && scur == req->slen) {
> +			ret = zstd_compress_one(req, ctx, walk.src.virt.addr,
> +						walk.dst.virt.addr, &total_out);
> +			if (!ret) {
> +				acomp_walk_done_src(&walk, scur);
> +				acomp_walk_done_dst(&walk, total_out);
These two functions should be called regardless of the return code of
zstd_compress_one() as they are unmapping the buffers.

...

> @@ -209,12 +242,12 @@ static int zstd_decompress(struct acomp_req *req)
>  {
>  	struct crypto_acomp_stream *s;
>  	unsigned int total_out = 0;
> -	unsigned int scur, dcur;
> +	unsigned int scur;
>  	zstd_out_buffer outbuf;
>  	struct acomp_walk walk;
>  	zstd_in_buffer inbuf;
>  	struct zstd_ctx *ctx;
> -	size_t pending_bytes;
> +	size_t remaining = 1;
>  	int ret;
>  
>  	s = crypto_acomp_lock_stream_bh(&zstd_streams);
> @@ -224,54 +257,105 @@ static int zstd_decompress(struct acomp_req *req)
>  	if (ret)
>  		goto out;
>  
> +	ret = zstd_acomp_next_dst(&walk, &outbuf);
> +	if (ret)
> +		goto out;
> +
>  	ctx->dctx = zstd_init_dstream(ZSTD_MAX_SIZE, ctx->wksp, ctx->wksp_size);
>  	if (!ctx->dctx) {
>  		ret = -EINVAL;
>  		goto out;
>  	}
>  
> -	do {
> +	for (;;) {
>  		scur = acomp_walk_next_src(&walk);
> -		if (scur) {
> -			inbuf.pos = 0;
> -			inbuf.size = scur;
> -			inbuf.src = walk.src.virt.addr;
> -		} else {
> -			break;
> +		if (outbuf.size == req->dlen && scur == req->slen) {
> +			ret = zstd_decompress_one(req, ctx, walk.src.virt.addr,
> +						  walk.dst.virt.addr, &total_out);
> +			if (!ret) {
> +				acomp_walk_done_src(&walk, scur);
> +				acomp_walk_done_dst(&walk, total_out);
> +			}
Same here.

Regards,

-- 
Giovanni

  reply	other threads:[~2026-03-19 22:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  8:20 [PATCH] crypto: zstd - fix segmented acomp streaming paths Wesley Atwell
2026-03-19 22:43 ` Giovanni Cabiddu [this message]
2026-03-20 20:44   ` Wesley Atwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abx7522F7DLyBauU@gcabiddu-mobl.ger.corp.intel.com \
    --to=giovanni.cabiddu@intel.com \
    --cc=atwellwea@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsterba@suse.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suman.kumar.chakraborty@intel.com \
    --cc=terrelln@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox