---

_CVE-2022-34495_ is a security flaw discovered in the Linux kernel, specifically in the virtio_rpmsg_bus module. This vulnerability is a classic example of a double free issue, which can lead to system crashes, privilege escalation, or arbitrary code execution. If you're a Linux systems developer or you run devices with Linux kernels prior to version 5.18.4, this is a flaw you need to understand.

Let’s break down what happened, where, why it’s so risky, and how someone could exploit it — all in simple, clear terms.

Understanding the Problem: What is Double Free?

A double free occurs when a program tries to free (or delete) a memory section that has already been freed. If a malicious actor is able to trigger this bug, they might redirect code execution, inject code, or cause the kernel to crash (DoS).

The problem is in the rpmsg_probe function. The file involved is

drivers/rpmsg/virtio_rpmsg_bus.c

The issue is present in Linux kernel versions before 5.18.4.

Here’s a recreation of how the double free occurs (simplified)

int rpmsg_probe(struct virtio_device *vdev)
{
    struct rpmsg_device *rpdev;

    // Allocate memory for rpdev
    rpdev = kzalloc(sizeof(*rpdev), GFP_KERNEL);
    if (!rpdev)
        return -ENOMEM;

    // [Some code that can bail out on error]
    if (some_error_condition) {
        kfree(rpdev);
        return -EINVAL;
    }

    // ... more code ...

    // If registration fails, rpdev is freed again!
    if (register_rpmsg_device_fails) {
        kfree(rpdev);  // <--- SECOND free!
        return -EIO;
    }

    return ;
}

Notice how kfree(rpdev) can be called twice if the function exits through different error paths. This is the "double free."

- CVE Record at NVD
- Patch commit on Kernel.org
- oss-sec Mailing List Writeup

The Exploit: How Would an Attacker Use This?

While this issue isn’t the easiest target, a local attacker (user or process with the ability to trigger the rpmsg_probe path) could potentially:

1. Trigger a Double Free: By carefully crafting operations that cause each exit path to be hit, the same memory is freed twice.
2. Hijack Allocations: The freed memory could then be reused (“heap spray attack”) by attacker-controlled code, overwriting function pointers or struct fields.
3. Gain Control: If successful, the attacker could escalate privileges (e.g., from a regular user to root), or crash the kernel, causing Denial of Service.

Let’s imagine a device or driver triggers rpmsg_probe under the right (wrong!) conditions

// Pseudo code to simulate vulnerable sequence
load_virtio_device();
trigger_some_error_condition(); // frees rpdev
trigger_register_rpmsg_device_fail(); // frees rpdev AGAIN
// At this point, heap memory is corrupted!

An attacker might use tools like Heap Exploitation techniques to:

Overwrite important data in the kernel space

Real-world exploitation is complex, since the kernel’s heap management (SLAB, SLUB, etc.) offers some protection, but history shows determined attackers find a way.

The Patch: How is it Fixed?

The official patch ensures that the memory is freed only once, and that code paths are adjusted to avoid double kfree() calls.

// Patch paraphrased for clarity:
kfree_rpdev:
    kfree(rpdev);
    return error_code; // single exit point

// All error conditions now jump here, no double free!

Reference: linux.git commit 17e18e3

Audit Similar Code: Check other kernel modules for similar patterns.

- Use Memory Safety Tools: Enable Spectre/Meltdown mitigations, and run tools like KASAN (Kernel Address Sanitizer) if you’re a developer.

Conclusion

CVE-2022-34495 proves that even mature, widely-used projects like the Linux kernel are not immune from classic bugs. Double frees can be catastrophic at the kernel level. The fix is simple in code, but the impact of not patching can be devastating.

Admins — Patch now!

If you want to read more about double-free vulnerabilities, check these resources

- A Guide to Double-Free Exploitation
- Linux Kernel Heap Memory Exploitation Techniques (Google Project Zero)

Timeline

Published on: 06/26/2022 16:15:00 UTC
Last modified on: 07/08/2022 03:59:00 UTC