Preface: The iframe (Inline Frame) is an HTML element used to embed another document or website within the current web page (e.g., embedding a YouTube video or a Google Map).

Background: High-bandwidth Digital Content Protection (HDCP) in a Trusted Execution Environment (TEE) refers to securing the handshake, authentication, and encryption keys of audio/video content within a secure, isolated area of a device’s processor.

• When a HDCP session is deinitialized, the non-secure buffer allocated for communication with the TEE is freed.
• However, if the cleanup sequence does not enforce strict ordering, “lingering references” (such as asynchronous callbacks or TEE drivers) might still attempt to access that memory.
• This results in a memory corruption (Use-After-Free), allowing a local attacker with low privileges to potentially escalate their rights or cause a system crash. 

This is a memory integrity issue, not a cryptographic one.  Memory corruption during deinitialization. The vulnerability resides in the way the HLOS (Android kernel/drivers) and TrustZone interact, the fix must be applied at the Firmware/Kernel level via a system update from the manufacturer (OEM). 

Vulnerability details:

Title: Exposed Dangerous Method or Function in HLOS

Description: Cryptographic issue when a Trusted Zone with outdated code is triggered by a HLOS providing incorrect input.

Technology Area: HLOS

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

Risk Level High (CVSS Score: 7.8)

Affected Platforms: Multiple Qualcomm Chipsets (including Snapdragon series)

Official announcement: Please refer to the link for more details –

https://docs.qualcomm.com/securitybulletin/february-2026-bulletin.html

Preface: The ESP32 is a low-cost, low-power System on a Chip (SoC) microcontrollers with integrated Wi-Fi and dual-mode Bluetooth, making it a cornerstone for modern Internet of Things (IoT) applications. It offers direct, high-level control over hardware peripherals, including GPIOs, built-in Flash memory, and network interfaces, with extensive support for low-power operation.

Background: When using SandboxJS (@nyariv/sandboxjs) for ESP32 or any Internet of Things (IoT) development, caution is essential. While the tool is designed to provide a “secure eval runtime environment,” a major vulnerability recently discovered could put your embedded devices at risk.

Core Security Risks

• Prototype Pollution: A critical vulnerability (CVE-2025-34146) exists in versions 0.8.23 and earlier. An attacker could inject malicious JavaScript code into `Object.prototype`, potentially leading to a denial-of-service (DoS) attack or escape from the sandbox environment to execute arbitrary code.
• Sandbox Escape: In early 2026, a critical escape vulnerability (GHSA-wxhw-j4hc-fmq6) was disclosed again. The reason was that the AsyncFunction was not properly isolated, which allowed attackers to access the entire scope and execute native commands.
• Specific threats to IoT devices: Because ESP32 typically has direct control over hardware (GPIO, Flash memory, network), once the sandbox is breached, attackers may directly manipulate the physical device, steal keys stored in Flash memory, or even perform malicious firmware updates.

Vulnerability details: SandboxJS is a JavaScript sandboxing library. Prior to 0.8.27, SanboxJS does not properly restrict __lookupGetter__ which can be used to obtain prototypes, which can be used for escaping the sandbox / remote code execution. This vulnerability is fixed in 0.8.27.

Official announcement: Please refer to the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2026-25142

https://github.com/nyariv/SandboxJS/security/advisories/GHSA-9p4w-fq8m-2hp7

Recommendation:

Implement hardware isolation – Utilize ESP32’s hardware security features (such as Secure Boot, Flash encryption, and digital signature peripherals) to protect core keys, making it difficult for attackers to obtain sensitive credentials even if application-layer software is cracked. Consider alternatives – For embedded scenarios with extremely high security requirements, consider well-maintained JavaScript engines designed specifically for microcontrollers, such as Espruino or Moddable SDK.

Preface: ADAS data streams refer to the constant flow of real-time information collected from the vehicle’s environment by sensors like cameras, radar, lidar, and ultrasonic sensors. This data, along with processed information, is sent to the vehicle’s central computer (ADAS ECU) which uses it to perform functions such as object detection, lane keeping, and adaptive cruise control, ultimately improving safety and driving comfort. The Qualcomm Snapdragon SA9000P is a highly capable, leading-edge AI accelerator designed for Advanced Driver Assistance Systems (ADAS) and autonomous driving, frequently used in combination with the SA8540P SoC as part of the Snapdragon Ride platform.

Background: Qualcomm defines memory-conservative configurations in device trees primarily to optimize boot speed, ensure system stability, and manage the complex, carved-out memory architecture typical of modern mobile SoCs. By limiting available RAM during the initial boot, Qualcomm can skip initializing vast amounts of memory, resulting in significant boot time savings (e.g., 20-30ms per GB of RAM).

DTS is capable of providing attacker‑controlled (or misconfigured) large memory partitions, which is necessary for exploitability. But the DTS alone is not the vulnerability — the bug is in Qualcomm’s handling of these sizes in downstream drivers or frameworks.

Remark: Secure engineering limit for HLOS‑visible reserved regions: Do NOT exceed 1/16th of total DDR per region unless Qualcomm documentation explicitly permits it. So the “secure maximum” becomes: 2 GB per reserved-memory region. The recommended in safety‑critical domains): Limit to 1 GB.

Vulnerability details: CVE-2025-47363 integer Overflow or Wraparound in Automotive (Memory corruption when calculating oversized partition sizes without proper checks).

This means the vulnerable path occurs when a Qualcomm driver or subsystem performs arithmetic on a partition size, and the size is large enough to overflow internal calculations, resulting in corrupted pointers, truncated lengths, or allocated regions smaller or larger than expected.

Even if the original driver is not the bug — but it can exercise the buggy Qualcomm code by providing a large memory region, which may cause overflow inside Qualcomm subsystems.

Official announcement: Please refer to the link for details – https://docs.qualcomm.com/securitybulletin/february-2026-bulletin.html

Qualcomm – Official announcement: 1^st Jan 2026

Preface: The Qualcomm Snapdragon Ride platform is used to develop advanced driver assistance systems (ADAS) and autonomous driving (AD) for vehicles. It combines powerful hardware (SoCs containing AI, GPUs, and vision engines) and software (SDKs, cloud tools) to support a wide range of functions from basic safety features to advanced autonomous driving. It allows for the integration of digital cockpit, ADAS, and AD functions on the same hardware and supports over-the-air (OTA) updates for continuous improvement.

Qualcomm SA9000P is a high-performance automotive-grade System-on-Chip (SoC) from Qualcomm’s Snapdragon Ride platform, part of a 5nm compute platform for advanced driver-assistance systems (ADAS) and autonomous driving, designed to compete with NVIDIA and Intel Mobileye, often paired with the SA8540P, enabling powerful in-car computing for future connected and self-driving vehicles.

Background: In the context of Qualcomm’s software ecosystem and the Linux kernel, _count_phandle_with_args() is typically a low-level helper or a variant of the standard DeviceTree (DT) API used to determine the number of phandle entries in a specific property.

While the internal underscore-prefixed version (_count_phandle_with_args) is often used within kernel core code (like drivers/of/base.c), it is most commonly accessed by Qualcomm drivers via the public wrapper: of_count_phandle_with_args()

Therefore, developers are advised to use `of_count_phandle_with_args()` to verify array indices.

Usage in Qualcomm Drivers: Qualcomm’s MSM (Mobile Station Modem) kernel and downstream drivers use this to dynamically determine how many resources (like regulator handles or clock inputs) are defined for a hardware block before allocating memory for them.

Vulnerability details:

CVE ID – CVE-2025-47393

Title – Improper Validation of Array Index in Automotive Linux OS

Description – Memory corruption when accessing resources in kernel driver.

Technology Area – Automotive Linux OS

Vulnerability Type – CWE-129 Improper Validation of Array Index

Official announcement: Please refer to the link for details –

https://docs.qualcomm.com/securitybulletin/january-2026-bulletin.html

Qualcomm – Official announcement: 1^st Dec 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: Secure boot is defined as a boot sequence in which each software image to be executed is authenticated by software that was previously verified. This sequence is designed to prevent unauthorized or modified code from being run. Our chain of trust is built according to this definition, starting with the first piece of immutable software to be run out of read-only-memory (ROM). This first ROM bootloader cryptographically verifies the signature of the next bootloader in the chain, then that bootloader cryptographically verifies the signature of the next software image or images, and so on.

Background: Unlike other signed software images, the signature for Qualcomm Technologies signed images is only computed over a single segment in the image and not the entire image. The segment containing the signature is called the hash segment. This hash segment is a collection of the hash values of the other ELF segments that are included in the image. In other words we sign the collection of ELF segment hashes, rather than signing the entire ELF image. This representation is designed to relax memory size requirements and increases flexibility during loading.

Vulnerability details: The vulnerability described (CVE-2025-47372) is a heap overflow caused by reading an oversized ELF image into a buffer without proper bounds checking or authentication.

•       The overflow occurs during the write operation, before free() is called.

•       Once data exceeds the allocated size, adjacent memory is already corrupted.

•       Freeing memory only releases the block back to the allocator; it cannot undo corruption or prevent exploitation.

Official announcement: Please refer to the link for details

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

Preface: AIS-Catcher is a MIT licensed dual band AIS receiver for Linux, Windows and Raspberry Pi. It is compatible with RTL-SDR dongles and the Airspy HF+.

AIS stands for Automatic Identification System and is used by marine vessels to broadcast their GPS locations in order to help avoid collisions and aide with rescues. An RTL-SDR with the right software can be used to receive and decode these signals, and plot ship positions on a map.

Background: You can set up your own receiver at home. With just a small USB radio adapter and a simple antenna, you can receive live signals from nearby ships and decode them directly on your computer or Raspberry Pi.

Setup requirement for an SDR AIS Receiver:

-RTL-SDR dongle (e.g. Nooelec NESDR, RTL-SDR Blog V3)

-VHF antenna (marine band, tuned for ~162 MHz)

-Raspberry Pi (Model 3 or later) or any PC

-Internet connection (for updates, optional data sharing)

Recommended Command (Dual-channel AIS, Auto Gain)

This does the following:

-A listens to both AIS frequencies:

Channel 1: 161.975 MHz

Channel 2: 162.025 MHz

-g auto lets AIS-catcher automatically choose the gain setting

Uses default device (-d 0) unless otherwise specified

You should see continuous outputs like this:

!AIVDM,1,1,,B,15MuqP001oK>rWnE`D0?;wvP0<2R,0*6D

These are raw NMEA AIS messages being received in real time.

Vulnerability details: CVE-2025-66216 – AIS-catcher is a multi-platform AIS receiver. Prior to version 0.64, a heap buffer overflow vulnerability has been identified in the AIS::Message class of AIS-catcher. This vulnerability allows an attacker to write approximately 1KB of arbitrary data into a 128-byte buffer. This issue has been patched in version 0.64.

Best Practices:

Never store data() pointer across operations that can reallocate (like push_back, resize, insert, emplace).

If you need a stable pointer, consider:

• std::deque (doesn’t invalidate all pointers on growth).
• std::vector::reserve() before operations to avoid reallocation.
• Or use indices instead of raw pointers.

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

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

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

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