[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-acpi
Subject:    Re: ACPI BIOS bug and memory leak?
From:       Armin Wolf <W_Armin () gmx ! de>
Date:       2024-03-31 2:46:33
Message-ID: cb9c17e4-53f0-4579-879a-0a8fa1352fb9 () gmx ! de
[Download RAW message or body]

Am 27.03.24 um 11:48 schrieb Dmitry Antipov:

> Is it possible that this:
>
> [=C2=A0=C2=A0=C2=A0 7.727080] ACPI BIOS Error (bug): Could not resolve s=
ymbol
> [\_TZ.ETMD], AE_NOT_FOUND (20230628/psargs-335)
> [=C2=A0=C2=A0=C2=A0 7.728470] ACPI Error: Aborting method \_SB.IETM._OSC=
 due to
> previous error (AE_NOT_FOUND) (20230628/psparse-529)
>
> is somehow related to:
>
> unreferenced object 0xffff944e85013d58 (size 56):
> =C2=A0 comm "thermald", pid 966, jiffies 4294674933
> =C2=A0 hex dump (first 32 bytes):
> =C2=A0=C2=A0=C2=A0 00 00 00 00 00 00 00 00 0d 01 2d 00 00 00 00 00 .....=
.....-.....
> =C2=A0=C2=A0=C2=A0 94 8c 05 80 51 b8 ff ff 00 00 00 00 00 00 00 00 ....Q=
...........
> =C2=A0 backtrace (crc 41e9984d):
> =C2=A0=C2=A0=C2=A0 [<000000004b53f9d1>] kmem_cache_alloc+0x256/0x340
> =C2=A0=C2=A0=C2=A0 [<000000008d9ead3a>] acpi_ps_alloc_op+0xbf/0xd0
> =C2=A0=C2=A0=C2=A0 [<000000002f1e617e>] acpi_ps_get_next_arg+0xbb/0x6a0
> =C2=A0=C2=A0=C2=A0 [<00000000b697bac7>] acpi_ps_parse_loop+0x466/0x6b0
> =C2=A0=C2=A0=C2=A0 [<000000008dbc2acb>] acpi_ps_parse_aml+0x80/0x3c0
> =C2=A0=C2=A0=C2=A0 [<00000000b26066ae>] acpi_ps_execute_method+0x13f/0x2=
70
> =C2=A0=C2=A0=C2=A0 [<00000000f80592ab>] acpi_ns_evaluate+0x12b/0x2c0
> =C2=A0=C2=A0=C2=A0 [<00000000bbc91886>] acpi_evaluate_object+0x14e/0x310
> =C2=A0=C2=A0=C2=A0 [<000000005729c43d>] acpi_run_osc+0x158/0x270
> =C2=A0=C2=A0=C2=A0 [<00000000e6666993>] int3400_thermal_run_osc+0x73/0xc=
0
> [int3400_thermal]
> =C2=A0=C2=A0=C2=A0 [<000000000a474314>] current_uuid_store+0xd5/0x110 [i=
nt3400_thermal]
> =C2=A0=C2=A0=C2=A0 [<00000000e27be786>] kernfs_fop_write_iter+0x13e/0x1f=
0
> =C2=A0=C2=A0=C2=A0 [<00000000992f9e08>] vfs_write+0x293/0x460
> =C2=A0=C2=A0=C2=A0 [<000000008b9e130c>] ksys_write+0x6d/0xf0
> =C2=A0=C2=A0=C2=A0 [<000000007d501d09>] do_syscall_64+0x85/0x170
> =C2=A0=C2=A0=C2=A0 [<0000000073c5a34b>] entry_SYSCALL_64_after_hwframe+0=
x6c/0x74
>
> (recently observed on 6.9.0-rc1)
>
> Dmitry
>
Hi,

i thing the memory leak happens in acpi_ps_get_next_arg(). After allocatin=
g an acpi_parse_object in line 820 of psargs.c,
calling of acpi_ps_get_next_namepath() fails due to to the missing symbol.=
 The code now returns the error without freeing
the acpi_parse_object, causing a memory leak.

IMHO the solution would be to call acpi_ps_free_op() in case of an error b=
efore returning said error code. I attached an
experimental patch which might fix this, but it is still untested. If you =
want you can test if it solves the problem.

Thanks,
Armin Wolf

["0001-ACPICA-Fix-memory-leak-then-namespace-lookup-fails.patch" (text/x-patch)]

From 650c010ef7841bebbacc074f359909e84633b4f8 Mon Sep 17 00:00:00 2001
From: Armin Wolf <W_Armin@gmx.de>
Date: Sun, 31 Mar 2024 04:39:54 +0200
Subject: [PATCH] ACPICA: Fix memory leak then namespace lookup fails

When acpi_ps_get_next_namepath() fails due to a namespace lookup
failure, the acpi_parse_object is not freed before returning the
error code, casuing a memory leak.

Fix this by freeing the acpi_parse_object when encountering an
error.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
 drivers/acpi/acpica/psargs.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/acpica/psargs.c b/drivers/acpi/acpica/psargs.c
index 422c074ed289..7debfd5ce0d8 100644
--- a/drivers/acpi/acpica/psargs.c
+++ b/drivers/acpi/acpica/psargs.c
@@ -820,6 +820,10 @@ acpi_ps_get_next_arg(struct acpi_walk_state *walk_state,
 			    acpi_ps_get_next_namepath(walk_state, parser_state,
 						      arg,
 						      ACPI_NOT_METHOD_CALL);
+			if (ACPI_FAILURE(status)) {
+				acpi_ps_free_op(arg);
+				return_ACPI_STATUS(status);
+			}
 		} else {
 			/* Single complex argument, nothing returned */
 
@@ -854,6 +858,10 @@ acpi_ps_get_next_arg(struct acpi_walk_state *walk_state,
 			    acpi_ps_get_next_namepath(walk_state, parser_state,
 						      arg,
 						      ACPI_POSSIBLE_METHOD_CALL);
+			if (ACPI_FAILURE(status)) {
+				acpi_ps_free_op(arg);
+				return_ACPI_STATUS(status);
+			}
 
 			if (arg->common.aml_opcode == AML_INT_METHODCALL_OP) {
 
-- 
2.39.2



[prev in list] [next in list] [prev in thread] [next in thread]