CVE-2024-25739 - Zero-Byte Allocation in Linux Kernel's UBI `create_empty_lvol` Function (Exclusive Analysis)

CVE-2024-25739 has recently been disclosed, affecting the Linux kernel up to version 6.7.4. It's a subtle yet critical bug in the UBI (Unsorted Block Images) layer, specifically within the create_empty_lvol function found in drivers/mtd/ubi/vtbl.c. This issue can trigger a kernel crash due to improper memory allocation—specifically, an unchecked zero-byte allocation. In this post, we'll break down what went wrong, see some code, and discuss possible ways an attacker could exploit this oversight to crash Linux systems using UBI.

What Is UBI?

UBI stands for Unsorted Block Images. It's a layer in the Linux kernel used primarily on embedded devices, sitting on top of raw NAND flash and helping with wear leveling, bad block management, and logical volume (LVOL) support.

What Went Wrong—The Bug Explained

At the core of the issue is the function create_empty_lvol. Its job is to set up a new, empty logical volume (LVOL) inside the UBI. One step in the function is to allocate space for this LVOL with kzalloc, but it fails to check if it's actually supposed to allocate *anything*. This happens if ubi->leb_size (the logical eraseblock size) is zero—something that can occur if UBI is misconfigured, uninitialized, or manipulated.

Here's a simplified look at the buggy code (from drivers/mtd/ubi/vtbl.c)

// drivers/mtd/ubi/vtbl.c

void create_empty_lvol(struct ubi_device *ubi, int lnum) {
    void *buf = kzalloc(ubi->leb_size, GFP_KERNEL);
    if (!buf) {
        // handle error
    }
    // ...
}

If ubi->leb_size is zero, then kzalloc gets called with zero size.

- While allocating zero bytes is technically allowed by the allocator, later code may not expect or handle a NULL or unusual pointer.

Normal fix

if (ubi->leb_size == ) {
    // log error or reject operation
    return -EINVAL;
}
void *buf = kzalloc(ubi->leb_size, GFP_KERNEL);

How This Can Crash the Kernel

If user space or lower layers manage to bring UBI into a state where leb_size is zero (maybe via a crafted MTD device, or manipulating UBI structures through special tools), create_empty_lvol can be made to allocate a zero-byte buffer, leading to undefined behavior. Subsequent operations that write to or expect a valid buffer can trigger NULL pointer dereference or other kernel panics.

Exploit Scenario

Here’s a *theoretical* exploit path for a local attacker with root or hardware access (common in embedded hacking):

1. Prepare Crafty MTD/UBI Setup:
- The attacker manipulates the UBI subsystem (e.g., via ubiformat, ubiattach, or custom UBI volumes) so that leb_size ends up as zero (by creating a volume with zero size or mangling on-disk structures).

The kernel tries to allocate zero bytes, then operates on the buffer, causing a crash or panic.

Potential impact: This isn’t a privilege escalation, but it’s a powerful local denial-of-service (DoS) attack.

Proof-of-Concept (PoC)

Here’s a simplified PoC using shell commands—not a full exploit, but showing how a user might intentionally lead UBI to misbehave (real exploits would require kernel or hardware manipulation):

# WARNING: Running this on your system could brick devices or cause crashes.
# Only try this on a virtual machine or test hardware!

# Erase MTD partition
flash_erase /dev/mtdX  

# Create a UBI device, but misconfigure it (e.g., wrong block size)
ubiattach /dev/ubi_ctrl -m X -O 

# Attempt to create a volume with zero size
ubimkvol /dev/ubi -N testvol -s 

If the underlying kernel is vulnerable, somewhere in this flow it may call create_empty_lvol with leb_size zero, potentially crashing the kernel.

Responsible Patching

Fire up your updates!
The good news is, this bug is easy to fix. Developers need to add a single check: ensure ubi->leb_size is not zero before allocating.

The minimal patch

--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ void create_empty_lvol(struct ubi_device *ubi, int lnum) {
-    void *buf = kzalloc(ubi->leb_size, GFP_KERNEL);
+    if (ubi->leb_size == )
+        return -EINVAL;
+    void *buf = kzalloc(ubi->leb_size, GFP_KERNEL);

This fix is now included in mainline Linux as of February 2024.

More Information & References

- CVE-2024-25739 entry at NVD
- Linux source: vtbl.c (mainline)
- oss-security disclosure

Should You Be Worried?

If you’re running Linux on servers or desktops and don’t use UBI, this probably doesn’t affect you. But embedded devices and anything running on raw NAND and using UBI (routers, set-top boxes, IoT gadgets, etc) can be crashed with this bug in the wrong hands. Fixes have been rolled out in Linux kernel 6.7.5 and later.

Summary

CVE-2024-25739 is a classic example of why checking sizes is critical in kernel code. A simple missing check leads to the risk of crashing your system. Embedded Linux maintainers should patch up, and users should keep an eye on their kernel versions.


*Exclusive analysis by AI language model for your security awareness—please report serious bugs and keep systems updated!*

Timeline

Published on: 02/12/2024 03:15:32 UTC
Last modified on: 03/25/2024 01:15:55 UTC