Preface: QNX hypervisors are available in two variants: QNX Hypervisor and QNX Hypervisor for Safety.

The QNX Hypervisor variant (QH), which includes QNX Hypervisor 8.0, is not a safety-certified product. It must not be used in a safety-related production system.

If you are building a safety-related system, you must use the QNX Hypervisor for Safety (QHS) variant that has been built and approved for use in the type of system you are building, and you must use it only as specified in its Safety Manual. The latest QHS release is QNX Hypervisor for Safety 2.2, which is based on QNX SDP 7.1.

Background:  Functions like mprotect() are not commonly used in QNX hypervisor memory resource management for reasons:

1. Memory Isolation: The hypervisor ensures that each VM (both primary and guest) has its own isolated memory space. This prevents one VM from accessing the memory of another, enhancing security and stability.
2. Dynamic Memory Allocation: The hypervisor can dynamically allocate memory to VMs based on their needs. This means that if a guest VM requires more memory, the hypervisor can allocate additional memory from the available pool.
3. Memory Ballooning: This technique allows the hypervisor to reclaim unused memory from VMs and reallocate it where needed. The balloon driver within the VM inflates to consume memory, which is then returned to the hypervisor.
4. Memory Hotplug: The hypervisor can add or remove memory from a VM while it is running. This allows for flexible memory management without needing to restart the VM.

Vulnerability details: Memory corruption may occur during communication between primary and guest VM.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2024-53022

Preface: Many programmers continue to use Arm Compiler 5 for several reasons:

Developers who have been using Arm Compiler 5 for years are familiar with its quirks and features, making it easier for them to continue using it rather than learning a new toolchain.

Furthermore, Arm Compiler 5 supports older ARM architectures that may not be fully supported by newer compilers.

Background: When compiling ARM code with stack protection, the –protect_stack option is used to safeguard against stack buffer overflows and potential malicious tampering. Here are the conditions under which a function is considered vulnerable and thus protected:

1. Arm Compiler 5:
   A function is considered vulnerable if it contains a char or wchar_t array of any size1.
2. Arm Compiler 6:
   With -fstack-protector, a function is considered vulnerable if it contains:
   -A character array larger than 8 bytes.
   -An 8-bit integer array larger than 8 bytes.
   -A call to alloca() with either a variable size or a constant size bigger than 8 bytes1.
   With -fstack-protector-strong, a function is considered vulnerable if it contains:
   -An array of any size and type.
   -A call to alloca().
   -A local variable that has its address taken1.

Using these options helps improve the overall security and integrity of your code by preventing stack buffer overflows

Vulnerability details: In certain circumstances the stack protection feature can be rendered ineffective, leaving the protected function vulnerable to stack-based buffer overflows.

An undetected stack overflow can lead to a function return address being overwritten, potentially causing a crash or hang or allowing an attacker to gain control over program execution.

Official announcement: Please refer to the vendor announcement for detail – https://developer.arm.com/documentation/110262/1-1/?lang=en

Preface: Use-after-free (UAF) vulnerabilities are a class of software flaws that involve using a memory resident object after it has been freed. UAF vulnerabilities most commonly occur when a C++ object that was allocated on the heap is accessed after it is deleted, but stack-allocated objects can also be used after a free.

Background: The Robot Operating System (ROS) is a set of software libraries and tools for building robot applications. From drivers and state-of-the-art algorithms to powerful developer tools, ROS has the open source tools you need for your next robotics project.

Since ROS was started in 2007, a lot has changed in the robotics and ROS community. The goal of the ROS 2 project is to adapt to these changes, leveraging what is great about ROS 1 and improving what isn’t.

The base unit in ROS is called a node. Nodes are in charge of handling devices or computing algorithms – each node for a separate task. Nodes can communicate with each other using topics or services. ROS software is distributed in packages. A single package is usually developed for performing one type of task and can contain one or multiple nodes.

Vulnerability details: Open Robotics Robotic Operating System 2 (ROS2) and Nav2 humble versions were discovered to contain a use-after-free via the nav2_amcl process. This vulnerability is triggerd via remotely sending a request for change the value of dynamic-parameter`/amcl max_beams` .

Official announcement: Please see the link below for details –

https://nvd.nist.gov/vuln/detail/CVE-2024-38920

Preface: Android Auto is a platform running on the user’s phone, projecting the Android Auto user experience to a compatible in-vehicle infotainment system over a USB connection. Android Auto supports apps designed for in-vehicle use.

Background: The Android for Cars App Library lets you bring your navigation, point of interest (POI), and internet of things (IOT) apps to the car.

Android[.]car[.]app

Interfaces

OnDoneCallback – A host-side interface for handling success and failure scenarios on calls to the client.

OnRequestPermissionsListener – A listener with the results from a permissions request.

OnScreenResultListener – A listener to provide the result set by a Screen.

SurfaceCallback – A callback for changes on the SurfaceContainer and its attributes.

Vulnerability details: There exists a code execution vulnerability in the Car App Android Jetpack Library. In the CarAppService desrialization logic is used that allows for arbitrary java classes to be constructed. In combination with other gadgets, this can lead to arbitrary code execution. An attacker needs to have an app on a victims Android device that uses the CarAppService Class and the victim would need to install a malicious app alongside it. We recommend upgrading the library past version 1.7.0-beta02

Official announcement: Please see the link below for details – https://nvd.nist.gov/vuln/detail/cve-2024-10382

Preface: The Cortex-M3 processor is specifically developed for high-performance, low-cost platforms for a broad range of devices including microcontrollers, automotive body systems, industrial control systems and wireless networking and sensors.

Background: SCP Firmware provides a software reference implementation for the System Control Processor (SCP) and Manageability Control Processor (MCP) components found in several Arm Compute Sub-Systems. Functionality.

Description. Initialization. Initialization of the system to enable application core boot.

Power Control System Architecture (PCSA) defines the concept of a System Control Processor (SCP), a specialized processor that abstracts power and system management tasks from the application processor.

Vulnerability details: The transport_message_handler function in SCP-Firmware release versions 2.11.0-2.15.0 does not properly handle errors, potentially allowing an Application Processor (AP) to cause a buffer overflow in System Control Processor (SCP) firmware.

Official announcement: For detail, please refer to link –

https://nvd.nist.gov/vuln/detail/CVE-2024-9413

Preface: The Cortex-M stands for the Microcontroller which is used in most of our daily life applications also starting from the automation to DSP applications, sensors, smart displays, IoT applications ,etc.

Background: In April of 2024, Arm Limited published a Cortex-M Security Extensions (CMSE) Security Bulletin that identifies a potential software security issue in code that uses CMSE. The security vulnerability allows an attacker to pass out-of-range values to code executing in Secure state to cause incorrect operation in Secure state. This security vulnerability is present in compilers that are not compliant with version 1.4 of the Arm v8-M Security Extensions Requirements on Development Tools.

Vulnerability details: When using Arm Cortex-M Security Extensions (CMSE), Secure stack contents can be leaked to Non-secure state via floating-point registers when a Secure to Non-secure function call is made that returns a floating-point value and when this is the first use of floating-point since entering Secure state. This allows an attacker to read a limited quantity of Secure stack contents with an impact on confidentiality. This issue is specific to code generated using LLVM-based compilers.

LLVM and the GNU Compiler Collection (GCC) are both compilers. The difference is that GCC supports a number of programming languages while LLVM isn’t a compiler for any given language. LLVM is a framework to generate object code from any kind of source code.

Official announcement: For more information about the vulnerability, please see the link –

https://nvd.nist.gov/vuln/detail/CVE-2024-7883

https://developer.arm.com/Arm%20Security%20Center/Cortex-M%20Security%20Extensions%20Vulnerability

Preface: What is an MF4/MDF4 file? Measurement Data Format version 4 (MDF 4) is a standard file format by ASAM used by the automotive industry for storing measurement data in binary file format. It records CAN, CAN FD, LIN bus data, sensor data from an engine control unit (ECU), offering interoperability across many CAN tools.

Background: MF4 (aka MDF or Measurement Data Format) is a popular CAN bus log file format. It was designed for use in the automotive industry, primarily for the areas of ECU development, Calibration and testing.

What is ECU development? The development of an ECU involves both hardware and software required to perform the functions expected from that particular module. Automotive ECU’s are being developed following the V-model.

Can I use the MDF-LIB freely? Yes, the lib was created to encourage all software developers to use the MDF4 format.

Vulnerability details: Library MDF (mdflib) v2.1 is vulnerable to a heap-based buffer overread via a crafted mdf4 file is parsed using the ReadData function.

Official announcement: Please refer to the vendor announcement for details – https://nvd.nist.gov/vuln/detail/CVE-2024-41445