CVE-2026-12520: Stack buffer overflow and off-by-one writes in Zephyr HL7800 modem AT response handlers
The Sierra Wireless HL7800 cellular modem driver (drivers/modem/vendorstandalone/hl7800.c, located at drivers/modem/hl7800.c in v4.4.0 and earlier) parses AT responses with roughly twenty handlers that call netbuflinearize(value, sizeof(value), buf, 0, len) into a 128-byte stack buffer and then write value[outlen] = 0. Because netbuflinearize() (lib/netbuf/buf.c) can return a count equal to its destination-length argument, a field that exactly fills the buffer makes the terminating NUL land one byte past the end, a single-byte out-of-bounds write into adjacent stack memory.
The +KCELLMEAS cell-measurement handler oncmdatcmdinforssi() is worse: it passed the wire length len as the destination size (netbuflinearize(value, len, buf, 0, len)), so a response line longer than 128 bytes overflows the value stack buffer with attacker-influenceable content. The line length comes from netbuffindcrlf(), which accumulates bytes across the whole netbuf fragment chain and is not bounded to 128, so an over-long line reaches the defect.
The data originates from the cellular modem over UART, driven by the network: operator-scan results, +CGCONTRDP IP/DNS info, socket indications, and +KCELLMEAS neighbour-cell reports. An attacker able to shape what the modem emits — a rogue base station, a compromised modem baseband, or a remote peer feeding oversized response framing — can drive a line past 128 bytes. The handlers run in the driver's RX thread in kernel context, so the corruption is kernel-side.
The +KCELLMEAS path is a full stack buffer overflow whose worst case is code execution in kernel context and whose floor is a reliable crash; the remaining sites are single-byte NUL out-of-bounds writes. Exploitation requires the modem to emit an over-long AT response line, giving high attack complexity over an adjacent (cellular radio) vector. The fix passes sizeof(dst) - 1 (and correct explicit bounds for the IMSI and +KCELLMEAS sites) so the terminator always stays in bounds.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Zephyr HL7800 modem AT response handlers (Sierra Wireless HL7800 driver)to a version that resolves this vulnerability.Fixed in v4.4.0 and earlier - Configuration
In the HL7800 modem AT response handlers, ensure net_buf_linearize() is called with sizeof(dst) - 1 for 128-byte stack buffers, and apply correct explicit bounds for the IMSI and +KCELLMEAS handlers so the terminator NUL is written within the buffer.
HL7800 AT response parsing (net_buf_linearize usage) Destination-length argument to net_buf_linearize() = sizeof(dst) - 1 (and correct explicit bounds for IMSI and +KCELLMEAS sites) - Compensating control
Since the line length is taken from net_buf_findcrlf() over the full net_buf fragment chain (and is not bounded to 128), add/ensure an input-length bound on parsed AT response lines in the RX path so lines longer than the 128-byte stack buffer cannot reach the off-by-one/overflow defects.
Event History
Frequently Asked Questions
Which systems should be considered potentially exposed?
Deployments using the Sierra Wireless HL7800 modem driver in Zephyr v4.4.0 or earlier should be prioritized for review. The provided data does not establish whether the driver is enabled by default in any particular Zephyr configuration.
What input does an attacker need to control?
An attacker needs to influence AT-response data received from the HL7800 modem over UART. The affected data can be driven by the cellular network, including operator-scan results, IP/DNS information, socket indications, and cell-measurement responses; the +KCELLMEAS path becomes a stack-buffer overflow when a response line exceeds 128 bytes.
Are all affected parsing paths equally dangerous?
Fields that exactly fill the 128-byte local buffer can trigger a one-byte out-of-bounds NUL write in roughly twenty response handlers. The cell-measurement handler is more severe because it uses the received line length as the destination size, allowing content beyond the 128-byte stack buffer to be copied.