{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64599", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64599" ], "published": "2026-08-06T07:14:03Z", "summary": "crypto: amlogic - avoid double cleanup in meson_crypto_probe()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: amlogic - avoid double cleanup in meson_crypto_probe()\n\nWhen meson_allocate_chanlist() fails after a partial allocation, it already\nunwinds the allocated chanlist state through its local error path.\nmeson_crypto_probe() then jump to error_flow and calls\nmeson_free_chanlist() again, causing the same per-flow resources to be torn\ndown twice. In the reproduced failure path, the second teardown\nre-entered crypto_engine_exit() on an already destroyed worker and KASAN\nreported a slab-use-after-free in kthread_destroy_worker().\n\nPrevent double-free by handling partial allocation failures locally within\nmeson_allocate_chanlist() and skipping the outer cleanup path.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable.\n\nThe bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1,\nusing the reproducer under tools/testing/meson_crypto_probe. The reproducer\nforces the second dma_alloc_attrs() call in the gxl-crypto probe path to\nreturn NULL, making meson_allocate_chanlist() fail after partial\ninitialization. On the unpatched kernel this reliably triggered a\nslab-use-after-free. With this fix applied, the same reproducer no longer\nemits any KASAN report and the probe fails cleanly with -ENOMEM.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0\n Read of size 8 at addr ff1100010c057a68 by task insmod/265\n\n CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy)\n Tainted: [O]=OOT_MODULE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n Call Trace:\n \n dump_stack_lvl+0x68/0xa0\n print_report+0xcb/0x5e0\n ? __virt_addr_valid+0x21d/0x3f0\n ? kthread_destroy_worker+0xb2/0xd0\n ? kthread_destroy_worker+0xb2/0xd0\n kasan_report+0xca/0x100\n ? kthread_destroy_worker+0xb2/0xd0\n kthread_destroy_worker+0xb2/0xd0\n meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]\n platform_probe+0x99/0x140\n really_probe+0x1c6/0x6a0\n ? __pfx___device_attach_driver+0x10/0x10\n __driver_probe_device+0x248/0x310\n ? acpi_driver_match_device+0xb0/0x100\n driver_probe_device+0x48/0x210\n ? __pfx___device_attach_driver+0x10/0x10\n __device_attach_driver+0x160/0x320\n bus_for_each_drv+0x104/0x190\n ? __pfx_bus_for_each_drv+0x10/0x10\n ? _raw_spin_unlock_irqrestore+0x2c/0x50\n __device_attach+0x19d/0x3b0\n ? __pfx___device_attach+0x10/0x10\n ? do_raw_spin_unlock+0x53/0x220\n device_initial_probe+0x78/0xa0\n bus_probe_device+0x5b/0x130\n device_add+0xcfd/0x1430\n ? __pfx_device_add+0x10/0x10\n ? insert_resource+0x34/0x50\n ? lock_release+0xc9/0x290\n platform_device_add+0x24e/0x590\n ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]\n meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]\n do_one_initcall+0xc0/0x450\n ? __pfx_do_one_initcall+0x10/0x10\n ? _raw_spin_unlock_irqrestore+0x2c/0x50\n ? __create_object+0x59/0x80\n ? kasan_unpoison+0x27/0x60\n do_init_module+0x27b/0x7d0\n ? __pfx_do_init_module+0x10/0x10\n ? kasan_quarantine_put+0x84/0x1d0\n ? kfree+0x32c/0x510\n ? load_module+0x561e/0x5ff0\n load_module+0x54fe/0x5ff0\n ? __pfx_load_module+0x10/0x10\n ? security_file_permission+0x20/0x40\n ? kernel_read_file+0x23d/0x6e0\n ? mmap_region+0x235/0x4a0\n ? __pfx_kernel_read_file+0x10/0x10\n ? __file_has_perm+0x2c0/0x3e0\n init_module_from_file+0x158/0x180\n ? __pfx_init_module_from_file+0x10/0x10\n ? __lock_acquire+0x45a/0x1ba0\n ? idempotent_init_module+0x315/0x610\n ? lock_release+0xc9/0x290\n ? lock\n---truncated---", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.178", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64599" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c2c48aa7a6be36d4c93da75d14d4b4f2f4168c81" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c80360b4e85099fc3835378a96a59c0a2480fb07" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5b452019a4127f63c1f2147237fc287d1581f606" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f30e2b879bda14bc3e1524fba6f8ab9ec119da90" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6effdbaca3cd8354540bdf42c7f5fb84412afeb7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/84a00be9b736aa5dce902a290f62cbbbdcfab9ed" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6dda8406d8a3da2519c8b388d443d7357839cb63" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6d827ade51a24e18d81afb9f32756d339520a14c" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-17T05:24:08Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only in the Amlogic GXL platform driver probe path (meson_crypto_probe \u2192 meson_allocate_chanlist error unwind), via boot/deferred probe, module bind, or local sysfs rebind\u2014not from network, adjacent, or physical I/O.\nAC:L - Once meson_allocate_chanlist() fails after partial engine/DMA setup, the outer error_flow double-calls meson_free_chanlist() deterministically; a local attacker can induce that ENOMEM with memory pressure or allocation failure, with no race beyond their control.\nPR:L - On Amlogic GXL devices the DT node is status=okay and probes automatically (including deferred retries when clocks/IRQs appear); an ordinary local user can apply memory pressure during that probe without CAP_SYS_MODULE or init-namespace root, matching the higher-severity choice over PR:H.\nUI:N - No victim action such as opening a file or mounting a filesystem is required; probe error unwinding runs entirely in kernel context once allocation failure is induced.\nS:U - The double-free/UAF corrupts host kernel heap and crypto-engine worker state within the same kernel security authority and does not cross a VM, IOMMU, or sandbox boundary by itself.\nC:H - The second teardown re-enters crypto_engine_exit()/kthread_destroy_worker() and dma_free_coherent() on already freed objects (confirmed KASAN slab-UAF), which can expose arbitrary kernel memory via attacker-controlled reuse of the freed slabs.\nI:H - Double-free of kthread_worker and DMA descriptor buffers yields overlapping live objects and classic heap corruption primitives that can be leveraged for arbitrary kernel writes or control-flow hijacking, not merely a clean crash.\nA:H - The use-after-free and double-free paths reliably cause kernel oops/panic (KASAN reported slab-UAF in kthread_destroy_worker), and NULL engine pointers on early failure also crash via crypto_engine_exit(NULL)." } } }