Preface: Swift is memory-safe by default. Unlike C, your enum and String cannot “overflow” a buffer and crash the app unless you use the Unsafe prefix.

Background: Swift is memory-safe by default. Use Enums to represent mutually exclusive states (e.g., loading, success, error) to eliminate “impossible” states. [.]onAppear { manager.fetchData() } will run every time the view appears, meaning every time SwiftUI reconstructs or re‑displays this DataView, it triggers fetchData() again.\ This can lead to multiple overlapping async calls unless explicitly prevented. The enum-based state machine helps protect against impossible logical states, but it does not prevent multiple requests from firing. Swift’s memory safety doesn’t stop logical repetition or resource exhaustion.

Ref: In Swift, “checking the bounds of a memory buffer” typically refers to ensuring you don’t access memory outside of an allocated range (like an Array or UnsafeBufferPointer).

Vulnerability details: CVE-2026-20700 A memory corruption issue was addressed with improved state management. This issue is fixed in watchOS 26.3, tvOS 26.3, macOS Tahoe 26.3, visionOS 26.3, iOS 26.3 and iPadOS 26.3. An attacker with memory write capability may be able to execute arbitrary code. 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 and CVE-2025-43529 were also issued in response to this report.

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

https://support.apple.com/en-us/126353

Preface: As of February 2026, Apple has issued urgent security updates—specifically iOS 26.2.1 and iOS 26.2—to patch critical vulnerabilities (CVE-2025-43529, CVE-2025-14174, and CVE-2025-46285) that were exploited in targeted attacks. These bugs, affecting the WebKit browser engine and Kernel, allow arbitrary code execution and unauthorized root privileges. Users must immediately update to protect their devices.

Background: Adopting 64-bit timestamps means changing how computers store time, replacing 32-bit integers with 64-bit integers to record seconds since the Unix Epoch (Jan 1, 1970). This shift eliminates the “Year 2038 problem,” extending the maximum representable date from January 2038 to over 292 billion years in the future, ensuring long-term system stability and precision.

Apple’s security hardening efforts following vulnerability CVE‑2025‑46285. CVE‑2025‑46285 was a system‑level integer‑overflow vulnerability in Apple platforms. It occurred because 32‑bit timestamps could overflow, and in certain OS internals this overflow allowed a malicious app to gain root privileges. Apple’s official fix for this vulnerability was to “adopt 64‑bit timestamps”, which eliminates the overflow condition entirely on the affected systems.

Vulnerability details: CVE-2025-46285: A Kernel vulnerability allowing apps to gain root privileges, bypassing app sandboxes.

Official announcement: Please refer to the link for more details

https://support.apple.com/en-us/100100

Reference:

https://nvd.nist.gov/vuln/detail/CVE-2025-46285#vulnCurrentDescriptionTitle

http://www.antihackingonline.com/cell-phone-iphone-android-windows-mobile/cve-2025-43529-apple-multiple-products-use-after-free-webkit-vulnerability-31-12-2025/

http://www.antihackingonline.com/cell-phone-iphone-android-windows-mobile/the-media-reports-in-january-2026-were-triggered-by-a-security-warning-issued-by-apple-on-december-16-2025-20th-jan-2026/

Official Last updated: 14 Jan 2026

Preface: Smartphones using the ARM Cortex-X925 CPU core are primarily powered by the MediaTek Dimensity 9400 and Dimensity 9400+ chipsets. Key flagship devices featuring this processor include the OPPO Find X8 Pro, vivo X200 series, and Xiaomi 15T Pro. These phones utilize the chip’s “all-big-core” design for high-performance computing.

Dimensity 9400 and Dimensity 9400+ both chipsets use the same core components, including the ARM Cortex-X925 CPU, the Immortalis-G925 GPU, and the NPU 890. The primary difference lies in the clock speeds and certain enhanced connectivity/AI features of the Plus model.

Background: Cache prefetch predictionrestriction by context – This instruction prevents cache allocation predictions that predict execution addresses based on information gathered from earlier execution within a particular execution context. The actions of code in the target execution context or contexts appearing in program order before the instruction cannot exploitatively control cache prefetch predictions occurring after the instruction is complete and synchronized.

The Cortex-X925 supports Armv9’s Realm Management Extension (RME), which goes a step further than traditional TEE:

Confidential Computing: In addition to Android (Normal World) and TEE (Secure World), Armv9 introduces Realm World.

Realm Guest OS: A fully encrypted Guest OS (called Realm) can run on the Hypervisor (EL2), which even the Android Kernel cannot peek at.

Vulnerability details: An issue has been identified in some Arm-based CPUs which may allow a modified, untrusted guest OS to compromise the host in certain hypervisor environments.

Workaround: To workaround this issue, affected partners must perform TLB invalidation whenever a CPP RCTX instruction is executed. For details on how to do this, please see the Errata Notice for the relevant product.

Official announcement: Please refer to the link for details –

https://developer.arm.com/documentation/111546/1-0/?lang=en

Preface: This article is scheduled for release on January 21, 2026. It may contain some key topics that will be helpful to developers. Therefore it release today.

The “spyware” mentioned in April 2025 was the Apple Company policy, but the attacks reported in January 2026 are live threats using newer exploits (CVE-2025-43529 and CVE-2025-14174). If you have not updated to iOS 26.2 or newer, your device is at high risk from these “extremely sophisticated” attacks.

Background:

ANGLE on iOS: Chrome on iOS uses WebKit as its rendering engine (due to Apple’s App Store policy), and ANGLE is integrated for WebGL translation.

WebKit Zero-Day Exploits: If attackers exploit WebKit vulnerabilities (like CVE-2025-43529) and combine them with ANGLE flaws (CVE-2025-14174), they can potentially achieve remote code execution or device compromise.

Shared Components: Safari and Chrome on iOS both rely on WebKit, so any ANGLE-related bug in WebKit’s GPU pipeline could propagate to iOS.

Cyber security focus – CVE-2025-43529

When the JIT compiler requests executable memory via jit_heap and writes machine code, bmalloc/libpas allocates memory regions. If an object or memory block is freed prematurely and then accessed, that’s where UAF occurs. Complex DOM/JS operations or JIT optimizations often trigger these conditions.

The CVE-2025-43529 is tied to a use-after-free in WebKit’s internal memory management (bmalloc/libpas) during complex DOM/JS operations.

Cyber security focus – CVE-2025-14174

A security issue was found in ANGLE regarding gl.deleteTexture().

• Asynchronous Release Bottlenecks: A known behavior is that calling gl.deleteTexture() does not immediately free memory if the GPU is still processing draw calls that reference that texture. Memory is only reclaimed after the GPU finished execution.
• Shader Translation Memory Retention: A discovered bug in ANGLE’s PoolAllocator revealed that it often moves single-page allocations to a free list rather than returning them to the OS, causing memory used during shader translation to persist until the compiler instance is destroyed.

The following detailed information explains the relationship between ANGLE and different web browsers.

-Google Chrome Full Support (v1.0 & v2.0) Uses ANGLE

-Mozilla Firefox Full Support (v1.0 & v2.0) Uses ANGLE (on Windows) or own implementation

-Apple Safari Full Support (v1.0 & v2.0) Uses ANGLE (since v15+)

-Microsoft Edge Full Support (v1.0 & v2.0) Uses ANGLE (Chromium-based)

These vulnerabilities were actively exploited in the wild, often in spyware campaigns targeting high-profile individuals.

Even if you’re not a high-risk target, updating was critical because these flaws allow remote code execution via a crafted webpage.

For more details on these matters, please see the link.

https://support.apple.com/en-us/100100

https://www.forbes.com/sites/zakdoffman/2026/01/12/apple-warning-hundreds-of-millions-of-iphones-must-now-restart

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

Published: 2025-11-21

Preface: The “mach kernel” in iOS refers to the **Mach kernel component of the XNU hybrid kernel, which is the core of Apple’s iOS operating system. XNU is a hybrid kernel that merges the Mach microkernel with components from the BSD Unix system to create a single, cohesive kernel that runs iOS and other Apple operating systems like macOS. This kernel architecture applies to all current iOS versions and will continue to be used in future versions running on Apple Silicon.

Background: In Apple platforms, the thread_amount function calls task_threads (via Mach kernel APIs) which allocates memory for the thread list. iOS uses a hybrid kernel called XNU, which is an acronym for “X is Not Unix”. This kernel combines components of the Mach microkernel and the FreeBSD Unix kernel to form the core of Apple’s Darwin operating system, which underpins iOS, macOS, watchOS, and other Apple platforms.

Vulnerability details: thread-amount is a tool that gets the amount of threads in the current process. Prior to version 0.2.2, there are resource leaks when querying thread counts on Windows and Apple platforms. In Windows platforms, the thread_amount function calls CreateToolhelp32Snapshot but fails to close the returned HANDLE using CloseHandle. Repeated calls to this function will cause the handle count of the process to grow indefinitely, eventually leading to system instability or process termination when the handle limit is reached. In Apple platforms, the thread_amount function calls task_threads (via Mach kernel APIs) which allocates memory for the thread list. The function fails to deallocate this memory using vm_deallocate. Repeated calls will result in a steady memory leak, eventually causing the process to be killed by the OOM (Out of Memory) killer. This issue has been patched in version 0.2.2.

Official announcement: Please refer to the link for details –

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