All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ACPICA: Fix memory leak then namespace lookup fails
@ 2024-04-03  0:47 Armin Wolf
  2024-04-08 14:29 ` Rafael J. Wysocki
  0 siblings, 1 reply; 4+ messages in thread
From: Armin Wolf @ 2024-04-03  0:47 UTC (permalink / raw)
  To: robert.moore, rafael.j.wysocki, lenb
  Cc: dmantipov, linux-acpi, acpica-devel, linux-kernel

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, causing a memory leak.

Fix this by freeing the acpi_parse_object when encountering an
error.

Tested-by: Dmitry Antipov <dmantipov@yandex.ru>
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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPICA: Fix memory leak then namespace lookup fails
  2024-04-03  0:47 [PATCH] ACPICA: Fix memory leak then namespace lookup fails Armin Wolf
@ 2024-04-08 14:29 ` Rafael J. Wysocki
  2024-04-12 16:16   ` Armin Wolf
  0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2024-04-08 14:29 UTC (permalink / raw)
  To: Armin Wolf
  Cc: robert.moore, rafael.j.wysocki, lenb, dmantipov, linux-acpi,
	acpica-devel, linux-kernel

On Wed, Apr 3, 2024 at 2:47 AM Armin Wolf <W_Armin@gmx.de> wrote:
>
> 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, causing a memory leak.
>
> Fix this by freeing the acpi_parse_object when encountering an
> error.
>
> Tested-by: Dmitry Antipov <dmantipov@yandex.ru>
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>

Because ACPICA is an external project supplying code to the Linux
kernel, the way to change the ACPICA code in the kernel is to submit a
pull request to the upstream ACPICA project on GitHub and once that PR
has been merged, submit a Linux patch corresponding to it including
the Link: tag pointing to the PR in question and the git ID of the
corresponding upstream ACPICA commit.

However, note that upstream ACPICA commits are automatically included
into the Linux kernel source code every time the upstream ACPICA
project makes a release, so it is not necessary to send the
corresponding Linux patches for them unless in the cases when timing
matters.

> ---
>  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
>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPICA: Fix memory leak then namespace lookup fails
  2024-04-08 14:29 ` Rafael J. Wysocki
@ 2024-04-12 16:16   ` Armin Wolf
  2024-04-12 17:07     ` Dmitry Antipov
  0 siblings, 1 reply; 4+ messages in thread
From: Armin Wolf @ 2024-04-12 16:16 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: robert.moore, rafael.j.wysocki, lenb, dmantipov, linux-acpi,
	acpica-devel, linux-kernel

Am 08.04.24 um 16:29 schrieb Rafael J. Wysocki:

> On Wed, Apr 3, 2024 at 2:47 AM Armin Wolf <W_Armin@gmx.de> wrote:
>> 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, causing a memory leak.
>>
>> Fix this by freeing the acpi_parse_object when encountering an
>> error.
>>
>> Tested-by: Dmitry Antipov <dmantipov@yandex.ru>
>> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> Because ACPICA is an external project supplying code to the Linux
> kernel, the way to change the ACPICA code in the kernel is to submit a
> pull request to the upstream ACPICA project on GitHub and once that PR
> has been merged, submit a Linux patch corresponding to it including
> the Link: tag pointing to the PR in question and the git ID of the
> corresponding upstream ACPICA commit.
>
> However, note that upstream ACPICA commits are automatically included
> into the Linux kernel source code every time the upstream ACPICA
> project makes a release, so it is not necessary to send the
> corresponding Linux patches for them unless in the cases when timing
> matters.

I submitted a PR to upstream ACPICA and the changes where accepted.

Dmitry, do you think that this memory leak is critical? If not, then i think
we can wait till the next ACPICA release.

Thanks,
Armin Wolf

>> ---
>>   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
>>
>>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPICA: Fix memory leak then namespace lookup fails
  2024-04-12 16:16   ` Armin Wolf
@ 2024-04-12 17:07     ` Dmitry Antipov
  0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Antipov @ 2024-04-12 17:07 UTC (permalink / raw)
  To: Armin Wolf, Rafael J. Wysocki
  Cc: robert.moore, rafael.j.wysocki, lenb, linux-acpi, acpica-devel,
	linux-kernel

On 4/12/24 19:16, Armin Wolf wrote:

> Dmitry, do you think that this memory leak is critical? If not, then i think
> we can wait till the next ACPICA release.

Hopefully not too critical. The leak itself is small, and it's highly depended
from the particular notebook model and/or UEFI BIOS revision, so it should be
safe to wait.

Dmitry


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-04-12 17:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-03  0:47 [PATCH] ACPICA: Fix memory leak then namespace lookup fails Armin Wolf
2024-04-08 14:29 ` Rafael J. Wysocki
2024-04-12 16:16   ` Armin Wolf
2024-04-12 17:07     ` Dmitry Antipov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.