All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mikko Perttunen" <mperttunen@nvidia.com>
Cc: robh@kernel.org, dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 3/7] gpu: host1x: Correctly parse linear ranges of context devices
Date: Fri, 12 Jun 2026 06:45:18 +0000	[thread overview]
Message-ID: <20260612064519.20DBE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612-t264-host1x-v1-3-8d934987de67@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver synchronously frees the dynamically allocated `cdl->devs` array immediately after calling `device_unregister()`, while using an empty `.release()` callback. This violates the Linux device model and leads to a Use-After-Free.
--

commit 46b291569da04e8306d82ff644615dfc60ee956f
Author: Mikko Perttunen <mperttunen@nvidia.com>

gpu: host1x: Correctly parse linear ranges of context devices

The commit updates the parsing of the iommu-map property to support
linear ranges of context devices instead of assuming each device has
a one-length entry.

> diff --git a/drivers/gpu/host1x/context.c b/drivers/gpu/host1x/context.c
> --- a/drivers/gpu/host1x/context.c
> +++ b/drivers/gpu/host1x/context.c
[ ... ]
> @@ -34,7 +34,16 @@ int host1x_memory_context_list_init(struct host1x *host1x)
>  	if (err < 0)
>  		return 0;
>  
> -	cdl->len = err / 4;
> +	devs = 0;
> +
> +	for (i = 0; i < err / 4; i++) {
> +		u32 length;
> +
> +		of_property_read_u32_index(node, "iommu-map", i * 4 + 3, &length);
> +		devs += length;
> +	}
> +
> +	cdl->len = devs;
>  	cdl->devs = kzalloc_objs(*cdl->devs, cdl->len);

[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing
issue with how the cdl->devs array is managed during cleanup.

In host1x_memory_context_list_init(), if an error occurs later in the
initialization, the unreg_devices error path unregisters the devices and
immediately frees the array:

host1x_memory_context_list_init() {
    ...
unreg_devices:
    while (i--)
        device_unregister(&cdl->devs[i].dev);
        
    kfree(cdl->devs);
    ...
}

The same pattern appears in host1x_memory_context_list_free() during
normal teardown.

The driver also provides a dummy release callback:

static void host1x_memory_context_release(struct device *dev)
{
    /* context device is freed in host1x_memory_context_list_free() */
}

Could this lead to a use-after-free? When device_unregister() is called,
it drops the initial device reference, but sysfs or userspace might still
hold elevated references to the embedded kobjects.

Since kfree(cdl->devs) is called synchronously while references could
still exist, would userspace interaction with the sysfs attributes for
these devices during teardown end up accessing freed memory?

>  	if (!cdl->devs)
>  		return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=3

  reply	other threads:[~2026-06-12  6:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12  6:32 [PATCH 0/7] Host1x/VIC support on Tegra264 Mikko Perttunen
2026-06-12  6:32 ` [PATCH 1/7] dt-bindings: display: tegra: Changes to support Tegra264 Mikko Perttunen
2026-06-12  6:40   ` sashiko-bot
2026-06-12 16:16   ` Conor Dooley
2026-06-12  6:32 ` [PATCH 2/7] dt-bindings: display: tegra: Add Tegra264 compatible for VIC Mikko Perttunen
2026-06-12 16:17   ` Conor Dooley
2026-06-12  6:32 ` [PATCH 3/7] gpu: host1x: Correctly parse linear ranges of context devices Mikko Perttunen
2026-06-12  6:45   ` sashiko-bot [this message]
2026-06-12  6:32 ` [PATCH 4/7] gpu: host1x: Add Tegra264 support Mikko Perttunen
2026-06-12  6:43   ` sashiko-bot
2026-06-12  6:32 ` [PATCH 5/7] drm/tegra: falcon: Add support for RISC-V external boot Mikko Perttunen
2026-06-12  6:44   ` sashiko-bot
2026-06-12  6:32 ` [PATCH 6/7] drm/tegra: vic: Add Tegra264 support Mikko Perttunen
2026-06-12  6:47   ` sashiko-bot
2026-06-12  6:32 ` [PATCH 7/7] arm64: tegra: Add Host1x and VIC on Tegra264 Mikko Perttunen

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=20260612064519.20DBE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mperttunen@nvidia.com \
    --cc=robh@kernel.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.