drivers/media/test-drivers/vimc/vimc-core.c | 1 + 1 file changed, 1 insertion(+)
When platform_device_register() fails in vimc_init(), the embedded
struct device in vimc_pdev has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
vimc_init()
-> platform_device_register(&vimc_pdev)
-> device_initialize(&vimc_pdev.dev)
-> setup_pdev_dma_masks(&vimc_pdev)
-> platform_device_add(&vimc_pdev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/test-drivers/vimc/vimc-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/test-drivers/vimc/vimc-core.c b/drivers/media/test-drivers/vimc/vimc-core.c
index 15167e127461..fee0c7a09c4f 100644
--- a/drivers/media/test-drivers/vimc/vimc-core.c
+++ b/drivers/media/test-drivers/vimc/vimc-core.c
@@ -421,6 +421,7 @@ static int __init vimc_init(void)
if (ret) {
dev_err(&vimc_pdev.dev,
"platform device registration failed (err=%d)\n", ret);
+ platform_device_put(&vimc_pdev);
return ret;
}
--
2.43.0
On 4/15/26 09:45, Guangshuo Li wrote:
> When platform_device_register() fails in vimc_init(), the embedded
> struct device in vimc_pdev has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> vimc_init()
> -> platform_device_register(&vimc_pdev)
> -> device_initialize(&vimc_pdev.dev)
> -> setup_pdev_dma_masks(&vimc_pdev)
> -> platform_device_add(&vimc_pdev)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
Can you share your manual review?
Can other static analysis tools for example scripts/coccinelle support
your findings?
>
> Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/media/test-drivers/vimc/vimc-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/test-drivers/vimc/vimc-core.c b/drivers/media/test-drivers/vimc/vimc-core.c
> index 15167e127461..fee0c7a09c4f 100644
> --- a/drivers/media/test-drivers/vimc/vimc-core.c
> +++ b/drivers/media/test-drivers/vimc/vimc-core.c
> @@ -421,6 +421,7 @@ static int __init vimc_init(void)
> if (ret) {
> dev_err(&vimc_pdev.dev,
> "platform device registration failed (err=%d)\n", ret);
> + platform_device_put(&vimc_pdev);
Where does platform_device_get() happen when platform_device_register() fails?
thanks,
-- Shuah
Hi Shuah,
Thanks for reviewing.
On Thu, 16 Apr 2026 at 00:01, Shuah Khan <skhan@linuxfoundation.org> wrote:
>
>
> Can you share your manual review?
>
> Can other static analysis tools for example scripts/coccinelle support
> your findings?
>
> >
> > Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> > drivers/media/test-drivers/vimc/vimc-core.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/media/test-drivers/vimc/vimc-core.c b/drivers/media/test-drivers/vimc/vimc-core.c
> > index 15167e127461..fee0c7a09c4f 100644
> > --- a/drivers/media/test-drivers/vimc/vimc-core.c
> > +++ b/drivers/media/test-drivers/vimc/vimc-core.c
> > @@ -421,6 +421,7 @@ static int __init vimc_init(void)
> > if (ret) {
> > dev_err(&vimc_pdev.dev,
> > "platform device registration failed (err=%d)\n", ret);
> > + platform_device_put(&vimc_pdev);
>
> Where does platform_device_get() happen when platform_device_register() fails?
>
> thanks,
> -- Shuah
My manual review was based on the platform_device_register() call
chain and its documented lifetime rules.
The relevant code path is:
ret = platform_device_register(&vimc_pdev);
if (ret) {
dev_err(&vimc_pdev.dev,
"platform device registration failed (err=%d)\n", ret);
return ret;
}
and
int platform_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
setup_pdev_dma_masks(pdev);
return platform_device_add(pdev);
}
If platform_device_add() fails, platform_device_register() returns an
error, but the reference initialized by device_initialize() is still
owned by the caller. The API documentation for platform_device_register()
also explicitly says:
"Never directly free @pdev after calling this function, even if it
returned an error! Always use platform_device_put() to give up the
reference initialised in this function instead."
So there is no matching platform_device_get() on the failure path.
The reference comes from device_initialize(), and platform_device_put()
is needed to drop that initial reference when registration fails.
That was also how I manually confirmed the issue after the tool report:
I checked the platform_device_register() / platform_device_add()
implementation and verified that the vimc failure path returns directly
without calling platform_device_put().
I found this issue using a tool I recently developed. The scan was run
on kernel version v7.0-1262-g4fa12523f7bc.
Thanks,
Guangshuo
On 4/15/26 10:56, Guangshuo Li wrote:
> Hi Shuah,
>
> Thanks for reviewing.
>
> On Thu, 16 Apr 2026 at 00:01, Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>
>>
>> Can you share your manual review?
>>
>> Can other static analysis tools for example scripts/coccinelle support
>> your findings?
>>
Did you try other static analysis tools in the kernel?
>>>
>>> Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
>>> ---
>>> drivers/media/test-drivers/vimc/vimc-core.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/media/test-drivers/vimc/vimc-core.c b/drivers/media/test-drivers/vimc/vimc-core.c
>>> index 15167e127461..fee0c7a09c4f 100644
>>> --- a/drivers/media/test-drivers/vimc/vimc-core.c
>>> +++ b/drivers/media/test-drivers/vimc/vimc-core.c
>>> @@ -421,6 +421,7 @@ static int __init vimc_init(void)
>>> if (ret) {
>>> dev_err(&vimc_pdev.dev,
>>> "platform device registration failed (err=%d)\n", ret);
>>> + platform_device_put(&vimc_pdev);
>>
>> Where does platform_device_get() happen when platform_device_register() fails?
>>
>> thanks,
>> -- Shuah
>
> My manual review was based on the platform_device_register() call
> chain and its documented lifetime rules.
>
> The relevant code path is:
>
> ret = platform_device_register(&vimc_pdev);
> if (ret) {
> dev_err(&vimc_pdev.dev,
> "platform device registration failed (err=%d)\n", ret);
> return ret;
> }
>
> and
>
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> setup_pdev_dma_masks(pdev);
> return platform_device_add(pdev);
> }
>
> If platform_device_add() fails, platform_device_register() returns an
> error, but the reference initialized by device_initialize() is still
> owned by the caller. The API documentation for platform_device_register()
> also explicitly says:
>
> "Never directly free @pdev after calling this function, even if it
> returned an error! Always use platform_device_put() to give up the
> reference initialised in this function instead."
>
> So there is no matching platform_device_get() on the failure path.
> The reference comes from device_initialize(), and platform_device_put()
> is needed to drop that initial reference when registration fails.
>
> That was also how I manually confirmed the issue after the tool report:
> I checked the platform_device_register() / platform_device_add()
> implementation and verified that the vimc failure path returns directly
> without calling platform_device_put().
>
> I found this issue using a tool I recently developed. The scan was run
> on kernel version v7.0-1262-g4fa12523f7bc.
There are several calls to platform_device_register() all over the kernel.
Did your tool find all other cases or just this one?
thanks,
-- Shuah
Hi Shuah, Thanks for reviewing. On Thu, 16 Apr 2026 at 04:49, Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 4/15/26 10:56, Guangshuo Li wrote: > > Hi Shuah, > > > > Thanks for reviewing. > > > > On Thu, 16 Apr 2026 at 00:01, Shuah Khan <skhan@linuxfoundation.org> wrote: > >> > > > >> > >> Can you share your manual review? > >> > >> Can other static analysis tools for example scripts/coccinelle support > >> your findings? > >> > > Did you try other static analysis tools in the kernel? > I have not used other static analysis tools for this case. > There are several calls to platform_device_register() all over the kernel. > Did your tool find all other cases or just this one? > > thanks, > -- Shuah My tool also identified other similar issues in the kernel, and I have posted corresponding patches for them, for example: [PATCH] eeprom: digsy_mtc: fix reference leak on failed device registration https://patchew.org/linux/20260415165203.3584869-1-lgs201920130244@gmail.com/ [PATCH] arm_pmu: acpi: fix reference leak on failed device registration https://patchew.org/linux/20260415174159.3625777-1-lgs201920130244@gmail.com/ Thanks, Guangshuo
© 2016 - 2026 Red Hat, Inc.