Skip to content
VulniPulse
Advisory severityMedium5.5Red Hat Linux

Medium [CVE-2026-64368] do not limit zeroing to orig_size when only red zoning is enabled

This medium-severity Red Hat Linux advisory covers CVE-2026-64368 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat package: kernel-rt.

Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.

CVE-2026-64368 Source published Source updated

VulniPulse record published Record updated

Affected products & platforms
Red Hat LinuxLinux Kernel
Open source advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

Summary

In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not limit zeroing to orig_size 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 __GFP_ZERO 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 SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s __GFP_ZERO contract.

Fix this by using slub_debug_orig_size() 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. A flaw was found in the Linux kernel's memory management subsystem.

This issue occurs when the kernel's memory allocator attempts to zero out newly allocated memory, but an incorrect check prevents the full memory region from being cleared under specific configurations.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.

Official advisory · high-confidence parse· fetched 12 days ago·verify at source

Fixed versions
  • kernel-0:6.12.0-211.46.1.el10_2
  • kernel-0:5.14.0-687.38.1.el9_8
  • RHSA-2026:53330
  • RHSA-2026:53329

Official advisory · high-confidence parse· fetched 12 days ago·verify at source

Mitigation

Upgrade to a fixed release: kernel-0:6.12.0-211.46.1.el10_2, kernel-0:5.14.0-687.38.1.el9_8, RHSA-2026:53330, RHSA-2026:53329. That is the remediation for this advisory.

The vendor advisory may list additional interim mitigations or workarounds not captured here — review it before change work.

Official advisory · high-confidence parse· fetched 12 days ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.