[PATCH] thermal/drivers/rcar_thermal: fix list_first_entry on possibly empty sensor list in suspend/resume

[PATCH] thermal/drivers/rcar_thermal: fix list_first_entry on possibly empty sensor list in suspend/resume

[Li Ximo]

From: Wang Haoran <haoranwangsec@gmail.com>

rcar_thermal_suspend() and rcar_thermal_resume() call
list_first_entry(&common->head, ...) without checking whether the list
is empty. list_first_entry() does not return NULL for an empty list; it
returns the container_of() of the list head pointer, i.e. a wild pointer
into struct rcar_thermal_common. Dereferencing it at
priv->chip->needs_suspend_resume (and the MMIO accesses through
priv->base that follow) is undefined behavior and can corrupt memory or
crash the kernel.

The list can indeed be empty: rcar_thermal_probe() only adds a sensor to
common->head after platform_get_resource() succeeds, and it returns
success even when zero sensors were probed (no i == 0 check before
"return 0"). With a malformed DT node (no MEM resource) the driver binds
successfully with an empty list, and the PM core then unconditionally
invokes the suspend/resume callbacks. This was found by code audit; we
do not have R-Car hardware to reproduce it at runtime.

Fix both callbacks by switching to list_first_entry_or_null() and
returning 0 early when the sensor list is empty. This matches how the
rest of the driver already tolerates an empty list via the
list_for_each_entry()-based rcar_thermal_for_each_priv() iterator used
in remove and IRQ handling, and does not change behavior on the normal
non-empty path.

Reported-by: Wang Haoran <haoranwangsec@gmail.com>
Reported-by: Li Ximo <lixicaicai@gmail.com>
Signed-off-by: Wang Haoran <haoranwangsec@gmail.com>
---
 drivers/thermal/renesas/rcar_thermal.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/renesas/rcar_thermal.c b/drivers/thermal/renesas/rcar_thermal.c
index 9a9038671..65dba6354 100644
--- a/drivers/thermal/renesas/rcar_thermal.c
+++ b/drivers/thermal/renesas/rcar_thermal.c
@@ -530,8 +530,11 @@ static int rcar_thermal_probe(struct platform_device *pdev)
 static int rcar_thermal_suspend(struct device *dev)
 {
 	struct rcar_thermal_common *common = dev_get_drvdata(dev);
-	struct rcar_thermal_priv *priv = list_first_entry(&common->head,
-							  typeof(*priv), list);
+	struct rcar_thermal_priv *priv = list_first_entry_or_null(&common->head,
+								  typeof(*priv), list);
+
+	if (!priv)
+		return 0;
 
 	if (priv->chip->needs_suspend_resume) {
 		rcar_thermal_common_write(common, ENR, 0);
@@ -545,10 +548,13 @@ static int rcar_thermal_suspend(struct device *dev)
 static int rcar_thermal_resume(struct device *dev)
 {
 	struct rcar_thermal_common *common = dev_get_drvdata(dev);
-	struct rcar_thermal_priv *priv = list_first_entry(&common->head,
-							  typeof(*priv), list);
+	struct rcar_thermal_priv *priv = list_first_entry_or_null(&common->head,
+								  typeof(*priv), list);
 	int ret;
 
+	if (!priv)
+		return 0;
+
 	if (priv->chip->needs_suspend_resume) {
 		ret = rcar_thermal_update_temp(priv);
 		if (ret < 0)
-- 
2.30.2

Re: [PATCH] thermal/drivers/rcar_thermal: fix list_first_entry on possibly empty sensor list in suspend/resume

[Niklas Söderlund]

Hello Li,

Thanks for your work.

On 2026-10-26 19:50:18 +0800, Li Ximo wrote:
> From: Wang Haoran <haoranwangsec@gmail.com>
> 
> rcar_thermal_suspend() and rcar_thermal_resume() call
> list_first_entry(&common->head, ...) without checking whether the list
> is empty. list_first_entry() does not return NULL for an empty list; it
> returns the container_of() of the list head pointer, i.e. a wild pointer
> into struct rcar_thermal_common. Dereferencing it at
> priv->chip->needs_suspend_resume (and the MMIO accesses through
> priv->base that follow) is undefined behavior and can corrupt memory or
> crash the kernel.
> 
> The list can indeed be empty: rcar_thermal_probe() only adds a sensor to
> common->head after platform_get_resource() succeeds, and it returns
> success even when zero sensors were probed (no i == 0 check before
> "return 0"). With a malformed DT node (no MEM resource) the driver binds
> successfully with an empty list, and the PM core then unconditionally
> invokes the suspend/resume callbacks. This was found by code audit; we
> do not have R-Car hardware to reproduce it at runtime.

Could you please audit the code some more, preferably without an LLM.  
While I agree the issue should be solved this is not the fix.

Nacked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

Does it make sens to allow probe to succeed if we haver a malformed DT 
node? Would a nicer fix not be to fail probe with -ENODEV in that case?

> 
> Fix both callbacks by switching to list_first_entry_or_null() and
> returning 0 early when the sensor list is empty. This matches how the
> rest of the driver already tolerates an empty list via the
> list_for_each_entry()-based rcar_thermal_for_each_priv() iterator used
> in remove and IRQ handling, and does not change behavior on the normal
> non-empty path.
> 
> Reported-by: Wang Haoran <haoranwangsec@gmail.com>
> Reported-by: Li Ximo <lixicaicai@gmail.com>
> Signed-off-by: Wang Haoran <haoranwangsec@gmail.com>
> ---
>  drivers/thermal/renesas/rcar_thermal.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/thermal/renesas/rcar_thermal.c b/drivers/thermal/renesas/rcar_thermal.c
> index 9a9038671..65dba6354 100644
> --- a/drivers/thermal/renesas/rcar_thermal.c
> +++ b/drivers/thermal/renesas/rcar_thermal.c
> @@ -530,8 +530,11 @@ static int rcar_thermal_probe(struct platform_device *pdev)
>  static int rcar_thermal_suspend(struct device *dev)
>  {
>  	struct rcar_thermal_common *common = dev_get_drvdata(dev);
> -	struct rcar_thermal_priv *priv = list_first_entry(&common->head,
> -							  typeof(*priv), list);
> +	struct rcar_thermal_priv *priv = list_first_entry_or_null(&common->head,
> +								  typeof(*priv), list);
> +
> +	if (!priv)
> +		return 0;
>  
>  	if (priv->chip->needs_suspend_resume) {
>  		rcar_thermal_common_write(common, ENR, 0);
> @@ -545,10 +548,13 @@ static int rcar_thermal_suspend(struct device *dev)
>  static int rcar_thermal_resume(struct device *dev)
>  {
>  	struct rcar_thermal_common *common = dev_get_drvdata(dev);
> -	struct rcar_thermal_priv *priv = list_first_entry(&common->head,
> -							  typeof(*priv), list);
> +	struct rcar_thermal_priv *priv = list_first_entry_or_null(&common->head,
> +								  typeof(*priv), list);
>  	int ret;
>  
> +	if (!priv)
> +		return 0;
> +
>  	if (priv->chip->needs_suspend_resume) {
>  		ret = rcar_thermal_update_temp(priv);
>  		if (ret < 0)
> -- 
> 2.30.2
> 

-- 
Kind Regards,
Niklas Söderlund