Category Archives: AI and ML

CVE-2025-36852: “first-to-cache wins” jeopardizes Bucket-based object storage! (12th June 2025)

Preface: Cloud service providers use “first-to-cache wins” (also known as “cache hit”) for improved performance and efficiency. By caching frequently accessed data, they can quickly retrieve it without needing to access the slower underlying storage layer. This reduces latency, enhances user experience, and can also lower costs associated with accessing and processing data.

Background: In a “first-to-cache wins” scenario, the winning location is in CPU embedded memory, specifically the L1 and L2 caches, which are located directly on the processor chip. The L1 cache is the fastest and smallest, while the L2 cache is slower but larger. Both are much faster than accessing physical memory (RAM).

Do well-known cloud service providers implement the concept of “first-to-cache wins”?

Example 1: S3 is designed to store and manage data objects (files, images, etc.) in the cloud. While S3 itself doesn’t have a “first-to-cache wins” mechanism, it can be used as a layer of caching, especially when combined with other caching services like Amazon ElastiCache for Redis.

Example 2: Google Cloud Storage does not operate on a strict “first-to-cache wins” theory. Instead, it uses a more nuanced caching system that considers factors like the Cache-Control metadata, object type, and the location of the read operation.

Is the Vulnerability Valid?

Yes, it’s valid and serious in the context of build systems that:

-Use remote caching with object storage.

-Allow untrusted contributors (e.g., via pull requests).

-Do not enforce cache validation or isolation between trusted and untrusted environments.

Vulnerability details: A critical security vulnerability exists in remote cache extensions for common build systems utilizing bucket-based remote cache (such as those using Amazon S3, Google Cloud Storage, or similar object storage) that allows any contributor with pull request privileges to inject compromised artifacts from an untrusted environment into trusted production environments without detection. The vulnerability exploits a fundamental design flaw in the “first-to-cache wins” principle, where artifacts built in untrusted environments (feature branches, pull requests) can poison the cache used by trusted environments (protected branches, production deployments). This attack bypasses all traditional security measures including encryption, access controls, and checksum validation because the poisoning occurs during the artifact construction phase, before any security measures are applied.

Official announcement: Please refer to the link for details –

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

https://nx.app/files/cve-2025-06

CVE-2025-2884 – Design weakness in the Trusted Platform Module (TPM) 2.0 reference implementation code. (11th June 2025)

Preface: The main difference between AMD’s Trusted Platform Module (TPM) and those from other manufacturers , how it’s implemented: AMD offers a firmware TPM (fTPM), while many other manufacturers, including Intel, also offer a dedicated hardware TPM (dTPM).

Background: TPM refers to a Trusted Platform Module, which is a specialized chip that securely stores cryptographic keys used for encryption and decryption, enhancing overall system security. AMD’s approach often involves Firmware TPM (fTPM), also known as Intel’s Platform Trust Technology (PTT), which implements TPM functionality within the system’s firmware rather than using a dedicated physical chip.

The AMD Ryzen Embedded 7000 series processors indeed integrate advanced security features, including:

  • AMD Secure Processor (ASP): A dedicated security co-processor embedded directly into the CPU die.
  • Firmware TPM (fTPM): Implemented in firmware and runs on the ASP.
  • Microsoft Pluton: A hardware-based security processor integrated into the silicon, designed to work alongside ASP and fTPM for enhanced protection.

Ref: The most common TPM is the TPM function supported by the Trusted Execution Environment (TEE) of Intel Core i series or AMD Ryzen series CPU in the motherboard UEFI firmware. fTPM can be used in all processors after Intel Broadwell (5th generation) and AMD Ryzen series. This is the most common method because you can easily use the TPM function without purchasing a separate module.

Vulnerability details: An out-of-bounds read vulnerability exists in TPM2.0’s Module Library allowing a read past the end of a TPM2.0 routine as described above. An attacker who can successfully exploit this vulnerability can read sensitive data stored in the TPM and/or impact the availability of the TPM.

Official announcement: Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4011.html

CVE-2025-0036: A potential vulnerability exists with the configuration of the SSS (Secure Stream Switch) – 5th Jun 2025

Preface: AMD’s Versal Adaptive SoCs are designed for high-performance computing, offering a blend of programmable logic, processing system, and AI engines, along with advanced memory and interfaces. They excel in cloud, network, and edge applications by combining heterogeneous compute with a wide range of hard IP. This architecture enables outstanding performance/watt and adapts to changing requirements, making them suitable for various applications like AI, data centers, and network acceleration.

Background: In Versal™ Adaptive SoC devices, the Platform Loader and Manager (PLM) implements runtime (post-boot) software services that allows a remote processor to command the PLM to execute cryptographic operations – including AES, SHA3, RSA, ECDSA – on behalf of the remote processor. These operations require the Secure Stream Switch (SSS) to be configured such that the Direct Memory Access (DMA) hardware can send data to and read from these cryptographic engines.

Ref: Some crypto engines (like AES, SHA3) are integrated into the PMC for secure boot and runtime services. Others may be instantiated in the PL for custom cryptographic acceleration.

Vulnerability details: A potential vulnerability exists with the configuration of the SSS because the PLM does not clear the SSS configuration after a cryptographic operation completes. This allows an improper SSS configuration when setting up the SSS for any following cryptographic command.

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

Deserialization of Untrusted Data vulnerability in Apache InLong (29-05-2025)

Preface: Apache InLong can be a valuable component in machine learning (ML) and artificial intelligence (AI) workflows, particularly in the data engineering and streaming data pipeline stages.

Background: Apache InLong is a one-stop massive data integration framework that provides automatic, secure, reliable and high-performance data transmission capabilities. It also supports batch and streaming, making it easier for businesses to build streaming-based data analysis.

InLong Sort requires Apache Flink and uses Flink SQL to define and run data processing jobs.

Data Ingestion and Integration – Apache InLong is designed as a one-stop, full-scenario integration framework for massive data. It supports:

•       Batch and stream data ingestion

•       Data synchronization and subscription

•       Real-time ETL (Extract, Transform, Load)

Real-Time Data Processing

Integration with ML Pipelines

Vulnerability details: Deserialization of Untrusted Data vulnerability in Apache InLong. This issue affects Apache InLong: from 1.13.0 through 2.1.0. This vulnerability allows attackers to bypass the security mechanisms of InLong JDBC and leads to arbitrary file reading. 

Remedy: Users are advised to upgrade to Apache InLong’s 2.2.0.

Official announcement: Please see the link for details –

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

CVE-2025-23247: NVIDIA CUDA Toolkit for all platforms contains a vulnerability in the cuobjdump binary (28-5-2025)

Preface: ROCm open source software platform is AMD’s core strategy. This platform supports deep learning frameworks such as PyTorch 2.0 and TensorFlow.

Nvidia’s CUDA cores are indispensable for training and deploying neural networks and deep learning models, taking advantage of their parallel processing capabilities. To put that into perspective, a dozen Nvidia H100 GPUs can provide the same deep learning equivalent as 2,000 midrange CPUs.

Background: NVIDIA CUDA provides a simple C/C++ based interface. The CUDA compiler leverages parallelism built into the CUDA programming model as it compiles your program into code.
CUDA is a parallel computing platform and programming interface model created by Nvidia for the development of software which is used by parallel processors. It serves as an alternative to running simulations on traditional CPUs.

The CUDA Toolkit targets a class of applications whose control part runs as a process on a general purpose computing device, and which use one or more NVIDIA GPUs as coprocessors for accelerating single program, multiple data (SPMD) parallel jobs. Such jobs are self-contained, in the sense that they can be executed and completed by a batch of GPU threads entirely without intervention by the host process, thereby gaining optimal benefit from the parallel graphics hardware.

When a program like cuobjdump parses an ELF file, it expects certain structures and lengths to be valid. If it doesn’t validate the length of a buffer before copying or accessing it:

•        An attacker can overflow the buffer or inject data into memory.

•        This can overwrite return addresses or function pointers, leading to code execution.

Vulnerability details: NVIDIA CUDA Toolkit for all platforms contains a vulnerability in the cuobjdump binary, where a failure to check the length of a buffer could allow a user to cause the tool to crash or execute arbitrary code by passing in a malformed ELF file. A successful exploit of this vulnerability might lead to arbitrary code execution.

Official announcement: Please refer to the supplier announcement –https://nvidia.custhelp.com/app/answers/detail/a_id/5643

CVE-2025-37992: About NULL pointer dereference in net_sched (27-05-2025)

Preface: Linux powers large parts of the Internet, cloud infrastructure, and supercomputers. But it is difficult to determine the exact number of Linux systems in the world. This appears to be a technology trend that includes AI system infrastructure.

Background: In Linux, a “qdisc” stands for queueing discipline. It’s a core component of the Linux traffic control system, responsible for managing and scheduling network traffic on a per-interface basis. Essentially, a qdisc determines how the kernel handles packets before sending them to the network adapter.

Vulnerability details: Previously, when reducing a qdisc’s limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q[.]qlen.

Remedy: This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.

Official announcement: Please see the link for details –

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

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fe88c7e4fc2c1cd75a278a15ffbf1689efad4e76

When artificial intelligence encounters a geomagnetic storm (26-05-2025)

Preface: About fifteen years ago, extreme climate sounded the alarm for humanity. But we haven’t woken up yet. As we enter 2025, extreme weather is raging. Are we awake now?

Background: A coronal mass ejection (CME) can induce a geomagnetic storm when it interacts with Earth’s magnetosphere. CMEs are large clouds of plasma and magnetic fields ejected from the Sun, and when they hit Earth, they can disrupt the Earth’s magnetosphere, leading to temporary disturbances and geomagnetic storms.

Geomagnetic storms create geomagnetically induced currents (GICs). Geomagnetic storms, which are disturbances of Earth’s magnetic field caused by space weather events like coronal mass ejections (CMEs), induce rapid changes in the magnetic field. These changes, in turn, create electric fields that drive GICs to flow through conductive paths on Earth’s surface, such as power grids, pipelines, and other infrastructure.

How much electricity does a supercomputer used for artificial intelligence consume?

A single modern AI GPU can consume up to 700 watts of power. A typical supercomputer, especially those used for AI training, can consume significantly more power, with some examples exceeding 4 megawatts (4,000,000 watts). This high power consumption is largely due to the large number of powerful GPUs and other specialized hardware needed for these complex computations.

How does artificial intelligence think about this problem?

Building a supercomputer facility underground with its own dedicated power supply does significantly reduce—but not entirely eliminate—the risks from geomagnetic storms. Here’s a breakdown:

1.Underground Location:

-Provides natural shielding from fluctuating magnetic fields.

-Reduces exposure to induced currents in long conductors.

2.Dedicated Power Supply:

-If it’s isolated from the main power grid (e.g., using local generators, batteries, or renewables), it avoids GICs that typically enter through long transmission lines.

Shorter internal cabling means less potential for induced voltages.

3.Shielded Infrastructure:

-If the facility uses shielded transformers, GIC-blocking devices, and grounding systems, it can further mitigate risks.

End.

CVE-2025-47436: Heap-based Buffer Overflow vulnerability in Apache ORC. (15-5-2025)

Preface: Traditional row-based formats for data normalization have several limitations:

Complex Queries: Normalization often requires joining multiple tables to retrieve data, which can make queries more complex and slower.

Maintenance Challenges: Maintaining a highly normalized database can be more difficult, as changes to the schema may require updates to multiple tables.

Background: Apache ORC (Optimized Row Columnar) is a free and open-source, column-oriented data storage format designed for use in Hadoop and other big data processing systems. It was created to address the limitations of traditional row-based formats, providing a more efficient way to store and process large datasets. ORC is widely used by data processing frameworks like Apache Spark, Apache Hive, Apache Flink, and Apache Hadoop.

Vulnerability details: Heap-based Buffer Overflow vulnerability in Apache ORC. A vulnerability has been identified in the ORC C++ LZO decompression logic, where specially crafted malformed ORC files can cause the decompressor to allocate a 250-byte buffer but then attempts to copy 295 bytes into it. It causes memory corruption.

Remedy: This issue affects Apache ORC C++ library: through 1.8.8, from 1.9.0 through 1.9.5, from 2.0.0 through 2.0.4, from 2.1.0 through 2.1.1. Users are recommended to upgrade to version 1.8.9, 1.9.6, 2.0.5, and 2.1.2, which fix the issue.

Official announcement: Please see the link for details –

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

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection – Part 2 (14-05-2025)

Preface: Before reading the detailed information, it is recommended to read Part 1 first.

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (Part 1)  –

http://www.antihackingonline.com/under-our-observation/privilege-desynchronization-cross-privilege-spectre-attacks-with-branch-privilege-injection-14-05-2025/

Technical details: It is to ensure the serialization of memory access. The internal operation is to add some delays in a series of memory accesses to ensure that the memory access after this instruction occurs after the memory access before this instruction is completed (no overlap occurs).

Performs a serializing operation on all load-from-memory instructions that were issued prior the LFENCE instruction. Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE completes.

AMD’s AutoIBRS (Automatic Indirect Branch Restricted Speculation) is designed to mitigate timing-based attacks, such as Spectre. AutoIBRS helps avoid the performance overhead associated with LFENCE by automatically restricting speculative execution of indirect branches. This mechanism reduces the need for frequent LFENCE instructions, thereby minimizing delays while still protecting against timing vulnerabilities.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (14-05-2025)

Preface: Enhanced IBRS (eIBRS) and Automatic IBRS (AutoIBRS) are features designed to mitigate the Spectre V2 vulnerability, which affects speculative execution in CPUs.

Background: AutoIBRS is a similar feature introduced by AMD in their Zen 4 processors. It automatically manages IBRS mitigation resources across privilege level transitions, offering better performance compared to Retpoline. This feature is particularly beneficial for AMD’s Ryzen 7000 and EPYC 9004 series processors.

AMD EPYC 9004 series processors are designed for data centers and high-performance computing (HPC) environments. They offer features like up to 96 “Zen 4” cores, 12 channels of DDR5 memory, and PCIe Gen5 support.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html