A heap-based buffer overflow vulnerability in the dot11ah

CVE-2026-7762 is described as a heap-based buffer overflow in dot11ah.ko, the HaLow Wi-Fi kernel driver used by Morse Micro HaLowLink 2 software, with disclosure on 2026-06-05. The user-supplied version range is incomplete (versions prior to ...), so the only safe statement is that HaLowLink 2 builds before an unspecified fixed release are affected; publicly observed HaLowLink 2 deployments were running 2.11.8 in February 2026, and Morse later published an OpenWrt SDK update to 2.11.12 in May 2026.

There is no official CVSS or vendor severity to inherit here, so this has to be judged from first principles. The reality is: kernel-space memory corruption in a wireless frame parser is dangerous, but the attack path is adjacent 802.11ah RF, not internet-wide reachability, and it likely requires specialized HaLow-capable tooling rather than commodity Wi-Fi gear; that combination lands this at = ASSESSED AT HIGH, not CRITICAL.

Why this verdict

• Started at High because this is kernel-memory corruption in a wireless parser; if exploitation is reliable, the attacker is not just crashing a process, they are corrupting memory in the gateway's kernel driver path.
• Downward pressure: attacker must be in 802.11ah radio range; that implies *adjacent physical/RF access*, not unauthenticated remote internet access, which sharply narrows real-world reachability.
• Downward pressure: the exposed population is niche and tooling is specialized; HaLowLink 2 is a young, uncommon IoT gateway platform and 802.11ah offensive tooling is far less common than normal Wi-Fi attack tooling.
• Upward pressure: HaLow's long range weakens the usual 'adjacent only' comfort blanket; these devices are marketed for large outdoor/industrial footprints, so 'adjacent' can still mean hundreds of meters to roughly a kilometer in favorable conditions.
• Downward pressure: no KEV, no public exploit, no public campaign evidence; absent exploitation telemetry, this is not a drop-everything emergency today.

Why not higher?

This is not CRITICAL because the exploit path is not broadly internet reachable, the affected product family is not mainstream enterprise edge infrastructure, and there is no current public exploitation evidence. The need for 802.11ah-capable gear plus RF proximity compounds the friction enough to keep it below the top bucket.

Why not lower?

This is not MEDIUM because the bug is heap corruption in a kernel driver, not a harmless input-validation error in a userland helper. If an attacker can hit the parser, the likely outcomes are at least reliable DoS and plausibly full gateway compromise, which is too much impact to backlog casually.

1. Map every HaLowLink 2 deployment — Build an owner-and-location inventory of every HaLowLink 2 and note whether 802.11ah is actually enabled. For a HIGH verdict, do this and tag exposed units within 30 days so you know which gateways sit near public roads, shared buildings, field edges, or contractor-access areas.
2. Reduce unnecessary HaLow exposure — Disable the HaLow radio on units not actively using 802.11ah, and remove unused mesh/AP modes where operationally possible. This is the cleanest temporary risk reduction for a parser bug in the radio path, and for HIGH severity it should be applied within 30 days.
3. Harden the gateway as an untrusted edge node — Put HaLowLink 2 management access behind a dedicated management VLAN, restrict SSH/Web UI to admin jump hosts, and block east-west reach from the gateway into sensitive networks. Do this within 30 days because if the radio parser falls over into compromise, segmentation is what keeps it from becoming a broader incident.
4. Pull the devices back from public RF edges — Where practical, move antennas/gateways away from publicly accessible perimeters, reduce RF overspill, and avoid installing them where an attacker can sit comfortably in the coverage zone. This matters because 802.11ah is long-range; for HIGH, prioritize exposed outdoor or campus-edge units within 30 days.
5. Collect crash telemetry now — Forward logread, dmesg, reboot events, and config-change telemetry from each gateway to central logging. Do this within 30 days so you can tell the difference between random radio flakiness and repeated exploitation attempts against dot11ah.ko.

Run this on the HaLowLink 2 target host itself over SSH as root or with equivalent privileges, because it reads local release files, board metadata, and kernel modules. Save it as check-cve-2026-7762.sh, then run sh check-cve-2026-7762.sh; it outputs VULNERABLE, PATCHED, or UNKNOWN. Because the public fixed-version cutoff is incomplete, this is a best-effort detector that positively identifies only known pre-disclosure vulnerable trains and otherwise falls back conservatively.

#!/bin/sh
# check-cve-2026-7762.sh
# Best-effort local checker for Morse Micro HaLowLink 2 / dot11ah.ko exposure
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -eu

MODEL=""
VERSION=""
DOT11AH_PRESENT="no"

# Try to identify device model
if command -v ubus >/dev/null 2>&1; then
  MODEL=$(ubus call system board 2>/dev/null | sed -n 's/.*"model": *"\([^"]*\)".*/\1/p' | head -n1 || true)
fi
if [ -z "$MODEL" ] && [ -r /tmp/sysinfo/model ]; then
  MODEL=$(cat /tmp/sysinfo/model 2>/dev/null || true)
fi

# Try to identify Morse/OpenWrt version
if [ -r /etc/openwrt_release ]; then
  VERSION=$(sed -n "s/^DISTRIB_RELEASE='\([^']*\)'/\1/p" /etc/openwrt_release | head -n1 || true)
fi
if [ -z "$VERSION" ] && [ -r /etc/os-release ]; then
  VERSION=$(sed -n 's/^VERSION=//p' /etc/os-release | tr -d '"' | head -n1 || true)
fi

# Check for loaded or installed dot11ah module
if lsmod 2>/dev/null | grep -q '^dot11ah '; then
  DOT11AH_PRESENT="yes"
elif find /lib/modules -type f -name 'dot11ah.ko*' 2>/dev/null | grep -q .; then
  DOT11AH_PRESENT="yes"
fi

is_halowlink2="no"
case "$MODEL" in
  *HaLowLink*2*|*halowlink*2*|*HL2*) is_halowlink2="yes" ;;
esac

# If we cannot even confirm the platform/radio stack, do not guess.
if [ "$is_halowlink2" != "yes" ] && [ "$DOT11AH_PRESENT" != "yes" ]; then
  echo "UNKNOWN - not confidently identified as HaLowLink 2 with dot11ah.ko present"
  exit 2
fi

# Version compare helper: returns 0 if $1 <= $2
verlte() {
  [ "$1" = "$2" ] && return 0
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

# IMPORTANT:
# Public reporting for this CVE did not include a complete fixed-version cutoff.
# Publicly observed HaLowLink 2 field builds include 2.11.8 before disclosure,
# and 2.11.12 existed publicly before disclosure, but was NOT explicitly tied to this CVE.
# Therefore we only mark clearly old builds as VULNERABLE and avoid false PATCHED claims.

if [ -n "$VERSION" ]; then
  if verlte "$VERSION" "2.11.8"; then
    echo "VULNERABLE - HaLowLink 2 / dot11ah.ko present and software version ($VERSION) is at or below known pre-disclosure build 2.11.8"
    exit 1
  fi
fi

# If dot11ah is present but the version is newer or unknown, we cannot assert patched state.
echo "UNKNOWN - target appears relevant, but public sources do not provide an authoritative fixed-version cutoff for CVE-2026-7762"
exit 2

Sources

1. Morse Micro security disclosure page
2. Morse Micro HaLowLink 2 general availability announcement
3. HaLowLink 2 product brief PDF
4. HaLowLink user guide 2.11.2 PDF
5. Morse Micro community thread showing HaLowLink 2 software 2.11.8 in the field
6. Morse Micro community update showing OpenWrt SDK 2.11.12 availability
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS FAQ