From: Yongxin Liu yongxin.liu@windriver.com
The intel_pmc_ipc() function uses ACPI_ALLOCATE_BUFFER to allocate memory for the ACPI evaluation result but never frees it, causing a 192-byte memory leak on each call.
This leak is triggered during network interface initialization when the stmmac driver calls intel_mac_finish() -> intel_pmc_ipc().
unreferenced object 0xffff96a848d6ea80 (size 192): comm "dhcpcd", pid 541, jiffies 4294684345 hex dump (first 32 bytes): 04 00 00 00 05 00 00 00 98 ea d6 48 a8 96 ff ff ...........H.... 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ backtrace (crc b1564374): kmemleak_alloc+0x2d/0x40 __kmalloc_noprof+0x2fa/0x730 acpi_ut_initialize_buffer+0x83/0xc0 acpi_evaluate_object+0x29a/0x2f0 intel_pmc_ipc+0xfd/0x170 intel_mac_finish+0x168/0x230 stmmac_mac_finish+0x3d/0x50 phylink_major_config+0x22b/0x5b0 phylink_mac_initial_config.constprop.0+0xf1/0x1b0 phylink_start+0x8e/0x210 __stmmac_open+0x12c/0x2b0 stmmac_open+0x23c/0x380 __dev_open+0x11d/0x2c0 __dev_change_flags+0x1d2/0x250 netif_change_flags+0x2b/0x70 dev_change_flags+0x40/0xb0
Add kfree() to properly release the allocated buffer.
Cc: stable@vger.kernel.org Fixes: 7e2f7e25f6ff ("arch: x86: add IPC mailbox accessor function and add SoC register access") Signed-off-by: Yongxin Liu yongxin.liu@windriver.com --- include/linux/platform_data/x86/intel_pmc_ipc.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/x86/intel_pmc_ipc.h b/include/linux/platform_data/x86/intel_pmc_ipc.h index 1d34435b7001..2fd5e684ce26 100644 --- a/include/linux/platform_data/x86/intel_pmc_ipc.h +++ b/include/linux/platform_data/x86/intel_pmc_ipc.h @@ -89,6 +89,7 @@ static inline int intel_pmc_ipc(struct pmc_ipc_cmd *ipc_cmd, struct pmc_ipc_rbuf return -EINVAL; }
+ kfree (obj); return 0; #else return -ENODEV;
On Mon, 24 Nov 2025, yongxin.liu@windriver.com wrote:
From: Yongxin Liu yongxin.liu@windriver.com
The intel_pmc_ipc() function uses ACPI_ALLOCATE_BUFFER to allocate memory for the ACPI evaluation result but never frees it, causing a 192-byte memory leak on each call.
This leak is triggered during network interface initialization when the stmmac driver calls intel_mac_finish() -> intel_pmc_ipc().
unreferenced object 0xffff96a848d6ea80 (size 192): comm "dhcpcd", pid 541, jiffies 4294684345 hex dump (first 32 bytes): 04 00 00 00 05 00 00 00 98 ea d6 48 a8 96 ff ff ...........H.... 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ backtrace (crc b1564374): kmemleak_alloc+0x2d/0x40 __kmalloc_noprof+0x2fa/0x730 acpi_ut_initialize_buffer+0x83/0xc0 acpi_evaluate_object+0x29a/0x2f0 intel_pmc_ipc+0xfd/0x170 intel_mac_finish+0x168/0x230 stmmac_mac_finish+0x3d/0x50 phylink_major_config+0x22b/0x5b0 phylink_mac_initial_config.constprop.0+0xf1/0x1b0 phylink_start+0x8e/0x210 __stmmac_open+0x12c/0x2b0 stmmac_open+0x23c/0x380 __dev_open+0x11d/0x2c0 __dev_change_flags+0x1d2/0x250 netif_change_flags+0x2b/0x70 dev_change_flags+0x40/0xb0
Add kfree() to properly release the allocated buffer.
Cc: stable@vger.kernel.org Fixes: 7e2f7e25f6ff ("arch: x86: add IPC mailbox accessor function and add SoC register access") Signed-off-by: Yongxin Liu yongxin.liu@windriver.com
include/linux/platform_data/x86/intel_pmc_ipc.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/x86/intel_pmc_ipc.h b/include/linux/platform_data/x86/intel_pmc_ipc.h index 1d34435b7001..2fd5e684ce26 100644 --- a/include/linux/platform_data/x86/intel_pmc_ipc.h +++ b/include/linux/platform_data/x86/intel_pmc_ipc.h @@ -89,6 +89,7 @@ static inline int intel_pmc_ipc(struct pmc_ipc_cmd *ipc_cmd, struct pmc_ipc_rbuf return -EINVAL; }
- kfree (obj);
Good catch but this fix doesn't address all possible paths. So please use cleanup.h instead:
union acpi_object *obj __free(kfree) = buffer.pointer;
And don't forget to add the #include.
return 0; #else return -ENODEV;
Good catch but this fix doesn't address all possible paths. So please use cleanup.h instead:
union acpi_object *obj __free(kfree) = buffer.pointer;
And don't forget to add the #include.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
1.6.5. Using device-managed and cleanup.h constructs¶
Low level cleanup constructs (such as __free()) can be used when building APIs and helpers, especially scoped iterators. However, direct use of __free() within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function.
Andrew
--- pw-bot: cr
-----Original Message----- From: Andrew Lunn andrew@lunn.ch Sent: Tuesday, November 25, 2025 8:30 To: Ilpo Järvinen ilpo.jarvinen@linux.intel.com Cc: Liu, Yongxin Yongxin.Liu@windriver.com; LKML <linux- kernel@vger.kernel.org>; Netdev netdev@vger.kernel.org; david.e.box@linux.intel.com; chao.qin@intel.com; yong.liang.choong@linux.intel.com; kuba@kernel.org; platform-driver- x86@vger.kernel.org; stable@vger.kernel.org Subject: Re: [PATCH net] platform/x86: intel_pmc_ipc: fix ACPI buffer memory leak
CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe.
Good catch but this fix doesn't address all possible paths. So please use cleanup.h instead:
union acpi_object *obj __free(kfree) = buffer.pointer;And don't forget to add the #include.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
1.6.5. Using device-managed and cleanup.h constructs¶
Low level cleanup constructs (such as __free()) can be used when building APIs and helpers, especially scoped iterators. However, direct use of __free() within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function.
Andrew
Thank you Ilpo and Andrew for your valuable review. I will send a V2 to cover all possible paths.
Thanks, Yongxin
pw-bot: cr
linux-stable-mirror@lists.linaro.org