linux-kernel - RE: [PATCH] media: chips-media: wave5: Fix Potential Probe Resource Leak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <SLXP216MB1148CE2E7ABF4280D6C27B44EDD8A@SLXP216MB1148.KORP216.PROD.OUTLOOK.COM>
Date: Tue, 2 Dec 2025 02:06:30 +0000
From: jackson.lee <jackson.lee@...psnmedia.com>
To: Brandon Brnich <b-brnich@...com>, Nas Chung <nas.chung@...psnmedia.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Nicolas Dufresne
	<nicolas.dufresne@...labora.com>
CC: Darren Etheridge <detheridge@...com>
Subject: RE: [PATCH] media: chips-media: wave5: Fix Potential Probe Resource
 Leak

Hi Brandon


> -----Original Message-----
> From: Brandon Brnich <b-brnich@...com>
> Sent: Thursday, November 20, 2025 6:32 AM
> To: Nas Chung <nas.chung@...psnmedia.com>; jackson.lee
> <jackson.lee@...psnmedia.com>; Mauro Carvalho Chehab <mchehab@...nel.org>;
> linux-media@...r.kernel.org; linux-kernel@...r.kernel.org; Nicolas
> Dufresne <nicolas.dufresne@...labora.com>
> Cc: Darren Etheridge <detheridge@...com>; Brandon Brnich <b-brnich@...com>
> Subject: [PATCH] media: chips-media: wave5: Fix Potential Probe Resource
> Leak
> 
> After kthread creation during probe sequence, a handful of other failures
> could occur. If this were to happen, the kthread is never explicitly
> deleted which results in a resource leak. Add explicit cleanup of this
> resource.
> 
> Signed-off-by: Brandon Brnich <b-brnich@...com>
> ---
> 
> I am aware that all the dev attributes would be freed since it is
> allocated using the devm_* framework. But I did not believe that this
> framework would recursively free the thread and stop the timer. These
> would just be dangling resources unable to get killed unless deliberately
> removed in the probe function.
> 
>  drivers/media/platform/chips-media/wave5/wave5-vpu.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> index e1715d3f43b0..f027b4ac775a 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> @@ -339,6 +339,11 @@ static int wave5_vpu_probe(struct platform_device
> *pdev)
>  	v4l2_device_unregister(&dev->v4l2_dev);
>  err_vdi_release:
>  	wave5_vdi_release(&pdev->dev);
> +
> +	if (dev->irq < 0) {
> +		kthread_destroy_worker(dev->worker);
> +		hrtimer_cancel(&dev->hrtimer);
> +	}

I'd like to change the above to as below.
I think we have to distinguish failure between registering IRQ handler and registering v4l2_device_register.

err_irq_release:
	if (dev->irq < 0) {
		kthread_destroy_worker(dev->worker);
		hrtimer_cancel(&dev->hrtimer);
	}
err_vdi_release:

thanks
Jackson


>  err_clk_dis:
>  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks);
>  err_reset_assert:
> --
> 2.34.1