What the developer wrote
Authored by benma's agent
da14531: avoid unaligned u16 loads
The serial-link frame buffer is byte-addressed. Casting &frame[1] /
&frame[3+len] to a uint16_t* can be unaligned, which is undefined
behavior in C.
What changed, and why it matters
This commit fixes a low-level coding issue in the firmware that talks to a Bluetooth chip (DA14531). The code was reading 2-byte numbers from positions in a byte buffer that might not be properly aligned in memory, which is undefined behavior in C. The fix uses memcpy instead of direct pointer casts, which is safe regardless of alignment. On its own this is a robustness/correctness fix; there is no direct evidence in the commit that it is exploitable as a security vulnerability.
Treat as a code-quality and hardening improvement. Include in routine firmware release notes as a robustness fix. No urgent security response is warranted unless additional analysis shows the unaligned access can be triggered reliably and weaponized to affect firmware loading or chip communication.
Security signals we found
Undefined behavior due to unaligned uint16_t pointer casts in a serial protocol parser
Memory-safety hardening in firmware communication path with external radio chip
Use of memcpy for safe unaligned multi-byte reads
Evidence from the diff
In src/da14531/da14531_protocol.c, two uint16_t reads from arbitrary byte offsets in self->frame were performed via casts such as ((uint16_t)&self->frame[1]) and (uint16_t)&self->frame[3 + len]. Because frame is a byte-addressed buffer, those offsets are not guaranteed to be 2-byte aligned, producing undefined behavior under the C standard and potential unaligned-access faults or inconsistent behavior on ARM Cortex-M. The patch replaces the casts with memcpy into local uint16_t variables, which is the standard portable idiom for unaligned multi-byte loads. The CRC and length parsing logic is otherwise unchanged.
Changed components
src/da14531/da14531_protocol.cDA14531 serial-link frame parserBitBox02 firmware Bluetooth/radio loader interfaceInspect captured patch +5 / −2
diff --git a/src/da14531/da14531_protocol.c b/src/da14531/da14531_protocol.c
index 86fb193..4cc2287 100644
--- a/src/da14531/da14531_protocol.c
+++ b/src/da14531/da14531_protocol.c
@@ -17,6 +17,7 @@
#include <stdbool.h>
#include <stdint.h>
+#include <string.h>
enum firmware_loader_state {
FIRMWARE_LOADER_STATE_IDLE,
@@ -286,7 +287,8 @@ static struct da14531_protocol_frame* _serial_link_in_poll(
}
// bytes with index 1-2 are the length
- uint16_t len = *((uint16_t*)&self->frame[1]);
+ uint16_t len;
+ memcpy(&len, &self->frame[1], sizeof(len));
if (len > self->frame_len - 5) {
util_log("da14531: ERROR, invalid len %d, dropped frame", len);
@@ -301,7 +303,8 @@ static struct da14531_protocol_frame* _serial_link_in_poll(
// CRC in frame
// bytes with index n-2 and n-1 are the crc
- uint16_t crc_frame = *(uint16_t*)&self->frame[3 + len];
+ uint16_t crc_frame;
+ memcpy(&crc_frame, &self->frame[3 + len], sizeof(crc_frame));
// Recalculate CRC
uint16_t crc = rust_da14531_crc(rust_util_bytes(&self->frame[0], 3 + len));
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.