EUVD-2026-34189
GHSA-7c7h-p74x-w3h5
Severity by source
AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Primary rating from Vendor (Bugcrowd) · only source for this CVE.
CVSS VectorVendor: Bugcrowd
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Lifecycle Timeline
4DescriptionCVE.org
An out-of-bounds read vulnerability in the morse.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.12 allows an unauthenticated attacker within radio range to disclose a small amount of kernel heap memory or cause a Denial of Service (kernel oops/panic) via a crafted 802.11ah beacon or probe response frame containing a malformed Vendor Information Element. The function morse_vendor_find_vendor_ie() does not validate the IE length against the expected structure size before its result is passed to morse_vendor_rx_caps_ops_ie() and morse_vendor_fill_sta_vendor_info(), which read at fixed offsets into the IE data. Because the length check only requires the IE to be longer than 3 bytes, an attacker can supply an undersized IE, causing a heap out-of-bounds read of up to 9 bytes. No authentication, association, or user interaction is required.
AnalysisAI
Heap out-of-bounds read in Morse Micro HaLowLink 2 prior to version 2.11.12 allows an unauthenticated attacker within 802.11ah radio range to disclose up to 9 bytes of kernel heap memory or trigger a kernel panic (DoS) by transmitting a crafted beacon or probe response frame containing a malformed Vendor Information Element. The morse.ko kernel driver function morse_vendor_find_vendor_ie() fails to validate IE body length against the expected structure size before downstream callers read at fixed offsets, requiring only that the IE length field exceed 3 bytes. No public exploit identified at time of analysis; EPSS places exploitation probability at 0.03% (8th percentile) with no CISA KEV listing, though the zero-prerequisite radio-range attack surface warrants prompt patching for HaLow-enabled deployments.
Technical ContextAI
The vulnerability resides in the morse.ko kernel module, the 802.11ah (Wi-Fi HaLow) driver component of Morse Micro's HaLowLink 2 software stack (CPE: cpe:2.3:a:morse_micro:halowlink_2:*:*:*:*:*:*:*:*). 802.11ah operates in the sub-1 GHz ISM band and is architected for extended-range IoT connectivity, where management frames such as beacons and probe responses are processed passively before any authentication or association occurs. The root cause is in morse_vendor_find_vendor_ie(), which parses Vendor Information Elements from received 802.11 management frames but applies only a threshold check (IE length > 3 bytes) rather than validating the IE body is large enough to satisfy the expected structure layout. The returned pointer is subsequently passed to morse_vendor_rx_caps_ops_ie() and morse_vendor_fill_sta_vendor_info(), both of which perform fixed-offset reads into the IE data without re-checking bounds. An undersized IE body causes these reads to extend up to 9 bytes beyond the allocated IE payload into adjacent kernel heap memory. Though no CWE was formally assigned by NVD, the flaw maps to CWE-125 (Out-of-bounds Read), consistent with the 'Buffer Overflow' and 'Denial Of Service' tags provided by intelligence sources.
RemediationAI
The primary remediation is to upgrade Morse Micro HaLowLink 2 to version 2.11.12 or later, which introduces proper IE length validation in morse_vendor_find_vendor_ie() against the expected structure size before fixed-offset reads are performed downstream. Upgrade guidance is available in vendor advisory MM-SA-2026-003 at https://www.morsemicro.com/security-advisories/MM-SA-2026-003. Where immediate patching is not operationally feasible, the most effective compensating control is to disable the HaLow (802.11ah) radio interface entirely, eliminating the attack surface at the cost of all HaLow connectivity. Alternatively, deploying physical RF access controls or directional antenna configurations to restrict attacker radio proximity reduces exploitability but does not eliminate it, given 802.11ah's extended sub-1 GHz range. Monitoring kernel logs (dmesg, crash dumps) for unexpected oops or panic events attributable to the morse.ko module can serve as a detection signal for exploitation attempts. No software-only workaround that preserves HaLow functionality has been identified in available data.
More in Halowlink 2
View allRemote unauthenticated code execution and denial-of-service in Morse Micro HaLowLink 2 (versions prior to 2.11.13) allow
Remote code execution and kernel-level denial of service in Morse Micro HaLowLink 2 devices running software prior to 2.
Same weakness CWE-125 – Out-of-bounds Read
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today