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.
{
"cna_assigner": "zephyr",
"cwe_ids": [
"CWE-843"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/15xxx/CVE-2026-15461.json"
}"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-15461.json"
[
{
"deprecated": false,
"digest": {
"line_hashes": [
"253818307077490001438243700317125309975",
"31207950082524776644977841900063922751",
"212261057644861808421384498338540196807",
"141882820947914182198921818466402419697",
"212525186370949278377518755404697655960",
"256723120289624319516114948184987312711",
"317372753858675874097091729649453813123",
"143520122520805161911079296362138349883",
"75771721516872676638252796431529165270"
],
"threshold": 0.9
},
"id": "CVE-2026-15461-712a258f",
"signature_type": "Line",
"signature_version": "v1",
"source": "https://github.com/zephyrproject-rtos/zephyr/commit/8a2465784e8909aa3835559381a60c00cc2218a1",
"target": {
"file": "drivers/modem/vendor_standalone/hl78xx/hl78xx_gnss.h"
}
}
]
"2026-09-12T08:17:55Z"