Preface: Snapdragon chipsets, which are a type of System-on-a-Chip (SoC), often include memory components, such as RAM (Random Access Memory) and ROM (Read-Only Memory), within the chip itself. This integrated approach allows for faster and more efficient data processing within the device.

Background: In Qualcomm Snapdragon SoCs, the Adreno GPU is responsible for graphics and compute tasks. The GPU is managed through a combination of firmware, drivers (like KGSL on Android), and secure execution environments. Authorized memory operations are typically handled as follows:

1. Initialization Phase

• The GPU driver (KGSL) initializes the GPU and sets up memory mappings.
• The TrustZone or Secure Execution Environment (SEE) may be involved in verifying firmware and boot integrity.

2. Command Submission

• Memory operations (e.g., buffer allocation, mapping, copying) are submitted via command buffers.
• These buffers are managed by the GPU Command Processor (CP) and passed through the Ringbuffer.

3. Permission Check

• Before execution, the GPU driver and firmware perform permission checks:
  • Is the memory region accessible to the current process?
  • Is the memory marked as GPU-accessible?
  • Are the command buffers properly signed or validated?
• These checks may involve IOMMU (Input-Output Memory Management Unit) to ensure memory isolation and protection.

Ref: The IOMMU (Input-Output Memory Management Unit) is responsible for managing DMA (Direct Memory Access) from I/O devices and ensuring that these devices can only access the memory they are authorized to. A problem where the IOMMU is not checking permissions would mean that I/O devices could potentially access memory they shouldn’t, leading to security vulnerabilities and system instability.

Vulnerability details: Memory corruption due to unauthorized command execution in GPU micronode while executing specific sequence of commands.

Official announcement: Please see the link for details

https://docs.qualcomm.com/product/publicresources/securitybulletin/june-2025-bulletin.html

Preface: A Mesh Basic Service Set (MBSS) is a self-contained wireless network created by a group of interconnected mesh stations (STAs). Each mesh station can act as both an access point and a mesh node, enabling communication and data sharing within the mesh network. The MBSS uses a “mesh profile” to define the network’s characteristics, including a Mesh ID and other parameters. Unlike traditional Wi-Fi setups that rely on a single router, mesh networks create a more resilient, decentralized system.

Background: FragAttacks, short for Fragmentation and Aggregation attacks, are a category of Wi-Fi vulnerabilities that exploit design flaws in how Wi-Fi devices handle data packets. These flaws affect a wide range of Wi-Fi devices, potentially allowing attackers to steal information or disrupt network services.

Vulnerability details: IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.

Ref: CVE-2020-24588: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn’t require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets.

Official announcement: For details, please refer to the link –

https://nvd.nist.gov/vuln/detail/CVE-2025-27558

Preface: As of June 26, 2023, QNX software is now embedded in over 255 million vehicles worldwide, including most leading OEMs and Tier 1s, such as BMW, Bosch, Continental, Dongfeng Motor, Geely, Ford, Honda, Mercedes-Benz, Subaru, Toyota, Volkswagen, Volvo, and more.

Background: In Automotive Ethernet Audio Video Bridging (eAVB), reliable communication is not limited to audio alone. eAVB ensures efficient and reliable communication for both audio and video data, as well as other types of data that require low latency and high synchronization. This includes applications such as infotainment systems, advanced driver-assistance systems (ADAS), and vehicle-to-vehicle communication.

The standards for eAVB, including Time-Sensitive Networking (TSN), provide guaranteed latencies and the ability to build redundant network paths for safety-critical communications. This makes eAVB a versatile solution for various types of data within the automotive network.

Vulnerability details:

Improper Input Validation in Automotive Software platform based on QNX

Description: Memory corruption while processing a message, when the buffer is controlled by a Guest VM, the value can be changed continuously.

Official announcement: Please see the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-21460

NVD Published Date: 04/07/2025

NVD Last Modified: 04/07/2025

Preface: Released on September 3, 2024 as Android 15. Android 16, Internal codename as Baklava, released on 2nd April 2025.

Background: The core of the Android OS operating system is the Android Open Source Project (AOSP), which is free open source software (FOSS) licensed primarily under the Apache License. However, most devices run a proprietary version of Android developed by Google, which comes pre-installed with additional proprietary, closed-source software, most popular Google Mobile Services (GMS), which includes core applications such as Google Chrome, the digital distribution platform Google Play, and the related Google Play Services development platform.

Qualcomm Android source code is divided into development source code and proprietary source code. Proprietary source code is further divided into proprietary non-HLOS software and proprietary HLOS software. HLOS is the High-level Operating System, and non-HLOS software refers to software below the HLOS layer.

Vulnerability details: Cryptographic issue occurs during PIN/password verification using Gatekeeper, where RPMB writes can be dropped on verification failure, potentially leading to a user throttling bypass.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2024-45551

Preface: The Snapdragon SA8540P SoC and SA9000P AI accelerator are designed to work together seamlessly, particularly in advanced driver-assistance systems (ADAS) like GM’s Ultra Cruise. The buffer sharing design between these components is crucial for efficient data processing and low-latency performance. In automotive Ethernet Audio Video Bridging (eAVB), processors handle various types of message content to ensure efficient and reliable communication within the vehicle’s network.

Background: In Automotive Ethernet Audio Video Bridging (eAVB), processors handle the content of various types of messages to ensure efficient and reliable communication within the vehicle network.

Synchronization: eAVB ensures that audio and video streams are synchronized across different devices in the vehicle, providing a seamless infotainment experience.

Low Latency: Messages are designed to be transmitted with minimal delay, which is crucial for real-time applications like advanced driver-assistance systems (ADAS) and infotainment

Fault Tolerance: The system is built to handle faults and ensure continuous operation even in the presence of network issues

High Bandwidth: eAVB supports high-speed data transmission, which is necessary for handling large amounts of audio and video data

Vulnerability details: in Automotive Vehicle Networks. Memory corruption while processing message content in eAVB. Found that Buffer Copy Without Checking Size of Input (‘Classic Buffer Overflow’).

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-21443

Preface: QNX hypervisors are available in two variants: QNX Hypervisor and QNX Hypervisor for Safety.

The QNX Hypervisor variant (QH), which includes QNX Hypervisor 8.0, is not a safety-certified product. It must not be used in a safety-related production system.

If you are building a safety-related system, you must use the QNX Hypervisor for Safety (QHS) variant that has been built and approved for use in the type of system you are building, and you must use it only as specified in its Safety Manual. The latest QHS release is QNX Hypervisor for Safety 2.2, which is based on QNX SDP 7.1.

Background:  Functions like mprotect() are not commonly used in QNX hypervisor memory resource management for reasons:

1. Memory Isolation: The hypervisor ensures that each VM (both primary and guest) has its own isolated memory space. This prevents one VM from accessing the memory of another, enhancing security and stability.
2. Dynamic Memory Allocation: The hypervisor can dynamically allocate memory to VMs based on their needs. This means that if a guest VM requires more memory, the hypervisor can allocate additional memory from the available pool.
3. Memory Ballooning: This technique allows the hypervisor to reclaim unused memory from VMs and reallocate it where needed. The balloon driver within the VM inflates to consume memory, which is then returned to the hypervisor.
4. Memory Hotplug: The hypervisor can add or remove memory from a VM while it is running. This allows for flexible memory management without needing to restart the VM.

Vulnerability details: Memory corruption may occur during communication between primary and guest VM.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2024-53022

Preface: Many programmers continue to use Arm Compiler 5 for several reasons:

Developers who have been using Arm Compiler 5 for years are familiar with its quirks and features, making it easier for them to continue using it rather than learning a new toolchain.

Furthermore, Arm Compiler 5 supports older ARM architectures that may not be fully supported by newer compilers.

Background: When compiling ARM code with stack protection, the –protect_stack option is used to safeguard against stack buffer overflows and potential malicious tampering. Here are the conditions under which a function is considered vulnerable and thus protected:

1. Arm Compiler 5:
   A function is considered vulnerable if it contains a char or wchar_t array of any size1.
2. Arm Compiler 6:
   With -fstack-protector, a function is considered vulnerable if it contains:
   -A character array larger than 8 bytes.
   -An 8-bit integer array larger than 8 bytes.
   -A call to alloca() with either a variable size or a constant size bigger than 8 bytes1.
   With -fstack-protector-strong, a function is considered vulnerable if it contains:
   -An array of any size and type.
   -A call to alloca().
   -A local variable that has its address taken1.

Using these options helps improve the overall security and integrity of your code by preventing stack buffer overflows

Vulnerability details: In certain circumstances the stack protection feature can be rendered ineffective, leaving the protected function vulnerable to stack-based buffer overflows.

An undetected stack overflow can lead to a function return address being overwritten, potentially causing a crash or hang or allowing an attacker to gain control over program execution.

Official announcement: Please refer to the vendor announcement for detail – https://developer.arm.com/documentation/110262/1-1/?lang=en