Re: [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff

From: Andy Shevchenko

Date: Fri Apr 17 2026 - 04:17:03 EST


On Fri, Apr 17, 2026 at 10:55:29AM +0300, Dan Carpenter wrote:
> On Fri, Apr 17, 2026 at 03:01:24PM +0800, Huihui Huang wrote:
> > There is a memory leak in
> > drivers/staging/media/atomisp/pci/atomisp_compat_css20.c.
> >
> > In atomisp_alloc_dis_coef_buf(), dvs2_coeff is allocated by
> > ia_css_dvs2_coefficients_allocate() and stored in
> > asd->params.css_param.dvs2_coeff. If the subsequent
> > ia_css_dvs2_statistics_allocate() for dvs_stat fails, the function
> > returns -ENOMEM without freeing the previously allocated dvs2_coeff.
> >
> > Add the missing ia_css_dvs2_coefficients_free() call before returning
> > on the error path.

> The design of this code is that if we have an -ENOMEM here the caller,
> atomisp_update_grid_info(), calls atomisp_css_free_stat_buffers() which
> calls ia_css_dvs2_coefficients_free(). I can't tell if adding a second
> ia_css_dvs2_coefficients_free() here leads to a double free.

Exactly my point about NULLification... I asked that question twice and
no answer has been received. :-( I believe the atomisp must not be given
as the material for "the first contribution to the Linux kernel" mentored
by anybody. This driver is quite heavy (100kLoC) and very complex with all
magic inside.

> I call this style of error handling One Magical Cleanup Function. It's
> always buggy...
> https://staticthinking.wordpress.com/2025/03/31/reviewing-magical-cleanup-functions/

--
With Best Regards,
Andy Shevchenko