mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil+cisco@kernel.org>
To: Jeongjun Park <aha310510@gmail.com>,
	mchehab@kernel.org, khoroshilov@ispras.ru
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com
Subject: Re: [PATCH v2 RESEND] media: as102: fix to not free memory after the device is registered in as102_usb_probe()
Date: Tue, 14 Oct 2025 12:06:52 +0200	[thread overview]
Message-ID: <1a6e25c6-820e-4610-80bb-518edca18bd5@kernel.org> (raw)
In-Reply-To: <20250904054629.3849431-1-aha310510@gmail.com>

On 04/09/2025 07:46, Jeongjun Park wrote:
> In as102_usb driver, the following race condition occurs:
> ```
> 		CPU0						CPU1
> as102_usb_probe()
>   kzalloc(); // alloc as102_dev_t
>   ....
>   usb_register_dev();
> 						open("/path/to/dev"); // open as102 dev
> 						....
>   usb_deregister_dev();
>   ....
>   kfree(); // free as102_dev_t
>   ....
> 						close(fd);
> 						  as102_release() // UAF!!
> 						    as102_usb_release()
> 						      kfree(); // DFB!!
> ```
> 
> When a USB character device registered with usb_register_dev() is later
> unregistered (via usb_deregister_dev() or disconnect), the device node is
> removed so new open() calls fail. However, file descriptors that are
> already open do not go away immediately: they remain valid until the last
> reference is dropped and the driver's .release() is invoked.
> 
> In as102, as102_usb_probe() calls usb_register_dev() and then, on an
> error path, does usb_deregister_dev() and frees as102_dev_t right away.
> If userspace raced a successful open() before the deregistration, that
> open FD will later hit as102_release() --> as102_usb_release() and access
> or free as102_dev_t again, occur a race to use-after-free and
> double-free vuln.
> 
> The fix is to never kfree(as102_dev_t) directly once usb_register_dev()
> has succeeded. After deregistration, defer freeing memory to .release().
> 
> In other words, let release() perform the last kfree when the final open
> FD is closed.
> 
> Cc: <stable@vger.kernel.org>
> Reported-by: syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db
> Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()")
> Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> ---
> v2: Fix incorrect patch description style and CC stable mailing list
> - Link to v1: https://lore.kernel.org/all/20250822143539.1157329-1-aha310510@gmail.com/
> ---
>  drivers/media/usb/as102/as102_usb_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/usb/as102/as102_usb_drv.c b/drivers/media/usb/as102/as102_usb_drv.c
> index e0ef66a522e2..abde5666b2ee 100644
> --- a/drivers/media/usb/as102/as102_usb_drv.c
> +++ b/drivers/media/usb/as102/as102_usb_drv.c
> @@ -404,6 +404,7 @@ static int as102_usb_probe(struct usb_interface *intf,
>  	as102_free_usb_stream_buffer(as102_dev);
>  failed_stream:
>  	usb_deregister_dev(intf, &as102_usb_class_driver);
> +	return ret;

Here too I wonder if the memory is actually freed. I suspect a usb_put_intf()
is needed. I'm not a USB expert, though. But you should check if you didn't
replace a UAF by a memory leak.

Regards,

	Hans

>  failed:
>  	usb_put_dev(as102_dev->bus_adap.usb_dev);
>  	usb_set_intfdata(intf, NULL);
> --
> 


      reply	other threads:[~2025-10-14 10:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04  5:46 Jeongjun Park
2025-10-14 10:06 ` Hans Verkuil [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a6e25c6-820e-4610-80bb-518edca18bd5@kernel.org \
    --to=hverkuil+cisco@kernel.org \
    --cc=aha310510@gmail.com \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®