CVE-2022-49935
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-14
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.0 |
| linux | linux_kernel | 6.0 |
| linux | linux_kernel | 6.0 |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
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 involves the Linux kernel's dma-buf/dma-resv subsystem where a new fence added to a dma_resv object was always assumed to be newer than all existing fences. Due to recent changes allowing explicit export/import via UAPI, this assumption is no longer valid. Without checking if the new fence is actually later, userspace can cause the kernel to experience a use-after-free error.
How can this vulnerability impact me? :
The vulnerability can lead to a use-after-free error in the kernel, which may cause system instability, crashes, or potentially allow malicious userspace processes to exploit the kernel memory management, leading to security risks such as privilege escalation or denial of service.
What immediate steps should I take to mitigate this vulnerability?
Apply the patch that adds the check to ensure the new fence is really later when adding a fence to a dma_resv object. Backport this fix to stable kernels if you are using them, to prevent potential use after free errors caused by userspace forcing the kernel into an invalid state.