Skip to main content
VulnerabilityPublished Updated

CVE-2026-31576: Linux kernel · media: hackrf: fix to not free memory after the device is registered in hackrf_probe()

Affects Linux kernelSource GCVE Database

0
Compare

Not known to be exploited.

Data as of 12 Nov 2026, 00:34 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 11 Nov 2026.

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.

References

Community reviews

Loading reviews…