CVE-2026-31576

Advisory lineage Upstream: 0 Downstream: 3
Modified
Published: 24 Apr 2026, 14:42
Last modified:01 Jun 2026, 16:11

Vulnerability Summary

Overall Risk (default)
medium
31/100
CVSS Score
7.8 HIGH
v3.1 (nvd)
EPSS Score
0.01% LOW
0% probability 0.00%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

24 Apr 2026, 14:42
Published
Vulnerability first disclosed
01 Jun 2026, 16:11
Last Modified
Vulnerability information updated

Description

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 .... 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.

CVSS Metrics

  • v3.1•HIGH•Score: 7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Trends

Current EPSS score: 0.01%• Percentile: 3%

Techniques & Countermeasures

  • CWE-416•Use After Free

    The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Affected Systems

  • linux•linux

    ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 98a0a81ce78020c2522e0046f49d200de9778cb9 | ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 07e9e674b6146b1f6fc41b1f54b8968bf2802824 | ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 2145c71a8044362e82e9923f001ba2aeb771b848 | ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < fcd1d70792a35c8a97414fe429f48311e41269c2 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 87b9685cca91ed715c39ba544715832d26a7f4b4 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 131ec9046e1c8af101aebdaec4e8095e05f3312b | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 67fd62e3efdc9dce01f76d95a745212f4feb38e6 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 45cbaf5c7cdc5386d86377f0daf94a17a007fed0 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 98a0a81ce78020c2522e0046f49d200de9778cb9 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 07e9e674b6146b1f6fc41b1f54b8968bf2802824 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 2145c71a8044362e82e9923f001ba2aeb771b848 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < fcd1d70792a35c8a97414fe429f48311e41269c2 | ≥ 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, < 3b7da2b4d0fe014eff181ed37e3bf832eb8ed258 | 4.4

  • linux•linux_kernel

    < 6.6.136 | ≥ 6.7, < 6.12.83 | ≥ 6.13, < 6.18.24 | ≥ 6.19, < 6.19.14 | ≥ 7.0, < 7.0.1

References (9)