CVE-2026-64368

What it actually does

This Linux kernel memory-management flaw affects SLAB/SLUB allocation behavior when allocation zeroing is requested and slab red zoning is enabled without requested-size tracking. In that configuration, kmalloc()/krealloc() handling can zero only the originally requested size when the allocator does not actually have enough metadata to preserve krealloc()'s __GFP_ZERO guarantee. As a result, memory returned after reallocation may contain stale heap contents instead of being fully initialized. Depending on which kernel subsystem or driver exposes or consumes the reallocated buffer, this can result in kernel memory disclosure, logic errors, data corruption, or potentially a path toward privilege-impacting exploitation. The issue is most relevant to systems running affected Linux kernels with slab red-zone debugging enabled.

Why it matters to the business

Systems using vulnerable Linux kernels may expose sensitive in-memory data or experience instability if kernel memory is reused without being properly cleared. Because this is a kernel-level issue, successful exploitation could affect the confidentiality and reliability of the whole host, including workloads running on it. The issue has a high CVSS score, but current exploitation signals are low: it is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported mature exploit, and has a low EPSS score. Organizations should still prioritize remediation for internet-facing, multi-tenant, container-hosting, virtualization, and high-sensitivity Linux systems, especially where slab debugging/red zoning is enabled.

How an attack unfolds

An attacker must reach a kernel code path that allocates memory with zero-on-allocation semantics, later expands or reallocates that object with krealloc(), and then either returns the uninitialized portion to an observable interface or causes the kernel to make security-relevant decisions based on stale data. In practice, exploitation depends heavily on finding a reachable subsystem, driver, filesystem, networking feature, or ioctl/netlink/syscall path that uses the affected allocation pattern. The attacker would shape kernel heap state so that sensitive data is present in a reusable slab object, trigger the vulnerable allocation/reallocation sequence, and then attempt to read back the uncleared bytes or influence behavior through the stale contents. No public exploitation or named threat-actor activity is currently indicated for this CVE.

How to fix it

Upgrade to a vendor kernel that includes the upstream fix for the Linux kernel mm/slab change: "mm/slab: do not limit zeroing to orig_size when only red zoning is enabled." No exact fixed package versions were provided in the input, so use the fixed kernel advisory from the operating-system or distribution vendor. After installing the patched kernel, reboot the system so the fixed kernel is actually running. As a temporary mitigation where patching is delayed, avoid running affected production systems with slab red zoning enabled alone; review and remove boot parameters such as red-zone-only SLUB debugging unless explicitly required. Where debug allocation features must remain enabled, follow vendor guidance for safe combinations of slab debugging options. Because this is a kernel fix, updating user-space packages alone is not sufficient.

How to confirm the fix worked

Confirm both package installation and runtime kernel state. Verify the running kernel version with `uname -r` and compare it against the vendor advisory for this CVE or the kernel package changelog containing the mm/slab fix. Check that the host has been rebooted into the patched kernel, not merely staged with an updated package. Review `/proc/cmdline` for slab debugging options such as `slub_debug` or red-zone settings that may increase exposure on unpatched systems. On distributions that expose package changelogs, confirm the installed kernel changelog references the CVE or the upstream commit title. For fleet validation, query endpoint inventory for kernel versions and boot parameters, then prioritize any unpatched hosts with slab red zoning enabled.

Typical attack path

1. Identify a Linux system running an affected kernel build.
2. Determine whether slab red zoning/debug allocation behavior is enabled, such as through kernel boot parameters or debug configuration.
3. Find a reachable kernel interface that uses kmalloc()/krealloc() with __GFP_ZERO or equivalent zeroing expectations under the affected allocator conditions.
4. Spray or shape kernel heap memory so sensitive or attacker-controlled data is placed in reusable slab objects.
5. Trigger allocation and reallocation so the kernel returns or uses memory that was expected to be zeroed but contains stale contents.
6. Read leaked data through a kernel-exposed interface or use stale values to attempt a follow-on integrity or stability impact.
7. Use any disclosed kernel memory to support further exploitation, bypass mitigations, or attack adjacent services/workloads.

How to detect it

There are no reliable, CVE-specific indicators that prove exploitation because this flaw manifests as allocator misuse, uninitialized kernel memory exposure, or memory corruption rather than a distinctive file, process, or network signature. Retrospective detection should focus on kernel and system logs from the period before patching. Review `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, crash dumps, pstore records, and kernel oops/panic reports for SLUB allocator warnings, red-zone violations, KASAN/KMSAN uninitialized memory reports, unexpected kernel BUG/Oops events, or crashes in subsystems reachable by untrusted input. If systems run workloads that can access low-level kernel interfaces, correlate allocator warnings with suspicious syscall-heavy activity, container escape attempts, unusual ioctl/netlink use, or unexplained service crashes. In hardened environments, review eBPF/audit telemetry for unusual access to kernel-exposed interfaces shortly before allocator warnings. Absence of these artifacts does not rule out exploitation, especially for pure information disclosure.

• slub_debug=Z
• SLUB: Redzone
• SLUB: redzone
• KASAN:
• KMSAN:
• BUG: KASAN:
• BUG: KMSAN:
• kernel BUG at mm/slub.c
• BUG kmalloc
• general protection fault
• Oops:
• kernel panic
• use-after-free
• uninitialized memory
• Kernel panic - not syncing

What your security team should do

• Inventory Linux kernel versions across servers, appliances, container hosts, hypervisors, and embedded Linux systems.
• Prioritize patching hosts that are multi-tenant, internet-facing, run untrusted workloads, host containers, or process sensitive data.
• Check `/proc/cmdline` and configuration management for slab red-zone/debug options such as `slub_debug`; treat unpatched systems using red zoning as higher priority.
• Apply the vendor-provided fixed kernel and reboot into it; verify the running kernel, not just the installed package version.
• If immediate patching is not possible, disable red-zone-only slab debugging where operationally safe and approved.
• Monitor kernel logs for memory-corruption, SLUB, KASAN, KMSAN, or allocator-related warnings that could indicate triggering of vulnerable paths.
• Because there are no known public exploit indicators, do not rely on IOC-only detection; use exposure management and patch verification as the primary control.