Look up another CVE · open CVE-2026-64368 in the interactive tracker

CVE-2026-64368

mm/slab: do not limit zeroing to orig_size when only red zoning is enabled

8.1 EPSS 0.4% AV:N

Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-64368 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	fixed	6.12.96-1	Update the kernel and reboot. Fixed in 6.12.96-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.4-1	Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.4-1	Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4724-1 · 2026-08-07 · text	6.12.100-1~deb12u1	Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

mm/slub.c

What this is: SLAB ALLOCATORMAINTAINERS section matched on mm/slub.c · linux-mm@kvack.org · Maintained

Check it on the machine

grep -w CONFIG_SLUB /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

bookworm, trixie, forky, sid, bookworm · linux-6.12y

y: built into the kernel image on every flavour - only a patch removes it

Build switch: CONFIG_SLUB

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-25 (3 months ago)source
CVSS: 8.1 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.42%, higher than 34.5% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: mm

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.2	6.6.145	6256899c3a34
6.2	6.12.96	7e706d50fa11
6.2	6.18.39	2382971aaaef
6.2	7.1.4	0d18ccef142f
6.2	7.2	648927ceb840

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4724-1	2026-08-07	bookworm 6.12.100-1~deb12u1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: On an already-mounted CephFS client, a malicious or compromised monitor can deliver crafted MDS-map data over TCP that reaches ceph_mdsmap_decode(), krealloc(), and the vulnerable allocator behavior.
AC:HAttack complexity, high: Exploitation requires the uncommon, attacker-uncontrolled configuration of SLUB red zoning without SLAB_STORE_USER. Once configured, the attacker controls allocation sizes and heap-grooming messages without needing an uncontrolled race.
PR:NPrivileges required, none: The attacking network peer requires no local account or capability on the target, and legacy or unauthenticated Ceph monitor connections can deliver the map without verified credentials.
UI:NUser interaction, none: An already-mounted, long-lived CephFS client processes MDS-map updates asynchronously, requiring no victim action during exploitation.
S:UScope, unchanged: Successful exploitation compromises the kernel and host resources within the same security authority; it does not inherently cross a VM or equivalent boundary.
C:HConfidentiality impact, high: The skipped allocation tail exposes stale kernel-heap contents as valid data, including a pointer that check_new_map() can dereference, creating arbitrary kernel-memory read and disclosure potential.
I:HIntegrity impact, high: Stale attacker-groomed counts and pointers can reach unchecked set_bit() operations and kfree(), enabling out-of-bounds writes, arbitrary frees, and potential control-flow hijacking.
A:HAvailability impact, high: Invalid pointer dereferences, out-of-bounds stack writes, or freeing a stale pointer can cause a kernel oops or panic and can be triggered repeatedly by crafted map updates.