CVE-2022-48670 in Linux
Summary
by MITRE • 05/03/2024
In the Linux kernel, the following vulnerability has been resolved:
peci: cpu: Fix use-after-free in adev_release()
When auxiliary_device_add() returns an error, auxiliary_device_uninit() is called, which causes refcount for device to be decremented and .release callback will be triggered.
Because adev_release() re-calls auxiliary_device_uninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15
[ 1269.464007] refcount_t: underflow; use-after-free.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2025
The vulnerability CVE-2022-48670 represents a critical use-after-free condition in the Linux kernel's PECI (Platform Environment Control Interface) subsystem, specifically within the cpu auxiliary device management framework. This flaw resides in the auxiliary device release mechanism where improper handling of error conditions during device initialization leads to memory corruption. The issue manifests when the auxiliary_device_add() function fails and returns an error code, triggering the auxiliary_device_uninit() cleanup routine. This cleanup process decrements the device reference count and subsequently invokes the .release callback function. However, the adev_release() callback function contains a recursive call to auxiliary_device_uninit(), creating a scenario where the same memory location is accessed after it has been freed, resulting in a dangerous use-after-free condition that can lead to system instability or potential privilege escalation.
The technical exploitation of this vulnerability follows a specific execution path that demonstrates the recursive nature of the flaw. When a device initialization fails, the kernel attempts to clean up resources through auxiliary_device_uninit(), which properly decrements the reference count and triggers the release callback. The problematic adev_release() function then calls auxiliary_device_uninit() again, causing the same device structure to be processed twice. The first call to auxiliary_device_uninit() properly frees the device memory and sets up the release callback, but the second recursive call attempts to access the already-freed memory structure. This pattern directly violates fundamental memory safety principles and results in the refcount_t underflow warning that the kernel logs, indicating the reference counter has gone below zero due to the double-free scenario.
The operational impact of this vulnerability extends beyond simple system crashes or hangs, potentially enabling malicious actors to exploit the use-after-free condition for privilege escalation attacks. According to the ATT&CK framework, this vulnerability maps to technique T1068 (Local Privilege Escalation) and T1547.001 (Registry Run Keys/Startup Folder) as attackers could leverage the kernel memory corruption to gain elevated privileges. The CWE classification for this issue is CWE-416, Use After Free, which specifically addresses the access of memory after it has been freed by the same program. The vulnerability affects systems running Linux kernel versions that include the PECI subsystem and auxiliary device management components, particularly those implementing Intel's Platform Environment Control Interface for hardware monitoring and management purposes.
Mitigation strategies for CVE-2022-48670 require immediate kernel updates to versions that contain the patched implementation of the auxiliary device management functions. The fix implemented by the kernel maintainers addresses the recursive call issue by preventing adev_release() from calling auxiliary_device_uninit() again, thus breaking the circular dependency that leads to the use-after-free condition. System administrators should prioritize patching affected systems, particularly those running embedded systems or servers that utilize PECI for hardware monitoring. The vulnerability also highlights the importance of proper error handling in kernel space code, where recursive cleanup functions must be carefully designed to avoid double-free scenarios. Organizations should implement continuous monitoring for similar patterns in other kernel subsystems and consider implementing kernel hardening techniques such as stack canaries and memory safety checks to prevent analogous issues from occurring in other parts of the kernel codebase.