How severe is CVE-2026-64599?

No CVSS score has been assigned to CVE-2026-64599 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-64599?

CVE-2026-64599 affects the following packages: Kernel (Linux). Ecosystems affected: Linux.

How do I fix CVE-2026-64599?

Update Kernel to 5.10.261 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-64599 is resolved across your whole dependency graph.

How do I detect CVE-2026-64599 in my Linux dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Kernel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate CVE-2026-64599 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against CVE-2026-64599?

O3 pinpoints whether CVE-2026-64599 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is CVE-2026-64599 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-64599 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was CVE-2026-64599 published, and has it been updated?

CVE-2026-64599 was published on August 6, 2026 and was last updated on August 8, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐧 Linux

CVE-2026-64599

CVE-2026-64599 is a security vulnerability in Kernel. O3 Security confirms whether CVE-2026-64599 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

crypto: amlogic - avoid double cleanup in meson_crypto_probe()

Published

Aug 6, 2026

Updated

Aug 8, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

🐧Kernel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Linux packages — download data is not available via public APIs for these ecosystems.

Description

In the Linux kernel, the following vulnerability has been resolved:

crypto: amlogic - avoid double cleanup in meson_crypto_probe()

When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker().

Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available.

The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM.

==================================================================
BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0
Read of size 8 at addr ff1100010c057a68 by task insmod/265

CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G           O        7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy)
Tainted: [O]=OOT_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x68/0xa0
 print_report+0xcb/0x5e0
 ? __virt_addr_valid+0x21d/0x3f0
 ? kthread_destroy_worker+0xb2/0xd0
 ? kthread_destroy_worker+0xb2/0xd0
 kasan_report+0xca/0x100
 ? kthread_destroy_worker+0xb2/0xd0
 kthread_destroy_worker+0xb2/0xd0
 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]
 platform_probe+0x99/0x140
 really_probe+0x1c6/0x6a0
 ? __pfx___device_attach_driver+0x10/0x10
 __driver_probe_device+0x248/0x310
 ? acpi_driver_match_device+0xb0/0x100
 driver_probe_device+0x48/0x210
 ? __pfx___device_attach_driver+0x10/0x10
 __device_attach_driver+0x160/0x320
 bus_for_each_drv+0x104/0x190
 ? __pfx_bus_for_each_drv+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x2c/0x50
 __device_attach+0x19d/0x3b0
 ? __pfx___device_attach+0x10/0x10
 ? do_raw_spin_unlock+0x53/0x220
 device_initial_probe+0x78/0xa0
 bus_probe_device+0x5b/0x130
 device_add+0xcfd/0x1430
 ? __pfx_device_add+0x10/0x10
 ? insert_resource+0x34/0x50
 ? lock_release+0xc9/0x290
 platform_device_add+0x24e/0x590
 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]
 meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]
 do_one_initcall+0xc0/0x450
 ? __pfx_do_one_initcall+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x2c/0x50
 ? __create_object+0x59/0x80
 ? kasan_unpoison+0x27/0x60
 do_init_module+0x27b/0x7d0
 ? __pfx_do_init_module+0x10/0x10
 ? kasan_quarantine_put+0x84/0x1d0
 ? kfree+0x32c/0x510
 ? load_module+0x561e/0x5ff0
 load_module+0x54fe/0x5ff0
 ? __pfx_load_module+0x10/0x10
 ? security_file_permission+0x20/0x40
 ? kernel_read_file+0x23d/0x6e0
 ? mmap_region+0x235/0x4a0
 ? __pfx_kernel_read_file+0x10/0x10
 ? __file_has_perm+0x2c0/0x3e0
 init_module_from_file+0x158/0x180
 ? __pfx_init_module_from_file+0x10/0x10
 ? __lock_acquire+0x45a/0x1ba0
 ? idempotent_init_module+0x315/0x610
 ? lock_release+0xc9/0x290
 ? lock

---truncated---

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐧Linux	`Kernel`	≥ 5.5.0&&< 5.10.261	5.10.261

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Kernel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update Kernel to 5.10.261 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-64599 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-64599 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to CVE-2026-64599. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker

O3 Security · Impact-Aware SCA

Is CVE-2026-64599 in your dependencies?

O3 detects CVE-2026-64599 across Linux dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works