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.