CVE-2026-42804 in BHI360 SensorAPI
Summary
by MITRE • 09/10/2026
A stack-based buffer overflow vulnerability exists in the Bosch Sensortec BHI360 SensorAPI(C-Library) in versions up to and including commit d6b200416a.
The vulnerability is located within the FIFO parsing and debug logging subsystem inside the function bhi360_parse_debug_message() in bhi360_parse.c (lines 1852-1875).
The parser trusts the first payload byte of a debug frame as the message length (msg_length) and copies that many bytes into a fixed-size 17-byte stack buffer (debug_msg) via memcpy without performing any bounds checking.
A locally or physically positioned attacker (e.g., via a malicious sensor, counterfeit hardware module, or a Man-in-the-Middle on the communication bus) can exploit this vulnerability by injecting a crafted debug frame with a length byte exceeding 16.
This corrupts adjacent stack data, including the saved return address.
Furthermore, because the overflowed buffer is subsequently passed to a printf-style logging sink, the attacker can supply format string specifiers (e.g., %n) to execute arbitrary code on the host microcontroller/SoC or cause a reliable system crash (Denial of Service).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The Bosch Sensortec BHI360 SensorAPI C-Library contains a critical stack-based buffer overflow vulnerability within its FIFO parsing and debug logging subsystem. This flaw is specifically located in the bhi360_parse_debug_message function found in the source file bhi360_parse.c, affecting versions up to and including commit d6b200416a. The core technical deficiency lies in how the parser handles incoming debug frames from connected sensors or hardware modules. When a debug frame is received, the system extracts the first payload byte, interpreting it as the message length variable named msg_length. This value is then used directly to determine the number of bytes to copy into a fixed-size stack buffer called debug_msg, which has a capacity of only 17 bytes. The operation utilizes memcpy without any prior validation or bounds checking against the actual size of the destination buffer. Consequently, if an attacker provides a crafted input where the length byte exceeds sixteen, the copy operation writes beyond the allocated memory space on the stack, corrupting adjacent data structures including the saved return address and potentially other critical context information stored in that frame.
From a threat modeling perspective, this vulnerability requires local or physical access to exploit effectively. An attacker positioned as a malicious sensor device, counterfeit hardware module, or through a Man-in-the-Middle attack on the communication bus connecting the host microcontroller or System-on-Chip (SoC) can inject specially crafted debug frames. By manipulating the length field in these frames, the adversary triggers the buffer overflow condition. The immediate operational impact of this memory corruption is severe, as it allows for arbitrary code execution by overwriting control flow data such as return addresses with shellcode pointers or gadget chains. Furthermore, even if direct code execution is mitigated by stack protection mechanisms like canaries or non-executable stacks, the vulnerability remains dangerous due to its interaction with subsequent logging functions. The overflowed buffer containing attacker-controlled data is passed directly into a printf-style logging sink. This secondary flaw enables format string attacks where specifiers such as %n are used to write arbitrary values to memory addresses or read sensitive information from the stack, leading to reliable system crashes and Denial of Service conditions that disrupt normal device operations.
This vulnerability aligns with Common Weakness Enumeration (CWE) identifiers including CWE-121 Stack-based Buffer Overflow for the initial memory corruption issue and CWE-134 Use of Externally-Controlled Format String for the exploitation via printf-style sinks. In terms of adversary tactics, this exploit path corresponds to ATT&CK techniques related to Command and Control or Execution on embedded platforms, specifically leveraging physical access vectors such as Hardware Injection or Peripheral Device Compromise. The lack of input validation represents a fundamental failure in secure coding practices common in low-level firmware development where performance is often prioritized over safety checks.
To mitigate this vulnerability, developers must implement strict bounds checking before performing any memory copy operations involving external inputs. Specifically, the msg_length value extracted from debug frames should be validated against the maximum size of the destination buffer minus one to account for null terminators if applicable. Additionally, replacing printf-style logging functions with safer alternatives that do not interpret user-controlled data as format strings is essential to prevent secondary exploitation vectors like format string attacks. Updating the SensorAPI library to a version released after commit d6b200416a where these fixes are presumably applied is the primary remediation step for end users. For system architects, enforcing hardware-level protections such as Memory Protection Units (MPUs) can help contain the impact of stack overflows by preventing access to unauthorized memory regions, although this does not replace the need for proper input validation in software logic.