CVE-2026-49895 AI-generated analysis

platform/external/wpa_supplicant_8, IEEE 802.11 common definitions (EHT Operation element parsing)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (3 corrections). Verify against the commit before relying on it.

Raises the EHT Operation element minimum-length constant in src/common/ieee802_11_defs.h from 1 to 5 so the length check used by get_eht_operation_channel_width() accounts for the fixed-size fields that precede the EHT Operation Information field.

Root cause

Per the commit message and diff, EHT_OPERATION_IE_MIN_LEN (EHT_OPERATION_ELEM_MIN_LEN on Android 17) was defined as 1. That value predated the addition of basic_eht_mcs_nss_set[4] to struct ieee80211_eht_operation, so the fixed part that precedes the operation information is 5 octets. Per the commit message, get_eht_operation_channel_width() bounds-checks the element against this constant and, when EHT_OPER_INFO_PRESENT is set, accesses oper_info at offset 5. An element with length between 1 and 4 inclusive passed the check, which allowed a heap out-of-bounds read.

How the fix works

• src/common/ieee802_11_defs.h: the constant EHT_OPERATION_IE_MIN_LEN is changed from 1 to 5 (Android 14, 15, 16). On Android 17 the already-renamed EHT_OPERATION_ELEM_MIN_LEN is changed from 1 to 5. On 14/15/16 the comment is also updated from the P802.11be/D2.3 draft reference (9.4.2.311) to IEEE Std 802.11be-2024 (9.4.2.321).
• No code in get_eht_operation_channel_width() is modified. Per the commit message, the existing bounds check that uses the macro now accounts for the 5 octets of fixed fields before oper_info.

Completeness

• The fix changes only the length-check constant. Every site that compares an EHT Operation element length against EHT_OPERATION_IE_MIN_LEN / EHT_OPERATION_ELEM_MIN_LEN gets the corrected minimum. Sites that use a different constant or no check are not affected by this change.
• The material does not show the body of get_eht_operation_channel_width(). It also does not show whether the length of the variable operation information (EHT_OPER_INFO_MIN_LEN = 3, plus the optional 2-octet disabled subchannel bitmap) is validated separately after the minimum-length check. That cannot be judged from the diff.

Behavior changes

• EHT Operation elements with length 1 through 4 now fail the minimum-length check wherever the macro is used. Previously they were accepted.

Per major

• Android 14: same fix: 0ce102474997 in android-security-14.0.0_r29 (a cherry-pick per its commit message) changes EHT_OPERATION_IE_MIN_LEN from 1 to 5 and updates the spec comment.
• Android 15: same fix: 234d284145fc in android-security-15.0.0_r17, same content (EHT_OPERATION_IE_MIN_LEN 1 -> 5); only whitespace alignment differs.
• Android 16: same fix: 6579923889d6 in android-security-16.0.0_r8, same content (EHT_OPERATION_IE_MIN_LEN 1 -> 5); the surrounding context differs (RNR MLD param defines).
• Android 17: adapted fix: 14398e6a6663 in android-security-17.0.0_r1 changes the renamed macro EHT_OPERATION_ELEM_MIN_LEN from 1 to 5. The 802.11be-2024 comment was already present, so it is a one-line change.

Unknowns

• The body of get_eht_operation_channel_width() and the exact comparison it performs against the macro are not included in the material.
• Which frames and code paths (scan results, association, hostapd if built) lead to get_eht_operation_channel_width() on Android is not shown.
• Whether the macro is referenced at any other site in the tree is not shown.

Back to September 2026 · Findings