Category Archives: IoT

IoT, Potential Risk of CVE

CVE-2025-7427: Affected Products (Arm Development Studio before 2025.0) [23-07-2025]

Leave a comment

Preface: Arm Development Studio (Arm DS) is a suite of software tools designed for developing and debugging software for Arm-based SoCs (Systems on Chip). Thus, Arm DS optimizing software for Arm-based hardware, primarily in embedded systems and IoT devices. These tools help developers write, compile, and debug code for various Arm processors, including those found in SoCs. Applications built with Arm DS can be deployed to various targets, including microcontrollers, embedded Linux systems, and even Android devices.

Background: Arm Development Studio is available for both Windows and Linux operating systems. Specifically, it supports 64-bit x86 host platforms for both Windows 10 and Linux distributions like Red Hat Enterprise Linux 7 and Ubuntu Desktop Editions 18.04 LTS and 20.04 LTS.

Redistributable Packages: For distributing applications built with Arm Development Studio, developers might need to include redistributable packages like those related to the Visual C++ runtime libraries, which are also provided as [.]dll files.

Vulnerability details: CVE-2025-32702: Improper neutralization of special elements used in a command (‘command injection’) in Visual Studio allows an unauthorized attacker to execute code locally.

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

AI and ML, IoT, Potential Risk of CVE

CVE-2025-23270: NVIDIA Jetson Linux contains a vulnerability in UEFI Management mode (20th July 2025)

Leave a comment

Preface: To enter UEFI Management mode on a Jetson device, you’ll typically need to access it during the boot process by pressing a specific key (like F2, F10, or Del) before the OS starts loading. Once in UEFI, you can configure settings related to booting, such as boot order and device selection.

Background: CUDA is a parallel computing platform and programming model developed by NVIDIA, designed to leverage the power of GPUs for general-purpose computing. Linux for Tegra (L4T) is NVIDIA’s customized Linux distribution based on Ubuntu, optimized for their Tegra family of system-on-chips (SoCs), including those used in Jetson development kits. Essentially, L4T provides the operating system and necessary drivers for running CUDA-enabled applications on NVIDIA’s embedded platforms.

NVIDIA Jetson Linux is a customized version of the Linux operating system specifically designed for NVIDIA Jetson embedded computing modules. It provides a complete software stack, including the Linux kernel, bootloader, drivers, and libraries, tailored for the Jetson platform’s hardware and intended for edge AI and robotics applications.

Vulnerability details:

CVE-2025-23270 NVIDIA Jetson Linux contains a vulnerability in UEFI Management mode, where an unprivileged local attacker may cause exposure of sensitive information via a side channel vulnerability. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, and information disclosure.

CVE-2025-23269 NVIDIA Jetson Linux contains a vulnerability in the kernel where an attacker may cause an exposure of sensitive information due to a shared microarchitectural predictor state that influences transient execution. A successful exploit of this vulnerability may lead to information disclosure.

Official announcement: Please see the link for details

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

“When error occurs, the data remaining on cache memory. When OS started, a malicious program stored in device then executes read on shared memory.”

AI and ML, IoT, Potential Risk of CVE, System, Under our observation

AMD releases details about Transient Scheduler Attack (TSA) – 9 Jul 2025

Leave a comment

Preface: CPU transient instructions refer to instructions that are speculatively executed by a processor’s out-of-order execution engine, but which may ultimately be discarded and not reflected in the processor’s architectural state. These instructions are executed based on predictions about control flow or data dependencies, and if the prediction is incorrect, the results of these transient instructions are discarded.

Background: Transient Scheduler Attacks (TSA) are new speculative side channel attacks related to the execution timing of instructions under specific microarchitectural conditions. In some cases, an attacker may be able to use this timing information to infer data from other contexts, resulting in information leakage.

Vulnerability details:

CVE-2024-36350 – A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.

CVE-2024-36357 – A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.

CVE-2024-36348 – A transient execution vulnerability in some AMD processors may allow a user process to infer the control registers speculatively even if UMIP[3] feature is enabled, potentially resulting in information leakage.

CVE-2024-36349 – A transient execution vulnerability in some AMD processors may allow a user process to infer TSC_AUX even when such a read is disabled, potentially resulting in information leakage.

Official announcement: Please see the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html

Cell Phone (iPhone, Android, windows mobile), IoT, Potential Risk of CVE

CVE-2025-21432: Double Free in SPS-HLOS (8th July 2025)

Leave a comment

Preface: Concise Binary Object Representation (CBOR) is a binary data serialization format loosely based on JSON authored by Carsten Bormann. The use of Concise Binary Object Representation (CBOR) in SPS HLOS (and other constrained environments) is primarily due to its ability to provide a compact, efficient, and extensible binary data format. This makes it suitable for resource-constrained devices and networks, where bandwidth and processing power are limited. 

Background: In Adreno GPUs, SPS (Shader Processors) HLOS refers to a specific architecture or organization within the GPU where Shader Processors are grouped and managed. “HLOS” likely stands for “High Level Operating System”, indicating that these SPS are managed by the system’s main operating system (like Android) rather than being directly controlled by the GPU’s internal firmware. This means the CPU and operating system handle the overall workload and scheduling for these shader processors.

Ref: CBOR data, from the perspective of a Transfer Agent (TA), refers to data formatted using the Concise Binary Object Representation (CBOR) standard, likely used for efficient and compact representation of information related to financial transactions or other assets managed by the TA. 

Vulnerability details: Memory corruption while retrieving the CBOR data from TA (Transfer Agent).

Summary:

Component – Qualcomm Adreno GPU (Graphics Driver)

Vulnerability Type – Double Free / Memory Corruption

Trigger – Occurs during CBOR data retrieval from shader memory by the Transfer Agent (TA).

Affected Subsystem: SPS-HLOS (Shader Processor System managed by High-Level OS)

Impact:

Double free condition in shared memory buffers.

Potential for arbitrary code execution or privilege escalation.

Exploitable via crafted GPU workloads or malicious apps using OpenCL/Vulkan.

Official announcement: Please see the link for details – https://docs.qualcomm.com/product/publicresources/securitybulletin/july-2025-bulletin.html

Cell Phone (iPhone, Android, windows mobile), IoT, Potential Risk of CVE

CVE-2025-21450: Improper Authentication in GPS GNSS (7th July 2025)

Leave a comment

Preface:

GNSS – This is a global term encompassing all satellite constellations that provide positioning, navigation, and timing (PNT) services. Besides GPS, other GNSS include GLONASS (Russia), Galileo (EU), and BeiDou (China).

GPS – The Global Positioning System, developed by the US Department of Defense, is the most widely recognized and used GNSS. It was the first global satellite navigation system and has become a household term.

Background: A GPS/GNSS receiver can be considered the client in a similar way to an IoT device or smartphone, particularly when used for location-based services. GPS/GNSS receivers require cryptographic downloads, specifically key material and potentially software updates, to enable authentication and anti-spoofing features. These features ensure the integrity and authenticity of the received signals, protecting against malicious attacks like spoofing where fake signals mimic legitimate satellites.

Ref: The GPS module in the Snapdragon 8 Gen 3 is integrated within the Snapdragon X75 5G Modem-RF System. The X75 is a comprehensive modem-RF solution that includes not only 5G capabilities but also other wireless technologies like Wi-Fi, Bluetooth, and location services like GPS. This integration allows for efficient and high-performance location tracking and navigation on devices powered by the Snapdragon 8 Gen 3.

Vulnerability details: Cryptographic issue occurs due to use of insecure connection method while downloading.

Vulnerability Type: CWE-287 Improper Authentication

Official announcement: Please see the link for details –

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

IoT, Potential Risk of CVE

CVE-2025-52496: Mbed TLSan open-source C library design weakness (6th July 2025)

Leave a comment

Preface: What is the difference between FreeRTOS and Cmsis-RTOS?

Basically FreeRTOS is a RTOS, while CMSIS-RTOS is only a wrapper for any RTOS (like FreeRTOS, CMSIS-RTOS RTX or anything you want). CMSIS-RTOS is an API that enables consistent software layers with middleware and library components. Mbed TLS aims to provide a set of powerful and flexible cryptographic and security building blocks, mainly for embedded systems, focusing on ease of integration and security. The design objective strives to be lean,  prioritizing readability, documentation and testability, while minimizing dependencies and providing a loosely coupled architecture. This allows developers to integrate only the necessary components without the overhead of the entire library.

Background: Do multi-threaded programs use the same AES key?

Yes, multithreaded programs using AES encryption typically use the same AES key for both encryption and decryption, as AES is a symmetric encryption algorithm. Both the sender and receiver need to share the same secret key to encrypt and decrypt data. In a multithreaded context, each thread would utilize this shared key when performing encryption or decryption operations.

Vulnerability details: Mbed TLS before 3.6.4 has a race condition in AESNI detection if certain compiler optimizations occur. An attacker may be able to extract an AES key from a multithreaded program, or perform a GCM forgery.

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

IoT, Potential Risk of CVE

CVE-2025-6073 – Industrial Controls Be Aware! (4th July 2025)

Leave a comment

Preface: The default configuration of the ABB RMC-100’s REST interface is disabled. ABB recommends leaving the REST interface disabled when not in use, particularly when configuring MQTT functionality. The RMC-100 is not intended for access over public networks.

Background: The ABB RMC-100 is a popular and widely used remote modular controller, particularly within the oil and gas industry. It is known for its scalability and ability to manage automation, liquids and gas measurement, and asset data concentration for various facility sizes, from large production and transmission facilities to smaller systems. The RMC-100 is part of ABB’s Totalflow portfolio, which has seen over 430,000 units sold since the 1980s.

Service available in some Totalflow devices like the RMC-100. When enabled, the device REST server capabilities are enabled. The device then can be accessed by a REST client such as a web browser. The access is for the configuration of the MQTT parameters.

Uses HTTP methods (protocol) to access resources on a REST server. For example, the web browser which accesses the MQTT configuration interface on the RMC-100.

Vulnerability details: Stack-based Buffer Overflow vulnerability in ABB RMC-100, ABB RMC-100 LITE. When the REST interface is enabled by the user, and an attacker gains access to the control network, and user/password broker authentication is enabled, and CVE-2025-6074 is exploited, the attacker can overflow the buffer for username or password.

Affected Products: This issue affects RMC-100: from 2105457-043 through 2105457-045; RMC-100 LITE: from 2106229-015 through 2106229-016.

Official announcement: Please see the link for details –

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

IoT, Potential Risk of CVE

CVE-2025-0038 exposes a runtime vulnerability due to missing checks in PMU firmware. (2nd July 2025)

Leave a comment

Preface: Users typically build custom PMU firmware tailored to their specific hardware platform and application requirements.

PMU firmware can be loaded by either FSBL or CSU BootROM (CBR). Both these flows are supported by AMD. Loading PMU firmware using FSBL has the following benefits:

– Possible quick boot time, when PMU firmware is loaded after bitstream.

– In use cases where you want two BIN files – stable and upgradable, PMU firmware can be part of the upgradable (by FSBL) image.

Background: The primary design objective of AMD’s Zynq™ UltraScale+™ devices is to provide a highly integrated platform that combines the processing power of a multi-core ARM processor with the flexibility of programmable logic (FPGA fabric). This enables a wide range of applications by offering both real-time control and processing capabilities within a single chip. The devices also prioritize low power consumption, security features, and efficient memory management.

Ref: Arm Trusted Firmware (ATF) and its role in managing the Secure Monitor and Trusted Board Boot Requirements (TBBR). These are essential for establishing a secure boot process and managing transitions between the secure and non-secure worlds in Arm-based systems like the Zynq UltraScale+.

Vulnerability details: In AMD Zynq UltraScale+ devices, the lack of address validation when executing CSU runtime services through the PMU Firmware can allow access to isolated or protected memory spaces resulting in the loss of integrity and confidentiality.

Official announcement: Please see the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-8008.html

https://docs.amd.com/r/en-US/000037628/Affected-Products

AI and ML, IoT, Potential Risk of CVE

CVE-2025-36852: “first-to-cache wins” jeopardizes Bucket-based object storage! (12th June 2025)

Leave a comment

Preface: Cloud service providers use “first-to-cache wins” (also known as “cache hit”) for improved performance and efficiency. By caching frequently accessed data, they can quickly retrieve it without needing to access the slower underlying storage layer. This reduces latency, enhances user experience, and can also lower costs associated with accessing and processing data.

Background: In a “first-to-cache wins” scenario, the winning location is in CPU embedded memory, specifically the L1 and L2 caches, which are located directly on the processor chip. The L1 cache is the fastest and smallest, while the L2 cache is slower but larger. Both are much faster than accessing physical memory (RAM).

Do well-known cloud service providers implement the concept of “first-to-cache wins”?

Example 1: S3 is designed to store and manage data objects (files, images, etc.) in the cloud. While S3 itself doesn’t have a “first-to-cache wins” mechanism, it can be used as a layer of caching, especially when combined with other caching services like Amazon ElastiCache for Redis.

Example 2: Google Cloud Storage does not operate on a strict “first-to-cache wins” theory. Instead, it uses a more nuanced caching system that considers factors like the Cache-Control metadata, object type, and the location of the read operation.

Is the Vulnerability Valid?

Yes, it’s valid and serious in the context of build systems that:

-Use remote caching with object storage.

-Allow untrusted contributors (e.g., via pull requests).

-Do not enforce cache validation or isolation between trusted and untrusted environments.

Vulnerability details: A critical security vulnerability exists in remote cache extensions for common build systems utilizing bucket-based remote cache (such as those using Amazon S3, Google Cloud Storage, or similar object storage) that allows any contributor with pull request privileges to inject compromised artifacts from an untrusted environment into trusted production environments without detection. The vulnerability exploits a fundamental design flaw in the “first-to-cache wins” principle, where artifacts built in untrusted environments (feature branches, pull requests) can poison the cache used by trusted environments (protected branches, production deployments). This attack bypasses all traditional security measures including encryption, access controls, and checksum validation because the poisoning occurs during the artifact construction phase, before any security measures are applied.

Official announcement: Please refer to the link for details –

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

https://nx.app/files/cve-2025-06

AI and ML, Cell Phone (iPhone, Android, windows mobile), IoT, Potential Risk of CVE

CVE-2025-2884 – Design weakness in the Trusted Platform Module (TPM) 2.0 reference implementation code. (11th June 2025)

Leave a comment

Preface: The main difference between AMD’s Trusted Platform Module (TPM) and those from other manufacturers , how it’s implemented: AMD offers a firmware TPM (fTPM), while many other manufacturers, including Intel, also offer a dedicated hardware TPM (dTPM).

Background: TPM refers to a Trusted Platform Module, which is a specialized chip that securely stores cryptographic keys used for encryption and decryption, enhancing overall system security. AMD’s approach often involves Firmware TPM (fTPM), also known as Intel’s Platform Trust Technology (PTT), which implements TPM functionality within the system’s firmware rather than using a dedicated physical chip.

The AMD Ryzen Embedded 7000 series processors indeed integrate advanced security features, including:

  • AMD Secure Processor (ASP): A dedicated security co-processor embedded directly into the CPU die.
  • Firmware TPM (fTPM): Implemented in firmware and runs on the ASP.
  • Microsoft Pluton: A hardware-based security processor integrated into the silicon, designed to work alongside ASP and fTPM for enhanced protection.

Ref: The most common TPM is the TPM function supported by the Trusted Execution Environment (TEE) of Intel Core i series or AMD Ryzen series CPU in the motherboard UEFI firmware. fTPM can be used in all processors after Intel Broadwell (5th generation) and AMD Ryzen series. This is the most common method because you can easily use the TPM function without purchasing a separate module.

Vulnerability details: An out-of-bounds read vulnerability exists in TPM2.0’s Module Library allowing a read past the end of a TPM2.0 routine as described above. An attacker who can successfully exploit this vulnerability can read sensitive data stored in the TPM and/or impact the availability of the TPM.

Official announcement: Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4011.html