linux-kernel - RE: [GIT PULL] ACPI fix for v4.18-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <db31a9d497ce2ef0f4b51eeb76729278@natalenko.name>
Date:   Sat, 28 Jul 2018 18:59:12 +0200
From:   Oleksandr Natalenko <oleksandr@...alenko.name>
To:     erik.schmauss@...el.com
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        rafael@...nel.org, torvalds@...ux-foundation.org
Subject: RE: [GIT PULL] ACPI fix for v4.18-rc7

Hi.

> From a828a091828599154d8f6e8bfee1495a3df5cf34 Mon Sep 17 00:00:00 2001
> From: Erik Schmauss <erik.schmauss@...el.com>
> Date: Fri, 27 Jul 2018 15:37:35 -0700
> From: Erik Schmauss <erik.schmauss@...el.com>
> Subject: [PATCH 1] ACPICA: AML Parser: ignore control method status in 
> module-level code
> 
> Previous change in the AML parser code blindly set all non-successful
> dispatcher statuses to AE_OK. This approach is incorrect because
> successful control method invocations from module-level return
> AE_CTRL_TRANSFER. Overwriting AE_OK to this status causes the AML
> parser to think that there was no return value from the control
> method invocation.
> 
> fixes: 73c2a01c52b6 (ACPICA: AML Parser: ignore dispatcher error status 
> during table load)
> 
> Reported-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Erik Schmauss <erik.schmauss@...el.com>
> ---
>  psloop.c |   19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff -Nurp linux.before_name/drivers/acpi/acpica/psloop.c 
> linux.after_name/drivers/acpi/acpica/psloop.c
> --- linux.before_name/drivers/acpi/acpica/psloop.c	2018-07-27 
> 15:53:31.073522915 -0700
> +++ linux.after_name/drivers/acpi/acpica/psloop.c	2018-07-27 
> 15:53:25.320522527 -0700
> @@ -714,15 +714,20 @@ acpi_status acpi_ps_parse_loop(struct ac
>  			} else
>  			    if ((walk_state->
>  				 parse_flags & ACPI_PARSE_MODULE_LEVEL)
> +				&& status != AE_CTRL_TRANSFER
>  				&& ACPI_FAILURE(status)) {
>  				/*
> -				 * ACPI_PARSE_MODULE_LEVEL means that we are loading a table by
> -				 * executing it as a control method. However, if we encounter
> -				 * an error while loading the table, we need to keep trying to
> -				 * load the table rather than aborting the table load. Set the
> -				 * status to AE_OK to proceed with the table load. If we get a
> -				 * failure at this point, it means that the dispatcher got an
> -				 * error while processing Op (most likely an AML operand error.
> +				 * ACPI_PARSE_MODULE_LEVEL flag means that we are currently
> +				 * loading a table by executing it as a control method.
> +				 * However, if we encounter an error while loading the table,
> +				 * we need to keep trying to load the table rather than
> +				 * aborting the table load (setting the status to AE_OK
> +				 * continues the table load). If we get a failure at this
> +				 * point, it means that the dispatcher got an error while
> +				 * processing Op (most likely an AML operand error) or a
> +				 * control method was called from module level and the
> +				 * dispatcher returned AE_CTRL_TRANSFER. In the latter case,
> +				 * leave the status alone, there's nothing wrong with it.
>  				 */
>  				status = AE_OK;
>  			}

Faced the same on my Dell Vostro 3360 with v4.17.11 update, and 
confirming that this patch fixes the issue for me too.

Thus,

Tested-by: Oleksandr Natalenko <oleksandr@...alenko.name>

Also, please Cc Greg once you do a submission, so v4.17 stable branch 
will be fixed too.

Thanks.

-- 
   Oleksandr Natalenko (post-factum)