OpenBSD TKIP countermeasure logic inversion enables wireless denial of service

OpenBSD before commit 1ee99df contains an inverted comparison vulnerability in the ieee80211_michael_mic_failure() function within sys/net80211/ieee80211_crypto_tkip.c that allows unauthenticated attackers within RF range to trigger denial of service by sending two malformed TKIP frames separated by more than 60 seconds. Attackers can exploit the reversed TKIP MIC failure countermeasure window check to deauthenticate all associated TKIP stations and block reassociation for up to 90 seconds, while within-window MIC failures that should engage countermeasures are silently discarded, leaving key-recovery attempts undetected.

• OpenBSD-current before 2026-07-15 is identified by the advisory as affected when WPA1/TKIP is enabled.
• The structured affected data marks the OpenBSD git tree from git version 0 to before the fixing commit 1ee99df as affected.
• The fix is in commit 1ee99df, affecting sys/net80211/ieee80211_crypto_tkip.c and ieee80211_michael_mic_failure().
• The record does not independently establish the status of other release or parallel branches. Their status should not be inferred solely from the existence of this commit.

This CWE-697 flaw is in ieee80211_michael_mic_failure() in sys/net80211/ieee80211_crypto_tkip.c. The function decides when a second Michael MIC failure should activate TKIP countermeasures, but the 60-second window comparison was inverted: ic->ic_tkip_micfail + 60 >= now causes failures inside the 60-second window to return without countermeasures, while failures more than 60 seconds apart fall through to the countermeasure path. In HostAP mode, that path sets IEEE80211_F_COUNTERM, refuses new TKIP associations for 60 to 90 seconds, deauthenticates every associated TKIP station, and schedules a GTK change. In STA mode, it sends two MIC failure reports and deauthenticates from the AP. The entry points are reachable from received frames through ieee80211_tkip_decrypt() and the EAPOL path in ieee80211_pae_input.c; the attacker needs no authentication and only needs to be within RF range. The confirmed scope is centered on OpenBSD-current and configurations with WPA1/TKIP enabled; the record does not provide a complete mapping to ordinary product release numbers.

The flaw is reachable over the wireless interface through received TKIP frames and does not require authentication or user interaction. The documented attack condition is two malformed TKIP frames with the second arriving more than 60 seconds after the first. On an access point, that sequence can activate countermeasures, deauthenticate all TKIP stations, and block reassociation for up to 90 seconds. The record marks a public exploit as available, and the public technical advisory describes the impact sequence, but it does not identify a specific campaign, victim, or breach. The record does not confirm known exploitation, so that status should not be interpreted as evidence that exploitation has not occurred.

The inverted condition reverses the intended behavior of TKIP countermeasures. MIC failures separated by more than 60 seconds can enter the protection path and cause broad deauthentication on an access point, while failures within 60 seconds are silently bypassed. The documented technical outcome is loss of availability for TKIP connections, temporary reassociation blocking, and, in STA mode, disconnection from the AP. Ignoring MIC failures inside the intended window also weakens detection of key-recovery attempts. The impact is bounded to enabled WPA1/TKIP deployments; the record does not establish effects on non-TKIP configurations or changes to confidentiality and integrity.

• On a HostAP access point using WPA1/TKIP, a malicious frame sequence can disconnect every associated TKIP station and cause a temporary wireless service outage.
• The system may refuse new TKIP associations for 60 to 90 seconds, disrupting users or devices that depend on legacy wireless connectivity.
• Rapid MIC failures that should activate countermeasures are discarded instead, weakening the protection intended to detect key-recovery attempts.
• The record documents availability and defensive-control consequences; it does not provide evidence of data disclosure or modification.
• The configuration scope is limited to deployments where WPA1/TKIP is enabled.

1. Update the kernel to one containing commit 1ee99df. The change corrects the comparison governing the TKIP MIC-failure window.
2. Verify that the running kernel or source tree contains the change in sys/net80211/ieee80211_crypto_tkip.c, rather than relying only on a package label or build date.
3. If updating is not immediately possible, disable WPA1/TKIP and use a wireless configuration that does not rely on TKIP where compatibility requirements permit. This reduces exposure but does not replace the kernel fix.
4. Assess each deployed OpenBSD branch or build separately. Treat a branch as remediated only after confirming that it contains the fixing change; do not assume the status of one branch applies to all others.
5. After updating or changing configuration, recheck APs and STAs that use WPA1/TKIP to confirm that no in-scope system remains.

1. Inventory OpenBSD wireless access points and stations, and determine whether WPA1/TKIP is enabled. The advisory states that TKIP is disabled by default, but enabled legacy configurations remain in scope.
2. Check the running kernel's source provenance or build metadata to determine whether sys/net80211/ieee80211_crypto_tkip.c contains the fix from commit 1ee99df.
3. Review for mass deauthentication, reassociation failures, and TKIP service interruptions following unusual MIC failures. This is precautionary monitoring, not a confirmed indicator of compromise.
4. If impact is suspected, correlate wireless events with malformed TKIP frames and MIC failures separated by more than 60 seconds.
5. Absence of related log evidence does not prove safety; combine telemetry review with configuration and kernel checks.