From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Huihui Huang <hhhuang@smu.edu.sg>
Cc: Hans de Goede <hansg@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: media: atomisp: fix map and vmap leaks in stat buffer allocation
Date: Thu, 16 Apr 2026 11:14:18 +0300 [thread overview]
Message-ID: <aeCaWgzGY5Z3PJay@ashevche-desk.local> (raw)
In-Reply-To: <20260416072731.2489513-1-hhhuang@smu.edu.sg>
On Thu, Apr 16, 2026 at 03:27:31PM +0800, Huihui Huang wrote:
> Our code analyzer reported memory leaks in
> drivers/staging/media/atomisp/pci/atomisp_compat_css20.c.
>
> In atomisp_css_allocate_stat_buffers(), s3a_map is allocated by
> ia_css_isp_3a_statistics_map_allocate() and its backing memory is
> mapped via hmm_vmap(). When dis_buf allocation fails, the error path
> frees s3a_data but does not unmap or free s3a_map. Similarly, when
> md_buf allocation fails, neither s3a_map nor dvs_map (and their hmm
> vmaps) are freed.
> My patch adds the missing hmm_vunmap() and map free calls on both
> error paths, matching the cleanup order used in
> atomisp_css_free_3a_buffer() and atomisp_css_free_dis_buffer().
Imperative mood.
...
> dev_err(isp->dev, "dvs buf allocation failed.\n");
> - if (s3a_buf)
> + if (s3a_buf) {
> + hmm_vunmap(s3a_buf->s3a_data->data_ptr);
> + ia_css_isp_3a_statistics_map_free(s3a_buf->s3a_map);
> + s3a_buf->s3a_map = NULL;
Are these NULLifications needed? It sounds like it tries to paper over some
potential UAF cases. Is there any possibility to access s3a_map at this point?
> ia_css_isp_3a_statistics_free(s3a_buf->s3a_data);
> + }
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-04-16 8:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 7:27 [PATCH] staging: media: atomisp: fix map and vmap leaks in stat buffer allocation Huihui Huang
2026-04-16 8:14 ` Andy Shevchenko [this message]
2026-04-16 13:24 ` [PATCH v2] " Huihui Huang
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=aeCaWgzGY5Z3PJay@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=hhhuang@smu.edu.sg \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.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