[PATCH] platform/x86: intel: punit_ipc: fix memory corruption

Dan Carpenter posted 1 patch 1 week, 3 days ago
There is a newer version of this series
drivers/platform/x86/intel/punit_ipc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] platform/x86: intel: punit_ipc: fix memory corruption
Posted by Dan Carpenter 1 week, 3 days ago
This passes a stack address to the IRQ handler, "&punit_ipcdev" vs
"punit_ipcdev" without the ampersand.  This means that the:

	complete(&ipcdev->cmd_complete);

in intel_punit_ioc() will corrupt the wrong memory.

Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/platform/x86/intel/punit_ipc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel/punit_ipc.c b/drivers/platform/x86/intel/punit_ipc.c
index bafac8aa2baf..14513010daad 100644
--- a/drivers/platform/x86/intel/punit_ipc.c
+++ b/drivers/platform/x86/intel/punit_ipc.c
@@ -250,7 +250,7 @@ static int intel_punit_ipc_probe(struct platform_device *pdev)
 	} else {
 		ret = devm_request_irq(&pdev->dev, irq, intel_punit_ioc,
 				       IRQF_NO_SUSPEND, "intel_punit_ipc",
-				       &punit_ipcdev);
+				       punit_ipcdev);
 		if (ret) {
 			dev_err(&pdev->dev, "Failed to request irq: %d\n", irq);
 			return ret;
-- 
2.51.0
Re: [PATCH] platform/x86: intel: punit_ipc: fix memory corruption
Posted by Andy Shevchenko 1 week ago
On Fri, Nov 21, 2025 at 04:34:22PM +0300, Dan Carpenter wrote:
> This passes a stack address to the IRQ handler, "&punit_ipcdev" vs
> "punit_ipcdev" without the ampersand.  This means that the:
> 
> 	complete(&ipcdev->cmd_complete);
> 
> in intel_punit_ioc() will corrupt the wrong memory.

Good catch, now the question, how this driver was ever tested?..

-- 
With Best Regards,
Andy Shevchenko
Re: [PATCH] platform/x86: intel: punit_ipc: fix memory corruption
Posted by Ilpo Järvinen 1 week, 3 days ago
On Fri, 21 Nov 2025, Dan Carpenter wrote:

> This passes a stack address to the IRQ handler, "&punit_ipcdev" vs

This first part I don't get, why you think &punit_ipcdev is a stack 
address? The punit_ipcdev variable is defined in the global scope:

static IPC_DEV *punit_ipcdev;

> "punit_ipcdev" without the ampersand.  This means that the:
> 
> 	complete(&ipcdev->cmd_complete);
> 
> in intel_punit_ioc() will corrupt the wrong memory.

Can you please also rephrace "will corrupt the wrong memory" as it has
a bit awkward sound in it. My suggestion:

...will write to a wrong memory address corrupting it.

(I'd have done this edit myself but I wanted to ask about the stack 
address claim so better you just send v2.)

The change diff itself looks correct.

> Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>  drivers/platform/x86/intel/punit_ipc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel/punit_ipc.c b/drivers/platform/x86/intel/punit_ipc.c
> index bafac8aa2baf..14513010daad 100644
> --- a/drivers/platform/x86/intel/punit_ipc.c
> +++ b/drivers/platform/x86/intel/punit_ipc.c
> @@ -250,7 +250,7 @@ static int intel_punit_ipc_probe(struct platform_device *pdev)
>  	} else {
>  		ret = devm_request_irq(&pdev->dev, irq, intel_punit_ioc,
>  				       IRQF_NO_SUSPEND, "intel_punit_ipc",
> -				       &punit_ipcdev);
> +				       punit_ipcdev);
>  		if (ret) {
>  			dev_err(&pdev->dev, "Failed to request irq: %d\n", irq);
>  			return ret;
> 

-- 
 i.
Re: [PATCH] platform/x86: intel: punit_ipc: fix memory corruption
Posted by Dan Carpenter 1 week, 3 days ago
On Fri, Nov 21, 2025 at 07:27:54PM +0200, Ilpo Järvinen wrote:
> On Fri, 21 Nov 2025, Dan Carpenter wrote:
> 
> > This passes a stack address to the IRQ handler, "&punit_ipcdev" vs
> 
> This first part I don't get, why you think &punit_ipcdev is a stack 
> address? The punit_ipcdev variable is defined in the global scope:
> 
> static IPC_DEV *punit_ipcdev;

Ah, right.  Sorry.  I thought it was a local variable.

Yeah.  Let me resend this.

regards,
dan carpenter