CVE-2026-31576
Published: 24 April 2026
Summary
CVE-2026-31576 is a high-severity Use After Free (CWE-416) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 2.6th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 SI-2 (Flaw Remediation) and SI-11 (Error Handling).
Deeper analysis
CVE-2026-31576 is a race condition vulnerability in the Linux kernel's hackrf driver within the media subsystem. During the hackrf_probe() function, memory for the hackrf_dev structure is allocated via kzalloc(). After v4l2_device_register() registers the device, an error path may trigger v4l2_device_unregister() followed by a direct kfree() of the device memory. This creates a use-after-free (UAF) and potential double-free (DFB) issue, as existing open file descriptors or in-flight I/O from V4L2 or video devices remain valid until their release callbacks execute. The vulnerability is classified under CWE-416 with a CVSS v3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
A local attacker with low privileges can exploit this by racing against the probe sequence. On one CPU, the probe allocates and registers the device; concurrently on another CPU, the attacker opens the device file (/path/to/dev), performs an ioctl, and keeps the file descriptor open. If the probe then unregisters and frees the memory directly, subsequent ioctl operations trigger UAF in video_is_registered(), and the eventual close invokes hackrf_video_release() which frees the already-freed memory, leading to DFB. Successful exploitation could result in high-impact confidentiality, integrity, and availability violations, such as arbitrary code execution or system crashes.
Kernel stable patches, available in the provided git commits (e.g., 07e9e674b6146b1f6fc41b1f54b8968bf2802824), mitigate the issue by ensuring that if the device is successfully registered in probe(), memory is not freed directly via kfree() on the error path. Instead, freeing is deferred exclusively to the driver's release() callback, preventing races with lingering file descriptors and in-flight operations. Security practitioners should apply these upstream fixes to affected Linux kernels supporting the hackrf driver.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25469
Vulnerability details
In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev…
more
.... v4l2_device_register(); .... fd = sys_open("/path/to/dev"); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local kernel UAF/double-free in hackrf driver enables arbitrary code execution or crashes from low-priv user context, directly mapping to exploitation for privilege escalation.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Directly and comprehensively mitigates the CVE by requiring timely remediation of the specific race condition UAF/DFB flaw in the hackrf driver via kernel patches.
Implements kernel memory protections like KASLR, SMEP, and SMAP that mitigate exploitation of the use-after-free vulnerability by local attackers.
Requires secure error handling in the probe function's error path to avoid direct kfree after v4l2_device_register, preventing races with open file descriptors.