CVE-2022-49277 - How a Memory Leak in the Linux Kernel’s jffs2_do_mount

In late 2022, a vulnerability identified as CVE-2022-49277 was patched in the Linux kernel’s JFFS2 (Journaling Flash File System 2) code. The issue was a classic memory leak: when mounting a JFFS2 filesystem, if an error occurred, some memory allocated by the kernel was left unreleased—a problem that, over time or with repeated errors, could slowly undermine system stability.

In this post, we’ll break down what went wrong, how it showed up, and how it was fixed. We’ll also look at some code and discuss what you can learn from this bug if you write or maintain low-level code.

The Vulnerability: A Memory Leak in jffs2_do_mount_fs

JFFS2 is often used in embedded Linux systems to support flash memory. The problem was found in the function jffs2_do_mount_fs(). When this function tried to mount a JFFS2 filesystem, it would first allocate certain memory resources in jffs2_sum_init(). If a later function (jffs2_build_filesystem()) failed, these resources weren’t properly freed.

The Kernel's Warning Signs

Developers spotted the problem using kmemleak, a tool for detecting memory leaks in the Linux kernel. Here’s the kind of report they saw:

unreferenced object xffff88811b25a640 (size 64):
  comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffa493be24>] kmem_cache_alloc_trace+x584/x880
    [<ffffffffa5423a06>] jffs2_sum_init+x86/x130
    [<ffffffffa540e58>] jffs2_do_mount_fs+x798/xac
    ...

*(Another similar entry for a larger chunk, 65536 bytes, was also unreferenced.)*

Translation: The kernel allocated some memory while mounting a filesystem. Something failed, nobody cleaned up, and the memory got “lost”—exactly what we mean by a memory leak.

Let’s take a peek at the code structure, simplified for clarity

int jffs2_do_mount_fs(...) {
    int ret;

    ret = jffs2_sum_init();
    if (ret)
        return ret;

    ret = jffs2_build_filesystem();

    if (ret) {
        // Missing cleanup!
        return ret;
    }

    // ...
}

What you can see is: if jffs2_sum_init() failed, it would just return. But if jffs2_sum_init() succeeded and jffs2_build_filesystem() failed, it would also just return, leaking any memory allocated in the earlier step.

The Fix

The solution? Free the resources that had been allocated in the failed path.

Originally, the bug happened because cleanup function jffs2_sum_exit() was not called before returning from the error case. Here’s how the patch changed it:

if (ret) {
    jffs2_sum_exit();
    return ret;
}

Now, if anything goes wrong after sum initialization—but before mounting is complete—the kernel will properly free any memory it allocated.

Is This a Security Issue?

While classified as a vulnerability (hence the CVE), the risk is low for most users. The bug could allow local users (who can mount JFFS2 filesystems) to slowly eat up kernel memory if they intentionally trigger mount errors in a loop. On servers or devices with untrusted users, it *might* make a denial-of-service attack easier.

Example: Repeatedly mounting a broken JFFS2 image

for i in $(seq 1 100); do
    mount -t jffs2 /dev/loop /mnt/test || true
done

If /dev/loop points to a corrupted/broken JFFS2 filesystem image, each failed mount would trigger the leak. Eventually, the system could run out of memory.

Fixed: Kernel patches landed and backported to supported trees

See the original patch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa094561f58201a23889530c385f795be560c462
(*Summary: jffs2: fix memory leak in jffs2_do_mount_fs*)

CVE Entry:
> https://nvd.nist.gov/vuln/detail/CVE-2022-49277

Relevant LKML thread:
> https://lore.kernel.org/linux-mtd/20221223202302.18073-1-mtd@kernel.org/

Lessons for Developers

- Always clean up after yourself. For every allocation, make sure there’s a free in every failure path.
- Use tools. Kernel devs use kmemleak—use Valgrind, AddressSanitizer, and other tools in your own projects.
- Even “harmless” bugs matter. Leaking memory on error can’t always be ignored; it adds up on systems that run for months or years.
- Defensive programming saves headaches. Handling every exit path properly is the mark of robust systems code.

Summary

CVE-2022-49277 is a great case study in careful systems programming. By missing a single cleanup call, the Linux kernel’s JFFS2 code risked leaking memory on repeated mount failures—a subtle but real reliability threat, especially in embedded systems. Thanks to good tools and attentive maintainers, the fix was simple and swift.

Worried about memory leaks in your code? Review every error path, and double-check your resource management. The best bugs are the ones you never let reach production.

Timeline

Published on: 02/26/2025 07:01:04 UTC
Last modified on: 04/14/2025 17:09:03 UTC

CVE-2022-49277 - How a Memory Leak in the Linux Kernel’s jffs2_do_mount_fs Was Fixed