*Published: June 2024
Author: [Senozhatsky@chromium.org](mailto:senozhatsky@chromium.org)*

What is CVE-2024-50064?

A recent issue was found in the Linux kernel's zram module, tracked as CVE-2024-50064. This bug affected versions with support for multi-stream compression algorithms in zram—a memory compression module often used to create compressed RAM disks.

The vulnerability stems from a memory leak when secondary (non-primary) compression algorithm names are not properly freed after resetting a zram device configured to use multiple streams. This can slowly exhaust system memory over time, especially on systems that frequently reset or reconfigure zram devices.

Technical Details

When a zram device is reset and was previously set up to use multiple compression streams (for performance), the code failed to kfree() (i.e., deallocate) the memory allocated for the secondary algorithm names. This means that names of the compression algorithms used for the extra streams would linger in memory, never being released, resulting in a memory leak.

Here’s a simplified version of what was missing

// Before fix: Secondary algorithm names not freed
static void zram_reset_device(struct zram *zram) {
    // ... other resets ...
    // memory allocated for secondary_algo_name was not freed here!
}

The fix ensures that any allocated secondary algorithm names are explicitly freed during device reset:

// After fix: Properly freeing any allocated names
static void zram_reset_device(struct zram *zram) {
    // ... other resets ...
    if (zram->secondary_algo_name)
        kfree(zram->secondary_algo_name);
    zram->secondary_algo_name = NULL;
}

> NOTE: Calling kfree(NULL) is legal in the kernel and does nothing, so the guard is technically optional; but it’s still a good habit.

Exploiting The Vulnerability

Exploiting this bug is straightforward: a local attacker can repeatedly configure, reset, or reinitialize a zram device with extra compression streams. Each reset will leak a small amount of kernel memory associated with the name buffer. Over time, this can accumulate, leading to gradual memory exhaustion (DoS) on affected hosts, especially those with unprivileged zram access or specific automation using zram.

Sample exploit command

while true; do
    # Assume /dev/zram exists
    echo 1 > /sys/block/zram/reset
    # Configure zram to use multi-stream algorithms here
    # This can involve setting /sys/block/zram/comp_algorithm, etc.
done

*(For security, only root can usually reset or configure zram devices.)*

Fix and Mitigation

The patch addresses the issue by ensuring every allocated buffer for a secondary compression algorithm name is freed on reset. Upgrade to a kernel version which includes the fix patched by Vasily Senozhatsky (commit link).

If you cannot update your kernel:
Restrict zram device creation and modification to trusted administrators, and monitor for unexplainable memory usage over time.

Original patch and discussion:

LKML Thread

zram kernel documentation:

https://www.kernel.org/doc/html/latest/block/zram.html

Summary Table

| CVE ID | Affected Component | Vulnerability Type | Impact | Fixed in |
|------------------|-------------------------|---------------------|--------------------|------------------|
| CVE-2024-50064 | Linux kernel zram | Memory leak | DoS, resource loss | Kernel 6.8+ |


Stay up to date with kernel patches, and check your systems for subtle resource leaks, especially in heavily-used environments like containers or swap-on-zram setups.

*This post is exclusive to this platform, made in simple terms for real-world system administrators and curious developers.*

Timeline

Published on: 10/21/2024 20:15:18 UTC
Last modified on: 10/23/2024 21:49:29 UTC