CVE-2022-50240
BaseFortify
Publication date: 2025-09-15
Last updated on: 2025-11-24
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| 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 is a use-after-free (UAF) issue in the Linux kernel's binder driver. It occurs because the binder code assumed that holding a read lock on the mmap was sufficient to protect a pointer to a virtual memory area (vma). However, a change in the kernel caused the mmap lock to be downgraded during munmap(), allowing the vma to be freed while still being accessed by binder_update_page_range(). This race condition can lead to binder accessing freed memory, causing a use-after-free bug.
How can this vulnerability impact me? :
This vulnerability can lead to use-after-free conditions in the kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or escalate privileges by exploiting the freed memory access.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is a use-after-free (UAF) issue in the Linux kernel binder driver related to mmap locking. Detection would typically involve monitoring kernel logs for KASAN (Kernel Address Sanitizer) reports indicating use-after-free errors in binder_update_page_range or vm_insert_page. You can check dmesg or kernel logs for such errors. Specific commands to detect this include: 1) dmesg | grep -i kasan 2) journalctl -k | grep -i kasan 3) Checking for binder-related errors in kernel logs. There are no direct network detection commands since this is a kernel memory corruption issue.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to apply the patch that reverts binder_update_page_range() to take the mmap write lock instead of the read lock, preventing the race condition causing the use-after-free. This patch is specific to stable kernel branches 5.4 and 5.10. Alternatively, upgrading to a newer kernel version where binder no longer caches a pointer to the VMA and uses vma_lookup() avoids this issue. Since this is a kernel vulnerability, updating the kernel to a fixed version is the recommended mitigation.