Category Archives: Potential Risk of CVE

CVE-2025-9612/9613/9614: AMD is concerned that a defect in non-AMD PCIe IDE could affect certain AMD products. (12th Dec 2025)

Preface: The security concerns regarding data integrity in Peripheral Component Interconnect Express (PCIe) transactions are a critical aspect of modern computing, particularly in data centers, cloud environments, and automotive systems where sensitive information is routinely handled. Historically, PCIe interfaces were considered relatively secure due to their placement inside a server enclosure, but the rise of disaggregated systems, confidential computing, and sophisticated physical attacks has changed this perspective entirely. As an interconnect that links the CPU to various peripherals like GPUs, SSDs, and network adapters, any vulnerability can have far-reaching consequences, leading to data corruption, unauthorized access, or system compromise.

Background: AMD EPYC processors use an I/O Die (IOD) to manage all external interfaces, connecting to CPU Dies (CCDs) via high-speed Global Memory Interconnect (GMI) links and handling numerous DDR5 memory channels, PCIe Gen5, and CXL lanes, with SERDES (Serializer/Deserializer) technology underpinning these fast connections for massive bandwidth and low latency in data-intensive workloads, allowing for up to 12 memory channels and 128 PCIe lanes per socket in recent generations.

AMD SERDES technology significantly enhances the physical-layer data integrity and signal quality in PCIe transactions, but it is distinct from higher-level security features like encryption. SERDES technology is a foundational element that ensures reliable data transmission at extremely high speeds.

Affected Products and Mitigation:

From security point of view, it expect additional details from the PCIe SIG and plan to update this security notice as more information is available.  At this time, AMD believes the following products may be impacted.

AMD EPYC™ 9005 Series Processors

AMD EPYC™ Embedded 9005 Series Processors

Ref: PCI-SIG (Peripheral Component Interconnect Special Interest Group) is the electronics industry consortium that defines and maintains the standards for PCI, PCI-X, and PCI Express (PCIe) computer buses, ensuring high-speed, interoperable connectivity for components like graphics cards, SSDs, and network adapters in computers and data centers. This non-profit group, with hundreds of member companies, develops specifications, promotes compliance, and fosters an open ecosystem for PCIe technology, allowing different manufacturers’ products to work together seamlessly.

Vulnerability details:

CVE-2025-9612 (non-AMD) : An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on Transaction Layer Packet (TLP) ordering and tag uniqueness may allow encrypted packets to be replayed or reordered without detection. This can enable local or physical attackers on the PCIe bus to violate data integrity protections.

CVE-2025-9613 (non-AMD): A vulnerability was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on tag reuse after completion timeouts may allow multiple outstanding Non-Posted Requests to share the same tag. This tag aliasing condition can result in completions being delivered to the wrong security context, potentially compromising data integrity and confidentiality.

CVE-2025-9614 (non-AMD): An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on re-keying and stream flushing during device rebinding may allow stale write transactions from a previous security context to be processed in a new one. This can lead to unintended data access across trusted domains, compromising confidentiality and integrity.

Official announcement: Please refer to the link for details –

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

CVE-2025-66471: Be vigilant with Python-based Kubernetes clients! (11th Dec 2025)

NVD Last Modified: 12/08/2025

Preface: urllib3 is extremely popular and foundational in the Python ecosystem, acting as a core dependency for many top libraries like requests, pip, and kubernetes, though it’s often used indirectly through the more user-friendly requests library for general tasks. It’s a robust, low-level HTTP client known for features like connection pooling and thread safety, making it a cornerstone for complex applications and other tools.

Background:

kubectl and client-go (Go-based)

These are the default and most widely used tools for Kubernetes:

  • kubectl is the official CLI tool for cluster management.
  • client-go is the official Go client library, used by Kubernetes controllers, operators, and most production-grade tools.
  • Almost all core Kubernetes components and many third-party operators are written in Go.

Ref: Kubernetes (via kubectl and client-go) doesn’t use urllib3—it’s written in Go and uses its own HTTP stack. So the Go-based Kubernetes API client is unaffected by this Python-specific issue.

Python-based Kubernetes clients

These are popular in data science, automation, and DevOps scripting, but far less common for building core Kubernetes components. They’re widely used in:

  • CI/CD pipelines
  • Custom scripts for cluster operations
  • Machine learning workflows (where Python dominates)

Ref: Python-based Kubernetes clients (like the one in your example) do rely on urllib3 internally through the requests library or similar. If you’re using these clients, you must upgrade urllib3 to a patched version (≥ 2.6.0 once available).

Vulnerability details: (CVE-2025-66471) urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3’s streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.

Official announcement: Please refer to the link for details –

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

CVE-2025-33201 and CVE-2025-33211: About NVIDIA Triton Inference Server 10th Dec 2025

Initial release – 02 December 2025   

Preface: Triton Inference Server is an open source inference serving software that streamlines AI inferencing. Triton Inference Server enables teams to deploy any AI model from multiple deep learning and machine learning frameworks, including TensorRT, PyTorch, ONNX, OpenVINO, Python, RAPIDS FIL, and more.

Background: The NVIDIA Triton Inference Server natively supports gRPC as one of its primary communication protocols for the client API. Furthermore, gRPC can also be used for health checks, statistics, and model loading/unloading operations, not just inference requests. Inference requests arrive at the server via either HTTP/REST or GRPC or by the C API and are then routed to the appropriate per-model scheduler. Triton implements multiple scheduling and batching algorithms that can be configured on a model-by-model basis.

Triton major features:

  • Supports multiple deep learning frameworks
  • Supports multiple machine learning frameworks
  • Concurrent model execution
  • Dynamic batching
  • Sequence batching and implicit state management for stateful models
  • Provides Backend API that allows adding custom backends and pre/post processing operations
  • Model pipelines using Ensembling or Business Logic Scripting (BLS)
  • HTTP/REST and GRPC inference protocols based on the community developed KServe protocol
  • A C API and Java API allow Triton to link directly into your application for edge and other in-process use cases
  • Metrics indicating GPU utilization, server throughput, server latency, and more

Vulnerability details:

CVE-2025-33211         NVIDIA Triton Server for Linux contains a vulnerability where an attacker may cause an improper validation of specified quantity in input. A successful exploit of this vulnerability may lead to denial of service.

CVE-2025-33201         NVIDIA Triton Inference Server contains a vulnerability where an attacker may cause an improper check for unusual or exceptional conditions issue by sending extra large payloads. A successful exploit of this vulnerability may lead to denial of service.

Official announcement: Please refer to the link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5734

CVE-2025-33208: NVIDIA TAO design weakness (9th Dec 2025)

Official Updated 11/26/2025

Preface: AI vision models are artificial intelligence systems, often multimodal (Vision-Language Models or VLMs), that analyze and interpret visual data (images, videos) alongside text, enabling them to “see” and understand the world like humans, performing tasks from object recognition and image captioning to answering questions about visuals and generating new images, by converting visual info into a format comparable to text.

Background: You use NVIDIA TAO (Train, Adapt, Optimize) to rapidly build, customize, and deploy high-performance, domain-specific AI models (especially for vision) with less code, less data, and faster training by leveraging powerful pre-trained foundation models, fine-tuning them with your own data, and optimizing them for efficient inference on edge-to-cloud devices, saving significant time and resources.

The NVIDIA TAO Toolkit is designed to function with both real and synthetic data.

Training with Real Data: The primary function of the TAO Toolkit is to fine-tune NVIDIA’s extensive library of pretrained foundation models using your own proprietary (real-world) datasets. This process is low-code and enables the customization of models for specific use cases without needing deep AI expertise or training from scratch.

Leveraging Synthetic Data: Synthetic data is often used to address the challenges associated with real data collection, such as scarcity, expensive labeling, and rare edge cases.

Models can be initially trained on large volumes of synthetic data generated from tools like NVIDIA Omniverse Replicator or partner platforms (e.g., Sky Engine AI, AI. Reverie, Lexset).

Vulnerability details: (CVE-2025-33208) NVIDIA TAO contains a vulnerability where an attacker may cause a resource to be loaded via an uncontrolled search path. A successful exploit of this vulnerability may lead to escalation of privileges, data tampering, denial of service, information disclosure

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

https://nvidia.custhelp.com/app/answers/detail/a_id/5730

A Tale of Two GPU’s

Story background: Rowhammer Attacks on GPU Memories are Practical (8th 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

CVE-2025-47372: Buffer Copy Without Checking Size of Input in Boot (5th Dec-2025)

Qualcomm – Official announcement: 1st Dec 2025

Quote: I chose a Qualcomm product affected by this vulnerability as an example. The Snapdragon Ride™ Flex SoC, including the SA9000P series, does not run on a single embedded OS, but rather supports mixed-criticality operating systems such as those provided by Qualcomm’s partners or the automaker themselves.

Preface: Secure boot is defined as a boot sequence in which each software image to be executed is authenticated by software that was previously verified. This sequence is designed to prevent unauthorized or modified code from being run. Our chain of trust is built according to this definition, starting with the first piece of immutable software to be run out of read-only-memory (ROM). This first ROM bootloader cryptographically verifies the signature of the next bootloader in the chain, then that bootloader cryptographically verifies the signature of the next software image or images, and so on.

Background: Unlike other signed software images, the signature for Qualcomm Technologies signed images is only computed over a single segment in the image and not the entire image. The segment containing the signature is called the hash segment. This hash segment is a collection of the hash values of the other ELF segments that are included in the image. In other words we sign the collection of ELF segment hashes, rather than signing the entire ELF image. This representation is designed to relax memory size requirements and increases flexibility during loading.

Vulnerability details: The vulnerability described (CVE-2025-47372) is a heap overflow caused by reading an oversized ELF image into a buffer without proper bounds checking or authentication.

•       The overflow occurs during the write operation, before free() is called.

•       Once data exceeds the allocated size, adjacent memory is already corrupted.

•       Freeing memory only releases the block back to the allocator; it cannot undo corruption or prevent exploitation.

Official announcement: Please refer to the link for details

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

CVE-2025-47319: Exposure of Sensitive System Information to an Unauthorized Control Sphere in HLOS (4th Dec 2025)

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

CVE-2025-66216: About AIS-catcher (3rd Dec 2025)

Preface: AIS-Catcher is a MIT licensed dual band AIS receiver for Linux, Windows and Raspberry Pi. It is compatible with RTL-SDR dongles and the Airspy HF+.

AIS stands for Automatic Identification System and is used by marine vessels to broadcast their GPS locations in order to help avoid collisions and aide with rescues. An RTL-SDR with the right software can be used to receive and decode these signals, and plot ship positions on a map.

Background: You can set up your own receiver at home. With just a small USB radio adapter and a simple antenna, you can receive live signals from nearby ships and decode them directly on your computer or Raspberry Pi.

Setup requirement for an SDR AIS Receiver:

-RTL-SDR dongle (e.g. Nooelec NESDR, RTL-SDR Blog V3)

-VHF antenna (marine band, tuned for ~162 MHz)

-Raspberry Pi (Model 3 or later) or any PC

-Internet connection (for updates, optional data sharing)

Recommended Command (Dual-channel AIS, Auto Gain)

This does the following:

-A listens to both AIS frequencies:

Channel 1: 161.975 MHz

Channel 2: 162.025 MHz

-g auto lets AIS-catcher automatically choose the gain setting

Uses default device (-d 0) unless otherwise specified

You should see continuous outputs like this:

!AIVDM,1,1,,B,15MuqP001oK>rWnE`D0?;wvP0<2R,0*6D

These are raw NMEA AIS messages being received in real time.

Vulnerability details: CVE-2025-66216 – AIS-catcher is a multi-platform AIS receiver. Prior to version 0.64, a heap buffer overflow vulnerability has been identified in the AIS::Message class of AIS-catcher. This vulnerability allows an attacker to write approximately 1KB of arbitrary data into a 128-byte buffer. This issue has been patched in version 0.64.

Best Practices:

Never store data() pointer across operations that can reallocate (like push_back, resize, insert, emplace).

If you need a stable pointer, consider:

  • std::deque (doesn’t invalidate all pointers on growth).
  • std::vector::reserve() before operations to avoid reallocation.
  • Or use indices instead of raw pointers.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2025-66216

CVE-2025-12183: About official lz4-java library (2nd Dec 2025)

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 MemoryHadoop 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

CVE-2025-33204: About NVIDIA NeMo Framework (1st Dec 2025)

Official Update 11/21/2025 04:36 PM

Preface: NeMo Curator is a Python library that includes a suite of modules for data-mining and synthetic data generation. They are scalable and optimized for GPUs, making them ideal for curating natural language data to train or fine-tune LLMs. With NeMo Curator, researchers in Natural Language Processing (NLP) can efficiently extract high-quality text from extensive raw web data sources.

NVIDIA NeMo Curator, particularly its image curation modules, requires a CUDA-enabled NVIDIA GPU and the corresponding CUDA Toolkit. The CUDA Toolkit is not installed as part of the NeMo Curator installation process itself, but rather is a prerequisite for utilizing GPU-accelerated features.

Background: NeMo Framework includes NeMo Curator because high-quality data is essential for training accurate generative AI models, and Curator provides a scalable, GPU-accelerated toolset for processing and preparing large datasets efficiently. It handles everything from cleaning and deduplicating text to generating synthetic data for model customization and evaluation, preventing data processing from becoming a bottleneck.

Potential risks under observation: The vulnerability arises when malicious files—such as JSONL files—are loaded by NeMo Curator. If these files are crafted to exploit weaknesses in how NeMo Curator parses or processes them, they can inject executable code.

Ref: Parser is related to predefined variables, as it can either parse data into variables or use predefined variables to perform its task.

Vulnerability details:

CVE-2025-33204         NVIDIA NeMo Framework for all platforms contains a vulnerability in the NLP and LLM components, where malicious data created by an attacker could cause code injection. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering.

CVE-2025-33205         NVIDIA NeMo framework contains a vulnerability in a predefined variable, where an attacker could cause inclusion of functionality from an untrusted control sphere by use of a predefined variable. A successful exploit of this vulnerability may lead to code execution.

Official announcement: Please refer to the link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5729