CVE-2026-64368: Linux Kernel Privilege Escalation Flaw

CVE-2026-64368 Overview

CVE-2026-64368 is a Linux kernel vulnerability in the slab memory allocator (mm/slab). When SLAB_RED_ZONE is enabled without SLAB_STORE_USER, the allocator incorrectly limits zeroing to the requested (orig_size) length instead of the full object size. This breaks krealloc()'s __GFP_ZERO guarantee, leaving uninitialized kernel memory reachable to callers that expect zeroed buffers. Because the requested size is not actually tracked when only red zoning is on, krealloc() growth operations can expose stale slab contents. The issue is resolved by replacing the imprecise check with slub_debug_orig_size(), which accurately reflects whether the requested size is tracked.

Critical Impact
Enabling SLAB_RED_ZONE alone can compromise krealloc()'s __GFP_ZERO contract, potentially exposing uninitialized kernel memory to consumers that rely on zero-initialized allocations.

Affected Products

Linux kernel builds with SLAB_RED_ZONE enabled and SLAB_STORE_USER disabled
Kernels using the SLUB allocator with slub_debug red-zoning options
Stable kernel branches referenced in the upstream fix commits

Discovery Timeline

2026-07-25 - CVE-2026-64368 published to NVD
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64368

Vulnerability Analysis

The Linux kernel's slab allocator supports optional debug facilities including SLAB_RED_ZONE (guard bytes around objects) and SLAB_STORE_USER (tracks the original allocation size and caller). When callers request zero-on-allocation via __GFP_ZERO, kmalloc() normally zeroes the full object size to preserve krealloc() semantics on subsequent growth.

When the requested size is tracked, the allocator can safely zero only the requested range and treat the remainder as red-zone padding. The pre-patch logic used an imprecise conditional that treated SLAB_RED_ZONE alone as sufficient evidence that the requested size was tracked. In configurations where red zoning is enabled without user tracking, orig_size is not recorded, so the allocator zeroes only a portion of the object, leaving stale bytes intact.

Root Cause

The defect is an incorrect conditional in the slab initialization path. The check conflated two independent debug options and assumed size tracking was present whenever red zoning was enabled. In practice, slub_debug_orig_size() is the authoritative signal for whether orig_size is tracked. Using the wrong predicate causes krealloc() with __GFP_ZERO to return buffers whose grown region contains uninitialized slab memory.

Attack Vector

Exploitation requires an attacker to influence kernel code paths that call krealloc() with __GFP_ZERO on kernels built with SLAB_RED_ZONE but without SLAB_STORE_USER. A local or remote-triggered allocation pattern that grows a previously freed and re-used slab object could disclose uninitialized data or bypass initialization assumptions in downstream consumers. Because the attack complexity is high and depends on non-default debug configurations, practical exploitation is constrained. See the upstream commits 0d18cce and 7e706d5 for the corrected logic.

Detection Methods for CVE-2026-64368

Indicators of Compromise

Kernel configuration inspection showing CONFIG_SLUB_DEBUG=y with slub_debug=Z (red zone) enabled and user tracking (U) disabled
Unexpected data patterns in buffers returned by krealloc() when callers assume zero-initialized memory
Kernel log entries from slub_debug reporting red-zone or poison inconsistencies

Detection Strategies

Audit kernel .config files across the fleet for SLAB_RED_ZONE enabled without SLAB_STORE_USER
Compare running kernel versions against the fixed commits referenced by upstream stable branches
Enable slub_debug=FZPU in test environments to surface allocator anomalies during regression testing

Monitoring Recommendations

Collect kernel boot arguments and /proc/cmdline values from Linux hosts to identify vulnerable slub_debug configurations
Monitor kernel version telemetry from endpoint agents and correlate against patched stable releases
Track kernel package updates through configuration management to confirm remediation deployment

How to Mitigate CVE-2026-64368

Immediate Actions Required

Apply the upstream stable kernel updates that include the corrected slub_debug_orig_size() check
Inventory hosts running custom kernel builds with debug allocator options enabled
Prioritize patching on systems where kernel debug options were retained in production builds

Patch Information

The fix replaces the imprecise conditional with slub_debug_orig_size(), which accurately reports whether the requested allocation size is tracked. Upstream commits addressing this issue include 648927c, 2382971, 6256899, 0d18cce, and 7e706d5. Update to a stable kernel release incorporating these commits from your distribution vendor.

Workarounds

Disable SLAB_RED_ZONE on production kernels until patched builds are deployed
If debug allocator options are required, enable SLAB_STORE_USER alongside SLAB_RED_ZONE so orig_size tracking is active
Remove slub_debug=Z from kernel command-line arguments on affected systems

bash

# Inspect current slub_debug configuration on a running host
cat /proc/cmdline | tr ' ' '\n' | grep slub_debug

# Verify kernel build options related to the slab allocator
zcat /proc/config.gz 2>/dev/null | grep -E 'SLUB_DEBUG|SLAB_'

# Remove red-zone-only debug from GRUB and rebuild config
sudo sed -i 's/slub_debug=Z//g' /etc/default/grub
sudo update-grub