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