Strix
26.1K

CVE-2025-39994

HIGHCVSS 7.3/10EPSS 0.22%

Last modified

CVE-2025-39994 is a high-severity vulnerability rated 7.3/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. EPSS estimates a 0.22% chance of exploitation in the next 30 days.

Description

In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]

Metrics

CVSS 3.1
7.3/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

EPSS Probability
0.22%

12.4th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < bc4ffd962ce16a154c44c68853b9d93f5b6fc4b8; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < e2f5eaafc0306a76fb1cb760aae804b065b8a341; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < 3f876cd47ed8bca1e28d68435845949f51f90703; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < df0303b4839520b84d9367c2fad65b13650a4d42; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < 71ed8b81a4906cb785966910f39cf7f5ad60a69e; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < effb1c19583bca7022fa641a70766de45c6d41ac; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < 9a00de20ed8ba90888479749b87bc1532cded4ce; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < 4266f012806fc18e46da4a04d130df59a4946f93; >= f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8, < 40b7a19f321e65789612ebaca966472055dab48c
LinuxLinux3.16

References

Timeline

Published
Last Modified
Status
Deferred

Frequently Asked Questions

What is CVE-2025-39994?
In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]
How severe is CVE-2025-39994?
CVE-2025-39994 has a CVSS score of 7.3/10 (HIGH severity). The EPSS model estimates a 0.22% probability of exploitation in the next 30 days.
How do I fix CVE-2025-39994?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2025

View all 2025CVEs →

Are you affected by CVE-2025-39994?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST