CVE-2024-53172 - Linux Kernel UBI Fastmap Slab Cache Name Collision Vulnerability Explained

---

Introduction: What Happened?

In 2024, a vulnerability identified as CVE-2024-53172 was resolved in the Linux Kernel. The issue concerned a somewhat technical but important part of the kernel: UBI (Unsorted Block Images) fastmap and how it allocated memory during device attachment.

A mix-up in how memory caches (called slab caches) were named caused conflicts during fast device attachment, triggering warnings and potential instability in debug environments.

In this post, we’ll break it all down, explain what caused the problem, demonstrate what went wrong, and show you how it was fixed and why you should care—even if you’re not a deep kernel hacker!

Slab Cache:

This is a memory management technique in the Linux kernel. It helps manage small bits of memory (objects) more efficiently.

UBI (Unsorted Block Images):

A subsystem in Linux used for managing flash devices. It provides wear leveling and bad block management for raw flash chips.

Fastmap:

A UBI feature that speeds up attaching (mounting/initializing) UBI devices by saving mapping information.

What’s the Problem?

After a recent kernel change (commit 4c39529663b9), Linux began to warn if two different creations of memory slabs use the same name (when CONFIG_DEBUG_VM is enabled).

Within UBI’s Fastmap feature, a function called alloc_ai() could be called multiple times while trying to attach the same device. Each time, it would try to create a slab cache with the same hardcoded name: 'ubi_aeb_slab_cache'.

It prints a WARNING and stack trace to the kernel log.

- This breaks debugging and indicates possible instability or memory corruption if undefined behavior sneaks in.

Example Warning

kmem_cache of name 'ubi_aeb_slab_cache' already exists
WARNING: CPU:  PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+x100/x5f

How Easy Was This to Trigger?

If you used UBI Fastmap with debugging turned on (CONFIG_DEBUG_VM=y), you could reproduce this by simply loading a UBI device. That’s it. No special privileges or tricks.

Is this a real “exploit”?

It’s not a remote code execution or “pwn-under-the-hood” type attack that lets someone run code. Instead, it’s a denial-of-service vector in certain kernel debug or developer environments by making the kernel stop or behave unpredictably due to warnings and taint.

People running debug or self-built kernels

- Users of flash/UBI storage on embedded devices in debug configurations

How Could It Be Used?

Malicious or buggy code could, intentionally or not, provoke repeated UBI fast attaches, possibly destabilizing kernel processes or tainting the system state, making it hard to debug other issues.

Here’s the rough problem area

static struct kmem_cache *ubi_aeb_slab_cache;

static int alloc_ai(...)
{
    ubi_aeb_slab_cache = kmem_cache_create("ubi_aeb_slab_cache", ...);
    // ...
}

Every call to alloc_ai() tries to create a slab with the same name.

How Was It Fixed?

The fix was surprisingly simple and elegant:
Use different slab names for each distinct caller of alloc_ai().

That way, slab names are unique, and repeated calls create separate caches without clashes.

Example Fix

kmem_cache_create("ubi_aeb_slab_cache_%d", instance_id, ...);

Or, more specifically, use context-specific or function-specific names as appropriate.

Linux Kernel commit & mailing:

- Original patch discussion
- Commit cdd3851b5da5

CVE page:

- CVE-2024-53172 @ cve.org *(may not be published yet at time of reading)*

Relevant commit causing warning:

- Kernel commit 4c39529663b9

Summary Table

| Aspect | Detail |
|------------------------------|----------------------------------------------------|
| CVE ID | CVE-2024-53172 |
| Component | UBI Fastmap Slab Caching |
| Exploitable by non-root? | No (requires ability to load UBI devices, root) |
| Impact | Kernel warnings, possible kernel taint/instability |
| Fixed in | Post May 30, 2024 mainline Linux kernel |

Conclusion

CVE-2024-53172 is a great example of how seemingly “trivial” bugs inside the kernel’s deep plumbing can have real-world consequences, especially for those building, debugging, or shipping Linux for embedded devices. This fix prevents a class of memory-management headaches caused by non-unique slab cache names, making Linux’s UBI subsystem more robust and debug-friendly.

Always keep up-to-date with kernel security updates, especially if you’re working with advanced features or custom storage setups. 👍

*If you liked this breakdown, consider following kernel maintainers and security mailing lists for more nerdy kernel stories!*

Timeline

Published on: 12/27/2024 14:15:24 UTC
Last modified on: 05/04/2025 09:54:51 UTC