CVE-2026-12519 in Zephyr
Summary
by MITRE • 08/17/2026
The WNC-M14A2A LTE-M modem driver mishandles unsolicited %NOTIFYEV: events in on_cmd_socknotifyev() (drivers/modem/vendor_standalone/wncm14a2a.c). The response line is linearized into a fixed 40-byte stack buffer via net_buf_linearize(), which caps the copy at 39 bytes and returns out_len <= 39. The two quote-delimiter scanning loops, however, were bounded by len — the full CR/LF-delimited frame length returned by net_buf_findcrlf() — rather than by out_len.
When a %NOTIFYEV: line longer than 39 bytes contains no " within the linearized region, the loop indices p1/p2 walk past value[39] and read adjacent stack memory until a stray quote byte is found or the index reaches len. The over-read string is then passed to strncmp()/atoi()/LOG_*, and if a quote byte is found out of bounds the subsequent value[p2] = '\0' performs a single-NUL out-of-bounds stack write at an attacker-influenced offset.
The %NOTIFYEV: payload carries network-derived content (LTIME network time, SIB1 base-station system information, CSPS/RRCSTATE), so a rogue cellular base station, a malicious or compromised modem module, or RF manipulation that induces an over-long notify line reaches the defect without any application interaction; the handler runs automatically on the unsolicited event in the modem RX thread.
The impact is out-of-bounds stack disclosure (into logs and parsing) and stack corruption that can crash the modem RX thread (denial of service). The write offset is only weakly controlled, so memory-safe code execution is not demonstrated. The fix bounds both scanning loops by out_len, keeping all accesses within the linearized buffer.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability in question resides within the WNC-M14A2A LTE-M modem driver, specifically affecting the on_cmd_socknotifyev function which processes unsolicited %NOTIFYEV events. This flaw represents a classic stack-based out-of-bounds read and write condition arising from an inconsistent use of buffer length variables during string parsing operations. The core technical defect occurs when the system linearizes a response line into a fixed 40-byte stack buffer using net_buf_linearize, which correctly caps the copy at thirty-nine bytes to preserve space for a null terminator and returns this constrained length as out_len. However, subsequent scanning loops designed to locate quote delimiters within that string are incorrectly bounded by len, which represents the full CR/LF-delimited frame length returned by net_buf_findcrlf rather than the actual size of the linearized data. This discrepancy creates a critical boundary violation where loop indices can traverse beyond the allocated stack buffer if the incoming network payload exceeds thirty-nine bytes and lacks internal quote characters within the first forty bytes.
This architectural inconsistency leads to severe memory safety violations, primarily categorized under CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write. When a rogue cellular base station or compromised modem module transmits an over-long notify line containing no quotes in the initial segment, the scanning loops continue iterating past value[39]. This results in reading adjacent stack memory until either a stray quote byte is encountered by chance or the index reaches the end of the frame length len. If such a stray quote is found outside the valid buffer region, the subsequent operation to null-terminate the string performs a single-byte write at an attacker-influenced offset on the stack. This out-of-bounds write poses a direct threat to memory integrity, potentially corrupting adjacent variables or return addresses, although the lack of precise control over the write offset makes reliable arbitrary code execution difficult to achieve consistently.
The operational impact is significant due to the nature of the input vector and the context in which this code executes. The %NOTIFYEV payload carries network-derived content such as LTIME network time, SIB1 base-station system information, or CSPS/RRCSTATE data. Because these events are processed automatically by the modem RX thread without requiring any application-level interaction, an attacker can trigger this vulnerability remotely via RF manipulation or through a malicious cellular infrastructure component. The immediate consequences include out-of-bounds stack disclosure where sensitive memory contents may be leaked into logs and parsing routines, as well as potential denial of service conditions caused by stack corruption that crashes the modem RX thread. This aligns with ATT&CK techniques related to resource hijacking and disruption of availability through exploitation of communication protocol handlers.
Mitigation strategies must focus on correcting the boundary checks within the driver code. The primary fix involves ensuring that both scanning loops are bounded strictly by out_len rather than len, thereby guaranteeing all memory accesses remain within the linearized buffer limits. Additionally, implementing strict input validation to reject or truncate excessively long frames before processing would provide defense in depth. Developers should also consider adopting safer string handling practices and enabling compiler-based stack protection mechanisms such as stack canaries to detect corruption attempts early. Regular security audits of modem drivers are essential given their exposure to untrusted network inputs and the critical role they play in maintaining system stability and confidentiality.