[lvc-project] [RESEND PATCH 2/2] media: em28xx: fix race between em28xx_free_v4l2() and em28xx_v4l2_fini()

Hans Verkuil hverkuil+cisco at kernel.org
Thu Sep 10 13:12:06 MSK 2026


Hi Dmitry,

On 07/09/2026 13:30, Fedor Pchelkin wrote:
> Hi,
> 
> On Mon, 07. Sep 13:28, Dmitry Antipov wrote:
>> Take device (an instance of 'struct em28xx') lock in em28xx_free_v4l2()
>> and do the same early in em28xx_v4l2_fini() to avoid UaF-triggering
>> racy access to 'v4l2' member.
>>
>> Reported-by: syzbot+dd0f06181ab66b93dc00 at syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=dd0f06181ab66b93dc00
>> Fixes: 288254383674 ("media: em28xx: use v4l2_device release callback")
>> Signed-off-by: Dmitry Antipov <dmantipov at yandex.ru>
>> ---
> 
> It would be nice to know what is the race and what is the root cause.
> Since if em28xx_v4l2_fini() and em28xx_free_v4l2() can _actually_ have a
> race, it's not clear what happens in the following scenario:
> 
>   Thread A                               Thread B
> 
>                                       em28xx_v4l2_fini()
> em28xx_free_v4l2()
>   mutex_lock(&dev->lock) 
>   dev->v4l2 = NULL
>   mutex_unlock(&dev->lock) 
>                                         mutex_lock(%dev->lock)
>                                         if (!dev->v4l2)
>                                           return
>                                         mutex_unlock(%dev->lock)
> 
> What about the resources which em28xx_v4l2_fini() should deallocate /
> disconnect / put ref / etc. when it doesn't return early?  Are they
> released eventually and who is supposed to do that?
> 

I agree with Fedor, this doesn't feel like the correct fix. em28xx_free_v4l2() shouldn't
be called until the very last user went away.

At the least there has to be more detailed information how this happens.

I'm not saying the patch is wrong, but I am not certain whether it fixes the
actual bug, or whether it just fixes the symptom.

Regards,

	Hans



More information about the lvc-project mailing list