Preface: To virtualize a single NVIDIA GPU into multiple virtual GPUs and allocate them to different virtual machines or users, you can use NVIDIA’s vGPU capability.

Background: Unified memory is disabled by default. If used, you must enable unified memory individually for each vGPU that requires it by setting a vGPU plugin parameter. NVIDIA CUDA Toolkit profilers are supported and can be enabled on a VM for which unified memory is enabled.

Enabling Unified Memory for Nvidia vGPU does indeed allow a guest virtual machine (VM) to access global resources. When Unified Memory is enabled, it allows the VM to dynamically share memory with the host and other VMs, providing more flexibility and potentially improving performance for certain workloads.

Enabling access to global resources through Unified Memory in Nvidia vGPU can potentially lead to denial of service (DoS) attacks due to several reasons:

• When multiple VMs share the same physical GPU resources, there’s a risk of resource contention. If one VM consumes excessive resources, it can starve other VMs, leading to degraded performance or even service outages.
• Allowing VMs to access global resources increases the attack surface. Malicious actors could exploit vulnerabilities to disrupt services or gain unauthorized access to sensitive data.

Vulnerability details:

CVE-2025-23246: NVIDIA vGPU software for Windows and Linux contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where it allows a guest to consume uncontrolled resources. A successful exploit of this vulnerability might lead to denial of service.

CWE-732: Incorrect Permission Assignment for Critical

CVE-2025-23245: NVIDIA vGPU software for Windows and Linux contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where it allows a guest to access global resources. A successful exploit of this vulnerability might lead to denial of service.

CWE-400: Uncontrolled Resource Consumption

Official announcement: Please see the link for details –

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

Preface: The NVIDIA Tesla R570 driver is used for various data center GPUs, including the NVIDIA A100 and NVIDIA V100. These GPUs are designed for high-performance computing, AI, and deep learning applications.

Background:

The CUDA software environment consists of three parts:

• CUDA Toolkit (libraries, runtime and tools) – User-mode SDK used to build CUDA applications
• CUDA driver – User-mode driver component used to run CUDA applications (for example, libcuda.so on Linux systems)
• NVIDIA GPU device driver – Kernel-mode driver component for NVIDIA GPUs

On Linux systems, the CUDA driver and kernel mode components are delivered together in the NVIDIA display driver package.

DxgkDdiEscape is a function used in Windows drivers, specifically within the DirectX graphics kernel subsystem. In Linux, a similar function to DxgkDdiEscape is ioctl (Input/Output Control).

The ioctl system call can indeed be a potential vector forIncorrect Authorization vulnerabilities if not implemented correctly.

Vulnerability details: NVIDIA GPU Display Driver for Linux contains a vulnerability which could allow an unprivileged attacker to escalate permissions. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

Impact: Code execution, denial of service, escalation of privileges, information disclosure, and data tampering

Official announcement: Please see the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5630

Preface: The most common way is Attackers place a malicious DLL in a directory that is checked before the legitimate system paths.

Because the application loading the DLL is trusted, security solutions may not flag the execution as suspicious.

Cybercriminals often use several common program instructions when creating malicious DLLs. For example, dll injection, Registry Manipulation,…etc.

Evasion Techniques:

Obfuscation: Code within the DLL is often obfuscated to avoid detection by security tools.

Steganography: Hiding malicious code within seemingly benign files.

Background: The NVIDIA NvContainer service is part of the NVIDIA graphics driver package and is responsible for various tasks, including telemetry data gathering, overlay management, and high-performance GPU scheduling. It doesn’t imply that Windows OS runs on a container runtime like Docker or Kubernetes. Instead, it refers to the way NVIDIA organizes and manages its services and processes within the driver package.

The term “container” in this context is more about how NVIDIA encapsulates its services to ensure they run efficiently and independently, rather than using a full-fledged containerization technology

Vulnerability details: NVIDIA NvContainer service for Windows contains a vulnerability in its usage of OpenSSL, where an attacker could exploit a hard-coded constant issue by copying a malicious DLL in a hard-coded path. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, or data tampering.

Official announcement: Please see the official link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5644

Preface: The symbol ~/. by itself is not a relative path traversal; it simply refers to the home directory of the current user. However, when combined with ./.., it can be part of a relative path traversal.

Relative path traversal involves using sequences like ../ to navigate up the directory hierarchy. For example, ~/. refers to the home directory, and ./.. moves up one directory level from the current directory. So, ~/. ./.. would navigate to the parent directory of the home directory, which can be considered a form of relative path traversal

Background: NVIDIA NeMo is an end-to-end platform designed for developing and deploying generative AI models. This includes large language models (LLMs), vision language models (VLMs), video models, and speech AI. NeMo offers tools for data curation, fine-tuning, retrieval-augmented generation (RAG), and inference, making it a comprehensive solution for creating enterprise-ready AI models. Here are some key capabilities of NeMo LLMs:

1. Customization: NeMo allows you to fine-tune pre-trained models to suit specific enterprise needs. This includes adding domain-specific knowledge and skills, and continuously improving the model with reinforcement learning from human feedback (RLHF).
2. Scalability: NeMo supports large-scale training and deployment across various environments, including cloud, data centers, and edge devices. This ensures high performance and flexibility for different use cases.
3. Foundation Models: NeMo offers a range of pre-trained foundation models, such as GPT-8, GPT-43, and GPT-530, which can be used for tasks like text classification, summarization, creative writing, and chatbots.
4. Data Curation: The platform includes tools for processing and curating large datasets, which helps improve the accuracy and relevance of the models.
5. Integration: NeMo can be integrated with other NVIDIA AI tools and services, providing a comprehensive ecosystem for AI development.

Vulnerability details:

CVE-2025-23249: NVIDIA NeMo Framework contains a vulnerability where a user could cause a deserialization of untrusted data by remote code execution. A successful exploit of this vulnerability might lead to code execution and data tampering.

CVE-2025-23250: NVIDIA NeMo Framework contains a vulnerability where an attacker could cause an improper limitation of a pathname to a restricted directory by an arbitrary file write. A successful exploit of this vulnerability might lead to code execution and data tampering.

CVE-2025-23251: NVIDIA NeMo Framework contains a vulnerability where a user could cause an improper control of generation of code by remote code execution. A successful exploit of this vulnerability might lead to code execution and data tampering.

Official announcement: Please see the official link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5641

When light weight AI become your partner. In the office, all people skill become equal. As a result, the inherent kindness in human nature will be hidden!

Preface: High Performance Computing (HPC) systems using AMD chips can utilize AXI crossbars. The AXI crossbar is used to route AXI4-Lite requests to corresponding sub-cores based on the address. This is particularly useful in complex SoC designs where efficient data routing and high throughput are essential.

However, it’s worth noting that AMD’s Versal adaptive SoCs feature a programmable Network-on-Chip (NoC), which replaces traditional AXI interconnects in the programmable logic. This NoC can achieve higher levels of design efficiency and performance compared to traditional AXI interconnects.

Background:

AXI Crossbar

• In an AXI Crossbar, the master interfaces are the sources of transactions, and the slave interfaces are the destinations.
• The crossbar routes transactions from multiple masters to multiple slaves based on address decoding and arbitration logic.
• It ensures efficient communication and data transfer within a System-on-Chip (SoC) design.

AXI4-Lite and the Orchestrator serve distinct roles within an AXI Crossbar:

AXI4-Lite: AXI4-Lite is a simplified subset of the AXI4 protocol designed for low-complexity, low-throughput applications. It supports:

• 32-bit address and data widths.
• Single data transfer per transaction, making it ideal for control register access and configuration tasks.

The Orchestrator in an AXI Crossbar manages the routing and arbitration of transactions between multiple masters and slaves.

Vulnerability details: Researchers from ETH Zurich, UC San Diego, and RPTU Kaiserslautern-Landau shared a paper with AMD titled “EXPECT: On the Security Implications of Violations in AXI Implementations” and “XRAY Detecting and Exploiting Vulnerabilities in ARM AXI Interconnects” which explore methods for exposing vulnerabilities related to the AXI interface when utilizing the AMD AXI Crossbar IP in Vivado™ designs. The AXI Protocol Checker IP was included in the design as a debug check but failed to catch all protocol violations in the design.

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