Linux clock framework development
 help / color / mirror / Atom feed
* [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()
@ 2026-10-09  6:18 Haotian Zhang
  2026-10-09  6:33 ` sashiko-bot
  2026-10-09  9:41 ` Krzysztof Kozlowski
  0 siblings, 2 replies; 4+ messages in thread
From: Haotian Zhang @ 2026-10-09  6:18 UTC (permalink / raw)
  To: Stephen Boyd, Brian Masney, Jerome Brunet, Michal Simek,
	Michael Tretter
  Cc: linux-clk, linux-arm-kernel, linux-kernel

xvcu_clk_hw_unregister_leaf() gets the mux with
clk_hw_get_parent(divider), which returns NULL when the divider has no
parent, and passes it to clk_hw_unregister_mux() without checking it.
The following check tests the wrong variable: divider has already been
verified to be non-NULL at this point, so "if (!divider) return;" is
dead code and a NULL mux is dereferenced, crashing in
clk_hw_unregister_mux().

Only unregister the mux when it is non-NULL, and always release the
divider.

Fixes: 9c789deea206 ("soc: xilinx: vcu: implement clock provider for output clocks")
Assisted-by: DeepSeek-V4.1-Flash
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
---
 drivers/clk/xilinx/xlnx_vcu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c
index f14bda375e35..b004c16692d3 100644
--- a/drivers/clk/xilinx/xlnx_vcu.c
+++ b/drivers/clk/xilinx/xlnx_vcu.c
@@ -516,9 +516,8 @@ static void xvcu_clk_hw_unregister_leaf(struct clk_hw *hw)
 		return;
 
 	mux = clk_hw_get_parent(divider);
-	clk_hw_unregister_mux(mux);
-	if (!divider)
-		return;
+	if (mux)
+		clk_hw_unregister_mux(mux);
 
 	clk_hw_unregister_divider(divider);
 }
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()
  2026-10-09  6:18 [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf() Haotian Zhang
@ 2026-10-09  6:33 ` sashiko-bot
  2026-10-09  9:10   ` Jerome Brunet
  2026-10-09  9:41 ` Krzysztof Kozlowski
  1 sibling, 1 reply; 4+ messages in thread
From: sashiko-bot @ 2026-10-09  6:33 UTC (permalink / raw)
  To: Haotian Zhang; +Cc: linux-clk

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] clk: xilinx: Use-After-Free due to incorrect child/parent unregister order
- [High] clk: xilinx: UAF race during removal due to mixed devm/manual cleanup
--

commit 7f74ba5d4aed358cc163ed1eb7e56a50f1f385b0
Author: Haotian Zhang <vulab@iscas.ac.cn>

clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()

This commit addresses a NULL pointer dereference when a divider has no parent
by checking that the mux is non-NULL before calling clk_hw_unregister_mux().
It also removes dead code that erroneously checked the divider instead of the
mux.

> diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c
> index ccd9d7c0b1809..58a9762ef20a9 100644
> --- a/drivers/clk/xilinx/xlnx_vcu.c
> +++ b/drivers/clk/xilinx/xlnx_vcu.c
> @@ -516,9 +516,8 @@ static void xvcu_clk_hw_unregister_leaf(struct clk_hw *hw)
>  		return;
>  
>  	mux = clk_hw_get_parent(divider);
> -	clk_hw_unregister_mux(mux);
> -	if (!divider)
> -		return;
> +	if (mux)
> +		clk_hw_unregister_mux(mux);
>  
>  	clk_hw_unregister_divider(divider);

[Severity: High]
Does this unregister the parent mux before the child divider, leading to a
use-after-free?

Calling clk_hw_unregister_mux() first reparents the divider to the orphan
list, but leaves divider->core->parents[0].hw pointing to the mux struct before
the memory is freed by the mux unregistration.

If a concurrent thread registers a new clock, the clock framework invokes
clk_core_reparent_orphans_nolock() to try resolving orphans. It iterates the
orphan list, finds the divider, and calls clk_core_fill_parent_index(), which
reads the dangling entry->hw pointer and dereferences it:

drivers/clk/clk.c:clk_core_fill_parent_index() {
    ...
	if (entry->hw) {
		parent = entry->hw->core;
    ...
}

Should the teardown strictly follow leaf-to-root order (gate -> divider -> mux)
to prevent orphaned children from dereferencing freed parent pointers during
concurrent reparenting?


[Severity: High]
Does this manual cleanup race with the devres-managed OF provider removal?

Because xvcu_register_clock_provider() registers the OF clock provider using
devm_of_clk_add_hw_provider(), the OF provider isn't removed from the global
clock provider list until the devres cleanup phase, which executes after
xvcu_remove() returns.

By manually freeing the hardware structures here during xvcu_remove(), the
active OF provider is left with dangling pointers in its internal hws array.
If a concurrent consumer invokes clk_get() during this window,
of_clk_hw_onecell_get() could yield a freed clk_hw pointer, resulting in a
use-after-free in the clock framework.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009061805.3172589-1-vulab@iscas.ac.cn?part=1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()
  2026-10-09  6:33 ` sashiko-bot
@ 2026-10-09  9:10   ` Jerome Brunet
  0 siblings, 0 replies; 4+ messages in thread
From: Jerome Brunet @ 2026-10-09  9:10 UTC (permalink / raw)
  To: sashiko-reviews, Haotian Zhang; +Cc: linux-clk

On ven. 09 oct. 2026 at 06:33, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] clk: xilinx: Use-After-Free due to incorrect child/parent unregister order
> - [High] clk: xilinx: UAF race during removal due to mixed devm/manual cleanup
> --
>
> commit 7f74ba5d4aed358cc163ed1eb7e56a50f1f385b0
> Author: Haotian Zhang <vulab@iscas.ac.cn>
>
> clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()
>
> This commit addresses a NULL pointer dereference when a divider has no parent
> by checking that the mux is non-NULL before calling clk_hw_unregister_mux().
> It also removes dead code that erroneously checked the divider instead of the
> mux.
>
>> diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c
>> index ccd9d7c0b1809..58a9762ef20a9 100644
>> --- a/drivers/clk/xilinx/xlnx_vcu.c
>> +++ b/drivers/clk/xilinx/xlnx_vcu.c
>> @@ -516,9 +516,8 @@ static void xvcu_clk_hw_unregister_leaf(struct clk_hw *hw)
>>  		return;
>>  
>>  	mux = clk_hw_get_parent(divider);
>> -	clk_hw_unregister_mux(mux);

should deregister the divider here

>> -	if (!divider)
>> -		return;
>> +	if (mux)
>> +		clk_hw_unregister_mux(mux);
>>  
>>  	clk_hw_unregister_divider(divider);

this last line should be removed

>
> [Severity: High]
> Does this unregister the parent mux before the child divider, leading to a
> use-after-free?

Yes, the function clearly has a copy paste error than you should address properly.

>
> Calling clk_hw_unregister_mux() first reparents the divider to the orphan
> list, but leaves divider->core->parents[0].hw pointing to the mux struct before
> the memory is freed by the mux unregistration.
>
> If a concurrent thread registers a new clock, the clock framework invokes
> clk_core_reparent_orphans_nolock() to try resolving orphans. It iterates the
> orphan list, finds the divider, and calls clk_core_fill_parent_index(), which
> reads the dangling entry->hw pointer and dereferences it:
>
> drivers/clk/clk.c:clk_core_fill_parent_index() {
>     ...
> 	if (entry->hw) {
> 		parent = entry->hw->core;
>     ...
> }
>
> Should the teardown strictly follow leaf-to-root order (gate -> divider -> mux)
> to prevent orphaned children from dereferencing freed parent pointers during
> concurrent reparenting?
>
>
> [Severity: High]
> Does this manual cleanup race with the devres-managed OF provider removal?
>
> Because xvcu_register_clock_provider() registers the OF clock provider using
> devm_of_clk_add_hw_provider(), the OF provider isn't removed from the global
> clock provider list until the devres cleanup phase, which executes after
> xvcu_remove() returns.
>
> By manually freeing the hardware structures here during xvcu_remove(), the
> active OF provider is left with dangling pointers in its internal hws array.
> If a concurrent consumer invokes clk_get() during this window,
> of_clk_hw_onecell_get() could yield a freed clk_hw pointer, resulting in a
> use-after-free in the clock framework.
>
>>  }
>
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261009061805.3172589-1-vulab@iscas.ac.cn?part=1

-- 
Jerome

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf()
  2026-10-09  6:18 [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf() Haotian Zhang
  2026-10-09  6:33 ` sashiko-bot
@ 2026-10-09  9:41 ` Krzysztof Kozlowski
  1 sibling, 0 replies; 4+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-09  9:41 UTC (permalink / raw)
  To: Haotian Zhang, Stephen Boyd, Brian Masney, Jerome Brunet,
	Michal Simek, Michael Tretter
  Cc: linux-clk, linux-arm-kernel, linux-kernel

On 09/10/2026 08:18, Haotian Zhang wrote:
> xvcu_clk_hw_unregister_leaf() gets the mux with
> clk_hw_get_parent(divider), which returns NULL when the divider has no
> parent, and passes it to clk_hw_unregister_mux() without checking it.
> The following check tests the wrong variable: divider has already been
> verified to be non-NULL at this point, so "if (!divider) return;" is
> dead code and a NULL mux is dereferenced, crashing in
> clk_hw_unregister_mux().
> 
> Only unregister the mux when it is non-NULL, and always release the
> divider.

So you fired up your OpenClaw or whatever LLM tool and don't bother to
slow down, right?

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-10-09  9:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-09  6:18 [PATCH] clk: xilinx: fix NULL pointer dereference in xvcu_clk_hw_unregister_leaf() Haotian Zhang
2026-10-09  6:33 ` sashiko-bot
2026-10-09  9:10   ` Jerome Brunet
2026-10-09  9:41 ` Krzysztof Kozlowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox