In late 2022, a vulnerability labeled CVE-2022-49370 was found in the Linux kernel, specifically within the dmi-sysfs subsystem. This security issue, although not directly leading to immediate privilege escalation or code execution, caused a memory leak due to improper resource cleanup on error. If left unpatched, systems could experience decreased performance or even instability.

In this article, we'll break down what happened, how the bug could be triggered, discuss potential exploit scenarios, and show you the patch and code snippets. Finally, you'll find reference links at the end.

What Is dmi-sysfs?

The dmi-sysfs driver exposes hardware information (like system vendor, product name, serial number, etc.) from the SMBIOS/DMI table to user space via the /sys/firmware/dmi path. It's a helpful feature for inventory tools and scripts.

What Happened?

In the method dmi_sysfs_register_handle(), kernel objects (kobject) were initialized and added. If adding the object failed, the reference counter was not properly reduced. This left kernel allocations hanging — a memory leak. With repeated failures (potentially triggerable by unprivileged users if circumstances align), the kernel memory usage could grow uncontrollably.

From the source code docs for kobject_init_and_add()

> If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.

Here is the critical patch (simplified for clarity)

// ...code before

err = kobject_init_and_add(&entry->kobj, &dmi_attr_group_type, parent, kobj_name);
if (err) {
    // MISSING CLEANUP BEFORE:
    // kfree(entry);
    // return err;

    // FIXED CODE:
    kobject_put(&entry->kobj); // Properly decrements the ref count and frees memory
    kfree(entry);
    return err;
}

// ...code after

Now, kobject_put() is called when the initialization fails, cleaning up resources as documented.

Full Patch:

Kernel Patch Commit on Linux kernel

How Could This Be Exploited?

This isn't a "remote code execution" bug, but persistent memory leaks let a local user with access to read dmi-sysfs under certain conditions exhaust kernel memory. That could create denial-of-service (DoS).

Exploitation Scenario

- A local user/script rapidly opens and closes DMI sysfs entries that trigger the failing kobject_init_and_add() path (for example, by feeding bogus platform DMI data via a virtual machine or fuzzed BIOS).

Each failure leaks a small chunk of memory.

- Over time, this can use up all available kernel memory, causing OOM (out-of-memory) conditions and kernel panics.

PoC: How to Test for the Leak

While most users can't directly trigger this memory leak (since DMI data comes from firmware at boot), in test labs or VMs you could:

// Not a real PoC, but a simulation in "pseudo C":
for (int i = ; i < 100000; i++) {
    // Try to register a fake/broken DMI entry which triggers kobject_init_and_add() error:
    dmi_sysfs_register_handle(bad_dmi_data);

    // Monitor /proc/slabinfo, see "kobj_*" grow without bounds in unpatched kernel
}

Or in userland, watch /proc/meminfo and the path /sys/firmware/dmi/entries/ as a stress or fuzz driver pokes at sysfs with malformed data.

Note: Normal userspace on normal systems cannot inject new DMI data. Most practical risk exists in cloud, virtualization, or advanced fuzzing/test setups.

Fix and Mitigation

If you run a Linux kernel older than v6.1.4 or v5.15.87 and you customize firmware device entries, you should upgrade. All distributions backported the fix, so update your kernel!

If you can't update, restrict access to /sys/firmware/dmi/ to trusted users/applications.

Original Kernel Patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=517b98a17a61002f173e6622d08830ea7bdd2188

CVE details:

https://nvd.nist.gov/vuln/detail/CVE-2022-49370

Kernel documentation on kobject:

https://www.kernel.org/doc/html/latest/core-api/kobject.html

Summary

CVE-2022-49370 was a subtle Linux kernel bug that caused a memory leak in the DMI sysfs driver when kobject_init_and_add() failed. It's been fixed by cleaning up with kobject_put() per documentation. While not a direct privilege escalation vector, unmitigated it could trigger denial-of-service in certain environments.

If you want to see what DMI info your own system exposes, try

ls /sys/firmware/dmi/entries/

Timeline

Published on: 02/26/2025 07:01:13 UTC
Last modified on: 04/14/2025 20:42:48 UTC