* [PATCH] media: atomisp: Fix resource leak in atomisp_pci_probe()
@ 2026-06-08 8:27 Dawei Feng
2026-06-08 8:51 ` Dan Carpenter
0 siblings, 1 reply; 3+ messages in thread
From: Dawei Feng @ 2026-06-08 8:27 UTC (permalink / raw)
To: andy
Cc: hansg, mchehab, sakari.ailus, gregkh, abdelrahmanfekry375,
linux-kernel, linux-media, linux-staging, jianhao.xu, Dawei Feng,
Zilin Guan
During atomisp_pci_probe(), the ISP subdev is initialized via
atomisp_initialize_modules() prior to entity registration. If
atomisp_register_entities() fails, the current error path only
uninitializes the CSI2 modules. This leaks the subdev entity and control
handler that were previously set up by atomisp_subdev_init().
Fix this by calling atomisp_subdev_unregister_entities() to properly
release the subdev state on this specific error path. Later error paths
remain unchanged, as they correctly use atomisp_unregister_entities() to
handle broader cleanup after successful registration.
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-rc5.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
Intel Atom ISP platform to test with, no runtime testing was able to be
performed.
Fixes: 9d4fa1a16b28 ("media: atomisp: cleanup directory hierarchy")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
drivers/staging/media/atomisp/pci/atomisp_v4l2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
index 900a67552d6a..d4e4e845f66e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
@@ -1401,6 +1401,7 @@ static int atomisp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *i
err = atomisp_register_entities(isp);
if (err < 0) {
dev_err(&pdev->dev, "atomisp_register_entities failed (%d)\n", err);
+ atomisp_subdev_unregister_entities(&isp->asd);
goto error_uninitialize_modules;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] media: atomisp: Fix resource leak in atomisp_pci_probe()
2026-06-08 8:27 [PATCH] media: atomisp: Fix resource leak in atomisp_pci_probe() Dawei Feng
@ 2026-06-08 8:51 ` Dan Carpenter
2026-06-08 14:05 ` Dawei Feng
0 siblings, 1 reply; 3+ messages in thread
From: Dan Carpenter @ 2026-06-08 8:51 UTC (permalink / raw)
To: Dawei Feng
Cc: andy, hansg, mchehab, sakari.ailus, gregkh, abdelrahmanfekry375,
linux-kernel, linux-media, linux-staging, jianhao.xu, Zilin Guan
On Mon, Jun 08, 2026 at 04:27:06PM +0800, Dawei Feng wrote:
> During atomisp_pci_probe(), the ISP subdev is initialized via
> atomisp_initialize_modules() prior to entity registration. If
> atomisp_register_entities() fails, the current error path only
> uninitializes the CSI2 modules. This leaks the subdev entity and control
> handler that were previously set up by atomisp_subdev_init().
>
> Fix this by calling atomisp_subdev_unregister_entities() to properly
> release the subdev state on this specific error path. Later error paths
> remain unchanged, as they correctly use atomisp_unregister_entities() to
> handle broader cleanup after successful registration.
>
> 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-rc5.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have an
> Intel Atom ISP platform to test with, no runtime testing was able to be
> performed.
>
> Fixes: 9d4fa1a16b28 ("media: atomisp: cleanup directory hierarchy")
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> ---
The code is buggy, but this isn't the right fix.
Here is generally the standard way to do error handling.
https://staticthinking.wordpress.com/2022/04/28/free-the-last-thing-style/
1. An allocation should clean up it's own partial allocations. That
should not be handled in the caller. 2. Every allocation function should
have a mirror cleanup function.
The atomisp_uninitialize_modules() function is just a dummy and was never
actually implemented. The correct thing is to implement it.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] media: atomisp: Fix resource leak in atomisp_pci_probe()
2026-06-08 8:51 ` Dan Carpenter
@ 2026-06-08 14:05 ` Dawei Feng
0 siblings, 0 replies; 3+ messages in thread
From: Dawei Feng @ 2026-06-08 14:05 UTC (permalink / raw)
To: error27
Cc: abdelrahmanfekry375, andy, dawei.feng, gregkh, hansg, jianhao.xu,
linux-kernel, linux-media, linux-staging, mchehab, sakari.ailus,
zilin
Hi Dan,
On Mon, Jun 08, 2026 at 11:51:45 +0300, Dan Carpenter wrote:
> The code is buggy, but this isn't the right fix.
>
> Here is generally the standard way to do error handling.
> https://staticthinking.wordpress.com/2022/04/28/free-the-last-thing-style/
>
> 1. An allocation should clean up it's own partial allocations. That
> should not be handled in the caller. 2. Every allocation function should
> have a mirror cleanup function.
>
> The atomisp_uninitialize_modules() function is just a dummy and was never
> actually implemented. The correct thing is to implement it.
Thanks for the review and the link to the error handling guidelines.
Thanks for the pointer. I'll update it in v2.
Thanks,
Dawei
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-08 14:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-08 8:27 [PATCH] media: atomisp: Fix resource leak in atomisp_pci_probe() Dawei Feng
2026-06-08 8:51 ` Dan Carpenter
2026-06-08 14:05 ` Dawei Feng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox