Re: [PATCH v2 02/35] clk: mediatek: mt6795: Fix memory leak on module removal

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] clk: mediatek: commit message mischaracterizes bug severity as memory leak instead of kernel panic
--

commit a61ee7f5e1c349f92340b7b9ebe198a23e34b370
Author: Akari Tsuyukusa <akkun11.open@gmail.com>
clk: mediatek: mt6795: Fix memory leak on module removal

This commit adds platform_set_drvdata() to the probe functions of three
MediaTek MT6795 clock drivers to properly store the clock data. The commit
message states this missing initialization caused a memory leak during
module removal.

>     clk-mt6795-apmixedsys.c, clk-mt6795-infracfg.c and clk-mt6795-pericfg.c
>     do not call platform_set_drvdata() during their driver probe callback,
>     but their remove callback calls platform_get_drvdata().
>     This results in platform_get_drvdata() returning NULL, which leads to
>     calling kfree(NULL) in mtk_free_clk_data(NULL).
>     This leaves clk_data unreleased, causing a memory leak.

[Severity: Low]
Does the missing platform_set_drvdata() actually cause a kernel panic rather
than a memory leak?

Looking at clk_mt6795_apmixed_remove(), clk_data is dereferenced before
mtk_free_clk_data() is called:

drivers/clk/mediatek/clk-mt6795-apmixedsys.c:clk_mt6795_apmixed_remove() {
	...
	struct clk_hw_onecell_data *clk_data = platform_get_drvdata(pdev);

	...
	mtk_clk_unregister_ref2usb_tx(clk_data->hws[CLK_APMIXED_REF2USB_TX]);
	...
}

If clk_data is NULL, accessing clk_data->hws will cause a NULL pointer
dereference.

Similarly, in clk_mt6795_infracfg_remove(), mtk_clk_unregister_cpumuxes()
is called with the NULL clk_data:

drivers/clk/mediatek/clk-cpumux.c:mtk_clk_unregister_cpumuxes() {
	...
	for (i = num; i > 0; i--) {
		const struct mtk_composite *mux = &clks[i - 1];

		if (IS_ERR_OR_NULL(clk_data->hws[mux->id]))
			continue;
	...
}

This also dereferences the NULL pointer before reaching mtk_free_clk_data().

Could the commit message be updated to reflect that this fixes a kernel panic
during driver unbind?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013151734.3177690-1-akkun11.open@gmail.com?part=2