Category Archives: Potential Risk of CVE

AI and ML, Potential Risk of CVE

Security Bulletin:  About NVIDIA RunAI – CVE-2025-33176 (6th Nov 2025)

Leave a comment

Preface: NVIDIA Run:ai is a Kubernetes-native platform for managing and optimizing AI workloads, acquired by NVIDIA in 2024. It provides dynamic orchestration for GPU resources, supporting flexible resource allocation to improve resource utilization and accelerate the AI ​​development lifecycle in hybrid, on-premises, and cloud environments. Prior to its acquisition by NVIDIA in December 2024, Run:ai was an Israeli software startup founded in 2018, focused on AI infrastructure management. Its core product is Kubernetes-based software for managing and optimizing GPU workloads for AI applications, helping enterprises utilize hardware more efficiently. The company’s software assists enterprises in managing GPU resources in on-premises, cloud, and hybrid environments. Run:ai does not “change its role in machine learning,” but rather focuses on the key challenges of AI workload management and GPU orchestration throughout the broader Machine Learning Operations (MLOps) lifecycle.

Background: NVIDIA Run:ai is a Kubernetes-based platform that acts as a GPU orchestrator to maximize the efficiency of AI and machine learning workloads. It addresses challenges like managing expensive GPU resources by enabling dynamic, policy-based scheduling, allowing for the sharing of GPUs across teams and projects, and optimizing workload performance for training, tuning, and inference. Run:ai integrates into existing hybrid or on-premises AI infrastructure to improve GPU utilization and accelerate AI development cycles.

NVIDIA DGX Cloud primarily leverages Kubernetes (K8s) for orchestrating and managing AI workloads.

While DGX systems historically used Docker for containerization, DGX Cloud, particularly for advanced AI workloads and resource management, relies on Kubernetes for its scalability, high-performance computing capabilities, and efficient GPU resource allocation. This is often integrated with other NVIDIA software like NVIDIA NeMo and NVIDIA Run:ai, and deployed on cloud services such as Amazon Elastic Kubernetes Service (Amazon EKS).

Vulnerability details: NVIDIA RunAI for all platforms contains a vulnerability where a user could cause an improper restriction of communications channels on an adjacent network. A successful exploit of this vulnerability might lead to 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/5719

IoT, Potential Risk of CVE

CVE-2025-47353: About Automotive Software platform based on QNX (5th Nov 2025)

Leave a comment

Preface: An automotive cockpit is the driver’s compartment, integrating all the controls and information displays needed to operate a vehicle, including the steering wheel, dashboard, instruments, and central displays.

Background: To install QNX on a Qualcomm SA8775P chip, you will need the specific QNX Board Support Package (BSP) for that platform, as it contains the necessary hardware-specific software to get the OS running. The installation process will involve loading the BSP onto the chip, which provides the essential startup code and device drivers needed to run QNX. Since this is an automotive-grade chip used for cockpit and driving functions, it’s likely an OEM or a specialized automotive development partner would be handling this process.

QNX handles guest virtual machine (GVM) memory by using a hypervisor to manage the host physical memory, which the guest sees as contiguous. The hypervisor allocates memory to a guest and uses services like “smmuman” to program the IOMMU/SMMU to protect the guest’s memory from the host and other guests. The hypervisor maps host physical memory to the guest’s guest-physical memory, and can use shared memory regions for efficient inter-VM communication.

Vulnerability details:

Title – Exposed Dangerous Method or Function in Automotive Software platform based on QNX

Description – Memory corruption while processing request sent from GVM.

Technology Area – Automotive Software platform based on QNX

Vulnerability Type – CWE-749: Exposed Dangerous Method or Function

Access Vector     Local

Security Rating   High

CVSS Rating        High

CVSS Score         7.8

Due to a lack of detailed supplier information, we discovered through observation that…

Attack Surface:

  • Shared memory + IPC exposed to guest.

Threats:

  • Buffer overflow → hypervisor memory corruption.
  • Capability spoofing → unauthorized access.

Mitigations:

  • Mediator validation.
  • Capability-based security.
  • Immutable protocol with checksum.

Official announcement: Please refer to the link for details –

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

Potential Risk of CVE

TEE.fail: Another perspective on how intercepting DDR5 memory bus can compromise a trusted execution environment. (4th Nov 2025)

Leave a comment

Preface: The recent research, released in a paper titled “TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition”, does not change Intel’s previous out of scope statement for these types of physical attacks.

Background: Intel SGX protects memory by creating encrypted “enclaves,” which are isolated, private regions within an application’s address space. These enclaves are stored in the Enclave Page Cache (EPC) within the processor’s reserved memory (PRM), and the CPU encrypts data as it is written to the EPC and decrypts it on the fly as it’s read from the CPU, preventing unauthorized access from even privileged software like the operating system or hypervisor.

When the CPU writes data to memory, the memory controller uses the plaintext and address as input to deterministically encrypt it. Writing the same plaintext to the same address will always produce the same ciphertext. Attackers cannot directly read a victim’s secret messages through aliasing mechanisms. However, a doctoral researcher at KU Leuven in Belgium claims it is possible to capture a victim’s ciphertext, and then the victim can simply replay the ciphertext at the same physical location to decrypt it into valid but outdated plaintext.

Ref: ACPI Machine Language (AML) is the platform independent code that ACPI utilizes. ASL is ACPI source language. It is a more human-readable form of the byte code that is AML.

For example the OS has a driver for an Embedded Controller device, and AML can actually talk to the OS driver. Or ACPI can reserve certain hardware resources, so that AML can use them directly, and the OS knows it is not allowed to use them.

Vulnerability details: Independent researchers have separately published methods to attack Intel® Software Guard Extensions (Intel® SGX) with a physical interposer device.

In the WireTap paper, researchers from Georgia Tech and Purdue University applied a passive interposer to read ciphertext memory of low entropy data to create a ciphertext-to-plain-text dictionary.

In the Battering RAM paper, researchers from KU Leuven and University of Birmingham developed a custom interposer to actively alias memory and gain arbitrary read/write access into Intel SGX-protected memory.​

Both research teams assume a physical adversary has direct access to the hardware with a memory bus interposer.

Official announcement: Please refer to the link for details – https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html

Network (Protocol, Topology & Standard), Potential Risk of CVE

CVE-2025-58185: improper handling of ASN.1 DER encoding (3rd Nov 2025)

Leave a comment

Preface: Is ASN-1 still in use? ASN-1 is used to define a large number of protocols. Its most widespread applications remain in telecommunications, cryptography, and biometrics.

ASN.1 is used in protocols like TLS and LDAP/Active Directory because it provides a language and platform independent way to define data structures, making it a standard for interoperability. Its encoding rules, such as Basic Encoding Rules (BER), offer a compact and efficient binary format for data transmission. Additionally, ASN.1 is used to formally define security standards, such as those in X.509 certificates, which are critical for establishing secure connections in TLS and authenticating users in LDAPIt often features in security vulnerabilities involving TLS and LDAP/Active Directory.

Background: ASN.1 (Abstract Syntax Notation dotone) is a standard for defining abstract data types and is used to describe data representation, transmission, and encoding.

ASN.1 includes data type definitions, data description syntax, encoding rules, etc. BER and DER are one type of encoding rule.

DER is a subset of BER, and it defines an encoding method that uses an octet string to represent any ASN.1 value. DER is used for applications that require encoding with a unique octet string, such as calculating digital signatures based on an ASN.1 encoding. DER is defined in Section 8.7 of X.509.

Vulnerability details: When parsing DER payloads, memories were being allocated prior to fully validating the payloads.
This permits an attacker to craft a big empty DER payload to cause memory exhaustion in functions such as asn1.Unmarshal, x509.ParseCertificateRequest, and ocsp.ParseResponse.

Official announcement: Please refer to the link for details –

https://www.tenable.com/cve/CVE-2025-58185

Potential Risk of CVE

About Chrome (V8 Bug 452296415 with CVE-2025-12036): updated to 141.0.7390.122/.123 for Windows and Mac and 141.0.7390.122 for Linux. (31-10-2025)

Leave a comment

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.

Details of the flaw:

  • Vulnerability: The flaw (CVE-2025-12036) is a memory-related weakness in the V8 JavaScript engine.
  • Exploitation: Attackers can exploit this by creating a crafted web page with malicious JavaScript to execute arbitrary code in the browser’s renderer process.
  • Impact: Successful exploitation can lead to data exposure, sandbox escape, or privilege escalation.
  • Affected versions: Any Chrome version on Windows, macOS, or Linux prior to 141.0.7390.122/.123 is vulnerable.
  • Patch status: Google has released an urgent update to address this issue.
  • CVSS Score: The vulnerability has a CVSS score of 7.5, indicating high severity

Official announcement: Please refer to the link for details –

https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_21.html

AI and ML, Application Development, Potential Risk of CVE, System

AMD ID: AMD-SB-7055RDSEED Failure on AMD “Zen 5” Processors(27th-10-2025)

Leave a comment

Preface: The main consequence of an RDSEED failure on AMD Zen 5 processors is instability, crashes, and potentially corrupted data, as this issue affects the processor’s ability to generate high-quality random numbers for cryptography and other sensitive tasks. This has led to the development of Linux kernel patches to temporarily disable RDSEED on affected Zen 5 CPUs until AMD provides a permanent hardware or firmware fix.

Background: RDSEED is a CPU instruction that provides high-entropy random numbers directly from a hardware entropy source, such as the Intel Digital Random Number Generator. It is designed to be used to seed other pseudo-random number generators (PRNGs) for cryptographic applications, ensuring a secure and unpredictable starting point.

RDSEED is a CPU instruction that provides high-entropy random numbers directly from a hardware entropy source, such as the Intel Digital Random Number Generator. It is designed to be used to seed other pseudo-random number generators (PRNGs) for cryptographic applications, ensuring a secure and unpredictable starting point.

Vulnerability Details: AMD was notified of a bug in “Zen 5” processors that may cause the RDSEED instruction to return 0 at a rate inconsistent with randomness while incorrectly signaling success (CF=1), indicating a potential misclassification of failure as success. This issue was initially reported publicly via the Linux kernel mailing list and was not submitted through AMD’s Coordinated Vulnerability Disclosure (CVD) process.

AMD has determined that the 16-bit and 32-bit forms of the RDSEED instruction on “Zen 5” processors are affected. The 64-bit form of RDSEED is not affected. AMD plans to release mitigations for this vulnerability.

Official announcement: Please refer to the link for details –

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

AI and ML, Potential Risk of CVE

Security Bulletin: NVIDIA ConnectX and BlueField (CVE‑2025-23299) – October 2025 (24th Oct 2025)

Leave a comment

Preface: Nvidia BlueField is a line of data processing units (DPUs) designed and produced by Nvidia. Initially developed by Mellanox Technologies. DOCA is a consistent and essential resource across all existing and future generations of BlueField DPU and SuperNIC products.

Background: The NVIDIA cloud-native supercomputing platform leverages the NVIDIA BlueField DPU architecture with high-speed, low-latency. The DPU enables native cloud services that let multiple users securely share resources without loss in application performance. HPC and AI communication frameworks and libraries play a critical role in determining application performance. Due to their latency and bandwidth-sensitive nature, offloading the libraries from the host CPU or GPU to the BlueField DPU creates the highest degree of overlap for parallel progression of communication and computation. DOCA is a consistent and essential resource across all existing and future generations of BlueField DPU and SuperNIC products.

DOCA BlueMan dashboard is the web-based interface for managing and monitoring an NVIDIA BlueField DPU (Data Processing Unit).

Vulnerability details: NVIDIA Bluefield and ConnectX contain a vulnerability in the management interface that may allow a malicious actor with high privilege access to execute arbitrary code.

Reference:

While Python itself is memory-safe, the real risk comes from:

  • YAML parsing libraries (like PyYAML) that allow arbitrary object deserialization.
  • C-based extensions or native bindings used by Python that may not enforce memory safety.
  • Improper validation of YAML configuration passed into privileged services like DTS.

Official announcement: Please see the link for details –

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

IoT, Potential Risk of CVE

CVE-2025-11678: About warmcat libwebsockets (Industrial network security – Are you worried about?) 23rd Oct 2025

Leave a comment

Published: 2025-10-20

Preface: Contribute Automation Expert is a software-centric industrial automation platform that is vendor-agnostic and based on the IEC 61499 standard. It is designed to make industrial automation more agile, efficient, and flexible by decoupling hardware and software, which allows for the use of components from different manufacturers and simplifies the process of updating and upgrading systems. 

Background: Libwebsockets is a C library that offers a high-performance, lightweight, and versatile way to handle WebSockets, HTTP, and other protocols. Libwebsockets is a strong contender for projects requiring low-level control and performance.

EcoStruxure Automation Expert Software dPAC is a state-of-the-art multi-platform IEC 61499-based control runtime that includes:

  • Event-based, network-transparent automation capability
  • Native process alarm support
  • Modbus/TCP client and server
  • OPC UA client and server b Ethernet/IP scanner
  • WebSocket server

Vulnerability details: Stack-based Buffer Overflow in lws_adns_parse_label in warmcat libwebsockets allows, when the LWS_WITH_SYS_ASYNC_DNS flag is enabled during compilation, to overflow the label_stack, when the attacker is able to sniff a DNS request in order to craft a response with a matching id containing a label longer than the maximum.

The CVE-2025-11678 vulnerability patch you referenced is in the async-dns-parse[.]c file of libwebsockets, which is a C library for WebSocket and related protocols.

Official details: Official documentation and vulnerability reports mention that EcoStruxure Automation Expert is an affected component for this CVE. Please refer to the link for details –

https://libwebsockets.org/git/libwebsockets/commit?id=2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a

https://www.tenable.com/cve/CVE-2025-11678

Application Development, Potential Risk of CVE

AMD response to research about Physical Address Bit Leakage on SEV-SNP Systems (22-10-2025)

Leave a comment

Official Revision Date: 20-10-2025

Preface: A 3rd Gen AMD EPYC processor uses an integrated memory controller within its System on a Chip (SoC) to connect to DDR4 DRAM modules, rather than having a separate memory controller component. The memory controller is part of the I/O Die (IOD) which is connected to the Core Complex Dies (CCDs) via the Infinity Fabric. Each processor has up to eight memory channels, each capable of supporting up to two DIMM slots, for a maximum of 4TB of memory per socket.

Background: The secure memory area for the RMP (Reverse Map Table) on a 3rd Gen AMD EPYC processor is a protected region within the DDR4 DRAM modules themselves, managed by the processor’s security features. It is not located inside the SoC but is in a secure area of the system’s main RAM, making it part of the dedicated system memory rather than the processor’s on-chip memory.

In a 3rd Gen AMD EPYC processor, the secure memory area for the Reverse Map Table (RMP) is a protected region within the DDR4 DRAM modules themselves, not a separate “hidden area” on the SoC. The secure memory is managed by the processor’s security features, such as the AMD Secure Processor (ASP), to protect the RMP and prevent attacks that could manipulate it.

Vulnerability details: Researchers reported a cache-based side-channel that could allow an unprivileged user process on AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) systems to leak up to six bits of physical address information. The researchers also noted that this leakage does not have an immediate security impact.

AMD has determined that the leakage results from Reverse Map Table (RMP) entries being cached in the L1D and L2 caches. Given that at most six physical address bits are exposed, AMD concurs with the researchers that this leakage does not have an immediate security impact.

Ref: In the absence of an immediate fix from AMD, the only way to reduce the risk of cache-based side-channel attacks in SEV-SNP environments is to follow secure memory handling and system-level best practices.

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

Application Development, Potential Risk of CVE

AMD response to research about ‘GhostFetch’ (21-10-2025)

Leave a comment

Official Revision Date: 17-10-2025

Preface: SEV-SNP is a security technology for confidential computing that encrypts virtual machine memory. SEV-SNP protects memory contents and integrity, and its security model does not depend on the cache indexing method.

Background: While SEV-SNP provides strong memory encryption and integrity protections, it does not offer built-in hardware protections specifically for PIPT cachesagainst all forms of side-channel attacks. However, AMD has introduced optional mitigations and best practices to reduce exposure:

  • SEV-SNP includes optional features to mitigate indirect branch predictor poisoning, which is a form of side-channel attack. This helps protect against speculative execution vulnerabilities like Spectre.
  • SEV-ES and SEV-SNP encrypt CPU register states during VM exits, preventing leakage of sensitive data through register inspection.
  • The Reverse Map Table (RMP) ensures that only the owner of a memory page can write to it. This prevents memory aliasing and replay attacks, which could otherwise be exploited via cache-based side channels.
  • SEV-SNP uses Page Validation to ensure that guest pages map to only one physical memory page at a time, reducing the risk of inconsistent memory views that could be exploited.

Vulnerability details: Researchers have shared with AMD a paper titled “GhostFetch: Uncovering and Exploiting the Physical-Address-Indexed Prefetcher to Break AMD SEV-SNP” which describes a prefetcher-based hardware side channel attack.

In their paper the researchers describe a method of using shared prefetcher state to determine whether the virtual address of a load matches the expected address, or whether a load access pattern matches an expected stride.  Either check requires multiple runs but potentially results in loss of confidentiality if the targeted code has either a secret dependent branch or a load access pattern that is secret dependent.

AMD’s response:

AMD believes that the researchers have not identified any AMD prefetchers that have not already been disclosed in the Software Optimization Guide and did not identify any new security implications with AMD prefetchers.

Official announcement: Please see the link for details –

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