All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: Dawei Feng <dawei.feng@seu.edu.cn>
Cc: hansg@kernel.org, mchehab@kernel.org,
	sakari.ailus@linux.intel.com, andy@kernel.org,
	gregkh@linuxfoundation.org, azpijr@gmail.com, kees@kernel.org,
	arnd@arndb.de, pontescpedro@gmail.com,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev, jianhao.xu@seu.edu.cn,
	zilin@seu.edu.cn
Subject: Re: [PATCH] media: atomisp: fix CAS scaler descriptor leaks
Date: Mon, 29 Jun 2026 11:30:40 +0300	[thread overview]
Message-ID: <akItMNqgKTDBCGV0@stanley.mountain> (raw)
In-Reply-To: <20260627060151.2543613-1-dawei.feng@seu.edu.cn>

On Sat, Jun 27, 2026 at 02:01:51PM +0800, Dawei Feng wrote:
> load_video_binaries() and load_primary_binaries() create a CAS scaler
> descriptor before allocating and looking up the YUV scaler binaries.
> Several failure paths after descriptor creation return without destroying
> the descriptor, leaking the frame-info arrays owned by it.
> 
> Route those exits through a descriptor cleanup label while keeping the
> existing pipe_settings ownership model. Also clear num_yuv_scaler when
> capture scaler binary allocation fails, so the existing failure unwind does
> not iterate a NULL scaler array.
> 
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still
> present in v7.1.1.
> 
> An x86_64 allyesconfig build showed no new warnings. As we do not have
> an Intel Atom ISP camera platform with matching sensor firmware and ACPI
> camera graph to test with, no runtime testing was able to be performed.
> 
> Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"")
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> ---
>  drivers/staging/media/atomisp/pci/sh_css.c | 35 ++++++++++++----------
>  1 file changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/sh_css.c b/drivers/staging/media/atomisp/pci/sh_css.c
> index 00082276f1db..d0ff16ba890f 100644
> --- a/drivers/staging/media/atomisp/pci/sh_css.c
> +++ b/drivers/staging/media/atomisp/pci/sh_css.c
> @@ -4528,20 +4528,20 @@ static int load_video_binaries(struct ia_css_pipe *pipe)
>  			  NULL,
>  			  &cas_scaler_descr);
>  		if (err)
> -			return err;
> +			goto destroy_cas_scaler_desc;
>  		mycs->num_yuv_scaler = cas_scaler_descr.num_stage;
>  		mycs->yuv_scaler_binary = kzalloc_objs(struct ia_css_binary,
>  						       cas_scaler_descr.num_stage);
>  		if (!mycs->yuv_scaler_binary) {
>  			mycs->num_yuv_scaler = 0;
>  			err = -ENOMEM;
> -			return err;
> +			goto destroy_cas_scaler_desc;
>  		}
>  		mycs->is_output_stage = kzalloc_objs(bool,
>  						     cas_scaler_descr.num_stage);
>  		if (!mycs->is_output_stage) {
>  			err = -ENOMEM;
> -			return err;
> +			goto destroy_cas_scaler_desc;
>  		}
>  		for (i = 0; i < cas_scaler_descr.num_stage; i++) {
>  			struct ia_css_binary_descr yuv_scaler_descr;
> @@ -4557,10 +4557,13 @@ static int load_video_binaries(struct ia_css_pipe *pipe)
>  			if (err) {
>  				kfree(mycs->is_output_stage);
>  				mycs->is_output_stage = NULL;
> -				return err;
> +				goto destroy_cas_scaler_desc;

What about freeing mycs->yuv_scaler_binary?  There are a bunch of
other leaks...  I would prefer a more complete fix.

https://staticthinking.wordpress.com/2022/04/28/free-the-last-thing-style/

I would probably just do the free before the goto since this is not
part of the cleanup function.

		if (err) {
			ia_css_pipe_destroy_cas_scaler_desc(&cas_scaler_descr);
			goto free_output_stage;
		}

...

	return 0;

free_output_stage:
	if (need_scalar) {
		kfree(mycs->is_output_stage);
		mycs->is_output_stage = NULL;
	}
free_scalar_binary:
	if (need_scalar) {
		kfree(mycs->yuv_scaler_binary);
		mycs->yuv_scaler_binary = NULL;
	}

etc.

regards,
dan carpenter


      reply	other threads:[~2026-06-29  8:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-27  6:01 [PATCH] media: atomisp: fix CAS scaler descriptor leaks Dawei Feng
2026-06-29  8:30 ` Dan Carpenter [this message]

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=akItMNqgKTDBCGV0@stanley.mountain \
    --to=error27@gmail.com \
    --cc=andy@kernel.org \
    --cc=arnd@arndb.de \
    --cc=azpijr@gmail.com \
    --cc=dawei.feng@seu.edu.cn \
    --cc=gregkh@linuxfoundation.org \
    --cc=hansg@kernel.org \
    --cc=jianhao.xu@seu.edu.cn \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=pontescpedro@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=zilin@seu.edu.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.