CVE-2023-52439: uio: Fix use-after-free in uio_open
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uio_open
core-1 core-2
-------------------------------------------------------
uio_unregister_device uio_open
idev = idr_find()
device_unregister(&idev->dev)
put_device(&idev->dev)
uio_device_release
get_device(&idev->dev)
kfree(idev)
uio_free_minor(minor)
uio_release
put_device(&idev->dev)
kfree(idev)
-------------------------------------------------------
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:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
freed.
To address this issue, we can get idev atomic & inc idev reference with
minor_lock.
Security readout for executives and security teams
Plain-English summary
This Linux kernel UIO flaw can corrupt kernel memory when opening a device races with its removal. A low-privileged local user may trigger use-after-free and double-free conditions, potentially causing a system crash or broader compromise. Practical risk depends on whether UIO is present and accessible to that user.
Executive priority
Treat this as high priority on affected multi-user Linux systems using UIO. It is not directly network-reachable according to the supplied CVSS vector, so prioritize by UIO usage and local-user exposure. Apply vendor-supported kernel updates promptly, accelerating remediation where untrusted or low-privileged users share the host.
Technical view
uio_open can obtain an idev pointer while uio_unregister_device is releasing the same object. Because the reference was not acquired atomically under minor_lock, the object may be freed before get_device, causing use-after-free and a subsequent double free during release. The cited fix acquires the device and increments its reference while holding the lock.
Likely exposure
Exposure is local rather than directly network-based. Highest concern applies to affected Linux systems using UIO where low-privileged users can access relevant device nodes. The bundled version entries lack clear range semantics, so distribution package and backport status must be checked before declaring a system vulnerable or fixed.
Exploitation context
The CVSS 3.1 score is 7.8 with local access, low privileges, low complexity, and no user interaction. The bundle marks KEV false and supplies no cited evidence of active exploitation or public exploit availability. Confidentiality, integrity, and availability impacts are rated high, but successful compromise is not demonstrated in the supplied evidence.
Researcher notes
The bundle provides no CWE, reproduction, or exploitation evidence. Its flattened version entries mix hashes and versions without clear range semantics. Validate vendor packages and backports rather than inferring status solely from that list. Impact beyond crashes and memory corruption remains potential, based on the supplied CVSS assessment rather than demonstrated exploitation.
Mitigation direction
Update affected kernels to a vendor-supported release containing the applicable upstream UIO fix.
Consult distribution advisories because the bundled affected-version data is insufficiently clear for package-level decisions.
Prioritize systems using UIO and allowing low-privileged users to access relevant device nodes.
If patching is delayed, restrict untrusted local access and UIO device-node permissions after operational review.
Validation and detection
Inventory running kernel versions, distribution package revisions, and hosts using the UIO subsystem.
Confirm the running kernel contains a cited stable fix or a documented vendor backport.
Review permissions and ownership for UIO device nodes available to low-privileged users.
After updating and rebooting, verify each host is running the intended remediated kernel.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-52439 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.