CVE-2026-64368: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled
In the Linux kernel, the following vulnerability has been resolved:
mm/slab: do not limit zeroing to origsize when only red zoning is enabled
When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s GFPZERO guarantees.
But if we track the requested size, krealloc() uses that information to do the right thing, so we can zero only the requested size. With red zoning also enabled, any extra size became part of the red zone, so it must not be zeroed and thus we must zero only the requested size.
However the current check is imprecise, and will trigger also when only SLABREDZONE is enabled without SLABSTOREUSER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s GFPZERO contract.
Fix this by using slubdebugorigsize() instead, which is the exact check for whether the requested size is tracked. We don't need to care if red zoning is also enabled or not. Also update and expand the comment accordingly.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.145.2-1 - Compensating control
In mm/slab, use slub_debug_orig_size() to determine the requested size when zeroing allocations, so krealloc() with __GFP_ZERO zeros only the requested size when SLAB_RED_ZONE is enabled without SLAB_STORE_USER.
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The affected software listed is the Linux kernel and Microsoft azl3 kernel 6.6.144.1-1. The problematic condition occurs when red zoning is enabled without SLAB_STORE_USER, while allocation zeroing is requested for kmalloc() objects.
What behavior can indicate that a system is affected?
Affected systems can violate krealloc()'s __GFP_ZERO guarantee: memory beyond the originally requested allocation size may not be zeroed after resizing. This condition is tied to enabling SLAB_RED_ZONE alone, without requested-size tracking enabled by SLAB_STORE_USER.
What should be done to remediate the issue?
Apply an available patch. The fix replaces the imprecise red-zone-related check with slub_debug_orig_size(), which accurately determines whether the requested allocation size is tracked.