All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Guangshuo Li" <lgs201920130244@gmail.com>
Cc: linux-amlogic@lists.infradead.org, neil.armstrong@linaro.org
Subject: Re: [PATCH] media: meson: ge2d: avoid double free on video register failure
Date: Sun, 17 May 2026 12:29:54 +0000	[thread overview]
Message-ID: <20260517122955.29299C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260517115343.955015-1-lgs201920130244@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch's workaround for a double free violates kobject lifecycle rules, introducing a Use-After-Free.
- [High] Pre-existing Use-After-Free due to device-managed (devm) memory lifecycle mismatch with asynchronous character device operations.
--

commit 7ed6ce0ea116cd8dcd5ff2e1837f5d339cda90fa
Author: Guangshuo Li <lgs201920130244@gmail.com>

media: meson: ge2d: avoid double free on video register failure

This commit attempts to fix a double free when video_register_device
fails by temporarily assigning video_device_release_empty to the video
device release callback. It restores the original callback if registration
succeeds.

> diff --git a/drivers/media/platform/amlogic/meson-ge2d/ge2d.c b/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
> index c5dc03905ce0f..b367169e6ad84 100644
> --- a/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
> +++ b/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
> @@ -983,6 +983,7 @@ static int ge2d_probe(struct platform_device *pdev)
>  	}
>  
>  	*vfd = ge2d_videodev;
> +	vfd->release = video_device_release_empty;

Can this workaround introduce a use-after-free regression in the kobject core?

When __video_register_device fails inside device_register, it calls
put_device to drop the reference count. The driver core expects the release
callback to free the containing structure.

By temporarily substituting vfd->release with video_device_release_empty,
put_device will not free the memory synchronously. The driver then explicitly
frees the video_device in the error path via video_device_release.

However, put_device is not guaranteed to execute cleanup synchronously. If
asynchronous kobject release debugging is enabled, it schedules cleanup
asynchronously on a workqueue.

Explicitly freeing the video_device struct immediately after registration
fails could destroy the embedded device struct memory while the kobject core
still holds an asynchronous reference.

>  	vfd->lock = &ge2d->mutex;
>  	vfd->v4l2_dev = &ge2d->v4l2_dev;

Does the use of devm memory for the meson_ge2d struct create a lifecycle
mismatch with the video device?

The ge2d context is allocated via devm_kzalloc, which automatically frees
the memory when the driver unbinds. However, this context embeds fields
like v4l2_dev and mutex that are referenced by the video_device.

If a user process opens the video character device and holds the file
descriptor open, the video_device remains active even after the driver
unbinds and the devm memory is freed.

If the user later closes the file descriptor, the final reference drop
invokes v4l2_release, which dereferences vdev->v4l2_dev and attempts
to lock the freed ge2d->mutex, resulting in a use-after-free regression.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260517115343.955015-1-lgs201920130244@gmail.com?part=1

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

      reply	other threads:[~2026-05-17 12:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17 11:53 [PATCH] media: meson: ge2d: avoid double free on video register failure Guangshuo Li
2026-05-17 11:53 ` Guangshuo Li
2026-05-17 12:29 ` sashiko-bot [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=20260517122955.29299C2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=lgs201920130244@gmail.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.