ID

VAR-202409-0013

CVE

CVE-2024-33060

TITLE

Use of freed memory vulnerability in multiple Qualcomm products

DESCRIPTION

Memory corruption when two threads try to map and unmap a single node simultaneously. 315 5g iot firmware, AQT1000 firmware, AR8031 Multiple Qualcomm products, such as firmware, contain vulnerabilities related to use of freed memory.Information is obtained, information is tampered with, and service operation is interrupted. (DoS) It may be in a state. 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

AFFECTED PRODUCTS

CVSS

PROBLEMTYPE DATA

EXTERNAL IDS

REFERENCES

CREDITS

Google Security Research, Seth Jenkins

SOURCES

LAST UPDATE DATE

2024-10-07T23:40:13.942000+00:00

SOURCES UPDATE DATE

SOURCES RELEASE DATE