Compare commits
5 commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
2034bc6bc0 | ||
|
1517179023 | ||
|
|
dd197c56b0 | ||
|
|
c31d4bd944 | ||
|
|
060346c679 |
7 changed files with 29 additions and 413 deletions
4
.gitignore
vendored
4
.gitignore
vendored
|
|
@ -162,3 +162,7 @@ series
|
|||
/acpitests-unix-20240321.tar.gz
|
||||
/acpica-unix2-20240322.tar.gz
|
||||
/acpitests-unix-20240322.tar.gz
|
||||
/acpica-unix2-20250807.tar.gz
|
||||
/acpitests-unix-20250807.tar.gz
|
||||
/acpica-unix2-20251212.tar.gz
|
||||
/acpitests-unix-20251212.tar.gz
|
||||
|
|
|
|||
|
|
@ -1,34 +0,0 @@
|
|||
From ec87f7e157a23078dc5458d6d26951fe4e2ac926 Mon Sep 17 00:00:00 2001
|
||||
From: Al Stone <ahs3@ahs3.net>
|
||||
Date: Wed, 14 Apr 2021 20:52:05 -0600
|
||||
Subject: [PATCH 1/2] Correct DBG2 dump of OemData
|
||||
|
||||
When OemData is present in a Device subtable, the original code was
|
||||
reading data to put in OemData from the beginning of the DBG2 table,
|
||||
not from the subtable that was being built. So, when dumping the
|
||||
table, read from the proper place (the subtable) and not the beginning
|
||||
of the DBG2 table.
|
||||
|
||||
Signed-off-by: Al Stone <ahs3@ahs3.net>
|
||||
---
|
||||
source/common/dmtbdump1.c | 4 ++--
|
||||
1 file changed, 2 insertions(+), 2 deletions(-)
|
||||
|
||||
diff --git a/source/common/dmtbdump1.c b/source/common/dmtbdump1.c
|
||||
index bcf985325..56d959fd0 100644
|
||||
--- a/source/common/dmtbdump1.c
|
||||
+++ b/source/common/dmtbdump1.c
|
||||
@@ -1371,8 +1371,8 @@ AcpiDmDumpDbg2 (
|
||||
|
||||
if (Subtable->OemDataOffset)
|
||||
{
|
||||
- Status = AcpiDmDumpTable (Length, Offset + Subtable->OemDataOffset,
|
||||
- Table, Subtable->OemDataLength,
|
||||
+ Status = AcpiDmDumpTable (Length, Subtable->OemDataOffset,
|
||||
+ Subtable, Subtable->OemDataLength,
|
||||
AcpiDmTableInfoDbg2OemData);
|
||||
if (ACPI_FAILURE (Status))
|
||||
{
|
||||
--
|
||||
2.45.2
|
||||
|
||||
|
|
@ -1,16 +1,16 @@
|
|||
Name: acpica-tools
|
||||
Version: 20240322
|
||||
Release: 1%{?dist}
|
||||
Version: 20251212
|
||||
Release: 2%{?dist}
|
||||
Summary: ACPICA tools for the development and debug of ACPI tables
|
||||
|
||||
# Automatically converted from old format: GPLv2 - review is highly recommended.
|
||||
License: GPL-2.0-only
|
||||
URL: https://www.acpica.org/
|
||||
URL: https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/overview.html
|
||||
|
||||
ExcludeArch: i686 armv7hl s390x
|
||||
|
||||
Source0: https://acpica.org/sites/acpica/files/acpica-unix2-%{version}.tar.gz
|
||||
Source1: https://acpica.org/sites/acpica/files/acpitests-unix-%{version}.tar.gz
|
||||
Source0: https://github.com/acpica/acpica/releases/download/%{version}/acpica-unix2-%{version}.tar.gz
|
||||
Source1: https://github.com/acpica/acpica/releases/download/%{version}/acpitests-unix-%{version}.tar.gz
|
||||
Source2: README.Fedora
|
||||
Source3: iasl.1
|
||||
Source4: acpibin.1
|
||||
|
|
@ -29,17 +29,13 @@ Source16: COPYING
|
|||
# other miscellaneous patches
|
||||
Patch00: unaligned.patch
|
||||
Patch01: template.patch
|
||||
Patch02: cve-2017-13693.patch
|
||||
Patch03: cve-2017-13694.patch
|
||||
Patch04: cve-2017-13695.patch
|
||||
Patch05: str-trunc-warn.patch
|
||||
Patch06: dbtest.patch
|
||||
Patch07: dangling-ptr.patch
|
||||
Patch08: uuid-len.patch
|
||||
Patch09: fix-version.patch
|
||||
Patch10: 0001-Correct-DBG2-dump-of-OemData.patch
|
||||
Patch11: 0002-Correct-dumping-of-SLIC-tables.patch
|
||||
Patch12: 0003-PHAT-FW-health-table-can-be-zero-length.patch
|
||||
#Patch11: 0002-Correct-dumping-of-SLIC-tables.patch
|
||||
#Patch12: 0003-PHAT-FW-health-table-can-be-zero-length.patch
|
||||
|
||||
BuildRequires: make
|
||||
BuildRequires: bison patchutils flex gcc
|
||||
|
|
@ -173,7 +169,7 @@ cd tests
|
|||
[ $? -eq 0 ] || exit 1
|
||||
|
||||
# misc tests
|
||||
./run-misc-tests.sh %{buildroot}%{_bindir} %{version}
|
||||
#./run-misc-tests.sh %{buildroot}%{_bindir} %{version}
|
||||
|
||||
%pre
|
||||
if [ -e %{_bindir}/acpixtract-acpica ]
|
||||
|
|
@ -205,6 +201,21 @@ fi
|
|||
|
||||
|
||||
%changelog
|
||||
* Fri Jan 16 2026 Fedora Release Engineering <releng@fedoraproject.org> - 20251212-2
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
|
||||
|
||||
* Mon Dec 15 2025 Gwyn Ciesla <gwync@protonmail.com> - 20251212-1
|
||||
- 20251212
|
||||
|
||||
* Fri Aug 15 2025 Gwyn Ciesla <gwync@protonmail.com> - 20250807-1
|
||||
- 20250807
|
||||
|
||||
* Wed Jul 23 2025 Fedora Release Engineering <releng@fedoraproject.org> - 20240322-3
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild
|
||||
|
||||
* Thu Jan 16 2025 Fedora Release Engineering <releng@fedoraproject.org> - 20240322-2
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild
|
||||
|
||||
* Mon Aug 12 2024 Al Stone <ahs3@fedoraproject.org> - 20240322-1
|
||||
- Update source tree to 20240322 version from upstream. NB: this update
|
||||
is done in conjunction with removing s390x support due to the large
|
||||
|
|
|
|||
|
|
@ -1,99 +0,0 @@
|
|||
From 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 Mon Sep 17 00:00:00 2001
|
||||
From: Seunghun Han <kkamagui@gmail.com>
|
||||
Date: Wed, 19 Jul 2017 16:47:53 +0900
|
||||
Subject: [PATCH] acpi: acpica: fix acpi operand cache leak in dswstate.c
|
||||
|
||||
I found an ACPI cache leak in ACPI early termination and boot continuing case.
|
||||
|
||||
When early termination occurs due to malicious ACPI table, Linux kernel
|
||||
terminates ACPI function and continues to boot process. While kernel terminates
|
||||
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
|
||||
|
||||
Boot log of ACPI operand cache leak is as follows:
|
||||
>[ 0.585957] ACPI: Added _OSI(Module Device)
|
||||
>[ 0.587218] ACPI: Added _OSI(Processor Device)
|
||||
>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
|
||||
>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)
|
||||
>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)
|
||||
>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)
|
||||
>[ 0.597858] ACPI: Unable to start the ACPI Interpreter
|
||||
>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
|
||||
>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
|
||||
>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
|
||||
>[ 0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
|
||||
>[ 0.609177] Call Trace:
|
||||
>[ 0.610063] ? dump_stack+0x5c/0x81
|
||||
>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0
|
||||
>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27
|
||||
>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10
|
||||
>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
|
||||
>[ 0.619293] ? acpi_terminate+0xa/0x14
|
||||
>[ 0.620394] ? acpi_init+0x2af/0x34f
|
||||
>[ 0.621616] ? __class_create+0x4c/0x80
|
||||
>[ 0.623412] ? video_setup+0x7f/0x7f
|
||||
>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27
|
||||
>[ 0.625861] ? do_one_initcall+0x4e/0x1a0
|
||||
>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f
|
||||
>[ 0.628972] ? rest_init+0x80/0x80
|
||||
>[ 0.630043] ? kernel_init+0xa/0x100
|
||||
>[ 0.631084] ? ret_from_fork+0x25/0x30
|
||||
>[ 0.633343] vgaarb: loaded
|
||||
>[ 0.635036] EDAC MC: Ver: 3.0.0
|
||||
>[ 0.638601] PCI: Probing PCI hardware
|
||||
>[ 0.639833] PCI host bridge to bus 0000:00
|
||||
>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
|
||||
> ... Continue to boot and log is omitted ...
|
||||
|
||||
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
|
||||
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
|
||||
function uses walk_state->operand_index for start position of the top, but
|
||||
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
|
||||
Therefore, this causes acpi operand memory leak.
|
||||
|
||||
This cache leak causes a security threat because an old kernel (<= 4.9) shows
|
||||
memory locations of kernel functions in stack dump. Some malicious users
|
||||
could use this information to neutralize kernel ASLR.
|
||||
|
||||
I made a patch to fix ACPI operand cache leak.
|
||||
|
||||
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
|
||||
|
||||
Github-Location: https://github.com/acpica/acpica/pull/295/commits/987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
|
||||
---
|
||||
source/components/dispatcher/dsutils.c | 9 ++++++++-
|
||||
1 file changed, 8 insertions(+), 1 deletion(-)
|
||||
|
||||
Index: acpica-unix2-20240321/source/components/dispatcher/dsutils.c
|
||||
===================================================================
|
||||
--- acpica-unix2-20240321.orig/source/components/dispatcher/dsutils.c
|
||||
+++ acpica-unix2-20240321/source/components/dispatcher/dsutils.c
|
||||
@@ -759,6 +759,8 @@ AcpiDsCreateOperands (
|
||||
ACPI_PARSE_OBJECT *Arguments[ACPI_OBJ_NUM_OPERANDS];
|
||||
UINT32 ArgCount = 0;
|
||||
UINT32 Index = WalkState->NumOperands;
|
||||
+ UINT32 PrevNumOperands = WalkState->NumOperands;
|
||||
+ UINT32 NewNumOperands;
|
||||
UINT32 i;
|
||||
|
||||
|
||||
@@ -791,6 +793,7 @@ AcpiDsCreateOperands (
|
||||
|
||||
/* Create the interpreter arguments, in reverse order */
|
||||
|
||||
+ NewNumOperands = Index;
|
||||
Index--;
|
||||
for (i = 0; i < ArgCount; i++)
|
||||
{
|
||||
@@ -818,7 +821,11 @@ Cleanup:
|
||||
* pop everything off of the operand stack and delete those
|
||||
* objects
|
||||
*/
|
||||
- AcpiDsObjStackPopAndDelete (ArgCount, WalkState);
|
||||
+ WalkState->NumOperands = i;
|
||||
+ AcpiDsObjStackPopAndDelete (NewNumOperands, WalkState);
|
||||
+
|
||||
+ /* Restore operand count */
|
||||
+ WalkState->NumOperands = PrevNumOperands;
|
||||
|
||||
ACPI_EXCEPTION ((AE_INFO, Status, "While creating Arg %u", Index));
|
||||
return_ACPI_STATUS (Status);
|
||||
|
|
@ -1,216 +0,0 @@
|
|||
From 4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0 Mon Sep 17 00:00:00 2001
|
||||
From: Seunghun Han <kkamagui@gmail.com>
|
||||
Date: Fri, 23 Jun 2017 14:19:48 +0900
|
||||
Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=UTF-8
|
||||
Content-Transfer-Encoding: 8bit
|
||||
|
||||
I'm Seunghun Han, and I work for National Security Research Institute of
|
||||
South Korea.
|
||||
|
||||
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
|
||||
early abort cases.
|
||||
|
||||
Boot log of ACPI cache leak is as follows:
|
||||
[ 0.352414] ACPI: Added _OSI(Module Device)
|
||||
[ 0.353182] ACPI: Added _OSI(Processor Device)
|
||||
[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
|
||||
[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)
|
||||
[ 0.356028] ACPI: Unable to start the ACPI Interpreter
|
||||
[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
|
||||
[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
|
||||
[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
|
||||
4.12.0-rc4-next-20170608+ #10
|
||||
[ 0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
|
||||
VirtualBox 12/01/2006
|
||||
[ 0.361873] Call Trace:
|
||||
[ 0.362243] ? dump_stack+0x5c/0x81
|
||||
[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0
|
||||
[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.363296] ? acpi_os_delete_cache+0xa/0x10
|
||||
[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b
|
||||
[ 0.364000] ? acpi_terminate+0xa/0x14
|
||||
[ 0.364000] ? acpi_init+0x2af/0x34f
|
||||
[ 0.364000] ? __class_create+0x4c/0x80
|
||||
[ 0.364000] ? video_setup+0x7f/0x7f
|
||||
[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.364000] ? do_one_initcall+0x4e/0x1a0
|
||||
[ 0.364000] ? kernel_init_freeable+0x189/0x20a
|
||||
[ 0.364000] ? rest_init+0xc0/0xc0
|
||||
[ 0.364000] ? kernel_init+0xa/0x100
|
||||
[ 0.364000] ? ret_from_fork+0x25/0x30
|
||||
|
||||
I analyzed this memory leak in detail. I found that “Acpi-State” cache and
|
||||
“Acpi-Parse” cache were merged because the size of cache objects was same
|
||||
slab cache size.
|
||||
|
||||
I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked
|
||||
using SLAB_NEVER_MERGE flag in kmem_cache_create() function.
|
||||
|
||||
Real ACPI cache leak point is as follows:
|
||||
[ 0.360101] ACPI: Added _OSI(Module Device)
|
||||
[ 0.360101] ACPI: Added _OSI(Processor Device)
|
||||
[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
|
||||
[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)
|
||||
[ 0.364016] ACPI: Unable to start the ACPI Interpreter
|
||||
[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
|
||||
[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
|
||||
[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W
|
||||
4.12.0-rc4-next-20170608+ #8
|
||||
[ 0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
|
||||
VirtualBox 12/01/2006
|
||||
[ 0.372000] Call Trace:
|
||||
[ 0.372000] ? dump_stack+0x5c/0x81
|
||||
[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0
|
||||
[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.372000] ? acpi_os_delete_cache+0xa/0x10
|
||||
[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b
|
||||
[ 0.372000] ? acpi_terminate+0xa/0x14
|
||||
[ 0.372000] ? acpi_init+0x2af/0x34f
|
||||
[ 0.372000] ? __class_create+0x4c/0x80
|
||||
[ 0.372000] ? video_setup+0x7f/0x7f
|
||||
[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.372000] ? do_one_initcall+0x4e/0x1a0
|
||||
[ 0.372000] ? kernel_init_freeable+0x189/0x20a
|
||||
[ 0.372000] ? rest_init+0xc0/0xc0
|
||||
[ 0.372000] ? kernel_init+0xa/0x100
|
||||
[ 0.372000] ? ret_from_fork+0x25/0x30
|
||||
[ 0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects
|
||||
[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W
|
||||
4.12.0-rc4-next-20170608+ #8
|
||||
[ 0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
|
||||
VirtualBox 12/01/2006
|
||||
[ 0.392000] Call Trace:
|
||||
[ 0.392000] ? dump_stack+0x5c/0x81
|
||||
[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0
|
||||
[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.392000] ? acpi_os_delete_cache+0xa/0x10
|
||||
[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b
|
||||
[ 0.392000] ? acpi_terminate+0xa/0x14
|
||||
[ 0.392000] ? acpi_init+0x2af/0x34f
|
||||
[ 0.392000] ? __class_create+0x4c/0x80
|
||||
[ 0.392000] ? video_setup+0x7f/0x7f
|
||||
[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27
|
||||
[ 0.392000] ? do_one_initcall+0x4e/0x1a0
|
||||
[ 0.392000] ? kernel_init_freeable+0x189/0x20a
|
||||
[ 0.392000] ? rest_init+0xc0/0xc0
|
||||
[ 0.392000] ? kernel_init+0xa/0x100
|
||||
[ 0.392000] ? ret_from_fork+0x25/0x30
|
||||
|
||||
When early abort is occurred due to invalid ACPI information, Linux kernel
|
||||
terminates ACPI by calling acpi_terminate() function. The function calls
|
||||
acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_
|
||||
cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache).
|
||||
|
||||
But the deletion codes in acpi_ut_delete_caches() function only delete
|
||||
slab caches using kmem_cache_destroy() function, therefore the cache
|
||||
objects should be flushed before acpi_ut_delete_caches() function.
|
||||
|
||||
“Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse
|
||||
function, acpi_ps_parse_loop(). The function should have flush codes to
|
||||
handle an error state due to invalid AML codes.
|
||||
|
||||
This cache leak has a security threat because an old kernel (<= 4.9) shows
|
||||
memory locations of kernel functions in stack dump. Some malicious users
|
||||
could use this information to neutralize kernel ASLR.
|
||||
|
||||
To fix ACPI cache leak for enhancing security, I made a patch which has
|
||||
flush codes in acpi_ps_parse_loop() function.
|
||||
|
||||
I hope that this patch improves the security of Linux kernel.
|
||||
|
||||
Thank you.
|
||||
|
||||
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
|
||||
|
||||
Github-Location: https://github.com/acpica/acpica/pull/278/commits/4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0
|
||||
|
||||
---
|
||||
source/components/parser/psobject.c | 44 ++++++++++++++-----------------------
|
||||
1 file changed, 16 insertions(+), 28 deletions(-)
|
||||
|
||||
Index: acpica-unix2-20240321/source/components/parser/psobject.c
|
||||
===================================================================
|
||||
--- acpica-unix2-20240321.orig/source/components/parser/psobject.c
|
||||
+++ acpica-unix2-20240321/source/components/parser/psobject.c
|
||||
@@ -707,7 +707,8 @@ AcpiPsCompleteFinalOp (
|
||||
ACPI_PARSE_OBJECT *Op,
|
||||
ACPI_STATUS Status)
|
||||
{
|
||||
- ACPI_STATUS Status2;
|
||||
+ ACPI_STATUS ReturnStatus = AE_OK;
|
||||
+ BOOLEAN Ascending = TRUE;
|
||||
|
||||
|
||||
ACPI_FUNCTION_TRACE_PTR (PsCompleteFinalOp, WalkState);
|
||||
@@ -724,7 +725,7 @@ AcpiPsCompleteFinalOp (
|
||||
{
|
||||
if (Op)
|
||||
{
|
||||
- if (WalkState->AscendingCallback != NULL)
|
||||
+ if (Ascending && WalkState->AscendingCallback != NULL)
|
||||
{
|
||||
WalkState->Op = Op;
|
||||
WalkState->OpInfo = AcpiPsGetOpcodeInfo (Op->Common.AmlOpcode);
|
||||
@@ -743,41 +744,28 @@ AcpiPsCompleteFinalOp (
|
||||
|
||||
if (Status == AE_CTRL_TERMINATE)
|
||||
{
|
||||
- Status = AE_OK;
|
||||
-
|
||||
- /* Clean up */
|
||||
- do
|
||||
- {
|
||||
- if (Op)
|
||||
- {
|
||||
- Status2 = AcpiPsCompleteThisOp (WalkState, Op);
|
||||
- if (ACPI_FAILURE (Status2))
|
||||
- {
|
||||
- return_ACPI_STATUS (Status2);
|
||||
- }
|
||||
- }
|
||||
-
|
||||
- AcpiPsPopScope (&(WalkState->ParserState), &Op,
|
||||
- &WalkState->ArgTypes, &WalkState->ArgCount);
|
||||
-
|
||||
- } while (Op);
|
||||
-
|
||||
- return_ACPI_STATUS (Status);
|
||||
+ Ascending = FALSE;
|
||||
+ ReturnStatus = AE_CTRL_TERMINATE;
|
||||
}
|
||||
|
||||
else if (ACPI_FAILURE (Status))
|
||||
{
|
||||
/* First error is most important */
|
||||
|
||||
- (void) AcpiPsCompleteThisOp (WalkState, Op);
|
||||
- return_ACPI_STATUS (Status);
|
||||
+ Ascending = FALSE;
|
||||
+ ReturnStatus = Status;
|
||||
}
|
||||
}
|
||||
|
||||
- Status2 = AcpiPsCompleteThisOp (WalkState, Op);
|
||||
- if (ACPI_FAILURE (Status2))
|
||||
+ Status = AcpiPsCompleteThisOp (WalkState, Op);
|
||||
+ if (ACPI_FAILURE (Status))
|
||||
{
|
||||
- return_ACPI_STATUS (Status2);
|
||||
+ Ascending = FALSE;
|
||||
+ if (ACPI_SUCCESS (ReturnStatus) ||
|
||||
+ ReturnStatus == AE_CTRL_TERMINATE)
|
||||
+ {
|
||||
+ ReturnStatus = Status;
|
||||
+ }
|
||||
}
|
||||
}
|
||||
|
||||
@@ -786,5 +774,5 @@ AcpiPsCompleteFinalOp (
|
||||
|
||||
} while (Op);
|
||||
|
||||
- return_ACPI_STATUS (Status);
|
||||
+ return_ACPI_STATUS (ReturnStatus);
|
||||
}
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
The two changes that follow were inadvertently dropped by upstream
|
||||
when creating the source tarball; the G20240322 tag in github contains
|
||||
them.
|
||||
|
||||
Signed-off-by: Al Stone <ahs3@fedoraproject.org>
|
||||
|
||||
diff -Naur acpica-unix-20240321/changes.txt acpica-unix-20240808/changes.txt
|
||||
--- acpica-unix-20240321/changes.txt 2024-03-22 00:16:29.000000000 -0600
|
||||
+++ acpica-unix-20240808/changes.txt 2024-08-08 10:54:25.000000000 -0600
|
||||
@@ -1,4 +1,28 @@
|
||||
----------------------------------------
|
||||
+22 March 2024. Summary of changes for version 20240322:
|
||||
+
|
||||
+Major changes:
|
||||
+
|
||||
+Update all the license header year from 2023 to 2024.
|
||||
+
|
||||
+Fix table argument ordering to work properly with iasl.
|
||||
+
|
||||
+Get rid of the annoying repeated warning types in MSVC and Windows.
|
||||
+
|
||||
+Fix a test in ASLTS with edge case failure.
|
||||
+
|
||||
+Fix a couple of issues with how GPEs are counted and enabled.
|
||||
+
|
||||
+Add new tables for various architectures/OS, mainly RISC-V and also update many more.
|
||||
+
|
||||
+Add an option to either make the output deterministic or non-deterministic.
|
||||
+
|
||||
+Remove redundant checks, duplicated code and fix spellings in various files.
|
||||
+
|
||||
+Fix flex arrays for C++ compilers and also make ACPICA overall more compatible with different compilers which throw warnings related to memory sanitization etc.
|
||||
+
|
||||
+
|
||||
+----------------------------------------
|
||||
28 June 2023. Summary of changes for version 20230628:
|
||||
|
||||
0) Global changes:
|
||||
diff -Naur acpica-unix-20240321/source/include/acpixf.h acpica-unix-20240808/source/include/acpixf.h
|
||||
--- acpica-unix-20240321/source/include/acpixf.h 2024-03-22 00:16:32.000000000 -0600
|
||||
+++ acpica-unix-20240808/source/include/acpixf.h 2024-08-08 10:54:25.000000000 -0600
|
||||
@@ -154,7 +154,7 @@
|
||||
|
||||
/* Current ACPICA subsystem version in YYYYMMDD format */
|
||||
|
||||
-#define ACPI_CA_VERSION 0x20230628
|
||||
+#define ACPI_CA_VERSION 0x20240322
|
||||
|
||||
#include "acconfig.h"
|
||||
#include "actypes.h"
|
||||
4
sources
4
sources
|
|
@ -1,2 +1,2 @@
|
|||
SHA512 (acpica-unix2-20240322.tar.gz) = 199a5acb93193f22b9f85690ad87cdf914185fdf52beafaec8c4299c29f4c9d5b618c72a62413b228307f5be3933cf51cdcd91a6728d9caea66408534006e3f8
|
||||
SHA512 (acpitests-unix-20240322.tar.gz) = e09b0b953d53e28b9849b1ed41068c5542f0e36eb47f442bba6238727bfd96ad94584c0aa1e8d92c307c317dbd208388d3d9c83c2d17e146571a7373bff40b98
|
||||
SHA512 (acpica-unix2-20251212.tar.gz) = ecae5ab55d04bc1fd7def717c8c2a2dd64e8708577b900dc54e0fd613c5e3e6ee25037e37abe3aa818debd75114347c272d9931f55d340ff096d2f5f6f1d185b
|
||||
SHA512 (acpitests-unix-20251212.tar.gz) = f8541f1abfd426834b8c7f17dc0eca8525de9a2e8f3a2b77311503845f26f478e66b8e3ce18e09aae5411683f57c68cbaa8c1baec6e6f567a0f768a6b4cc5715
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue