Preface: NVIDIA InfiniBand switches are based on technology from Mellanox Technologies. Nvidia Spectrum switches are based on technology from Mellanox Technologies. The Spectrum switch ASIC portfolio, originally developed by Mellanox for high-performance Ethernet networking, was rebranded under Nvidia and is now a core component of Nvidia’s networking division. NVIDIA completed the acquisition of Mellanox Technologies, a major supplier of high-performance interconnect technology (switches, NICs), in April 2020 for approximately $7 billion. This strategic move enhanced NVIDIA’s data center networking capabilities, specifically in InfiniBand and Ethernet, to support AI and high-performance computing.

Background: Cumulus Linux is optimized for Ethernet fabrics, while NVOS/Onyx is largely utilized in high-performance InfiniBand environments.

-Key switches supporting NVIDIA Cumulus Linux include:

• Spectrum-4: SN5600, SN5600D, SN5400
• Spectrum-2/3: SN3700, SN3700C, SN4600, SN4700
• Spectrum-1: SN2700, SN2100, SN2745 

Example: Spectrum-4 series (including the SN5600, SN5600D, and SN5400) is a line of physical Ethernet switches (hardware)

Use Cases: Ideal for hyperscale cloud data centers and enterprise AI networks, emphasizing scalability and full customizability.

-NVOS (NVIDIA Onyx) or similar OS typically supports:

Quantum/Quantum-2 InfiniBand: Switches designed for high-performance AI, such as the Quantum-2 series.

Use Cases: Focused on High-Performance Computing (HPC) and large-scale AI training clusters (AI Factories), particularly environments utilizing NVLink for GPU interconnects.

Note: As of early 2026, NVIDIA is focusing on standardizing the management commands (NVUE) across both systems to reduce the complexity of automation workflows when transitioning between different operating systems.

Cumulus Linux (Native Linux): When you SSH in, you land in a standard Debian Linux bash shell. You configure the switch using the NVUE (NVIDIA User Experience) object model via the nv command (e.g., nv set interface swp1…).

Vulnerability Note: The CVEs (CVE-2025-33179/33180) specifically target the NVUE API and CLI engine found in Cumulus Linux 5.x and later.

Vulnerability details:

CVE-2025-33179 NVIDIA Cumulus Linux and NVOS products contain a vulnerability in the NVUE interface, where a low-privileged user could run an unauthorized command. A successful exploit of this vulnerability might lead to escalation of privileges.

CVE-2025-33180 NVIDIA Cumulus Linux and NVOS products contain a vulnerability in the NVUE interface, where a low-privileged user could inject a command. A successful exploit of this vulnerability might lead to escalation of privileges.

Official announcement: Please refer to the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5722

Preface: AMD-SB-3042 is a formal advisory for a specific vulnerability, while AMD-SB-3043 is an advisory regarding an analytical tool (SNPeek) used to detect such vulnerabilities.

Background: If AMD zen5 operating AMD SEV-SNP, traditional hypervisor especially VMware or Hyper-V management include encryption will handle by hypervisor embedded in Xen5, so SNPeek collect the traffic is un-encrypted data. Details shown as below:

Limitations of SNPeek If using a tool like SNPeek to intercept traffic on the host side: It can only see data marked as “Shared” (usually for use by the hypervisor to assist with network or disk I/O). Data in Private Memory is always encrypted to SNPeek; the hypervisor cannot read its plaintext content at all. Potential Risk Warning Despite strong hardware encryption, the recently discovered StackWarp (CVE-2025-29943) vulnerability shows that a malicious hypervisor could still influence the execution path of Zen 5 virtual machines by manipulating the CPU’s internal “Stack Engine.” While this doesn’t mean it can directly “read” encrypted memory, it can achieve indirect attacks.

AMD-SB-3043: Analytical Framework (SNPeek)

• Nature: A bulletin regarding a research framework and toolkit for evaluating side-channel risks in Confidential VMs (CVM).
• Core Content: Describes the SNPeek open-source toolkit.
• Function & Purpose:
  • SNPeek is not a single vulnerability but an automated analysis pipeline that uses machine learning to assess how sensitive a CVM application is to side-channel attacks.
  • It helps developers quantify how much information an application might leak when running in encrypted environments like SEV-SNP.
  • It provides configurable attack primitives to help developers locate “weak points” in their code and guides the implementation of mitigations (e.g., oblivious memory access).

Official details and announcement: AMD’s assessment is that all side-channel techniques demonstrated in the paper fall within the category of already known, documented, and out of scope behaviors according to the published SEV/SNP threat model.  AMD has  introduced features on Zen 5 processors—specifically Ciphertext Hiding and PMC Virtualization—that address the ciphertext visibility and HPC based leakage paths highlighted by the researchers.

AMD recommends software developers employ existing best practices, including constant-time algorithms, and avoiding secret-dependent data accesses where appropriate. Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3043.html

Preface: Artificial intelligence is both harmful and beneficial. Why is it harmful? Fundamentally, it reduces opportunities for low-skilled jobs. Speakers chant slogans like “Smart living, increased productivity.” However, its underlying problems seem difficult to conceal, so you can learn about the latest developments in artificial intelligence from online newspapers and articles. Today, when you seek answers from artificial intelligence, the answers it provides may not be the truth! Why have humans been able to survive and thrive on Earth for thousands of years? The answer is: survival of the fittest.

Background: Megatron-Core and Megatron-LM are open-source tools that are typically used together to train LLMs at scale across GPUs. Megatron-Core expands the capability of Megatron-LM.

NeMo Megatron Bridge is utilized by AI researchers, infrastructure engineers, and developers focused on high-performance training and fine-tuning of large language models (LLMs) and foundation models, particularly those bridging the Hugging Face ecosystem with NVIDIA’s Megatron-Core. NVIDIA H100 GPU introduced support for a new datatype, FP8 (8-bit floating point), enabling higher throughput of matrix multiplies and convolutions. Megatron Bridge uses the NVIDIA TransformerEngine (TE) to leverage speedups from FP8.

While NVIDIA developed Megatron Bridge to facilitate checkpoint conversion between NVIDIA NeMo and other deep learning frameworks, OpenAI utilizes its own internal infrastructure. As of 2026, NVIDIA Megatron Bridge is primarily used by large enterprises, Cloud Service Providers (CSPs), and Sovereign AI initiatives that need to train or deploy open-source models (such as Llama 3, Mistral, or Qwen) at massive scale on NVIDIA hardware.

Vulnerability details:

CVE-2025-33239 NVIDIA Megatron Bridge contains a vulnerability in a data merging tutorial, where malicious input could cause a code injection. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering.

CVE-2025-33240 NVIDIA Megatron Bridge contains a vulnerability in a data shuffling tutorial, where malicious input could cause a code injection. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering.

Official announcement: Please refer to the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5781

Preface: NeMo 2.0 is NVIDIA’s major modernization of the NeMo ecosystem.

Two things to remember about NeMo 2.0:

1. NeMo 2.0 is the training & model building framework.

It focuses on:

•               Model architectures (LLMs, ASR, TTS, multimodal)

•               Training pipelines

•               NeMo Run + NeMo-based microservices

•               Distributed GPU/accelerated workflows

2. NeMo Guardrails and NeMo Curator are NOT part of the NeMo 2.0 training stack.

They live adjacent to NeMo 2.0, serving two different lifecycle phases.

Background: NeMo 1.x modules (ASR collections, VAD, etc.) used pickle because they relied heavily on Python multiprocessing and Python objects.

NeMo 2.0 is moving toward language  and framework agnostic formats

Instead of pickle, NeMo 2.0 favors:

•               Safetensors (for weights)

•               JSON / YAML (for metadata)

•               Parquet (for curated datasets)

•               Numpy / torch tensors loaded explicitly

•               HuggingFace compatible formats

These formats are:

•               Safe

•               Portable across hardware and OS

•               Usable by non Python systems

•               Compatible with cloud trust boundaries

NeMo Curator and NeMo Guardrails are designed to avoid pickle entirely

Even though older NeMo components still used pickle internally:

• NeMo Curator does not ingest pickle data
• NeMo Guardrails never used pickle at all
• NeMo 2.0 framework minimizes it or removes it

This aligns with modern security guidance for LLM infrastructure.

Vulnerability details: CVE-2025-33245 NVIDIA NeMo Framework contains a vulnerability where malicious data could cause remote code execution. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering.

Official announcement: Please refer to the link for details –

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