Inside of fastrpc_mmap_find, there exists the following code to search for ADSP_MMAP_HEAP_ADDR or ADSP_MMAP_REMOTE_HEAP_ADDR allocations:hlist_for_each_entry_safe(map, n, &me->maps, hn) { if (va >= map->va && va + len <= map->va + map->len && map->fd == fd) { if (refs) { if (map->refs + 1 == INT_MAX) { spin_unlock_irqrestore(&me->hlock, irq_flags); return -ETOOMANYREFS; } map->refs++; } match = map; break; } } This code is wrong at a couple different levels, particularly in the case of a fastrpc_mmap_create-->fastrpc_mmap_find call coming from userland such as in the FASTRPC_IOCTL_MEM_MAP ioctl. I think this code path may not be intended to be reachable from userland at all - although even for requests issued from kernel-land, the contract for this code appears to have some correctness issues. This code uses map->va for finding an associated mapping which for these heap addresses comes from a call to dma_alloc_attrs inside of fastrpc_alloc_cma_memory. dma_alloc_attrs has two different modes of operation - one returns a kernel virtual address to the allocated memory, and the other returns a struct page pointer that serves as an opaque cookie for the allocated memory. We have the latter case for this invocation of dma_alloc_attrs because of the DMA_ATTR_NO_KERNEL_MAPPING flag applied in fastrpc_mmap_create_remote_heap. We can see this looking at the debugfs-visible global file in the adsprpc directory:=================================== GMAPS ==================================== fd |phys |size |va -------------------------------------------------------------------------------- -1 |0xE883A000 |0x1000 |0xFFFFFFFE01A20E80 -1 |0xE8839000 |0x1000 |0xFFFFFFFE01A20E40 -1 |0xE8838000 |0x1000 |0xFFFFFFFE01A20E00 -1 |0xE8837000 |0x1000 |0xFFFFFFFE01A20DC0 -1 |0xE8836000 |0x1000 |0xFFFFFFFE01A20D80 -1 |0xE8835000 |0x1000 |0xFFFFFFFE01A20D40 0 |0xE8834000 |0x1000 |0xFFFFFFFE01A20D00 0 |0xE8833000 |0x1000 |0xFFFFFFFE01A20CC0 0 |0xE8832000 |0x1000 |0xFFFFFFFE01A20C80 -1 |0xE8900000 |0x200000 |0xFFFFFFFE01A24000 This means we end up comparing a userland supplied value against a kernel page pointer - behavior of the kernel ioctl FASTRPC_IOCTL_MEM_MAP differs in userland visible ways based on the outcome of the comparison, meaning that userland can leak kernel page pointer addresses by "guessing" a possible address and observing the resulting error code. Here is the output from the attached PoC on a Samsung S23: dm1q:/data/local/tmp $ ./poc Detected address 0xfffffffe01c00000 Final address: 0xfffffffe01a24000 Additionally, because map->va is a struct page pointer as opposed to a genuine address to the underlying buffer, the usage of map->va + map->len is incorrect, and can lead to there being multiple map matches for the same calling parameters. **This bug is subject to a 90-day disclosure deadline. If a fix for this** **issue is made available to users before the end of the 90-day deadline,** **this bug report will become public 30 days after the fix was made** **available. Otherwise, this bug report will become public at the deadline.** The scheduled deadline is 2024-09-22. **For more details, see the Project Zero vulnerability disclosure policy:** **https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-** **policy.html** Related CVE Number: CVE-2024-33060.