[PATCH] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()

Miaoqian Lin posted 1 patch 1 month ago
drivers/acpi/arm64/iort.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
[PATCH] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()
Posted by Miaoqian Lin 1 month ago
If krealloc_array() fails in iort_rmr_alloc_sids(), the function returns
NULL but does not free the original 'sids' allocation. This results in a
memory leak since the caller overwrites the original pointer with the
NULL return value.

Fixes: 491cf4a6735a ("ACPI/IORT: Add support to retrieve IORT RMR reserved regions")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
This follows the same pattern as the fix in commit 06615967d488
("bpf, verifier: Fix memory leak in array reallocation for stack state").
---
 drivers/acpi/arm64/iort.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 98759d6199d3..65f0f56ad753 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -937,8 +937,10 @@ static u32 *iort_rmr_alloc_sids(u32 *sids, u32 count, u32 id_start,
 
 	new_sids = krealloc_array(sids, count + new_count,
 				  sizeof(*new_sids), GFP_KERNEL);
-	if (!new_sids)
+	if (!new_sids) {
+		kfree(sids);
 		return NULL;
+	}
 
 	for (i = count; i < total_count; i++)
 		new_sids[i] = id_start++;
-- 
2.39.5 (Apple Git-154)
Re: [PATCH] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()
Posted by Catalin Marinas 3 weeks, 6 days ago
On Thu, 28 Aug 2025 19:22:43 +0800, Miaoqian Lin wrote:
> If krealloc_array() fails in iort_rmr_alloc_sids(), the function returns
> NULL but does not free the original 'sids' allocation. This results in a
> memory leak since the caller overwrites the original pointer with the
> NULL return value.
> 
> 

Applied to arm64 (for-next/fixes), thanks!

[1/1] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()
      https://git.kernel.org/arm64/c/f3ef7110924b

-- 
Catalin
Re: [PATCH] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()
Posted by Markus Elfring 1 month ago
> If krealloc_array() fails in iort_rmr_alloc_sids(), the function returns
> NULL but does not free the original 'sids' allocation. …

See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17-rc4#n94


…
> ---
> This follows the same pattern as the fix in commit 06615967d488
> ("bpf, verifier: Fix memory leak in array reallocation for stack state").
…

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.17-rc4&id=42378a9ca55347102bbf86708776061d8fe3ece2

Regards,
Markus
Re: [PATCH] ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()
Posted by Hanjun Guo 1 month ago
+Cc Catalin, Will

On 2025/8/28 19:22, Miaoqian Lin wrote:
> If krealloc_array() fails in iort_rmr_alloc_sids(), the function returns
> NULL but does not free the original 'sids' allocation. This results in a
> memory leak since the caller overwrites the original pointer with the
> NULL return value.
> 
> Fixes: 491cf4a6735a ("ACPI/IORT: Add support to retrieve IORT RMR reserved regions")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> ---
> This follows the same pattern as the fix in commit 06615967d488
> ("bpf, verifier: Fix memory leak in array reallocation for stack state").
> ---
>   drivers/acpi/arm64/iort.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 98759d6199d3..65f0f56ad753 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -937,8 +937,10 @@ static u32 *iort_rmr_alloc_sids(u32 *sids, u32 count, u32 id_start,
>   
>   	new_sids = krealloc_array(sids, count + new_count,
>   				  sizeof(*new_sids), GFP_KERNEL);
> -	if (!new_sids)
> +	if (!new_sids) {
> +		kfree(sids);
>   		return NULL;
> +	}
>   
>   	for (i = count; i < total_count; i++)
>   		new_sids[i] = id_start++;

Good catch!

Reviewed-by: Hanjun Guo <guohanjun@huawei.com>

Thanks
Hanjun