CVE-2023-52439 - Critical Use-After-Free Vulnerability in Linux Kernel’s UIO

CVE-2023-52439 is a recently patched security weakness found in the Linux kernel, specifically in the UIO (Userspace I/O) subsystem. The issue is a use-after-free bug in how devices are registered and freed. When two CPU cores access or release the same UIO device at almost the same time, memory can be freed while another part of the kernel is still using it—opening the door to a double-free or use-after-free condition, both of which can lead to system crashes or even code execution.

This post will break down the cause, exploitability, and code details so you fully understand this kernel-level vulnerability.

Here’s a timeline

| core-1 | core-2 |
|-------------------------------|-----------------------------------|
| uio_unregister_device | uio_open |
| device_unregister(&idev->dev) | idev = idr_find() |
| put_device(&idev->dev) | get_device(&idev->dev) |
| uio_device_release | uio_release |
| kfree(idev) | put_device(&idev->dev), kfree(idev) |

The issue:
- device_unregister can lead to freeing (kfree) the idev pointer once the last reference is dropped.
- But between unregister and free, another CPU could *find* the same device and increment its reference.

Here’s a simplified version of the UIO handling code at fault

// core-1: unregister
static void uio_unregister_device(struct uio_device *idev) {
    device_unregister(&idev->dev); // triggers release if refs hit 
    put_device(&idev->dev);        // drops final ref, triggers free
}

// core-2: open
static int uio_open(struct inode *inode, struct file *file) {
    struct uio_device *idev = idr_find(&uio_idr, iminor(inode));
    get_device(&idev->dev); // re-increment reference
    // ... use idev ...
}

But if core-1 frees idev in put_device() while core-2 is still using it, we have a use-after-free!

Exploitation Walkthrough

If you can trigger both the unregister and an open (from another process or thread) at the same time, you could use a user program to reliably hit the bug.

Exploit concept (pseudocode!)

// Thread 1: repeatedly unregisters device
while (1) {
    ioctl(uio_fd, UIO_UNREGISTER, ...);
}

// Thread 2: repeatedly opens the same device
while (1) {
    int fd = open("/dev/uioX", O_RDWR);
    if (fd > ) close(fd); // get & close fast
}

What can happen:

Kernel memory is freed while still being referenced.

- Malicious data could be written to now-freed areas or, in crash scenarios, arbitrary code execution may be possible due to corrupted kernel memory.

The solution: atomic operations and locking.

Developers patched the bug by introducing a lock (usually minor_lock) around allocation and referencing of idev, ensuring the following are atomic:

Patch excerpt

mutex_lock(&minor_lock);
idev = idr_find(&uio_idr, minor);
if (idev)
    get_device(&idev->dev);
mutex_unlock(&minor_lock);

This ensures:

Device is only used as long as it is truly alive

Patch reference:
- kernel/git/torvalds/linux
- LKML Fix Discussion

Summary Table

| Risk | Description |
|---------------------|----------------------------------------------|
| CVSS Score | Check NVD or Linux page |
| Impact | Local privilege escalation or kernel panic |
| Fixed in Kernel | Mainline (5.15+, backported to stable) |
| Affected Versions | Various (check vendor advisories) |

Update your system kernel—anything before early 2024 may be vulnerable!

- Check if you run custom kernel/UIs, especially in embedded/IoT.

Timeline

Published on: 02/20/2024 21:15:08 UTC
Last modified on: 03/15/2024 14:21:10 UTC

CVE-2023-52439 - Critical Use-After-Free Vulnerability in Linux Kernel’s UIO – Explained and Exploited