Category Archives: Potential Risk of CVE

CVE-2025-55780: AI LLM developers should not underestimate Mupdf design flaw! (29-09-2025)

Preface: LLMs are built on machine learning: specifically, a type of neural network called a transformer model. How do LLMs read PDFs? The first step was to extract the text blocks from the PDF using pdfplumber . Each text block came with its coordinates, which allowed to analyze their spatial relationships. Next, I created a “window” around each text block to capture its surrounding context. 

Background: MuPDF is not widely known by consumers as a popular standalone application, but it is popular and growing in popularity among developers, particularly those working with Large Language Models (LLMs) and Retrieval-Augmented Generation (RAG) systems, due to its powerful and lightweight nature.

Large Language Models (LLMs) do not directly “read” PDF files in their native binary format. Instead, they interact with the extracted content of the PDF. MuPDF, through its Python binding PyMuPDF (or its specialized variant PyMuPDF4LLM), plays a crucial role in this process by enabling efficient and accurate extraction of information from PDFs.

Vulnerability details: A null pointer dereference occurs in the function break_word_for_overflow_wrap() in MuPDF 1.26.4 when rendering a malformed EPUB document. Specifically, the function calls fz_html_split_flow() to split a FLOW_WORD node, but does not check if node->next is valid before accessing node->next->overflow_wrap, resulting in a crash if the split fails or returns a partial node chain.

Official announcement: For more details, see the link

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

CVE-2025-23348 and CVE-2025-23349: About NVIDIA Megatron-LM (26-09-2025)

Preface: For years, OpenAI’s GPT series has been a dominant force, while NVIDIA’s Megatron-LM has provided a powerful framework for training these massive models.

NVIDIA Megatron-LM faces competition from several other frameworks especially Microsoft DeepSpeed, Hugging Face Accelerate, JAX/Flax and PyTorch Lightning.

Both PyTorch Lightning and NVIDIA Megatron-LM are built on top of the PyTorch library. PyTorch provides the fundamental tensor operations and deep learning primitives, while these frameworks add abstractions and tools for more efficient and scalable model development and training.

Background: The full GPT pre-training process:

A script such as pretrain_gpt[.]py orchestrates the following major steps to train the model from scratch on billions of parameters and terabytes of data. This structure contains four steps:

  1. Data preparation
  2. Distributed setup
  3. Core training loop
  4. Model saving and evaluation

The design objective of a script like orqa/unsupervised/nq.py is to prepare the GPT model for open-domain question answering (QA), a task that is not typically a part of standard, large-scale unsupervised pre-training. The script specifically uses the Natural Questions (NQ) dataset to enhance the model’s ability to retrieve information from a large corpus of documents and generate answers, all without the direct use of a labeled QA dataset for this step.

Vulnerability details:

CVE-2025-23348: NVIDIA Megatron-LM for all platforms contains a vulnerability in the pretrain_gpt script, where malicious data created by an attacker may cause a code injection issue. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering.

CVE-2025-23349: NVIDIA Megatron-LM for all platforms contains a vulnerability in the tasks/orqa/unsupervised/nq.py component, where an attacker may cause a code injection. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering.

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

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

Chypnosis on FPGAs – AMD is investigating whether on specific devices and components are affected and plans to provide updates as new findings emerge.(22nd Sep 2025)

Preface: AMD uses FPGAs (Field-Programmable Gate Arrays) in High-Performance Computing (HPC) by offering accelerator cards and adaptive SoCs that allow users to program custom hardware for HPC workloads in fields like machine learning, data analytics, and scientific simulations.

AMD manufactures FPGA-based accelerator cards that enable users to program applications directly onto the FPGA, eliminating the lengthy card design process. These cards install as-is in servers, accelerating workloads in financial computing, machine learning, computational storage, and data analytics.

Background: The XADC is an integrated, on-chip block within certain AMD (formerly Xilinx) FPGAs that performs analog-to-digital conversion (ADC) and also includes on-chip sensors for voltage and temperature monitoring. The FPGA provides the programmable logic to process the digitized data from the XADC, use it for control, or access it through the FPGA’s interconnects like the Dynamic Reconfiguration Port (DRP) or JTAG interface.

Xilinx ADCs (XADCs), particularly flash ADCs, have disadvantages related to high power consumption, large physical size, and limited resolution due to the large number of comparators required for higher bit depth. Non-linearity can also introduce signal distortion and measurement errors, while the integration of ADCs directly into FPGAs may not be feasible for all applications due to the required external components.

Security Focus of an Academic Research Paper: Attacks on the Programmable Logic (PL) in AMD Artix™ 7 Series FPGA Devices.

Artix 7 FPGAs and Artix™ UltraScale+ difference – Key Differences at a Glance:

The main difference is that Artix™ UltraScale+ FPGAs are a newer, higher-performance family built on a 16nm FinFET process, offering improved power efficiency, higher transceiver speeds, and more advanced features like enhanced DSP blocks and hardened memory, while the Artix 7 FPGAs are older devices built on a 28nm process. UltraScale+ also features ASIC-class clocking, supports faster memory interfaces like LPDDR4x and DDR4, and includes advanced security features.

Vulnerability details: The academic research paper introducing the new approach demonstrates the attack on the programmable logic (PL) in AMD Artix™ 7-Series FPGA devices. It shows that the on-chip XADC-based voltage monitor is too slow to detect and/or execute a tamper response to clear memory contents. Furthermore, they show that detection circuits that have been developed to detect clock freezing2 are ineffective as well. In general, the attack can be applied on all ICs that do not have effective tamper responses to clear sensitive data in case of an undervoltage event.

Official announcement: Please see the link for details –

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

CVE-2025-10585: Type Confusion in V8 (22nd Sep 2025)

Preface: Type confusion is a vulnerability where a program accesses a resource using an incompatible type, leading to unexpected behavior or memory corruption. This often occurs when a program misinterprets the type of data being used, potentially leading to the execution of the wrong code or the disclosure of sensitive information. This can happen due to issues with type casting, memory layout mismatches, or speculative execution, and it’s a common foundation for various software attacks.

Background: V8 is Google’s open source high-performance JavaScript and Web Assembly engine, written in C++. It is used in Chrome and in Node.js, among others. V8 provides the core JavaScript execution environment that Node.js is built upon. It allows Node.js to: Execute JavaScript code outside the browser.

V8 is Google’s high-performance JavaScript engine used in Chrome and Node.js. It compiles JavaScript directly into machine code, optimizing execution through techniques like just-in-time (JIT) compilation. V8 uses multiple tiers of compilers (Ignition, Sparkplug, Maglev, Turbofan) and an efficient garbage collector to manage memory. Its design prioritizes speed and efficiency, making it a key component in modern web development.

Vulnerability details: CVE-2025-10585: Type Confusion in V8. Reported by Google Threat Analysis Group on 2025-09-16. Google has patched the issue, but details are restricted to prevent further exploitation until most users have updated.

Official announcement: Please refer to the link for details

https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_17.html

CVE-2025-3231: About ARM Mali. Learn more about the details (19th Sep 2025)

NVD Published Date: 09/08/2025
NVD Last Modified: 09/08/2025

Preface: The Mali kernel driver and userspace libraries are found in different locations depending on whether the system is Android or a general Linux distribution, and also based on the specific Mali GPU generation and the SoC vendor’s implementation.

Background: Mali GPU is a hardware accelerator.

  • It does not run an OS itself.
  • It relies on kernel-space and user-space drivers (like the Mali kernel driver and userspace libraries) to interface with the operating system (Linux, Android, etc.).

ioctl (Input/Output Control) is the primary syscall used by userspace GPU drivers to communicate with the kernel-space driver. It allows sending custom commands and structured data to the driver.

Typical ioctl operations in Mali drivers include:

  • MALI_IOCTL_ALLOC_MEM: Allocate GPU-accessible memory
  • MALI_IOCTL_FREE_MEM: Free previously allocated memory
  • MALI_IOCTL_SUBMIT_JOB: Submit a GPU job (e.g., shader execution)
  • MALI_IOCTL_WAIT_JOB: Wait for job completion
  • MALI_IOCTL_MAP_MEM: Map memory to userspace

Vulnerability details: CVE-2025-3212 is a vulnerability in the kernel driver that interfaces with the Mali GPU. Here’s what that means:

  • The vulnerability is in software, not the hardware.
  • It allows a local non-privileged user to exploit the driver to access freed memory, which could contain sensitive data or allow privilege escalation.
  • The Mali GPU hardware itself is not “vulnerable” in the sense of having a flaw — but it becomes a vector for exploitation because of the flawed driver.

Official announcement: Please refer to the link for details – https://developer.arm.com/documentation/110627/1-0/

2025-23316 and CVE-2025-23268: About NVIDIA Triton Inference Server (18th Sep 2025)

Preface: AI deployment is accelerated by hardware advancements (especially GPUs), ML platforms and MLOps for automation, the use of pre-trained models via transfer learning, containerization and orchestration for scalability, cloud infrastructure providing on-demand resources, and industry collaborations and specialized data partners to streamline various stages of the AI lifecycle.

Background: NVIDIA Triton Inference Server is an open-source inference serving platform whose primary goal is to simplify and accelerate the deployment of AI models in production environments. It aims to provide a unified platform capable of serving models from various machine learning frameworks, such as TensorFlow, PyTorch, ONNX Runtime, and custom backends, enabling flexibility and interoperability.

The “model name” parameter in NVIDIA Triton Inference Server is a crucial identifier used to specify which model a client wishes to interact with for inference requests.

Client API Usage: When using Triton client libraries (e.g., tritonclient[.]grpc or tritonclient[.]http), the model_name parameter is typically a required argument in functions used to send inference requests.

Both backends (Python and DALI) are part of Triton’s modular architecture. The Python backend often acts as a wrapper or orchestrator for other backends, including DALI.

Vulnerability details:

CVE-2025-23316 NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability in the Python backend, where an attacker could cause a remote code execution by manipulating the model name parameter in the model control APIs. A successful exploit of this vulnerability might lead to remote code execution, denial of service, information disclosure, and data tampering.

CVE-2025-23268 VIDIA Triton Inference Server contains a vulnerability in the DALI backend where an attacker may cause an improper input validation issue. A successful exploit of this vulnerability may lead to code execution.

Official announcement: Please see the link for details –

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

CVE-2024-45434 was published on September 12, 2025. You may have heard about it in popular cybersecurity magazine back in July of this year. Let’s take a closer look at it today. (16-09-2025)

Preface: If an SDK contains a use-after-free (UAF) vulnerability, the consequences can range from minor data corruption and program crashes to severe security issues like arbitrary code execution, information leakage, and privilege escalation, as the vulnerability allows attackers to manipulate previously freed memory, leading to system instability or full compromise.

Background: Classic and Low Energy devices use different hardware and software stacks: Bluetooth® Classic devices can´t communicate with Bluetooth® Low Energy and vice versa.  As for some applications, the power consumption of Bluetooth® Classic is still too high.  The Bluetooth® SIG developed a standard lower power consumption to overcome this obstacle.

Vulnerability details: OpenSynergy BlueSDK (aka Blue SDK) through 6.x has a Use-After-Free. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of validating the existence of an object before performing operations on the object (aka use after free). An attacker can leverage this to achieve remote code execution in the context of a user account under which the Bluetooth process runs.

This vulnerability was part of a broader exploit chain called PerfektBlue, which affected millions of vehicles from:

  • Volkswagen (ICAS3)
  • Mercedes-Benz (NTG6)
  • Škoda (MIB3)
  • And an unnamed OEM

Attackers could:

  • Send crafted AVRCP packets post-pairing
  • Trigger the use-after-free
  • Overwrite function pointers
  • Achieve remote code execution (RCE) in the infotainment system

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2024-45434

A quick look at branch predictor isolation in KVM-QEMU

Preface: AMD SoCs can have KVM virtualization for embedded multicore systems, especially with ARM-based architectures, as KVM supports various architectures including ARM and has been adapted for embedded platforms. While KVM was initially designed for Intel and AMD x86 processors, its flexibility and portability allowed for ports to the ARM architecture, making it suitable for embedded multicore SoCs.

Ref: The AMD Zen5 branch predictor is a major update for the Zen family, featuring a new “two-ahead” design that allows it to predict up to two branches per clock cycle, a significant increase from the previous “one-ahead” limit.

Background: Any modern 64-bit AMD processor with AMD-V (SVM) virtualization support can utilize KVM-QEMU for virtualization, as KVM is integrated into the Linux kernel and requires only these hardware extensions for acceleration. To use KVM, you need to ensure AMD-V is enabled in your system’s firmware (BIOS/UEFI) and that your Linux distribution’s kernel and QEMU packages are installed and configured.

The branch predictor is a hardware component located within the processor that stores prediction data internally to improve performance by guessing the outcome of conditional branches.

It uses Branch History Buffers (BHT) and Branch Target Buffers (BTB) to keep track of past branch outcomes and the addresses of the branch targets, respectively, which are small, fast on-chip structures, not part of the main memory system.

Vulnerability details: Researchers from ETH Zurich discovered that incomplete isolation of the branch predictor state in AMD CPUs (Zen 1–5) allows a malicious guest VM to influence indirect branch prediction in the host, specifically in user-space components like QEMU.

The attack, named VMSCAPE, enables a guest VM to leak memory from the host QEMU process at a rate of 32 bytes/sec, including sensitive data like disk encryption keys.

Official announcement: For details, please refer to the link – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7046.html

Point of view – NVIDIA’s NVDebug tool, about CVE-2025-23342 and CVE-2025-23343.  (12th Sep 2025)

Preface: Debug logs may contain user IDs and passwords to provide diagnostic information for failed login attempts, authentication failures, or to trace user activity within an application, but this is a significant security risk and should be avoided. Security best practices dictate that sensitive information like passwords should never be logged in cleartext. Instead, logging should only include non-sensitive user identifiers to help with troubleshooting without exposing credentials

Background: NVIDIA’s NVDebug tool is part of the broader Nsight Systems tool suite and relies on the NVIDIA Data Center GPU Manager (DCGM) library, specifically utilizing it for data collection and diagnostics to assist in troubleshooting and monitoring NVIDIA GPUs.

  • NVDebug is a tool for debugging and profiling NVIDIA GPUs, particularly in data center environments.
  • DCGM is a library for managing and monitoring NVIDIA GPUs in clusters and data centers.

NVDebug uses the DCGM library to gather essential diagnostic data, logs, and health information from the GPUs, enabling detailed analysis of the system’s state and performance.

Vulnerability details:

CVE-2025-23342: The NVIDIA NVDebug tool contains a vulnerability that may allow an actor to gain access to a privileged account . A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure and data tampering.

CVE-2025-23343: The NVIDIA NVDebug tool contains a vulnerability that may allow an actor to write files to restricted components. A successful exploit of this vulnerability may lead to information disclosure, denial of service, and data tampering.

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

The incorrect authorization described in CVE-2025-23256 may be triggered or facilitated by the underlying flaw CVE-2025-38456. (11th Sep 2025)

Preface:

  • IPMI is a standardized interface for hardware management, operating via the Baseboard Management Controller (BMC).
  • It supports both in-band (local) and out-of-band (remote) access.
  • BlueField’s reliance on OpenIPMI and IPMItool makes it susceptible to kernel-level vulnerabilities.

Background: The Intelligent Platform Management Interface (IPMI) is a standard interface for hardware management used by system administrators to control the devices and monitor the sensors. For these, it is necessary the IPMI Controller called Baseboard Management Controller (BMC) and a manager software (for example, IPMItool). It provides an interface to manage IPMI functions in a local (in-band) or remote (out-of-band) system.

Vulnerability details:

This advisory explores a potential causal relationship between two recent vulnerabilities:

  • CVE-2025-23256 – A high-severity vulnerability in the NVIDIA BlueField DPU management interface, allowing local attackers to bypass authorization and modify configurations.

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

  • CVE-2025-38456 – A moderate-severity vulnerability in the Linux IPMI subsystem, involving memory corruption due to mishandled pointers in ipmi_create_user().

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

Recommendations

  1. Patch Kernel IPMI Subsystem: Ensure CVE-2025-38456 is mitigated in all systems running BlueField.
  2. Update BlueField Firmware: Apply NVIDIA’s latest firmware updates addressing CVE-2025-23256.
  3. Audit IPMI Access Controls: Review and restrict local access to /dev/ipmi0 and IPMItool.