Category Archives: Under our observation

AI and ML, Under our observation

A more imaginative assumption on TDXRay: Microarchitectural Side-Channel Analysis of Intel TDX for Real-World Workloads (15th MAY 2026)

Leave a comment

Preface: In these scenarios (see attached diagram), microarchitecture side-channel attacks targeting Intel TDX can directly impact and jeopardize the security of AMD accelerators.

Even though the AMD Instinct APU operates on a completely different silicon package, the two architectures are fundamentally tied together by a shared software stack, device driver interface, and physical interconnect fabric.

The specific risks regarding how TDXRay and cross-domain side-channel leakage bypass the hardware boundary in your diagram are detailed below:

Technical details:

1. Host-Side Driver Leakage (The Primary Target)

As illustrated in attached diagram, the ROCm Driver and HIP Runtime execute inside the Intel TDX Virtual Machine / Trust Domain.

•When primitives like those found in the TDXRay research paper (e.g., page-level or cache-line tracking) are utilized by an untrusted host hypervisor, they target the Intel CPU’s caches and memory controller.

•Because the Intel CPU must actively prepare, schedule, and feed data arrays (h_a, h_b) to the AMD accelerator, the memory access patterns of the ROCm driver itself are leaked.

•An attacker can infer exactly when the AMD kernel is being launched, what memory addresses are being mapped, and the size or stride of the datasets being transferred.

2. Interconnect Fabric Bottlenecks & Shared Cache Timing

The highlighted section in your diagram notes that memcpy can leak info via cache and memory controller interaction.

•During hipMemcpyHostToDevice or hipMemcpyDeviceToHost, data travels across the PCIe Gen 5 / CXL Interconnect Fabric.

•If a malicious actor on the host hypervisor induces resource contention on the shared Intel CPU core or memory bus, they can observe subtle latency shifts.

•By monitoring the timing delays of the Intel CPU waiting for the AMD APU to complete its tasks (hipDeviceSynchronize), the attacker can infer secret-dependent execution paths inside the AMD hardware without ever probing the AMD chip directly.

3. The Cross-Domain Threat Model (AMD SEV-SNP Parallel)

According to AMD’s Official Security Bulletin (AMD-SB-3044) published regarding the TDXRay findings, these types of microarchitectural host-side tracing methodologies fall within a category of behaviors that affect both Intel TDX and AMD SEV-SNP.

If an application leaks data structure layouts through its memory access patterns on the Intel host, the fact that the actual matrix operations happen on an AMD chip does not protect the workflow’s overall confidentiality.

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

Under our observation, Virus & Malware

Checkmarx Jenkins AST Plugin Compromised (14th May 2026)

Leave a comment

Preface: Jenkins’ popularity and its rich plugin ecosystem are the main reasons for integrating event monitoring tools with it. While there isn’t a single “API plugin,” Jenkins has a powerful built-in remote access API (supporting XML, JSON, and Python), which many external monitoring tools use to retrieve data.

Background: With its unparalleled flexibility, vast plugin ecosystem, and vendor neutrality, Jenkins remains the preferred tool for cloud applications, especially in DevOps environments. Despite the emergence of many newer cloud-native tools, Jenkins remains the preferred solution for complex, hybrid, or highly customized CI/CD pipelines.

The TanStack incident and the Checkmarx Jenkins AST plugin intrusion incident were actually part of a well-planned coordinated supply chain attack campaign by the same threat group, TeamPCP.

Security researchers from Wiz, Snyk, and Socket have dubbed this large-scale, multi-targeted attack campaign (expected to launch in May 2026) the “Mini Shai-Hulud” worm attack. While the two incidents targeted different environments and used different initial entry points, they both originated from the same threat group, malware family, infrastructure, and ultimate target.

Incident details: The previous version of the Checkmarx Jenkins AST plugin (specifically version 2026.5.09) was compromised as part of an ongoing supply chain attack by the threat actor group TeamPCP, following their earlier compromise of Checkmarx infrastructure in March 2026.

The attack appears to be another TeamPCP incident because the attackers used the same techniques—gaining unauthorized access to Checkmarx’s GitHub repositories—to inject credential-stealing “Dune-themed” malware, similar to the previous KICS and GitHub Actions attacks.

Official announcement: Please refer to the link for details. – https://checkmarx.com/blog/ongoing-security-updates/

Cell Phone (iPhone, Android, windows mobile), Under our observation

Closer Look – SIM-Farm-as-a-Service (28th Apr 2026)

Leave a comment

Preface: A SIM box (or SIM bank) is a hardware device that houses multiple SIM cards simultaneously to facilitate VoIP-to-GSM call termination. It reroutes international VoIP calls to appear as local calls by using local prepaid SIM cards, allowing operators to bypass high international tariffs and exploit low local call rates. It is primarily used for, but not limited to, fraudulent bypass.

Background: Why SIM-Farm-as-a-Service (SFaaS) is a Major Security Concern

Industrial-Scale Fraud: It enables the mass creation of fake accounts for social media, messaging apps, and banking by bypassing SMS-based one-time password (OTP) verification.

Evading Detection: By using local SIM cards, scammers can disguise international phishing attempts as local calls or texts, making them harder for users and automated systems to detect.

Critical Infrastructure Risk: Massive setups, like the one dismantled by the US Secret Service in late 2025, have the capacity to overload cellular networks, potentially jamming emergency services.

Legal Gray Areas: While the hardware itself is often legal for testing purposes, its application in SFaaS models has prompted governments, notably the UK government, to pursue bans on the “possession and supply” of SIM farm equipment.

Security focus: The recent spotlight on SIM-Farm-as-a-Service in April 2026 stems from a major investigation by the cybersecurity firm Infrawatch. Please refer to the link for referene.

https://www.techradar.com/pro/sim-farm-as-a-service-how-a-belarus-based-network-hijacked-uk-and-us-telcos-to-enable-global-fraud

Potential Risk of CVE, Under our observation

AMD ID: AMD-SB-7050: About Vector Value Injection in AMD CPUs, AMD believes that existing mitigation guidance for FPVI remains valid and covers VVI cases as well. What are your thoughts on this? (18th Mar 2026)

Leave a comment

Background: The researchers’ paper introduces Vector Value Injection (VVI), which could allow an attacker with a deep understanding of microarchitectural behavior to inject values into vector registers during transient execution. Although they noted similarities with Floating Point Value Injection (FPVI), they reported Vector Value Injection as a new issue due to its capability to be triggered without denormal values as inputs.

AMD believes that VVI falls within the existing scope of CVE-2021-26314 (FPVI) as existing descriptions of FPVI do not specifically require denormal inputs. Additionally, AMD believes that existing mitigation guidance for FPVI remains valid and covers VVI cases as well.

Ref: CVE-2021-26314 – Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage.

Official announcement: AMD ID: AMD-SB-7050 “Vector Value Injection in AMD CPUs”. Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7050.html

CVE-2021-26314 is a vulnerability from five years ago; however, in today’s parallel environment, the situation may be different!

How does Parallel Processing handle “Different Types”?

When tasks are different (e.g., one calculates Pi, one downloads a file, one reads a database), the system handles them in three ways:

1.         Heterogeneous Task Assignment (Asynchronous):

Instead of using a “map” (which does the same thing to many items), we use apply_async. This allows Core 1 to run a “Math” function while Core 2 runs a “Data Backup” function simultaneously.

2.         OS Scheduling & Context Switching:

The Operating System (OS) is the “manager.” If Task A is waiting for a slow Hard Drive (I/O Bound), the OS immediately moves Task B (CPU Bound) onto that core so no time is wasted.

3.         Hardware Resource Partitioning:

On a chip like the 9995WX, different execution units inside the core can work at once. One part of the core handles Integer math, while another handles Floating Point (AVX-512). This allows the processor to crunch different types of data within the same clock cycle

Vector Value Injection integrated to pool.apply_async (which runs different functions simultaneously) cannot be curcumvented through Register Scrubbing or Control-Flow Enforcement (CET). In fact, manually assigning different functions using `apply_async’ lowers the defense level potentially.

Why apply_async May Lower the Defense Level?

When you use pool.apply_async to launch different functions, Python’s multiprocessing creates multiple independent OS Processes.

•          Expanded Attack Surface: Compared to a single-process loop, a multi-process environment increases the frequency of Inter-Process Communication (IPC). If an attacker leverages Vector Value Injection, they can hunt for vulnerabilities in the different logic paths of each unique function.

•          Context Switching Risks: Frequent task scheduling can increase the risk of Cache Side-channel leaks. These leaks can sometimes bypass Register Scrubbing protection by capturing data before it is cleared.

End of article

AI and ML, Under our observation

Edge TPU (an ASIC accelerator developed by Google) – Episode 1 (23rd Feb 2026)

Leave a comment

Preface: PyCoral is specifically a TPU processing technique. While TensorFlow Lite (TFLite) can run on a standard CPU, PyCoral is the dedicated library used to delegate those operations to the Edge TPU hardware.

PyCoral API: This is a Python library specifically designed by Google to run inference on Coral Edge TPU hardware, such as the Coral USB Accelerator or M.2 modules. It is built on top of TensorFlow Lite.

Nvidia H100: This is a high-end data center GPU based on the Hopper architecture. It uses Nvidia’s proprietary software stack, including the CUDA toolkit, TensorRT, and the Transformer Engine to accelerate AI workloads.

Background: It is accurate to say that foundational memory management principles—specifically allocation and copying (malloc/new, memcpy)—are the basis for both CUDA/TensorRT and Coral API inference, though they operate on different memory spaces.

  • CUDA/TensorRT (GPU-centric): Uses cudaMalloc and cudaMemcpy to manage dedicated GPU device memory.
  • PyCoral API/TFLite (CPU-centric/Edge): Primarily uses malloc or new for CPU-based input/output buffers and memcpy to manage memory within host memory, even when interacting with the Edge TPU.

In both cases, efficient management of data movement between host (CPU) and device (GPU/TPU) is key, making memory allocation and copying the common denominator.

PyCoral API (pycoral module): This is a Python library built on top of the TensorFlow Lite Python API (tflite_runtime). It provides convenience functions and additional features (like model pipelining and on-device transfer learning) to simplify development with Python.Coral C++ API (libcoral): This is a C++ library built on top of the TensorFlow Lite C++ API. It offers the same functionality as the PyCoral API but for C++ applications.

Cyber security focus: But the most common vulnerability occurs when developers call [.]get() to obtain the raw pointer, and then continue to use that raw pointer after the std::unique_ptr has gone out of scope or been destroyed. Is the C++ TPU programming related to this issue? Please refer to the recommendations in the diagram for details.

Under our observation

Learn more about AMD ID: AMD-SB-3042 (Control Flow Reconstruction using HPCs) [18 Feb 2026]

Leave a comment

Preface: AMD EPYC processors are extensively used for High-Performance Computing (HPC) clusters, powering some of the world’s most advanced supercomputers. They are specifically engineered to handle compute-intensive tasks such as scientific simulations, weather forecasting, and complex molecular modelling.

Background: AMD Infinity Guard is a suite of security features built directly into the silicon of the AMD EPYC processor. While it interacts with and protects firmware, its foundation is hardware-based. When AMD Infinity Guard forms Secure Encrypted Virtualization (SEV), the encryption keys are not stored on an external hard disk or in standard bare-metal memory. Instead, they are kept entirely within the processor’s hardware. The actual data belonging to your virtual machine is stored in the system’s “bare-metal” RAM (DRAM), but it is fully encrypted.

In a traditional setup, the hypervisor has “God mode”—it can see everything. With AMD SEV-SNP, the hardware creates a Trusted Execution Environment (TEE) where the hypervisor is demoted to a simple “data mover” that is cryptographically blocked from the VM’s secrets.

Ref: CounterSEVeillance is a novel side-channel attack that targets AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging), a technology designed to protect confidential virtual machines (VMs) from a malicious hypervisor. Unlike previous attacks that might manipulate the VM’s state, CounterSEVeillance is primarily a passive side-channel attack, making it difficult to detect. 

Official article details

Summary: Researchers from Universities of Durham and of Luebeck have reported a way for a malicious hypervisor to monitor performance counters and potentially recover data from a guest VM. 

Affected Products and Mitigation: Performance counters are not protected by Secure Encrypted Virtualization (SEV, SEV-ES, or SEV-SNP).  AMD has defined support for performance counter virtualization in APM Vol 2, section 15.39. Performance Monitoring Counters (PMC) virtualization, available on AMD products starting with AMD EPYC™ 9005 Series Processors, is designed to protect performance counters from the type of monitoring described by the researchers.

For processors released prior to AMD EPYC™ 9005 Series Processors, AMD recommends software developers employ existing best practices, including avoiding secret-dependent data access or control flows where appropriate to help mitigate this potential vulnerability.

Official announcement: Please refer to the link for details –

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

Under our observation

AMD ID: AMD-SB-8022 – Closer look in Optical Probing of Readback CRC Bus (13th Feb 2026)

Leave a comment

Preface: AMD 7000 series (7-series) processors are extensively used to build High Performance Clusters (HPC). AMD provides 7-series solutions for both enterprise-grade and consumer/prosumer levels:

  • AMD EPYC™ 7002 and 7003 Series: These server-grade processors (codenamed “Rome” and “Milan”) are specifically designed for commercial and scientific HPC. They offer up to 64 cores per socket, high memory bandwidth (8 channels), and extensive PCIe Gen4 lanes to reduce data bottlenecks.
  • AMD Ryzen™ 7000 Series: While typically consumer CPUs, they are often used for “personal HPC” or small-scale clusters due to their high clock speeds and performance-per-dollar for specialized parallel computing tasks.

Background: The “Readback CRC Bus” refers to the internal logic path or mechanism in FPGAs (especially AMD/Xilinx devices) used to perform readback cyclic redundancy checks.

This is not a physical external “bus,” but a key component of the configuration logic, primarily used to ensure the data integrity of the FPGA’s internal configuration memory. Its core functions.

Academic studies and AMD’s bulletin describe attacks where researchers collect near‑infrared photon emissions that escape from transistor switching events on the FPGA die.

This depends on silicon’s bandgap (~1.1 eV ⇒ transparent above ~1100 nm). Because of this:

  • Visible light cannot pass through silicon.
  • Near‑IR and SWIR (1.1–2.3 µm) passes through with relatively low attenuation.
  • The plastic/epoxy package is often more opaque, so attacking from the backside of a thinned die is normal.

The reason backside emissions are detectable:

  • switching transistors emit very weak photons,
  • silicon becomes transparent above ~1100 nm,
  • the backside offers a direct path to the active circuitry after thinning,
  • the metallization layers on the front side block light.

This is the same principle used in IRIS inspection methods, which also rely on silicon’s IR transparency for imaging.

Technical Summary: By leveraging a physical optical side channel, an attacker could recover plaintext configuration data from encrypted bitstreams. AMD recommends maintaining good physical security practices and keeping  systems closed unless needed for maintenance and repairs by authorized personnel.

 Affected Products and Mitigation: The testing by the academics was done on AMD Xilinx 7 series FPGAs. This is a physical back side attack and is outside of the threat model for AMD 7-series FPGAs.

Official announcement: Please refer to the link for more details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-8022.html

Under our observation

AMD ID: AMD-SB-6026 – AMD does not believe that the reported vulnerability exists within the MI3XX GPU designs. (12th Feb 2026)

Leave a comment

Preface: The MI3xx series (specifically the AMD Instinct MI300 and MI350 series) is designed and manufactured by AMD. These chips are not traditional graphics cards for gaming; they are high-performance GPU accelerators specifically designed for Generative AI, large-scale AI training, and High-Performance Computing (HPC).

Background: In the AMD Instinct MI300A architecture, the cache is technically known as the MALL (Memory Attached Last Level) cache. While “MIG” is a term commonly associated with NVIDIA’s Multi-Instance GPU technology, the MI300A’s shared last-level cache is officially branded as the AMD Infinity Cache.

Is L3/Limited-Level Cache (LLC) shared across all cores?

  • GPU L3/Infinity Cache (MALL)
  • Shared across all clients (CPU & GPU).
  • The MI300A features a massive 256 MB shared Last-Level Cache (LLC), often called the AMD Infinity Cache or MALL (Memory Attached Last Level).

This specific cache is located on the I/O Die (IOD) and sits beyond the coherence point, meaning it is accessible by both the 24 CPU cores and the 228 GPU Compute Units.

  • The MI300A uses a truly shared last‑level cache (MALL).
  • Shared caches always raise the theoretical possibility of side channels.
  • But only if an attacker can cause and observe measurable eviction‑based interference.
  • AMD claims their virtualization model prevents this for GPU workloads.

Ref: NVIDIA H100 GPUs with Multi-Instance GPU (MIG) enabled provide full hardware-level isolation, ensuring that each partitioned “GPU Instance” (GI) has its own dedicated high-bandwidth memory (HBM3), compute cores, and L2 cache. Each MIG instance has its own independent path through the memory system, including dedicated cross-switch ports, L2 cache groups, memory controllers, and DRAM address buses. Many cache-based side-channel attacks rely heavily on the time delays (latency differences) associated with accessing memory in the L2 (or L3/LLC) cache.

Security Focus: The researchers shared with AMD a report titled “Behind Bars: A Side-Channel Attack on NVIDIA H100 MIG Cache Partitioning Using Memory Barriers”.

Based on MI3XX GPU architectural analysis, AMD has determined that the Guest VM-initiated operations of kernel launch related memory operations only impact the local XCD partition spatially allocated to the Guest VM and do not result in any observable interference on any other Guest VM load operations. Therefore, AMD does not believe that the reported vulnerability exists within the MI3XX GPU designs.

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

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

Under our observation

AMD ID: AMD-SB-7038 – Memory Re-orderings as a Timerless Side-channel. AMD recommends that software developers employ existing best practices (14-01-2026)

Leave a comment

Preface: The vulnerability described in AMD-SB-7038 is based on a general microarchitectural behavior: memory reordering and out-of-order execution. These techniques are used by all major CPU vendors (Intel, ARM, etc.) to improve performance.

Background: The bulletin describes a research paper titled “MEMORY DISORDER: Memory Re-orderings as a Timerless Side-channel.”

Key points from AMD’s disclosure:

Nature of the issue:
Researchers demonstrated that memory re-orderings in CPUs and GPUs can be exploited as a timerless side-channel attack.
This means attackers can infer activity in other processes by observing subtle memory ordering patterns—without using timing measurements.

Impact:

  • Potential for covert channels (secret communication between processes).
  • Possible application fingerprinting (detecting what app is running).
  • No direct data corruption or privilege escalation, but information leakage risk.

Scope:

  • Applies to mainstream processors, including AMD CPUs and GPUs.
  • It’s informational, not an emergency patch scenario. AMD classifies it as low severity because exploitation requires local access and advanced techniques.

Vulnerability details: Please refer to the link for details –

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

AMD-SB-7038 is about information leakage via subtle ordering patterns, not about allowing other processes to access memory during waits.

The vulnerability is about memory reordering being observable as a side-channel, not about direct memory access.

Remark: The attacker doesn’t need precise timing; they can infer ordering by observing cache state or contention.

In conclusion, this is a problem common to the entire industry, not unique to AMD. It is not due to any unique defects in its hardware.

Potential Risk of CVE, Under our observation

About CVE-2025-47365: Qualcomm integrated with automotive platform (7th Nov 2025)

Leave a comment
Published: 11/03/2025

Preface: GM’s Ultra Cruise system is supposed to be a more capable iteration of its Super Cruise ADAS that was first introduced in 2017.

To dig into the weeds a bit, the Ultra Cruise compute, which is about the size of two laptops stacked together, is made up of two Snapdragon SA8540P SoCs and one SA9000P AI accelerator to deliver low-latency control functions on 16-core CPUs and AI compute of more than 300 Tera operations per second for camera, radar and lidar processing.

Background: The Snapdragon Ride Platform accelerates the shift to software-defined vehicles by empowering developers to create AI-driven automated driving solutions. The system-on-chip, called Snapdragon Ride Platform, was developed for advanced driver assistance systems (ADAS) and automated driving. It’s one of a suite of cloud-connected platforms introduced by Qualcomm.

The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P – part of Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for the purpose of efficiently running Artificial Intelligence (AI) Deep Learning inference workloads. They are AI accelerators.

Qualcomm’s Snapdragon SA8540P SoCs and SA9000P AI accelerator use the QNX Neutrino RTOS for safety-critical functions in automated driving systems.

Vulnerability details: Integer Overflow or Wraparound in Automotive Platform

Description – Memory corruption while processing large input data from a remote source via a communication interface.

Official announcement: Please refer to link for details –

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