Category Archives: IoT

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

A quick look at branch predictor isolation in KVM-QEMU

Preface: AMD SoCs can have KVM virtualization for embedded multicore systems, especially with ARM-based architectures, as KVM supports various architectures including ARM and has been adapted for embedded platforms. While KVM was initially designed for Intel and AMD x86 processors, its flexibility and portability allowed for ports to the ARM architecture, making it suitable for embedded multicore SoCs.

Ref: The AMD Zen5 branch predictor is a major update for the Zen family, featuring a new “two-ahead” design that allows it to predict up to two branches per clock cycle, a significant increase from the previous “one-ahead” limit.

Background: Any modern 64-bit AMD processor with AMD-V (SVM) virtualization support can utilize KVM-QEMU for virtualization, as KVM is integrated into the Linux kernel and requires only these hardware extensions for acceleration. To use KVM, you need to ensure AMD-V is enabled in your system’s firmware (BIOS/UEFI) and that your Linux distribution’s kernel and QEMU packages are installed and configured.

The branch predictor is a hardware component located within the processor that stores prediction data internally to improve performance by guessing the outcome of conditional branches.

It uses Branch History Buffers (BHT) and Branch Target Buffers (BTB) to keep track of past branch outcomes and the addresses of the branch targets, respectively, which are small, fast on-chip structures, not part of the main memory system.

Vulnerability details: Researchers from ETH Zurich discovered that incomplete isolation of the branch predictor state in AMD CPUs (Zen 1–5) allows a malicious guest VM to influence indirect branch prediction in the host, specifically in user-space components like QEMU.

The attack, named VMSCAPE, enables a guest VM to leak memory from the host QEMU process at a rate of 32 bytes/sec, including sensitive data like disk encryption keys.

Official announcement: For details, please refer to the link – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7046.html

CVE-2025-27072: Buffer Copy Without Checking Size of Input in Automotive Vehicle Networks (25-08-2025)

Official announcement: 08/04/2025

Quote: I chose a Qualcomm product affected by this vulnerability as an example. The Snapdragon Ride™ Flex SoC, including the SA9000P series, does not run on a single embedded OS, but rather supports mixed-criticality operating systems such as those provided by Qualcomm’s partners or the automaker themselves.

Preface: To set up Audio Video Bridging (AVB) on a Qualcomm SA9000P, you’ll need to enable the AVB stack and configure the appropriate settings for your specific hardware and software. While specific commands will depend on the operating system and software development kit (SDK) for the SA9000P, the general process involves using command-line tools or the provided SDK to enable the relevant protocols, such as Time-Sensitive Networking (TSN) and Multiple Stream Reservation Protocol (MSRP), which are part of the AVB standard.

Background: The Qualcomm SA9000P itself is a SoC (System on Chip), which typically does not include internal flash storage for OS images. Instead, the kernel and OS images are usually stored on external non-volatile memory connected to the SoC. Common storage options include:

  • eMMC (embedded MultiMediaCard)
  • UFS (Universal Flash Storage)
  • SPI NOR/NAND Flash
  • SD Card (for development purposes)

These storage devices are mounted on the development board or production hardware that integrates the SA9000P.

Vulnerability details: Information disclosure while processing a packet at EAVB BE side with invalid header length.

Vulnerability Type : CWE-120 Buffer Copy Without Checking Size of Input (‘Classic Buffer Overflow’)

Speculation: If a vulnerability (like CVE-2025-27072) allows processing of malformed packets that access invalid memory regions, and those regions are shared, then:

  1. Other subsystems (e.g., audio DSP, camera ISP, or modem) could be impacted.
  2. Sensitive data in shared buffers could be exposed or corrupted.
  3. System stability could degrade due to memory corruption.
  4. Security boundaries between subsystems could be violated.

Official announcement: Please refer to the link for details –

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

CVE-2025-8183: About µD3TN protocol.

A spaceman came travel, cyber security in space (29-07-2025)

NVD Published Date: 07/25/2025

NVD Last Modified: 07/25/2025

Preface: Essentially, any industry or application that requires communication in environments with unreliable or intermittent network conditions can benefit from BPv7’s capabilities. µD3TN has been successfully tested in Low Earth Orbit (LEO) on the OPS-SAT satellite, demonstrating its ability to handle the unique challenges of space communication, such as high latency and intermittent connectivity.

Background: The uD3TN project, a software implementation of the Delay-/Disruption-Tolerant Networking (DTN) Bundle Protocol, incorporates an allocator that functions similarly to the C standard library’s malloc dynamic memory allocator.

This allocator within uD3TN is responsible for managing memory allocation and deallocation for various components and data structures used within the DTN protocol stack. This includes, for example, the allocation of memory for bundles, which are the fundamental data units in DTN, as well as for internal structures and buffers required for bundle processing, forwarding, and storage.

The design of this allocator aims to provide efficient memory management within the constraints and requirements of a DTN implementation, potentially considering factors such as resource limitations in embedded systems or the need for robust handling of intermittent connectivity.

Vulnerability details: NULL Pointer Dereference in µD3TN via non-singleton destination Endpoint Identifier allows remote attacker to reliably cause DoS.

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

CVE-2025-8058: The regcomp function in the GNU C library design weakness, do not contempt! (24-07-2025)

Preface: Glibc is a fundamental component of many embedded systems, which are small, specialized computer systems found in vehicles for tasks like engine control, braking, and infotainment.

Background: The regcomp function in Linux is used to compile a regular expression pattern into a form that can be efficiently used by regexec for matching. A good example of its usage involves validating user input. For instance, you might want to ensure that a user-entered password meets certain criteria, such as containing at least one uppercase letter, one lowercase letter, one digit, and one special character.

The regcomp function in the GNU C Library’s <regex.h> is responsible for compiling a regular expression into an internal data structure that can be efficiently used for matching. Essentially, it takes a string representing a regular expression pattern and converts it into a format suitable for fast searching within other strings.

The GNU C Library (glibc) provides a consistent Application Binary Interface (ABI) across different architectures and versions, ensuring compatibility between compiled programs. Architectures define the underlying hardware instruction set, while ABIs specify how functions are called, data is passed, and objects are laid out in memory. glibc abstracts these details, allowing developers to write code once and have it run on various systems that adhere to the same ABI.

While compiling a regular expression avoids recompilation within the same program execution, a system shutdown will erase the in-memory compiled representation. When the system restarts and the program is run again, the regular expression will need to be re-compiled if the performance benefit of pre-compilation is desired. The ABI does not change this behavior; it merely dictates how the compiled code interacts with other system components.

Vulnerability details: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.

Ref: A double free error occurs if free() is called multiple times with the same memory address. Calling free() twice on the same value causes a memory leak. If a program calls free() twice with the same arguments, it corrupts the program’s memory management data structures.

Official announcement: Please refer to the URL for details –

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

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

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