Snapdragon 865 5g Mobile Platform Firmware vulnerabilities
8 known vulnerabilities in Snapdragon 865 5g Mobile Platform Firmware from Qualcomm. 8 are rated high or critical, and 3 have been exploited in real attacks. Each entry lists the affected versions and the release that fixes it, where the vendor has published one.
Latest first
- 7.1 High severity
Snapdragon: Improper Verification of Cryptographic Signature
Cryptographic Issue when processing non-ELF partitions, authentication and signature checks are bypassed, allowing unsigned or corrupted images to be mounted and processed.
- 7.8 High severity
Snapdragon: Use After Free
Memory Corruption when concurrent access to shared buffer occurs due to improper synchronization between assignment and deallocation of buffer resources.
- 8.6 High severity
Qualcomm Multiple Chipsets Incorrect Authorization Exploited
Memory corruption due to unauthorized command execution in GPU micronode while executing specific sequence of commands.
- 8.6 High severity
Qualcomm Multiple Chipsets Incorrect Authorization Exploited
Memory corruption due to unauthorized command execution in GPU micronode while executing specific sequence of commands.
- 7.0 High severity
Snapdragon: Use After Free
Memory corruption while invoking redundant release command to release one buffer from user space as race condition can occur in kernel space between buffer release and buffer access.
- 7.8 High severity
Qualcomm Multiple Chipsets Use-After-Free Exploited
Memory corruption while maintaining memory maps of HLOS memory.
- 7.0 High severity
Snapdragon: Concurrent Execution using Shared Resource with Improper Synchronization
The session index variable in PCM host voice audio driver initialized before PCM open, accessed during event callback from ADSP and reset during PCM close may lead to race condition between event callback - PCM close and reset session index causing memory corr
- 7.8 High severity
Snapdragon: Use After Free
In the function call related to CAM_REQ_MGR_RELEASE_BUF there is no check if the buffer is being used. So when a function called cam_mem_get_cpu_buf to get the kernel va to use, another thread can call CAM_REQ_MGR_RELEASE_BUF to unmap the kernel va which cause