7.8
CVE-2026-53401
- EPSS 0.13%
- Veröffentlicht 19.07.2026 12:02:01
- Zuletzt bearbeitet 17.08.2026 05:17:14
- CVE-Watchlists
- Unerledigt
fbdev: omap2: fix use-after-free in omapfb_mmap
In the Linux kernel, the following vulnerability has been resolved: fbdev: omap2: fix use-after-free in omapfb_mmap omapfb_mmap() has a race condition with OMAPFB_SETUP_PLANE ioctl that can lead to use-after-free: The fb_mmap() entry point holds mm_lock but not lock (fb_info->lock), while ioctl handlers like OMAPFB_SETUP_PLANE hold lock but not mm_lock. This allows concurrent execution. In omapfb_mmap(): 1. rg = omapfb_get_mem_region(ofbi->region); // Get old region ref 2. start = omapfb_get_region_paddr(ofbi); // Read from NEW region 3. len = fix->smem_len; // Read from NEW region 4. vm_iomap_memory(vma, start, len); // Map NEW region memory 5. atomic_inc(&rg->map_count); // Increment OLD region! Concurrently, OMAPFB_SETUP_PLANE can: - Reassign ofbi->region = new_rg - Update fix->smem_len - OMAPFB_SETUP_MEM then checks NEW region's map_count (0!) and frees it This leaves userspace with a mapping to freed physical memory. The fix is to read all required values (start, len) from the same region reference (rg) that will have its map_count incremented, preventing the region from being freed while still mapped.
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 2.6.36 < 7.1.3
VulnDex Vulnerability Enrichment
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.13% | 0.03 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 1.8 | 5.9 |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
|
CWE-416 Use After Free
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.
https://git.kernel.org/stable/c/6eb6ebcc8590007ad59ddccc8b5f9201655b33f8
https://git.kernel.org/stable/c/7958e67375aa111522086286bba13cfc0816ce8d