Preface: In the automotive industry, SocketCAN is an open-source implementation of the Controller Area Network (CAN) protocol for Linux. It provides a way for different electronic control units (ECUs) in a vehicle to communicate with each other over the CAN bus. SocketCAN uses the Linux network stack and Berkeley socket API to implement CAN device drivers as network interfaces, allowing multiple applications to access a CAN device simultaneously.

Background: CAN Broadcast Manager (BCM) can send a sequence of CAN frames to an actuator. In fact, a key functionality of the BCM is to handle cyclic transmission of CAN frames, which is commonly used for tasks like sending a sequence of commands or data to control an actuator. Actuators receive signals and respond with specified actions, including changing the air-fuel ratio in the engine, tightening up the suspension, or even applying the brakes. They convert electrical information into mechanical action, directly influencing and controlling a variety of vehicle components.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the ‘currframe’ counter is then set to zero. Although this appeared to be a safe operation the updates of ‘currframe’ can be triggered from user space and hrtimer context in bcm_can_tx().

Ref: Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the ‘count’ variable has been moved into the protected section as this variable can be modified from both contexts too.

Official announcement: Please see the link for details – https://www.tenable.com/cve/CVE-2025-38004

Preface: Android HLOS –

-Runs on the Application Processor (main CPU)    

-Main Android OS (Linux kernel, system services, apps)

Background: The Snapdragon 8 application processor (including variants like Snapdragon 8 Gen 3 and Snapdragon 8 Elite) uses the Adreno GPU. The Adreno GPU is a core component of Qualcomm’s Snapdragon mobile platforms and is responsible for handling graphics processing and rendering.

HLOS stands for High-Level Operating System, and in Qualcomm’s terminology, it refers to the Android OS running on the Application Processor (AP) of Snapdragon SoCs. This includes:

• The Android framework
• System services
• Linux kernel
• HALs (Hardware Abstraction Layers)
• Drivers and other user-space components

In Snapdragon and ARM-based systems, a VM (Virtual Machine) typically refers to a virtualized environment managed by a hypervisor. Qualcomm platforms may use Type-1 hypervisors (like Qualcomm’s own hypervisor or ARM’s KVM/EL2) to isolate different OS environments.

Vulnerability details: Memory corruption may occur while attaching VM when the HLOS retains access to VM.

Official Announcement: Please see the link for details – https://nvd.nist.gov/vuln/detail/CVE-2024-53010

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