CVE-2023-52439 Fix use-after-free in uio_open (20th Feb 2024)

Preface: Do you think this design flaw is risky? Yes, I think so.

Background: The UIO is a general purpose kernel driver that can be accessed from user space. The purpose of the driver is to act as a thin layer between user space programs and the hardware.

Since Linux uses a virtual address system, you cannot directly access the physical addresses of devices. You can gain a virtual address pointer to the device by using mmap() on the UIO device file for the device.

Vulnerability details:

There are two cores (processors) on a single chip, a SMP Kernel and RAM.

In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1.

But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then:

After core-1 kfree idev, the core-2 will do use-after-free for idev.

When core-2 do uio_release and put_device, the idev will be double freed.

Remedy: To address this issue, we can get idev atomic & inc idev reference with minor_lock. For details, please refer to

Official announcement: Please refer to the link for details –

Ref: mutex_unlock() returns 0 after successful operation. If any of the following conditions are detected, mutex_unlock() will fail and return the corresponding value.

EFAULT Description: The address pointed to by mp is illegal.

EPERM Description: The calling thread does not own the mutex lock.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.