Category Archives: IoT

CVE-2025-48507: About calling processor into Arm Trusted Firmware (26th Nov 2025)

Preface: AMD’s Zynq™ UltraScale+™ RFSoCs are a family of highly integrated adaptive Systems-on-Chip (SoCs) that combine a multi-core Arm® processing system, programmable logic (FPGA fabric), and direct RF-sampling data converters (ADCs and DACs) on a single chip. CVE-2025-48507 Affected Devices: Kria™ SOM, Zynq™ UltraScale+™ MPSoCs and Zynq™ UltraScale+™ RFSoCs.

Background: The crypto operations in Arm® Trusted Firmware (TF-A) are part of a subsystem, which can be implemented through various components like the Runtime Security Engine (RSE) or a dedicated secure enclave. This subsystem provides hardware-assisted security services, such as cryptographic acceleration and secure storage, which are distinct from the main processor and are protected by the system’s security architecture.

From a cyber security perspective, calling a processor into TF-A is different because it uses a specialized, secure boot process and requires the processor to switch to a secure state via a Secure Monitor Call (SMC) instruction, as outlined in the Arm Developer and Trusted Firmware-A Documentation. This differs from standard OS calls which typically use different mechanisms for switching between user and kernel modes.

*Secure Monitor Call (SMC): TF-A calls are initiated using the SMC instruction, which is specifically designed for secure operations and causes the processor to switch to a privileged secure state (like EL3).

Vulnerability details: The security state of the calling processor into Arm® Trusted Firmware (TF-A) is not used and could potentially allow non-secure processors access to secure memories, access to crypto operations, and the ability to turn on and off subsystems within the SOC.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2025-48507

In-depth analysis of the Android 0-Click vulnerability – CVE-2025-48593. The issue has been resolved.  (20th Nov 2025)

Published: 2025-11-17

Preface: An HFP (Hands-Free Profile) device is a Bluetooth device that supports the Hands-Free Profile, which allows for hands-free calling and control of a mobile phone, such as a car’s infotainment system or a wireless headset. It enables features like answering, making, and ending calls, as well as voice dialing and call waiting, using the paired phone’s microphone and speaker.

Background: Unlike many security threats that require users to click on malicious links or download files, this vulnerability operates silently without any user intervention.

Android’s Bluetooth module is responsible for managing the device’s Bluetooth protocol stack and settings. This module is part of the AOSP open-source code library and is used by the Android system and manufacturer firmware. Android’s Bluetooth functionality fundamentally relies on a modified Linux kernel, which is the core of the Android operating system. The device drivers for hardware components like Bluetooth reside within the kernel system. In the affected version, the HF client module lacks necessary state and boundary checks when handling the Bluetooth device discovery database. The suspicious part is that bta_hf_client_scb_init() is called during registration and also after disable, and if the timer callback is still active during this transition, it could access freed or partially reinitialized memory.

Vulnerability details: CVE-2025-48593 – In bta_hf_client_cb_init of bta_hf_client_main[.]cc, there is a possible remote code execution due to a use after free. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2025-48593

CVE-2025-47353: About Automotive Software platform based on QNX (5th Nov 2025)

Preface: An automotive cockpit is the driver’s compartment, integrating all the controls and information displays needed to operate a vehicle, including the steering wheel, dashboard, instruments, and central displays.

Background: To install QNX on a Qualcomm SA8775P chip, you will need the specific QNX Board Support Package (BSP) for that platform, as it contains the necessary hardware-specific software to get the OS running. The installation process will involve loading the BSP onto the chip, which provides the essential startup code and device drivers needed to run QNX. Since this is an automotive-grade chip used for cockpit and driving functions, it’s likely an OEM or a specialized automotive development partner would be handling this process.

QNX handles guest virtual machine (GVM) memory by using a hypervisor to manage the host physical memory, which the guest sees as contiguous. The hypervisor allocates memory to a guest and uses services like “smmuman” to program the IOMMU/SMMU to protect the guest’s memory from the host and other guests. The hypervisor maps host physical memory to the guest’s guest-physical memory, and can use shared memory regions for efficient inter-VM communication.

Vulnerability details:

Title – Exposed Dangerous Method or Function in Automotive Software platform based on QNX

Description – Memory corruption while processing request sent from GVM.

Technology Area – Automotive Software platform based on QNX

Vulnerability Type – CWE-749: Exposed Dangerous Method or Function

Access Vector     Local

Security Rating   High

CVSS Rating        High

CVSS Score         7.8

Due to a lack of detailed supplier information, we discovered through observation that…

Attack Surface:

  • Shared memory + IPC exposed to guest.

Threats:

  • Buffer overflow → hypervisor memory corruption.
  • Capability spoofing → unauthorized access.

Mitigations:

  • Mediator validation.
  • Capability-based security.
  • Immutable protocol with checksum.

Official announcement: Please refer to the link for details –

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

In-depth discussion of the basic knowledge of CAN BUS preventive control (30th Oct 2025)

Preface: Is the CAN bus still in use? While the CAN protocol was originally designed for road vehicles and is still primarily used there, the vehicle bus format has found its way into aircraft, aerospace, and rail systems.

Background: CAN bus significantly reduces traditional cable connections by allowing multiple electronic control units (ECUs) to communicate over a single two-wire bus, which simplifies wiring, lowers costs, and reduces weight. This is a major advantage over traditional systems that require a separate, complex harness for each connection.

Manufacturer concerned about the security of externally accessible CAN (Controller Area Network) wires. Physical access to the CAN bus can indeed allow malicious actors to inject crafted messages, potentially controlling critical vehicle functions like remote start, door locks, or even braking systems.

Preventative Procedures Against CAN Injection via Physical Access: While physical access is hard to prevent entirely, several defensive measures can be implemented to mitigate the risk:

1. Network Segmentation – Description: Separate critical ECUs (Electronic Control Units) from non-critical ones using gateways.

Benefit: Limits access to sensitive systems even if an attacker gains access to one part of the network.

2. Message Authentication – Description: Use cryptographic methods to authenticate CAN messages.

Benefit: Prevents unauthorized messages from being accepted by ECUs.

Challenge: Standard CAN protocol lacks built-in support for encryption or authentication, so this requires custom implementation or use of CAN-FD with added security layers.

3. Intrusion Detection Systems (IDS) – Description: Monitor CAN traffic for anomalies or unauthorized message patterns.

Benefit: Detects and alerts on suspicious activity.

Example: Detecting messages with unexpected arbitration IDs or unusual frequency.

4. Physical Security – Description: Secure access to OBD-II ports and other external CAN access points.

Benefit: Prevents unauthorized physical connection to the CAN bus.

5. Rate Limiting and Filtering – Description: Limit the rate of messages and filter based on known-good IDs.

Benefit: Reduces the impact of flooding or spoofing attacks.

Perhaps an effective preventive measure is to install a filter. See the attached diagram for details.

Reference:

Similar vulnerabilities in the automotive industry can be found here. Please refer to the link – https://nvd.nist.gov/vuln/detail/CVE-2025-6785

CVE-2025-11678: About warmcat libwebsockets (Industrial network security – Are you worried about?) 23rd Oct 2025

Published: 2025-10-20

Preface: Contribute Automation Expert is a software-centric industrial automation platform that is vendor-agnostic and based on the IEC 61499 standard. It is designed to make industrial automation more agile, efficient, and flexible by decoupling hardware and software, which allows for the use of components from different manufacturers and simplifies the process of updating and upgrading systems. 

Background: Libwebsockets is a C library that offers a high-performance, lightweight, and versatile way to handle WebSockets, HTTP, and other protocols. Libwebsockets is a strong contender for projects requiring low-level control and performance.

EcoStruxure Automation Expert Software dPAC is a state-of-the-art multi-platform IEC 61499-based control runtime that includes:

  • Event-based, network-transparent automation capability
  • Native process alarm support
  • Modbus/TCP client and server
  • OPC UA client and server b Ethernet/IP scanner
  • WebSocket server

Vulnerability details: Stack-based Buffer Overflow in lws_adns_parse_label in warmcat libwebsockets allows, when the LWS_WITH_SYS_ASYNC_DNS flag is enabled during compilation, to overflow the label_stack, when the attacker is able to sniff a DNS request in order to craft a response with a matching id containing a label longer than the maximum.

The CVE-2025-11678 vulnerability patch you referenced is in the async-dns-parse[.]c file of libwebsockets, which is a C library for WebSocket and related protocols.

Official details: Official documentation and vulnerability reports mention that EcoStruxure Automation Expert is an affected component for this CVE. Please refer to the link for details –

https://libwebsockets.org/git/libwebsockets/commit?id=2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a

https://www.tenable.com/cve/CVE-2025-11678

CVE-2025-33182 and CVE-2025-33177: About NVIDIA Jetson Linux and IGX OS (20-10-2025)

Official Updated 10/13/2025 09:19 AM

Preface: Railway applications have traditionally relied on fixed-function embedded computers to perform tasks such as signaling, monitoring, and train control. To bridge this gap, rail operators and system integrators are turning to AI-driven edge computing to meet the growing demand for real-time processing and automation.

Background: The Nvidia Jetson is not just a CPU; it is a complete embedded computing board with both a CPU and a powerful GPU, memory, and other components on a single module. It is a System on Module (SoM) designed for AI and machine learning applications at the edge.

CPU: The Jetson modules contain an ARM-based CPU for general-purpose processing.

GPU: A key feature is the integrated GPU with CUDA cores, which is specialized for parallel processing and AI tasks.

The NVIDIA Jetson Linux Driver Package includes a UEFI-based bootloader. This bootloader is the standard firmware for newer Jetson platforms like Orin and AGX Xavier, replacing the older CBoot system. The UEFI firmware is included with the Linux kernel, drivers, and a root filesystem for the Jetson platform. 

Component of the driver package: The UEFI bootloader is a standard part of the Jetson Linux Driver Package, alongside the Linux kernel, drivers, and utilities.

Support for modern platforms: Support for the UEFI bootloader is included in recent releases of Jetson Linux, such as R35.6.0 and later, for platforms like Jetson AGX Orin, Orin NX, Orin Nano, and others.

Vulnerability details:

CVE-2025-33182: NVIDIA Jetson Linux contains a vulnerability in UEFI, where improper authentication may allow a privileged user to cause corruption of the Linux Device Tree. A successful exploitation of this vulnerability might lead to data tampering, denial of service.

CVE-2025-33177: NVIDIA Jetson Linux and IGX OS contain a vulnerability in NvMap, where improper tracking of memory allocations could allow a local attacker to cause memory overallocation. A successful exploitation of this vulnerability might lead to denial of service.

Official announcement: Please refer to the url for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5716

CVE-2025-27053: Incorrect Calculation of Buffer Size in HLOS (17th Oct 2025)

Official Published: 10/06/2025

Preface: Microsoft partners with the Android ecosystem by enabling its PlayReady DRM technology for content protection on Android devices, both in apps and web browsers. This integration allows developers to protect premium content like live TV and video-on-demand (VOD) using Android’s Java DrmManagerClient API, while web browsers use the Encrypted Media Extensions (EME) standard to access PlayReady via a Content Decryption Module (CDM). Leading Android device manufacturers often embed a PlayReady client into their devices, and Microsoft provides a Porting Kit to help them do so.

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: Memory corruption during PlayReady APP use case while processing TA commands.

CVE-2025-27053 : If the BUFFER_SIZE is incorrectly calculated (e.g., too small for the actual data exchanged), the TA might read or write beyond the allocated memory, leading to memory corruption. The vulnerability CVE-2025-27053 is a memory corruption issue caused by incorrect buffer size calculation in HLOS when processing TA commands in the PlayReady APP usecase. Here’s why it affects Qualcomm Snapdragon chips.

Official announcement: Please refer to the url for details –

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

CVE-2025-47347: Stack-based Buffer Overflow in Automotive Software platform based on QNX  (14-10-2025)

Preface: QNX uses a 4KB page size by default for memory translation, where memory is organized into fixed-sized chunks called pages, which are the units the memory manager works with. However, newer versions of the QNX OS have introduced variable page sizes for improved performance, allowing for larger blocks of memory to be mapped with a single translation table entry instead of multiple 4KB entries, according to QNX. 

Background: Qualcomm embedded chips can run the QNX Hypervisor to securely virtualize multiple operating environments on a single System-on-Chip (SoC). This allows developers to consolidate different OSs, such as a functional safety OS for critical systems like driving and a less critical OS for infotainment, onto one processor. The QNX Hypervisor works by creating virtual machines (VMs) that execute directly on the physical CPU.

Vulnerability details: Memory corruption while processing control commands in the virtual memory management interface.

Ref: In QNX, if a thread is created without explicitly setting a stack size, it uses a default size (e.g., 256 KB on x86_64 and AArch64) with a guard page to detect overflows. But if the thread’s actual usage exceeds this size, and the guard page is bypassed or misconfigured (e.g., due to a bug in the memory management interface), it could lead to stack corruption.

Recommendations

  • Always explicitly set stack sizes for threads using pthread_attr_setstacksize() or pthread_attr_setstack() to ensure they are large enough for the thread’s workload.
  • Apply vendor patches addressing CVE-2025-47347 as soon as available.

Official announcement: Please see the link for details

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

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

CVE-2025-3231: About ARM Mali. Learn more about the details (19th Sep 2025)

NVD Published Date: 09/08/2025
NVD Last Modified: 09/08/2025

Preface: The Mali kernel driver and userspace libraries are found in different locations depending on whether the system is Android or a general Linux distribution, and also based on the specific Mali GPU generation and the SoC vendor’s implementation.

Background: Mali GPU is a hardware accelerator.

  • It does not run an OS itself.
  • It relies on kernel-space and user-space drivers (like the Mali kernel driver and userspace libraries) to interface with the operating system (Linux, Android, etc.).

ioctl (Input/Output Control) is the primary syscall used by userspace GPU drivers to communicate with the kernel-space driver. It allows sending custom commands and structured data to the driver.

Typical ioctl operations in Mali drivers include:

  • MALI_IOCTL_ALLOC_MEM: Allocate GPU-accessible memory
  • MALI_IOCTL_FREE_MEM: Free previously allocated memory
  • MALI_IOCTL_SUBMIT_JOB: Submit a GPU job (e.g., shader execution)
  • MALI_IOCTL_WAIT_JOB: Wait for job completion
  • MALI_IOCTL_MAP_MEM: Map memory to userspace

Vulnerability details: CVE-2025-3212 is a vulnerability in the kernel driver that interfaces with the Mali GPU. Here’s what that means:

  • The vulnerability is in software, not the hardware.
  • It allows a local non-privileged user to exploit the driver to access freed memory, which could contain sensitive data or allow privilege escalation.
  • The Mali GPU hardware itself is not “vulnerable” in the sense of having a flaw — but it becomes a vector for exploitation because of the flawed driver.

Official announcement: Please refer to the link for details – https://developer.arm.com/documentation/110627/1-0/

CVE-2024-45434 was published on September 12, 2025. You may have heard about it in popular cybersecurity magazine back in July of this year. Let’s take a closer look at it today. (16-09-2025)

Preface: If an SDK contains a use-after-free (UAF) vulnerability, the consequences can range from minor data corruption and program crashes to severe security issues like arbitrary code execution, information leakage, and privilege escalation, as the vulnerability allows attackers to manipulate previously freed memory, leading to system instability or full compromise.

Background: Classic and Low Energy devices use different hardware and software stacks: Bluetooth® Classic devices can´t communicate with Bluetooth® Low Energy and vice versa.  As for some applications, the power consumption of Bluetooth® Classic is still too high.  The Bluetooth® SIG developed a standard lower power consumption to overcome this obstacle.

Vulnerability details: OpenSynergy BlueSDK (aka Blue SDK) through 6.x has a Use-After-Free. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of validating the existence of an object before performing operations on the object (aka use after free). An attacker can leverage this to achieve remote code execution in the context of a user account under which the Bluetooth process runs.

This vulnerability was part of a broader exploit chain called PerfektBlue, which affected millions of vehicles from:

  • Volkswagen (ICAS3)
  • Mercedes-Benz (NTG6)
  • Škoda (MIB3)
  • And an unnamed OEM

Attackers could:

  • Send crafted AVRCP packets post-pairing
  • Trigger the use-after-free
  • Overwrite function pointers
  • Achieve remote code execution (RCE) in the infotainment system

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2024-45434