CVE-2025-38345

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 /> &gt;[ 0.585957] ACPI: Added _OSI(Module Device)<br /> &gt;[ 0.587218] ACPI: Added _OSI(Processor Device)<br /> &gt;[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> &gt;[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)<br /> &gt;[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)<br /> &gt;[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)<br /> &gt;[ 0.597858] ACPI: Unable to start the ACPI Interpreter<br /> &gt;[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> &gt;[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects<br /> &gt;[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26<br /> &gt;[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006<br /> &gt;[ 0.609177] Call Trace:<br /> &gt;[ 0.610063] ? dump_stack+0x5c/0x81<br /> &gt;[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0<br /> &gt;[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.613906] ? acpi_os_delete_cache+0xa/0x10<br /> &gt;[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b<br /> &gt;[ 0.619293] ? acpi_terminate+0xa/0x14<br /> &gt;[ 0.620394] ? acpi_init+0x2af/0x34f<br /> &gt;[ 0.621616] ? __class_create+0x4c/0x80<br /> &gt;[ 0.623412] ? video_setup+0x7f/0x7f<br /> &gt;[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.625861] ? do_one_initcall+0x4e/0x1a0<br /> &gt;[ 0.627513] ? kernel_init_freeable+0x19e/0x21f<br /> &gt;[ 0.628972] ? rest_init+0x80/0x80<br /> &gt;[ 0.630043] ? kernel_init+0xa/0x100<br /> &gt;[ 0.631084] ? ret_from_fork+0x25/0x30<br /> &gt;[ 0.633343] vgaarb: loaded<br /> &gt;[ 0.635036] EDAC MC: Ver: 3.0.0<br /> &gt;[ 0.638601] PCI: Probing PCI hardware<br /> &gt;[ 0.639833] PCI host bridge to bus 0000:00<br /> &gt;[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]<br /> &gt; ... 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-&gt;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 (