| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0031-Support-STAO-in-a-big-endian-world.patch | [PATCH 31/40] Support STAO in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-28 | ||
| 0032-Support-SLIC-and-MSDM-in-a-big-endian-world.patch | [PATCH 32/40] Support SLIC and MSDM in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-28 | ||
| 0033-Support-MCFG-in-a-big-endian-world.patch | [PATCH 33/40] Support MCFG in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-28 | ||
| 0034-Support-LPIT-in-a-big-endian-world.patch | [PATCH 34/40] Support LPIT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-28 | ||
| 0035-Support-PMTT-in-a-big-endian-world.patch | [PATCH 35/40] Support PMTT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-28 | ||
| 0036-Support-IORT-in-a-big-endian-world.patch | [PATCH 36/40] Support IORT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-30 | ||
| 0037-Support-IVRS-in-a-big-endian-world.patch | [PATCH 37/40] Support IVRS in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-30 | ||
| 0038-Support-TPM2-in-a-big-endian-world.patch | [PATCH 38/40] Support TPM2 in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-30 | ||
| fix_ftbfs_debian-kfreebsd.patch | Hi, the current version fails to build on GNU/kFreeBSD. It needs small tweak to define uintptr_t, see below. It would also be nice if you can ask upstream to include this change. Thanks in advance Petr |
no | ||||
| 0001-Add-in-basic-infrastructure-for-big-endian-support.patch | [PATCH 01/40] Add in basic infrastructure for big-endian support This adds in some basic functions -- AcpiUtReadUint32(), for example, to read a UINT32 value in little-endian form and return it in host-native format -- along with AcpiUtWriteUint() that writes out an integer in host-native format as a little-endian value. But, to do that, I'm adding the functions in a new file: utendian.c. So, the header files need fixing, and the makefiles need to be sure to compile the new code. However, this sets things up for the future, where endian-aware code can be added as the need is uncovered. For now, these functions cover all of the cases I know about. |
Al Stone <ahs3@redhat.com> | no | 2020-10-15 | ||
| 0002-Modify-utility-functions-to-be-endian-agnostic.patch | [PATCH 02/40] Modify utility functions to be endian-agnostic All of the modifications here use the big-endian code previously added (see utendian.c) to make themselves endian-agnostic; i.e., that the code does not need to change further to work on both big- and little-endian machines. These particular files were changed to handle the reading and writing of files (the length is often embedded in the binary stream), and to handle the reading and writing of integer values. The common cases are to "read" a 32-bit unsigned int in little-endian format, but convert it to host-native, and to write a byte, word, double word or quad word value as little-endian, regardless of host-native format. |
Al Stone <ahs3@redhat.com> | no | 2020-09-18 | ||
| 0003-Always-display-table-header-content-in-human-readabl.patch | [PATCH 03/40] Always display table header content in human-readable form When comparing two binary data tables, little-endian values are read from each table header and printed out. Make sure they show up in a form that makes sense to humans. |
Al Stone <ahs3@redhat.com> | no | 2020-09-18 | ||
| 0004-Re-enable-support-for-big-endian-machines.patch | [PATCH 04/40] Re-enable support for big-endian machines First, disable the big-endian check and fail. Then, make sure the namespace gets initialized properly (NB: needed even if we are only compiling/disassembling data tables). |
Al Stone <ahs3@redhat.com> | no | 2020-09-16 | ||
| 0005-Support-MADT-aka-APIC-in-a-big-endian-world.patch | [PATCH 05/40] Support MADT (aka APIC) in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-10-15 | ||
| 0006-Support-ASF-tables-in-a-big-endian-world.patch | [PATCH 06/40] Support ASF! tables in a big-endian world Read the table length properly and it all works right for big-endian. |
Al Stone <ahs3@redhat.com> | no | 2020-09-18 | ||
| 0007-Support-CPEP-tables-in-a-big-endian-world.patch | [PATCH 07/40] Support CPEP tables in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-18 | ||
| 0008-Support-DBG2-table-in-a-big-endian-world.patch | [PATCH 08/40] Support DBG2 table in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-19 | ||
| 0009-Support-DMAR-in-a-big-endian-world.patch | [PATCH 09/40] Support DMAR in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-19 | ||
| 0010-Support-DRTM-in-a-big-endian-world.patch | [PATCH 10/40] Support DRTM in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-19 | ||
| 0011-Support-EINJ-in-a-big-endian-world.patch | [PATCH 11/40] Support EINJ in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-19 | ||
| 0012-Support-ERST-in-a-big-endian-world.patch | [PATCH 12/40] Support ERST in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-19 | ||
| 0013-Support-FADT-aka-FACP-in-a-big-endian-world.patch | [PATCH 13/40] Support FADT (aka, FACP) in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-20 | ||
| 0014-Support-most-FPDTs-in-a-big-endian-world.patch | [PATCH 14/40] Support most FPDTs in a big-endian world the little-endian version. |
Al Stone <ahs3@redhat.com> | no | 2020-09-22 | ||
| 0015-Support-GTDT-in-a-big-endian-world.patch | [PATCH 15/40] Support GTDT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-22 | ||
| 0016-Support-HEST-in-a-big-endian-world.patch | [PATCH 16/40] Support HEST in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0017-Support-RSDT-RSD-PTR-in-a-big-endian-world.patch | [PATCH 17/40] Support RSDT ('RSD PTR') in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0018-Support-XSDT-in-a-big-endian-world.patch | [PATCH 18/40] Support XSDT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0019-Support-SRAT-in-a-big-endian-world.patch | [PATCH 19/40] Support SRAT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0020-Support-SLIT-in-a-big-endian-world.patch | [PATCH 20/40] Support SLIT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0021-Support-MSCT-in-a-big-endian-world.patch | [PATCH 21/40] Support MSCT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0022-Support-MPST-in-a-big-endian-world.patch | [PATCH 22/40] Support MPST in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-23 | ||
| 0023-Support-NFIT-in-a-big-endian-world.patch | [PATCH 23/40] Support NFIT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-24 | ||
| 0024-Support-SDEV-in-a-big-endian-world.patch | [PATCH 24/40] Support SDEV in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0025-Support-HMAT-in-a-big-endian-world.patch | [PATCH 25/40] Support HMAT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0026-Support-PDTT-in-a-big-endian-world.patch | [PATCH 26/40] Support PDTT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0027-Support-PPTT-in-a-big-endian-world.patch | [PATCH 27/40] Support PPTT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0028-Support-PCCT-in-a-big-endian-world.patch | [PATCH 28/40] Support PCCT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0029-Support-WDAT-in-a-big-endian-world.patch | [PATCH 29/40] Support WDAT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-25 | ||
| 0030-Support-TCPA-in-a-big-endian-world.patch | [PATCH 30/40] Support TCPA in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-09-27 | ||
| 0039-Add-partial-big-endian-support-for-WPBT-tables.patch | [PATCH 1/5] Add partial big-endian support for WPBT tables There's some weirdness here that at present does not warrant further investigation; this is just a really low priority table. |
Al Stone <ahs3@redhat.com> | no | 2020-09-30 | ||
| 0040-Support-DSDT-SSDT-in-a-big-endian-world.patch | [PATCH 2/5] Support DSDT/SSDT in a big-endian world are treated differently during compilation and disassembly so each of the resource types had code that needed to be touched directly. In general, however, just reading or writing individual AML opcodes wasn't that much of a change, and most of it was on the codegen side. |
Al Stone <ahs3@redhat.com> | no | 2020-10-15 | ||
| 0041-Support-MTMR-in-a-big-endian-world.patch | [PATCH 3/5] Support MTMR in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-10-16 | ||
| 0042-Support-VRTC-in-a-big-endian-world.patch | [PATCH 4/5] Support VRTC in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-10-19 | ||
| 0043-Support-S3PT-in-a-big-endian-world.patch | [PATCH 5/5] Support S3PT in a big-endian world | Al Stone <ahs3@redhat.com> | no | 2020-10-19 | ||
| 0044-Correct-an-endian-ness-problem-when-converting-ASL-t.patch | [PATCH] Correct an endian-ness problem when converting ASL to ASL+ | Al Stone <ahs3@redhat.com> | no | 2020-10-27 | ||
| 0045-Correct-a-couple-of-endianness-issues-previously-uns.patch | [PATCH] Correct a couple of endianness issues previously unseen Just odds and ends of some resource types and ASL analysis |
Al Stone <ahs3@redhat.com> | no | 2020-10-28 | ||
| unaligned.patch | Patch carried over from the prior iasl package and updated. This allows for builds on systems requiring aligned memory access. Please see http://lists.acpica.org/pipermail/devel/2010-July/000159.html. Resolves BZ#865013 and BZ#856856. -- Add more platforms to the list of the ones requiring aligned memory access. Also fix callsites where wrong assumptions where made in terms of aligment. |
no | ||||
| fix_ftbfs_debian-hurd.patch | Fix FTBFS on hurd-i386. | no | ||||
| add-testing.patch | =================================================================== | no | ||||
| OPT_LDFLAGS.patch | =================================================================== | no | ||||
| int-format.patch | Use proper integer formatting | Al Stone <ahs3@redhat.com> | no | |||
| f23-harden.patch | Introduce build hardening flags for f23 | Al Stone <ahs3@redhat.com> | no | |||
| template.patch | Add in a needed parameter for a test file template | Al Stone <ahs3@redhat.com> | no | |||
| arm7hl.patch | =================================================================== | no | ||||
| cve-2017-13693.patch | [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. |
Seunghun Han <kkamagui@gmail.com> | no | 2017-07-19 | ||
| cve-2017-13694.patch | [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks 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. |
Seunghun Han <kkamagui@gmail.com> | no | 2017-06-23 | ||
| cve-2017-13695.patch | [PATCH] acpi: acpica: fix acpi operand cache leak in nseval.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.464168] ACPI: Added _OSI(Module Device) >[ 0.467022] ACPI: Added _OSI(Processor Device) >[ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.471647] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20170303/dswexec-461) >[ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.497683] ACPI: Interpreter enabled >[ 0.499385] ACPI: (supports S0) >[ 0.501151] ACPI: Using IOAPIC for interrupt routing >[ 0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20170303/dswexec-461) >[ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991) >[ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.526795] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 >[ 0.529668] Call Trace: >[ 0.530811] ? dump_stack+0x5c/0x81 >[ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.533905] ? acpi_os_delete_cache+0xa/0x10 >[ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.537237] ? acpi_terminate+0xa/0x14 >[ 0.538701] ? acpi_init+0x2af/0x34f >[ 0.540008] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.541593] ? do_one_initcall+0x4e/0x1a0 >[ 0.543008] ? kernel_init_freeable+0x19e/0x21f >[ 0.546202] ? rest_init+0x80/0x80 >[ 0.547513] ? kernel_init+0xa/0x100 >[ 0.548817] ? ret_from_fork+0x25/0x30 >[ 0.550587] vgaarb: loaded >[ 0.551716] EDAC MC: Ver: 3.0.0 >[ 0.553744] PCI: Probing PCI hardware >[ 0.555038] PCI host bridge to bus 0000:00 > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found AcpiNsEvaluate() function only removes Info->ReturnObject in AE_CTRL_RETURN_VALUE case. But, when errors occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->ReturnObject is also not null. 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. |
Seunghun Han <kkamagui@gmail.com> | no | 2017-07-19 | ||
| str-trunc-warn.patch | =================================================================== | no | ||||
| facp.patch | [PATCH] Correct DSDT Address field in FACP tables The FADT allows either the DSDT Address or XDSDT Address field to be zero. However, the table definition used by the table compiler still requires the DSDT Address to be non-zero, which is not correct. So, remove the DT_NON_ZERO flag from the field. |
Al Stone <ahs3@ahs3.net> | no | 2018-12-19 | ||
| armv7-str-fixes.patch | diff -Naur acpica-unix2-20200214.orig/source/include/actypes.h acpica-unix2-20200214/source/include/actypes.h | no | ||||
| dbtest.patch | On s390, GCC does not like the string initialization in this case. When ValueToWrite is initialized this way, GCC tries to copy the entire string into an ACPI_OBJECT instead of just the pointer (see the use in the call to memcpy()). So, move the init so GCC recognizes that ValueToWrite is only a pointer, and not a whole string that needs to be moved. diff -Naur acpica-unix2-20200214.orig/source/components/debugger/dbtest.c acpica-unix2-20200214/source/components/debugger/dbtest.c |
no | ||||
| ull-32bit.patch | diff -Naur acpica-unix2-20200925.orig/source/common/dmtbdump.c acpica-unix2-20200925/source/common/dmtbdump.c | no | ||||
| fix_ftbfs_mips64el.patch | =================================================================== | no |