CVE-2025-39896
BaseFortify
Publication date: 2025-10-01
Last updated on: 2025-12-12
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 6.8 (inc) to 6.12.46 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.16.6 (exc) |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the Linux kernel's accel/ivpu component allowed recovery work to be queued even after device removal had started. The issue was that cancel_work_sync() was used, which canceled existing work but did not prevent new recovery work from being scheduled. This could lead to use-after-free bugs if recovery work accessed resources that had already been freed. The fix involved using disable_work_sync() to ensure no new recovery work can be queued during device removal.
How can this vulnerability impact me? :
This vulnerability can lead to use-after-free bugs, which may cause system instability, crashes, or potentially allow attackers to execute arbitrary code or cause denial of service by exploiting freed resources accessed during recovery work after device removal.
What immediate steps should I take to mitigate this vulnerability?
Update the Linux kernel to a version that includes the fix for this vulnerability, which prevents recovery work from being queued during device removal by using disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini(). This ensures no new recovery work items can be queued after device removal has started, avoiding use-after-free bugs.