Potential Risk of CVE, Under our observation

About CVE-2025-47365: Qualcomm integrated with automotive platform (7th Nov 2025)

Leave a comment
Published: 11/03/2025

Preface: GM’s Ultra Cruise system is supposed to be a more capable iteration of its Super Cruise ADAS that was first introduced in 2017.

To dig into the weeds a bit, the Ultra Cruise compute, which is about the size of two laptops stacked together, is made up of two Snapdragon SA8540P SoCs and one SA9000P AI accelerator to deliver low-latency control functions on 16-core CPUs and AI compute of more than 300 Tera operations per second for camera, radar and lidar processing.

Background: The Snapdragon Ride Platform accelerates the shift to software-defined vehicles by empowering developers to create AI-driven automated driving solutions. The system-on-chip, called Snapdragon Ride Platform, was developed for advanced driver assistance systems (ADAS) and automated driving. It’s one of a suite of cloud-connected platforms introduced by Qualcomm.

The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P – part of Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for the purpose of efficiently running Artificial Intelligence (AI) Deep Learning inference workloads. They are AI accelerators.

Qualcomm’s Snapdragon SA8540P SoCs and SA9000P AI accelerator use the QNX Neutrino RTOS for safety-critical functions in automated driving systems.

Vulnerability details: Integer Overflow or Wraparound in Automotive Platform

Description – Memory corruption while processing large input data from a remote source via a communication interface.

Official announcement: Please refer to link for details –

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

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

Science

Worth considering: The orbital plane of 3I/ATLAS is unusually precise with the Sun. (3rd Nov 2025)

Leave a comment

Worth considering: The orbital plane of 3I/ATLAS is unusually precise with the Sun.

Preface: Researchers at the University of California, Riverside conducted an experiment that found that if a terrestrial planet existed between Mars and Jupiter, it could push Earth out of the solar system and destroy life on it.

Ref: The full research paper was published in the February 28, 2022 issue of The Planetary Science Journal (PSJ); the title is: The Dynamical Consequences of a Super-Earth in the Solar System

https://iopscience.iop.org/article/10.3847/PSJ/acbb6b/epub

Point of view: The orbit of 3I/ATLAS passthrough MARS and Jupiter.  This is the topic if we are interested to worth? Because the asteroid belt is a region of space between the orbits of Mars and Jupiter where most of the asteroids in our Solar System are found orbiting the Sun.

Between Mars and Jupiter lies the main asteroid belt, a dense region of millions of rocky and metallic asteroids that orbit the Sun but cannot form planets. This region marks the boundary between the rocky planets of the inner solar system and the gas giants of the outer solar system. The asteroid belt is very sparse, and spacecraft can easily pass through it; the largest object in it is the dwarf planet Ceres.

Ceres is a dwarf planet in the main asteroid belt between Mars and Jupiter, discovered in 1801 by Giuseppe Piazzi. It is the largest object in the belt, composed of rock and ice, and was the first dwarf planet to be visited by a spacecraft (NASA’s Dawn mission). Evidence suggests that Ceres is a geologically active world, possibly containing an underground salty ocean, and may have once been able to support microbial life.

Do you think 3I/ATLAS is an advanced civilization probe? It came to our solar system to understand who we are. First, it wants to understand our solar system, especially the asteroid belt between Mars and Jupiter?

Professor Loeb provides the latest developments in 3I/Atlas –

https://avi-loeb.medium.com/gravitational-lensing-of-3i-atlas-by-the-sun-f4ca18720d65

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

IoT, Under our observation

In-depth discussion of the basic knowledge of CAN BUS preventive control (30th Oct 2025)

Leave a comment

Preface: Is the CAN bus still in use? While the CAN protocol was originally designed for road vehicles and is still primarily used there, the vehicle bus format has found its way into aircraft, aerospace, and rail systems.

Background: CAN bus significantly reduces traditional cable connections by allowing multiple electronic control units (ECUs) to communicate over a single two-wire bus, which simplifies wiring, lowers costs, and reduces weight. This is a major advantage over traditional systems that require a separate, complex harness for each connection.

Manufacturer concerned about the security of externally accessible CAN (Controller Area Network) wires. Physical access to the CAN bus can indeed allow malicious actors to inject crafted messages, potentially controlling critical vehicle functions like remote start, door locks, or even braking systems.

Preventative Procedures Against CAN Injection via Physical Access: While physical access is hard to prevent entirely, several defensive measures can be implemented to mitigate the risk:

1. Network Segmentation – Description: Separate critical ECUs (Electronic Control Units) from non-critical ones using gateways.

Benefit: Limits access to sensitive systems even if an attacker gains access to one part of the network.

2. Message Authentication – Description: Use cryptographic methods to authenticate CAN messages.

Benefit: Prevents unauthorized messages from being accepted by ECUs.

Challenge: Standard CAN protocol lacks built-in support for encryption or authentication, so this requires custom implementation or use of CAN-FD with added security layers.

3. Intrusion Detection Systems (IDS) – Description: Monitor CAN traffic for anomalies or unauthorized message patterns.

Benefit: Detects and alerts on suspicious activity.

Example: Detecting messages with unexpected arbitration IDs or unusual frequency.

4. Physical Security – Description: Secure access to OBD-II ports and other external CAN access points.

Benefit: Prevents unauthorized physical connection to the CAN bus.

5. Rate Limiting and Filtering – Description: Limit the rate of messages and filter based on known-good IDs.

Benefit: Reduces the impact of flooding or spoofing attacks.

Perhaps an effective preventive measure is to install a filter. See the attached diagram for details.

Reference:

Similar vulnerabilities in the automotive industry can be found here. Please refer to the link – https://nvd.nist.gov/vuln/detail/CVE-2025-6785

Under our observation

About Bouncy Castle cryptography – CVE‐2025‐12194: The real fix is reachability fencing, which ensures timely resource disposal regardless of thread type. (28-10-2025)

Leave a comment

Published: 2025-10-24

Preface: The Australian government has utilized Bouncy Castle cryptography APIs. Specifically, the Australian Government’s AUSKey project, which was a system for securely accessing government online services, used the Bouncy Castle libraries as its basis for Java cryptography.

Bouncy Castle is a widely-used open-source cryptographic API available for Java and C#, developed and maintained by the Legion of the Bouncy Castle Inc., a registered Australian charitable organization. It is known for its FIPS-certified modules, which meet a recognized government standard for cryptographic modules.

Background: The objective of the Bouncy Castle cryptography project is to provide a comprehensive set of open-source APIs for Java and C# that implement cryptographic algorithms and protocols to build secure applications. It aims to offer a wide range of security features, including those for public key infrastructure, digital signatures, authentication, secure communication, and FIPS-certified cryptographic modules for applications requiring a high level of compliance. 

While the javax.crypto.Cipher class and the JCA/JCE frameworks provide the core for cryptographic operations in Java, the Bouncy Castle cryptography library is often needed for below reasons: 

Extended Algorithm Support: Bouncy Castle offers a broader range of cryptographic algorithms and modes compared to the default JCE providers, including advanced algorithms like elliptic curve cryptography (ECC) which may not be fully or natively supported by the standard JCE.

Implementation of Emerging Standards: Bouncy Castle frequently incorporates implementations of newer cryptographic standards and protocols before they are fully integrated into the standard JCE, allowing developers to utilize cutting-edge security features.

CVE details: Further issues have shown up in high-core environments with Java 21 and BC-FJA 2.1.1. It appears under very high loads the scheduling of the disposal thread is such that it only gets called rarely, or at least not soon enough. The issue has been fixed by introducing the use of reachability-fencing. This available in Java 9 and later, so Java 8 is still using the disposal daemon as before has been changed to reduce friction (synchronized has been introduced where some friction is still required). A new property has also been added “org.bouncycastle.native.cleanup_priority” which can be set to “min”, “normal”, or “high” (default “min”) in case disposal thread scheduling will be beneficial for Java 8 as well.

Official announcement: Please see the link for details –

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

https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%9012194

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

antihackingonline.com