Official Published: 01/05/2026

Preface: In Qualcomm devices, the Host Operating System (HLOS), often Android/Linux, manages HDCP (High-bandwidth Digital Content Protection) sessions by interacting with dedicated hardware/firmware (DCP/ MediaLink/TrustZone) for key exchange and encryption, ensuring protected content (DRM) is output securely over HDMI/DisplayPort, with the HLOS kernel handling driver calls and security enforcement to prevent playback of protected media on non-compliant displays.

Background: For the HLOS (Normal World) to communicate with the Secure World, a small “shared memory” buffer must be initialized:

• Communication Buffers: The HLOS allocates non-secure memory to pass non-sensitive commands and status updates (e.g., “start session,” “query status”) to the TEE.

• Buffer Alignment: Systems often require specific alignment (typically 4KB page alignment) for these shared buffers to ensure they can be mapped into the TEE’s address space for processing.

When the app calls mediaDrm.closeSession(sessionId) – refer tp attached diagram, the Widevine DRM stack signals the TEE (TrustZone) to terminate the secure session.

The non-secure buffer allocated by HLOS for communication with the TEE is freed once the session ends.  Alignment requirements (e.g., 4KB) are relevant only during active mapping; after deinitialization, the memory is returned to the normal pool.

Related details:

• The HDCP link is not persistent beyond the DRM session. Once the session is closed, the secure channel is dismantled.
• If another app or playback starts later, the entire handshake process (including HDCP negotiation) will run again.

Vulnerability details: CVE-2025-47339 – Memory corruption while deinitializing a HDCP session – Use After Free in HLOS.

One of the possibilities – When the HLOS frees the non-secure buffer after session closure, any lingering references (e.g., in the TEE driver or asynchronous callbacks) can still access that memory. If the cleanup sequence doesn’t enforce strict ordering—such as ensuring all secure-world operations have completed before freeing the buffer—the freed memory could be reused by another process, leading to corruption.

Official announcement: Please refer to the link for details –

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

Preface: Essentially, when security experts read vulnerability lists, the priority is time-dependent. For example, if you read a CVE reference document on January 2, 2025, but the document’s starting date is 2023, there’s a 99% chance you’ll ignore it. This makes sense, after all, it’s two years ago. According to vendor practice, when patches are released, they prioritize notifying customers. The timing of public releases depends on the vendor’s policy. But what made me interested in this CVE and want to delve deeper? In fact, when you investigate further, you discover more information than expected.

You’re welcome to continue exploring.

Background: Instead of the md driver’s classic RAID, Android utilizes the Device Mapper (DM) framework—specifically the same dm-ioctl.c interface you noted earlier—to implement modern, mobile-specific storage features.

The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).

However, seems the major remedy  is implement a tool ( rw_semaphore devices_lock). When the Device Mapper drivers (dm-ioctl.c, dm-core.h, and dm-table.c) are used on an Android smartphone with a Qualcomm processor. The memory used by the storage drivers (drivers/md/) and the memory managed by the graphics drivers (Qualcomm’s KGSL) are distinct and reserved for different purposes:

Storage (Device Mapper) Memory

The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).

• When the storage drivers perform tasks like encryption (dm-crypt) or integrity checks (dm-verity), they are processing data from the main system RAM or directly from the physical storage chip using Direct Memory Access (DMA).
• The system uses memory pools like ION or ashmem to manage shared buffers between the kernel and user-space applications for storage tasks. These are separate from GPU pools. 

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved.

dm: fix a race condition in retrieve_deps There’s a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access.

See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html Fix this bug by introducing a new rw semaphore “devices_lock”. We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.

Official announcement: Please refer to the link for details. https://www.tenable.com/cve/CVE-2023-54324

NVD Published Date:12/17/2025

NVD Last Modified:18/12/2025

Preface: Apple Multiple Products Use-After-Free WebKit Vulnerability

Required Action – Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Date Added – 12/15/2025

Due Date – 01/05/2026

Ref: CISA’s BOD 22-01 isn’t specifically for cloud services but mandates U.S. federal agencies to rapidly fix high-risk, known exploited vulnerabilities (KEVs) listed in CISA’s catalog, including those in cloud environments, by providing strict timelines for remediation. It requires agencies to update vulnerability management procedures, apply to all software/hardware on federal systems (even third-party clouds), and focus on the CISA KEV catalog for critical patching, thereby significantly reducing federal cyber risk.

Background: Chrome used to use WebKit but now uses its own fork called Blink, except on Apple’s iOS/iPadOS where it’s forced to use WebKit due to Apple’s rules, while Blink powers most other desktop/mobile versions and is a descendant of WebKit. Think of it like this: Chrome started with WebKit, then created Blink from it for speed, but iOS versions remain WebKit-based.

The version of Google Chrome available on Apple’s iOS and iPadOS devices is indeed required to use the underlying WebKit framework provided by the operating system, which is the exact same engine that powers Apple’s own Safari browser.

Apple’s iOS and its Safari browser do not natively use Vulkan or DirectX; instead, they rely exclusively on Apple’s own proprietary graphics API, called Metal.

Google has to build its browser on top of Apple’s WebKit framework, which itself integrates seamlessly with Apple’s comprehensive memory management systems like ARC and the iOS kernel’s memory allocation routines. Metal plays a critical role in how the browser draws things incredibly fast on your screen, leveraging the GPU’s power, but it is not a general-purpose memory manager for the entire application’s operational needs.

Vulnerability details: A use-after-free issue was addressed with improved memory management. This issue is fixed in watchOS 26.2, Safari 26.2, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, visionOS 26.2, tvOS 26.2. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 26. CVE-2025-14174 was also issued in response to this report.

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