REDHAT-BUG-2560212: Low severity Intel iwd vulnerability

Published Oct 23, 2026
·
Updated

mdeequal() 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 ftparseies() (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 - ftrxassociate() 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.

Affected Software

1 affected component
Intel iwd>=1.14

Event History

Oct 23, 2026
Data Sourced
via Red Hat·09:26 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

What attacker position is required to exploit this issue?

The CVSS vector indicates adjacent-network access, with no privileges or user interaction required. Exploitation has high attack complexity and involves supplying an FT Authentication Response with an arbitrary Mobility Domain ID and FT capability flags.

2

Which connection flows are affected?

The vulnerable comparison is reached from ft_parse_ies() when validating that an access point echoed the station's Mobility Domain element during 802.11r FT Authentication Response and FT-over-DS processing.

3

Does this allow an attacker to bypass 802.11r authentication?

No. The data states that this is not an authentication bypass: __ft_rx_associate() performs the comparison correctly, and the FTE MIC is keyed on PMK-R1. The flawed check instead allows a malformed Mobility Domain response to proceed into FTE parsing and key derivation.

4

How can I determine whether my source tree contains the flaw?

Inspect src/ft.c around the mde_equal() implementation. The vulnerable code calls memcmp(mde1, mde1, mde1[1] + 2), meaning mde2 is never read and the comparison always passes; the issue was introduced in version 1.14.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203