Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDeploy GNSS spoofer at radio proximity
-
DeliveryTransmit crafted NMEA GSV sentences
-
ExploitHL78xx modem relays sentences to Zephyr kernel driver
-
ExecutionGSV callback reads bogus satellite pointer from wrong struct offset
-
PersistKernel writes parsed satellite data through wild pointer
-
ImpactKernel fault / device crash (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Type safety enforcement
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Three specific conditions must all hold simultaneously: (1) CONFIG_HL78XX_GNSS_SOURCE_NMEA must be active - this is the default GNSS source for HL78xx, so it is present in standard builds without explicit override; (2) CONFIG_GNSS_SATELLITES must be enabled - this activates the GSV callback that performs the wild pointer dereference; and (3) the attacker must be capable of influencing the GNSS radio signal received by the target hardware, for example through GPS/GNSS spoofing at radio proximity using readily available SDR equipment. The driver runs in kernel context with no privilege boundary between the GNSS radio data path and kernel memory. Limiting factors include the adjacent attack vector (physical proximity required), the high complexity of injecting valid-looking NMEA GSV sentences via spoofed signals, and the requirement for a specific Zephyr version with the vulnerable struct layout. Purely remote network exploitation is not possible; this is exclusively a physical-layer attack. |
| Impact | The CVSS 3.1 base score of 5.3 (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) appropriately reflects the constrained threat model. The adjacent attack vector is realistic - GNSS spoofing equipment is commercially available and has been demonstrated at under $300 in research settings - but still requires physical radio proximity to the target device. High attack complexity is justified by the dual requirement of CONFIG_GNSS_SATELLITES being enabled and the attacker being able to inject syntactically valid NMEA GSV sentences through spoofed signals. The impact is most likely a kernel crash (denial of service) because on MMU-equipped targets the bogus near-NULL pointer triggers a fault before data is written; on MMU-less targets adjacent memory corruption is technically possible, meaning integrity impact may be understated at I:N for those deployment configurations. Confidentiality is unaffected. No CISA KEV listing and no EPSS data are present, consistent with no public exploit. EUVD-2026-75539 confirms the advisory. Real-world priority is moderate: Zephyr with HL78xx GNSS in safety-critical or mobility applications (asset trackers, drones, industrial IoT) warrants prompt patching; general-purpose embedded deployments are lower priority absent GNSS spoofing threat actors in the operational environment. |
| Exploit ScenarioDerived | An attacker operating a software-defined radio GNSS simulator at radio proximity to a target embedded device (asset tracker, drone, or industrial gateway) running Zephyr 4.4.0 or 4.4.1 with CONFIG_GNSS_SATELLITES=y transmits spoofed NMEA sentences including GSV records. The HL78xx modem's GNSS receiver processes these sentences and passes them to the Zephyr kernel driver, which invokes the GSV callback with a user_data pointer pointing to the misaligned hl78xx_gnss_data struct, causing the kernel to read a bogus satellites pointer from non-pointer bytes and attempt to write parsed satellite data to an invalid address, most likely triggering a kernel fault and device reboot. No public proof-of-concept code exists, and exploiting this to achieve memory corruption beyond a crash requires MMU-less hardware and precise control over the garbage pointer value. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 10, 2026
Type confusion in the Sierra Wireless HL78xx GNSS driver within Zephyr RTOS (4.4.0-4.4.1) allows an adjacent, unauthenticated attacker with GNSS signal-spoofing capability to drive the kernel-side NMEA parser into writing satellite data through a wild/garbage pointer, most likely crashing the device. The root defect is a struct member ordering invariant violation: the generic NMEA0183 match helper casts user_data directly to struct gnss_nmea0183_match_data, but hl78xx_gnss_data placed match_data as the second member (after const struct device), causing GGA/RMC callbacks to write fix data at wrong offsets and the GSV satellite callback to dereference a pointer constructed from non-pointer bytes. No public exploit exists; a vendor-released patch is available in Zephyr 4.4.2.
RemediationAI
Upgrade to Zephyr 4.4.2, which contains the fix from commit 8a2465784e8909aa3835559381a60c00cc2218a1. The patch reorders struct hl78xx_gnss_data so that match_data is the first member and adds a compile-time _Static_assert(offsetof(struct hl78xx_gnss_data, match_data) == 0) to prevent regression. If immediate upgrade is not feasible, the GSV callback attack path can be closed by setting CONFIG_GNSS_SATELLITES=n in the build configuration, which disables satellite parsing and prevents the wild pointer dereference; this has the trade-off of removing satellite data reporting from the GNSS subsystem. Alternatively, if GNSS functionality is not required, setting CONFIG_HL78XX_GNSS_SOURCE_NMEA=n or disabling the HL78xx driver entirely removes the vulnerable code path entirely. Advisory reference: https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vvjg-6rg4-7235.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected code lives in drivers/modem/vendor_standalone/hl78xx/hl78xx_gnss.h (earlier drivers/modem/hl78xx/). The generic NMEA0183 match helper in drivers/gnss/gnss_nmea0183_match.c registers GGA, RMC, and GSV parse callbacks that all cast their user_data argument directly to struct gnss_nmea0183_match_data, relying on it residing at offset 0 of the enclosing context struct. In the affected releases, struct hl78xx_gnss_data placed match_data at a non-zero offset (preceded by const struct device *dev), so gnss_nmea0183_match_init() correctly initialized the struct at its true address while the registered callbacks operated on user_data at offset 0 - an entirely different memory region. This is CWE-843 (Type Confusion via incorrect type casting). The GSV satellite callback (active when CONFIG_GNSS_SATELLITES=y) reads a struct gnss_satellite pointer and array bound from the offset-shifted location, which contains arbitrary non-pointer bytes of hl78xx_gnss_data, then writes parsed satellite entries through that bogus pointer. The fix (commit 8a2465784e) reorders struct members so match_data is first and adds a _Static_assert to enforce the invariant at compile time. Affected CPE: cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* versions 4.4.0 through 4.4.1.
Know when Zephyr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Adjacent vector (GPS spoofing at proximity); high complexity (CONFIG_GNSS_SATELLITES + spoofing required); I:L added for MMU-less adjacent memory corruption possibility beyond crash.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
The Sierra Wireless HL78xx modem GNSS driver (drivers/modem/hl78xx/, later drivers/modem/vendor_standalone/hl78xx/) embeds a generic struct gnss_nmea0183_match_data match_data inside struct hl78xx_gnss_data. The generic NMEA0183 match helper (drivers/gnss/gnss_nmea0183_match.c) requires that context to be the first member because its callbacks cast user_data directly to struct gnss_nmea0183_match_data . In the affected releases match_data was the second member (after const struct device dev), so it sat at a non-zero offset while gnss_nmea0183_match_init() initialized it at the correct address. The registered NMEA handlers instead pass the whole device data object (data->devices.gnss->data, offset 0), producing an offset-shifted type confusion between where state is initialized and where the parse callbacks read and write it.
When NMEA sentences from the GNSS receiver are parsed, the GGA/RMC callbacks write parsed fix data into the wrong location within the struct, and the GSV callback (gnss_nmea0183_match_gsv_callback, active under CONFIG_GNSS_SATELLITES) reads its satellites pointer and bound from the wrong offsets - non-pointer bytes of struct hl78xx_gnss_data - and then writes parsed struct gnss_satellite entries through that bogus pointer. This is a write through an uninitialized/wild pointer with a garbage bound.
The NMEA handlers are registered by default (CONFIG_HL78XX_GNSS_SOURCE_NMEA is the default GNSS source) on devices using the HL78xx GNSS. The driver runs in kernel context and the NMEA data originates from the GNSS radio front-end, so a party able to influence the GNSS signal (for example GNSS/GPS spoofing at radio proximity) can drive the kernel-side parser into the faulty write. The most likely impact is a crash (denial of service) because the bogus pointer resolves to a fixed near-NULL value, with adjacent-memory corruption possible on MMU-less targets. Confidentiality is not affected. Exploitation requires the satellites feature to be enabled and active, so attack complexity is high.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
EUVD-2026-75539
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB