Preface: NVIDIA JetPack and Jetson Linux (formerly L4T – Linux for Tegra) are the foundational software stacks for NVIDIA Jetson AI modules. Jetson Linux provides the essential BSP (bootloader, Linux kernel, Ubuntu rootfs, drivers), while JetPack SDK bundles this with developer tools, libraries (CUDA, TensorRT), and APIs for AI, computer vision, and robotics.

Background: The initrd and root file system (rootfs) unencrypted creates a significant security gap against local physical attacks. In a standard industrial or autonomous deployment, physical access is often the most direct threat to a machine’s integrity.

The Security Gap: Local Physical Access

When a Jetson device is left with its default, unencrypted configuration, an attacker with physical access can easily bypass system protections:

Because the bootloader cannot read encrypted files directly, it must first mount an unencrypted partition containing the kernel and initrd images. Without signing or encryption, these critical files can be replaced via a malicious USB or NVMe drive.

Ref: nvluks-srv-app is a NVIDIA Jetson Linux user-space application used to retrieve a unique, secure passphrase from the Trusted Execution Environment (TEE) to unlock encrypted partitions at boot time. It enables disk encryption on Jetson devices by facilitating secure communication between the normal operating system and the hardware-backed security services (OP-TEE).

Vulnerability details:

CVE-2026-24154 NVIDIA Jetson Linux has vulnerability in initrd, where an unprivileged attacker with physical access could inject incorrect command line arguments. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, denial of service, data tampering, and information disclosure.

CVE-2026-24148 NVIDIA Jetson for JetPack contains a vulnerability in the system initialization logic, where an unprivileged attacker could cause the initialization of a resource with an insecure default. A successful exploit of this vulnerability might lead to information disclosure of encrypted data, data tampering, and partial denial of service across devices sharing the same machine ID.

CVE-2026-24153 NVIDIA Jetson Linux has a vulnerability in initrd, where the nvluks trusted application is not disabled. A successful exploit of this vulnerability might lead to information disclosure.

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

Preface: While NVIDIA CUDA provides powerful parallel processing capabilities on both Linux and Windows, developers still need to run Windows on top of Linux using virtio-win in several specific environments:

For example: Windows-Exclusive HPC Applications

Many specialized scientific and engineering applications are only developed for Windows and cannot be easily recompiled for Linux.

Background: To programmatically use RhelDoUnMap() while ensuring user requests are correctly validated, you must specifically address the descriptor count validation to prevent buffer overflows. This function is part of the virtio-win drivers used in Red Hat Enterprise Linux environments.

Key Components of virtio-win include Network (NetKVM), Storage (viostor / virtio-scsi), Memory Balloon (balloon), Serial (virtio-serial), Graphics (virtio-gpu), Input (virtio-input) and Guest Agent (qemu-ga). The RhelDoUnMap() function is part of the virtio-win driver suite, specifically within the VioStor (Virtio Storage) driver.

Vulnerability details : A flaw was found in virtio-win. The `RhelDoUnMap()` function does not properly validate the number of descriptors provided by a user during an unmap request. A local user could exploit this input validation vulnerability by supplying an excessive number of descriptors, leading to a buffer overrun. This can cause a system crash, resulting in a Denial of Service (DoS).

Official announcement: Please refer to the link for details –

https://nvd.nist.gov/vuln/detail/cve-2026-5164

Preface: NVIDIA NeMo is a widely adopted, end-to-end framework for building, customizing, and deploying generative AI models (LLMs) and conversational AI agents. It is primarily used to tailor open-source models—such as Llama, Mistral, and Google Gemma—using proprietary enterprise data.

Ollama, Mistral, and Google Gemma represent a powerful ecosystem for running local, open-weight Large Language Models (LLMs). Ollama acts as the engine to run models, while Mistral and Gemma are two of the most popular, high-performing model families designed to be efficient enough to run on personal computers.

Background: Regarding the restore_from() method, it is a core functionality used to load local checkpoint files with the .nemo extension.

Key Details of restore_from() –

• Purpose: Fully restores a model instance, including its weights and configuration, from a local [.]nemo file for evaluation, inference, or fine-tuning.
• File Structure: A [.]nemo file is an archive (specifically a tar.gz file) containing the model’s weights and a model_config[.]yaml file that defines its architecture.
• Usage: It is called directly from the model’s base class (e.g., ASRModel[.]restore_from(restore_path="path/to/file[.]nemo")).

Vulnerability details: (see below)

CVE-2026-24157 NVIDIA NeMo Framework contains a vulnerability in checkpoint loading where an attacker could cause remote code execution. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure and data tampering.

CVE-2026-24159 NVIDIA NeMo Framework contains a vulnerability where an attacker may 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/5800

Preface: A design limitation has been discovered in the ONNX quantization function of the NVIDIA model optimizer for Windows and Linux. However, confusingly, the ONXY function appears to only work on Windows/RTX (not Linux). What is the actual design limitation?

A sophisticated technical question. The confusion often stems from the fact that while ONNX is the primary deployment format for Windows/RTX, the quantization process (where the vulnerability often lies) frequently occurs on Linux development servers.

Background: Why does the vulnerability affect both Linux and Windows?

Although ONNX is the target format for Windows AI PC applications, the NVIDIA Model Optimizer (ModelOpt) library is cross-platform.

*Linux as the “Factory”: Most developers use powerful Linux servers (with A100/H100 GPUs) to run the ModelOpt quantization scripts. They generate the optimized ONNX model on Linux and then “ship” it to Windows clients. Therefore, the vulnerability exists in the Linux-based conversion tools.

Vulnerability details: NVIDIA Model Optimizer for Windows and Linux contains a vulnerability in the ONNX quantization feature, where a user could cause unsafe deserialization by providing a specially crafted input file. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. (Initial release – March 24, 2026)

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

Preface: The core design goal of NVIDIA Apex is to achieve mixed precision training, which mainly involves a combination of **16-bit (FP16)** and **32-bit (FP32)**.

Background: In NVIDIA APEX, handling FP16 and FP32 data is primarily managed through the Automatic Mixed Precision (AMP) module. You don’t need to manually cast your data.

• Use FP32 if you are doing scientific simulations that require extreme precision or if your model fails to converge using lower bit-depths.
• Use FP16 for Inference (running a finished model on a phone or server) or when training Large Language Models (LLMs) to save massive amounts of time and electricity.

Current Gold Standard is FP16; balances speed and memory.

Scientific simulations (such as those simulating black holes or aircraft airflow) require extremely high numerical stability to prevent errors from accumulating over time; while LLM training is more like finding a probability distribution of the “general direction,” where speed and model size are more important than accuracy to the 15th decimal place.

Vulnerability details: NVIDIA APEX for Linux contains a vulnerability where an unauthorized attacker could cause a deserialization of untrusted data. This vulnerability affects environments that use PyTorch versions earlier than 2.6. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, data tampering, and information disclosure.

Official announcement: Please refer to the link for details –

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

Best Practices:

•Weight Files: Always convert and store your .pth or .bin files as .safetensors.

•API Inputs: Prefer Protocol Buffers (Protobuf) or JSON for real-time requests.

•Integrity Checks: Before deserializing, verify the file’s SHA-256 hash to ensure it hasn’t been tampered with during transit