* [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff [not found] <V2_MESSAGE_ID> @ 2026-04-17 7:01 ` Huihui Huang 2026-04-17 7:55 ` Dan Carpenter 0 siblings, 1 reply; 3+ messages in thread From: Huihui Huang @ 2026-04-17 7:01 UTC (permalink / raw) To: Hans de Goede, Mauro Carvalho Chehab, Andy Shevchenko Cc: Sakari Ailus, Greg Kroah-Hartman, linux-media, linux-staging, linux-kernel, Huihui Huang 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. Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg> --- v3: Remove unnecessary NULL assignment per review feedback. v2: Reword commit message per review feedback (no code change). --- drivers/staging/media/atomisp/pci/atomisp_compat_css20.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c index be5f37f4a6fd..d6e135c42e2f 100644 --- a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c +++ b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c @@ -1363,8 +1363,10 @@ int atomisp_alloc_dis_coef_buf(struct atomisp_sub_device *asd) /* DIS projections. */ asd->params.dis_proj_data_valid = false; asd->params.dvs_stat = ia_css_dvs2_statistics_allocate(dvs_grid); - if (!asd->params.dvs_stat) + if (!asd->params.dvs_stat) { + ia_css_dvs2_coefficients_free(asd->params.css_param.dvs2_coeff); return -ENOMEM; + } asd->params.dvs_hor_proj_bytes = dvs_grid->aligned_height * dvs_grid->aligned_width * -- 2.50.1 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff 2026-04-17 7:01 ` [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff Huihui Huang @ 2026-04-17 7:55 ` Dan Carpenter 2026-04-17 8:15 ` Andy Shevchenko 0 siblings, 1 reply; 3+ messages in thread From: Dan Carpenter @ 2026-04-17 7:55 UTC (permalink / raw) To: Huihui Huang Cc: Hans de Goede, Mauro Carvalho Chehab, Andy Shevchenko, Sakari Ailus, Greg Kroah-Hartman, linux-media, linux-staging, linux-kernel 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. > > Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg> > --- > v3: Remove unnecessary NULL assignment per review feedback. > v2: Reword commit message per review feedback (no code change). > --- > drivers/staging/media/atomisp/pci/atomisp_compat_css20.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c > index be5f37f4a6fd..d6e135c42e2f 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c > +++ b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c > @@ -1363,8 +1363,10 @@ int atomisp_alloc_dis_coef_buf(struct atomisp_sub_device *asd) > /* DIS projections. */ > asd->params.dis_proj_data_valid = false; > asd->params.dvs_stat = ia_css_dvs2_statistics_allocate(dvs_grid); > - if (!asd->params.dvs_stat) > + if (!asd->params.dvs_stat) { > + ia_css_dvs2_coefficients_free(asd->params.css_param.dvs2_coeff); > return -ENOMEM; > + } 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. 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/ regards, dan carpenter ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff 2026-04-17 7:55 ` Dan Carpenter @ 2026-04-17 8:15 ` Andy Shevchenko 0 siblings, 0 replies; 3+ messages in thread From: Andy Shevchenko @ 2026-04-17 8:15 UTC (permalink / raw) To: Dan Carpenter Cc: Huihui Huang, Hans de Goede, Mauro Carvalho Chehab, Andy Shevchenko, Sakari Ailus, Greg Kroah-Hartman, linux-media, linux-staging, linux-kernel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-04-17 8:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <V2_MESSAGE_ID>
2026-04-17 7:01 ` [PATCH v3] staging: media: atomisp: fix memory leak of dvs2_coeff Huihui Huang
2026-04-17 7:55 ` Dan Carpenter
2026-04-17 8:15 ` Andy Shevchenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox