LiveActive security incident?Get immediate response
CVE Record

CVE-2021-47221: mm/slub: actually fix freelist pointer vs redzoning

In the Linux kernel, the following vulnerability has been resolved: mm/slub: actually fix freelist pointer vs redzoning It turns out that SLUB redzoning ("slub_debug=Z") checks from s->object_size rather than from s->inuse (which is normally bumped to make room for the freelist pointer), so a cache created with an object size less than 24 would have the freelist pointer written beyond s->object_size, causing the redzone to be corrupted by the freelist pointer. This was very visible with "slub_debug=ZF": BUG test (Tainted: G B ): Right Redzone overwritten ----------------------------------------------------------------------------- INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200 INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620 Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........ Redzone (____ptrval____): 40 1d e8 1a aa @.... Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ Adjust the offset to stay within s->object_size. (Note that no caches of in this size range are known to exist in the kernel currently.)

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysislow

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel memory allocator bug in SLUB debug redzoning. Under specific debug settings, a freelist pointer can overwrite allocator redzone bytes for very small objects. The source says no current in-kernel caches of that size are known, so practical business urgency appears limited from the provided evidence.

Executive priority

Track through normal kernel patch management unless your environment depends on SLUB debug redzoning or custom small-object caches. No source evidence supports emergency response or active exploitation.

Technical view

SLUB redzoning with slub_debug=Z checks from s->object_size, while the freelist pointer placement used s->inuse. For object sizes below 24 bytes, that can place the freelist pointer beyond s->object_size and corrupt the right redzone. The fix adjusts the freelist pointer offset to stay within s->object_size.

Likely exposure

Likely limited to Linux kernels containing the affected SLUB allocator behavior, especially when SLUB redzoning debug options are enabled. The source notes no known current kernel caches in the relevant small-object size range.

Exploitation context

The provided sources do not report active exploitation, KEV listing, exploit availability, privilege impact, or a practical attack path. Evidence frames this as a debug redzone corruption bug observed with slub_debug=ZF.

Researcher notes

Focus review on mm/slub freelist pointer placement versus redzone bounds. The affected condition depends on small object sizes and SLUB redzoning behavior; the source explicitly says no current in-kernel caches in that size range are known.

Mitigation direction

  • Apply Linux kernel updates containing the referenced stable fixes.
  • Check distribution advisories for backported fixes matching your kernel build.
  • Avoid treating upstream version numbers alone as proof of exposure.
  • Review use of SLUB debug redzoning on affected systems.

Validation and detection

  • Inventory Linux kernel versions and vendor patch levels.
  • Check whether kernels include the referenced stable commits or distro backports.
  • Identify systems booted with slub_debug=Z or slub_debug=ZF.
  • Review kernel logs for SLUB right redzone overwrite reports.
Prepared
Confidence
medium
Sources
5

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2021-47221 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
2ADP providers
4Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux89b83f282d8ba380cf2124f88106c57df49c538c, 89b83f282d8ba380cf2124f88106c57df49c538c, 89b83f282d8ba380cf2124f88106c57df49c538cunaffected
LinuxLinux5.7, 0, 5.10.46, 5.12.13, 5.13affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.