Category Archives: IoT

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

IoT, Potential Risk of CVE

CVE-2025-38004: An issue related to the automotive industry and Linux was discovered. (10th Jun 2025)

Leave a comment

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

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

CVE-2025-0037: About AMD Versal™ Adaptive SoC – Initial publication 2025-06-03

Leave a comment

(9th June 2025)

Preface: AMD’s Versal™ Adaptive SoCs are used in a wide range of industries, particularly those requiring high-performance, low-latency processing and flexibility, such as data centers, wireless networking, automotive, aerospace, and defense. Versal chips are also utilized in areas like 5G wireless, advanced driver assist, and even 3D printing.

AMD’s Versal™ Adaptive SoC technology is used in several different chip series, including the Versal AI Edge, Versal AI Core, Versal Prime, Versal Premium, and Versal RF series. These SoCs are designed for a variety of applications, including AI inference, data-intensive workloads, and high-speed communication.

Background: Platform Management Controller (PMC), Platform Loader and Manager (PLM), and boot and configuration are key components in modern embedded systems, especially in Xilinx Versal ACAPs and similar platforms.

Key Steps Illustrated:

1.BootROM loads PL –  Initial boot step from non-volatile memory.

2.PLM starts running – Executes on the MicroBlaze inside the PMC.

3.PLM authenticates and decrypts partitions – Uses hardware accelerators in the PMC for cryptographic operations.

4.PLM configures programmable logic – Loads and configures the Adaptive Engines and other programmable resources.

Remark: To understand the process, please refer to the attached diagram.

Vulnerability details: In Versal™ Adaptive SoC devices, the Platform Loader and Manager (PLM) implements runtime (post-boot) software services that can allow a remote processor to command the PLM to execute cryptographic operations – including AES, SHA3, RSA, ECDSA – using the hardened cryptographic accelerators, eFUSE and BBRAM reads and writes, reloading PDIs, and reading back the FPGA on behalf of the remote processor.

A potential vulnerability exists with commanding these runtime services, in that the memory passed with the command to execute the services is not checked by the PLM to verify that the requesting processor has access to the memory space.

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

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

CVE-2025-1246: A non-privileged user process can perform valid GPU processing operations (8th June 2025)

Leave a comment

Preface: The Valhall family of Mali GPUs uses the same top-level architecture as the previous generation Bifrost GPUs. The Valhall family uses a unified shader core architecture. Arm’s 5th generation GPU architecture, on the other hand, is a type of GPU architecture that is designed for visual computing, especially on mobile devices, and includes features like deferred vertex shading and hardware-based ray tracing. It is a part of the Arm Mali or Immortalis GPU family.

Background: Arm’s Mali GPUs are closely related to the Valhall architecture. Valhall is Arm’s fourth-generation architecture for Mali GPUs, and the Mali-G77 is the first high-end GPU to adopt this architecture. Valhall improves on previous generations of architectures such as Bifrost with a simplified, compiler-friendly instruction set and better compatibility with newer APIs such as Vulkan. The architecture also allows for configuration of the number of shader cores and the size of the L2 cache.

WebGL (Web Graphics Library) and WebGPU (Web Graphics Processing Unit) are both JavaScript APIs that allow web developers to use a computer’s GPU to render 3D graphics and perform computations within a web browser. WebGPU is a newer and more powerful API than WebGL, designed to provide better performance and support for modern GPUs.

Vulnerability details: A non-privileged user process can perform valid GPU processing operations, including via WebGL or WebGPU, to access outside of buffer bounds. This issue has been assigned the identifier CVE-2025-1246.

Affected Products – Bifrost GPU Userspace Driver

CVE-2025-1246: All versions from r18p0-r49p3, r50p0-r51p0 Valhall GPU Userspace Driver

CVE-2025-1246: All versions from r28p0-r49p3, r50p0-r54p0 Arm 5th Gen GPU Architecture Userspace Driver

CVE-2025-1246: All versions from r41p0-r49p3, r50p0-r54p0

Recommendations – These issues have been fixed in the following versions:

Bifrost GPU Userspace Driver – CVE-2025-1246: r49p4, r54p1

Valhall GPU Userspace Driver – CVE-2025-1246: r49p4, r54p1

Arm 5th Gen GPU Architecture Userspace Driver – CVE-2025-1246: r49p4, r54p1

Official announcement: Please see the link for – detailshttps://developer.arm.com/documentation/110466/1-0

IoT, Potential Risk of CVE

CVE-2024-53010 – Improper Access Control in Core (5th Jun 2025)

Leave a comment

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