CVE-2025-38345
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
10/07/2025
Last modified:
10/07/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
ACPICA: fix acpi operand cache leak in dswstate.c<br />
<br />
ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732<br />
<br />
I found an ACPI cache leak in ACPI early termination and boot continuing case.<br />
<br />
When early termination occurs due to malicious ACPI table, Linux kernel<br />
terminates ACPI function and continues to boot process. While kernel terminates<br />
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.<br />
<br />
Boot log of ACPI operand cache leak is as follows:<br />
>[ 0.585957] ACPI: Added _OSI(Module Device)<br />
>[ 0.587218] ACPI: Added _OSI(Processor Device)<br />
>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)<br />
>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)<br />
>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)<br />
>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)<br />
>[ 0.597858] ACPI: Unable to start the ACPI Interpreter<br />
>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br />
>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects<br />
>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26<br />
>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006<br />
>[ 0.609177] Call Trace:<br />
>[ 0.610063] ? dump_stack+0x5c/0x81<br />
>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0<br />
>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27<br />
>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10<br />
>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b<br />
>[ 0.619293] ? acpi_terminate+0xa/0x14<br />
>[ 0.620394] ? acpi_init+0x2af/0x34f<br />
>[ 0.621616] ? __class_create+0x4c/0x80<br />
>[ 0.623412] ? video_setup+0x7f/0x7f<br />
>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27<br />
>[ 0.625861] ? do_one_initcall+0x4e/0x1a0<br />
>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f<br />
>[ 0.628972] ? rest_init+0x80/0x80<br />
>[ 0.630043] ? kernel_init+0xa/0x100<br />
>[ 0.631084] ? ret_from_fork+0x25/0x30<br />
>[ 0.633343] vgaarb: loaded<br />
>[ 0.635036] EDAC MC: Ver: 3.0.0<br />
>[ 0.638601] PCI: Probing PCI hardware<br />
>[ 0.639833] PCI host bridge to bus 0000:00<br />
>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]<br />
> ... Continue to boot and log is omitted ...<br />
<br />
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_<br />
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()<br />
function uses walk_state->operand_index for start position of the top, but<br />
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.<br />
Therefore, this causes acpi operand memory leak.<br />
<br />
This cache leak causes a security threat because an old kernel (
Impact
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/156fd20a41e776bbf334bd5e45c4f78dfc90ce1c
- https://git.kernel.org/stable/c/1c0d9115a001979cb446ba5e8331dd1d29a10bbf
- https://git.kernel.org/stable/c/4fa430a8bca708c7776f6b9d001257f48b19a5b7
- https://git.kernel.org/stable/c/5a68893b594ee6ce0efce5f74c07e64e9dd0c2c4
- https://git.kernel.org/stable/c/64c4bcf0308dd1d752ef31d560040b8725e29984
- https://git.kernel.org/stable/c/755a8006b76792922ff7b1c9674d8897a476b5d7
- https://git.kernel.org/stable/c/76d37168155880f2b04a0aad92ceb0f9d799950e
- https://git.kernel.org/stable/c/e0783910ca4368b01466bc8dcdcc13c3e0b7db53