fastrpc_mmap_find Information Leak

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.