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 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c9ae0b8605078eafc3bea053cc78791e97ba2e2

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2023-52439

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.