Story background: Rowhammer Attacks on GPU Memories are Practical (8^th Dec 2025)

Preface: The story unfolds a hidden tale within two different design purpose GPUs (consumer display card and AI (install ROCm)) and reveals the untold behind-the-scenes story that the two sides concealed from the recent.

Background: AMD’s bulletin (Dec 2025) confirms GDDR6-based GPUs are vulnerable, but these are consumer display cards, not ROCm-enabled compute cards. This means AMD acknowledges Rowhammer risk on gaming GPUs, even if ROCm isn’t supported. Rowhammer risk exists for certain display (graphics) cards, specifically those with GDDR6 memory used in workstation and data center environments. Researchers recently demonstrated the “GPUHammer” attack, the first successful Rowhammer exploit on a discrete GPU, which can induce bit flips and compromise data integrity or AI model accuracy.

Rowhammer bit flips happen when repeatedly activating (hammering) specific DRAM rows causes electrical interference that causes adjacent “victim” rows to leak charge and flip their stored bit values. This vulnerability exploits the physical limitations of modern, high-density DRAM chips where cells are packed closely together, making them susceptible to disturbance errors.

Does Rowhammer Show on Screen?

Rowhammer is a memory integrity attack, not a rendering pipeline attack. Here’s why:

The workflow you described (PCIe → GDDR6 → cores → display controller) is correct for rendering.

Rowhammer flips bits in memory rows, potentially corrupting data structures (e.g., textures, buffers, or even code).

If the corrupted data is part of a framebuffer or texture, visual artifacts could appear on screen (e.g., glitches, wrong colors).

But if the corruption affects non-visual data (e.g., shader code, compute buffers), you might see crashes or silent errors instead.

So: it can manifest visually, but only if the hammered rows store display-related data.

AMD Official article: Please refer to the link for details.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7049.html

Published: 12/01/2025

Preface: Qualcomm HLOS (High-Level Operating System) refers to the operating system layer, like Android, that runs on a Qualcomm Snapdragon chipset and is responsible for general device functionality. “TA” (Trusted Application) is a component of the Qualcomm Trusted Execution Environment (QTEE) that runs in a secure environment, separate from the HLOS. Security issues arise when vulnerabilities exist at the boundary between the HLOS and a TA, such as memory corruption when the HLOS improperly processes commands from a TA, as described in Qualcomm security bulletins.

Background: The Qualcomm Secure Execution Environment Communication (QSEECom) lifecycle describes how a client application in the normal world interacts with a trusted application (TA) in the secure world via the qseecom kernel driver.

Step 1. QSEECom_start_app: Loads the TA into QTEE and allocates shared memory (ion_sbuffer) for communication.

Step 2. ion_sbuffer: The shared memory buffer used for both input and output.

Step 3:QSEECom_send_cmd: Sends a command to the TA, using the shared buffer.

Step 4: QSEECom_shutdown_app: Cleans up and unloads the TA.

Vulnerability details: CVE-2025-47319

• Component: High-Level Operating System (HLOS)
• Nature: Design weakness in buffer size calculation when processing commands from a Trusted Application (TA).
• Impact: Could lead to buffer overflow, exposing sensitive system information and enabling arbitrary code execution.
• Severity: Qualcomm rates it as critical, though its CVSS score is medium.
• Discovery: Internal Qualcomm security team.

Mitigation: Patches have been shared with OEMs; users should update devices promptly.

Official announcement: Please refer to the link for details –

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

Published: 2025-11-28

Preface: Apache Hadoop and Apache Spark are both prominent and widely used frameworks for big data analytics. They are central to the processing and analysis of large datasets that cannot be handled by traditional data processing tools.

Apache Hadoop utilizes the MapReduce programming model as a core component for processing and analyzing large datasets in a distributed manner.

How memory is used in Hadoop? Application Memory – Hadoop applications, such as those running on YARN (Yet Another Resource Negotiator), also utilize RAM for their processing needs. For instance, MapReduce tasks and Spark applications perform computations in memory, leveraging RAM for faster data access and processing.

Background: LZ4 is a very fast lossless compression algorithm, providing compression speed > 500 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems.

The liblz4-java[.]so file is a native shared library that provides the underlying LZ4 compression and decompression functionality for the lz4-java library in Java applications.

From technical point of view,  liblz4-java[.]so acts as the high-performance engine for LZ4 operations, while the Java lz4-java library provides a convenient and type-safe API for Java developers to interact with this engine.

Remark: Since the maintainers of the official lz4-java library could not be contacted, the lz4 organization decided to discontinue the project.

Vulnerability details:

CVE-2025-12183 – Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted compressed input.

Official announcement: Please refer to the link for details –

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