CVE-2022-49276 - Linux Kernel jffs2 Memory Leak in `jffs2_scan_medium` — Deep Dive and Exploit Path
---
CVE-2022-49276 refers to a memory leak vulnerability in the Linux kernel’s JFFS2 (Journaling Flash File System v2) subsystem. Specifically, the bug was in jffs2_scan_medium, where, if an error occurred (inside jffs2_scan_eraseblock), memory attached to a summary pointer s would not be freed. This issue could lead to persistent, unreleased memory allocations (memory leaks), observed during mount operations, as reported by kmemleak.
Let’s understand this vulnerability, how it happens, what its implications are, and see real kernel debug output. We'll also learn how the patch resolves it, with easy-to-grasp code examples. At the end, we’ll connect it to real-world exploitation potential.
The Vulnerability: What Went Wrong?
When jffs2_scan_eraseblock() returns an error, the function jffs2_scan_medium() might exit *without* freeing memory accumulated in jffs2_summary *s. Over time or repeated mounts, this could exhaust system memory — especially on systems mounting and unmounting many partitions or using small RAM (embedded devices).
This leak was easily detectable with tools like kmemleak—here is sample output:
unreferenced object xffff88812b889c40 (size 64):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
...
backtrace:
[<ffffffffae93a3a3>] __kmalloc+x613/x910
[<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+x5c/xa
[<ffffffffbf3afa8>] jffs2_scan_medium.cold+x36e5/x4794
...
Xref (cross reference) memory
These allocations are summarized in a jffs2_summary *s struct. If an error aborts too soon, these pointers have no clean-up path.
Here’s the relevant chunk from the old (vulnerable) kernel code (simplified)
int jffs2_scan_medium(...)
{
struct jffs2_summary *s = NULL;
// ... [some code]
ret = jffs2_scan_eraseblock(...);
if (ret) {
// Error! But s still holds allocated memory.
return ret;
}
// ... More code
}
As you can see, on an error (ret < ), function escapes with a return, but *nothing* frees things attached to s.
The Patch:
The commit added a call to clean up collected summaries before exit, ensuring no memory is leaked
int jffs2_scan_medium(...)
{
struct jffs2_summary *s = NULL;
// ... [some code]
ret = jffs2_scan_eraseblock(...);
if (ret) {
jffs2_sum_reset_collected(s); // << Release any memory in s
return ret;
}
// ... More code
}
The extra tag/label out_buf was also added for safer error handling elsewhere, making sure we don't dereference a NULL summary.
How This Bug Can Be Abused
While this bug doesn’t allow direct privilege escalation or code execution, it might be exploitable for a Denial-of-Service (DoS) attack:
- Low-memory devices: An attacker (or accident) could rapidly mount/umount JFFS2 filesystems, triggering this edge case repeatedly. Over time, the leaked memory accumulates:
Critical services may be OOM-killed.
- Attack Surface: Embedded systems, routers, IoT using JFFS2 are most at risk (as they often lack RAM and strong process separation).
Triggering It:
If you can mount a specially crafted (possibly malformed/corrupt) JFFS2 image that causes jffs2_scan_eraseblock() to fail, you can coerce the system into leaking memory each attempt.
Here’s a simplified "exploit path" for interested readers
# As root (or a privileged process):
while true; do
mount -t jffs2 -o loop /tmp/malformed_jffs2.img /mnt/test
umount /mnt/test
done
# Watch memory usage climb!
*(Note: creating a deliberately malformed JFFS2 image requires JFFS2 image tools, see mtd-utils)*
Linux commit:
LKML Thread (Credits: Zhang Yi):
https://lore.kernel.org/lkml/20221212142210.25291-1-yi.z.zhang@huawei.com/
Kernel changelog:
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
For formal CVE details:
- https://nvd.nist.gov/vuln/detail/CVE-2022-49276
Update your kernel to a version newer than December 2022
- Rebuild/reflash JFFS2 images only with the patched kernel
Consider using alternative filesystems if you’re able
- Use kmemleak to monitor your kernel for memory leaks
Summary:
CVE-2022-49276 was a low-level but impactful kernel bug: it did not cause instant chaos, but over time (especially in embedded systems) could be used to cause a memory DoS. The fix is simple—just free allocated summary memory on error—yet its importance is huge: many kernel issues are born from minor code path skips like this!
_This explanation is crafted for clarity for non-expert programmers and sysadmins, with links and practical know-how. If you enjoyed this article or need more kernel vulnerability deep dives, follow and share!_
Timeline
Published on: 02/26/2025 07:01:04 UTC
Last modified on: 04/14/2025 17:08:00 UTC