Re: [PATCH V5 4/6] drm/panel: anbernic-td4310: Add RG Vita Pro panel

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver calls an undefined function `devm_drm_panel_add()`, causing a compilation failure. Furthermore, the driver lacks a `.remove` callback (or a devres action) to call `drm_panel_remove()`. If the build error is fixed by trivially substituting the standard `drm_panel_add()`, it will result in a Use-After-Free vulnerability.
--

commit 15ea49b70a00236df8f23333ccc634c4fbaf642e
Author: Chris Morgan <macromorgan@hotmail.com>

drm/panel: anbernic-td4310: Add RG Vita Pro panel

This commit adds support for the TD4310 controller IC DSI panel used in the
Anbernic RG Vita-Pro.

> diff --git a/drivers/gpu/drm/panel/panel-anbernic-td4310.c b/drivers/gpu/drm/panel/panel-anbernic-td4310.c
> new file mode 100644
> index 0000000000000..84963671e3f94
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-anbernic-td4310.c

[ ... ]

> +static int panel_anbernic_td4310_probe(struct mipi_dsi_device *dsi)
> +{

[ ... ]

> +	ret = drm_panel_of_backlight(&ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	devm_drm_panel_add(dev, &ctx->panel);

[Severity: High]
Does devm_drm_panel_add() exist in the kernel? It looks like this might
cause a build failure due to an undefined function.

If this is resolved by simply replacing it with drm_panel_add(), could it
result in a use-after-free on unbind? Because the panel is allocated with
devm_drm_panel_alloc() earlier, its memory will be automatically freed when
the device is unbound. If drm_panel_remove() is never called, the freed
panel would remain in the global DRM panel list, risking memory corruption
when other components traverse the list.

[ ... ]

> +static struct mipi_dsi_driver anbernic_panel_td4310_driver = {
> +	.driver = {
> +		.name = "panel-anbernic-td4310",
> +		.of_match_table = panel_anbernic_td4310_of_match,
> +	},
> +	.probe	= panel_anbernic_td4310_probe,
> +};

[Severity: High]
Would it make sense to add a .remove callback here to call
drm_panel_remove(), or perhaps register a custom devm action during probe,
to ensure the panel is properly unregistered from the subsystem on teardown?

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