Bug 2560212 (CVE-2026-115698)
| Summary: | CVE-2026-115698 iwd: mde_equal() compares its first argument to itself | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | Keywords: | Security |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in iwd. Due to an improper comparison where the mobility domain check compares an element to itself rather than against the incoming frame, validation always succeeds. A network-adjacent attacker can exploit this issue by sending a crafted 802.11r Fast BSS Transition (FT) authentication response with arbitrary mobility domain parameters. This allows an attacker to bypass mobility domain verification and proceed into subsequent frame parsing and key derivation stages.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2560232 | ||
| Bug Blocks: | |||
mde_equal() compares its first argument to itself CWE-697. CVSS 3.1: 3.1 Low CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N src/ft.c:385 Introduced 1.14, commit 2c0234e1 return memcmp(mde1, mde1, mde1[1] + 2) == 0; mde2 is never read, so the check always passes. Its only caller is ft_parse_ies() (ft.c:667), where it should confirm the target AP echoed the Mobility Domain element the station sent on the 802.11r FT Authentication Response and FT-over-DS paths. Not an authentication bypass - __ft_rx_associate() compares correctly at ft.c:496 and the FTE MIC there is keyed on PMK-R1 - but a response carrying an arbitrary mobility domain ID and FT capability flags passes the authentication stage into FTE parsing and key derivation. Finding 4 sits on that path, one call later.