Intro:  
In this post, let’s break down CVE-2022-45934. If you use Linux (kernel through 6..10) and have Bluetooth enabled, this issue matters to you. There’s a bug in how the kernel handles L2CAP Config Request packets that can lead to an integer wraparound—opening the door for exploits, like memory corruption or even crashes. We’ll keep the technical jargon light and show actual code, so you can see the problem and how attackers might abuse it.

What is L2CAP and Why Does It Matter?

Bluetooth communication in Linux relies on the L2CAP (Logical Link Control and Adaptation Protocol). It helps organize data between Bluetooth devices. When two devices connect, they exchange configuration (CONF) requests to agree on how to talk to each other.

The main code handling this handshake is in net/bluetooth/l2cap_core.c. This code parses incoming L2CAP_CONF_REQ packets, but there’s a flaw: it might not correctly check the length of incoming data, allowing values to “wrap around”—like a broken odometer going from 99999 to 00000—which can lead to exploitation.

The Bug: l2cap_config_req Integer Wraparound

The core problem is integer wraparound or integer overflow. This happens if the length field sent by an attacker is so large that, added to other numbers in the kernel, the result “wraps around” in a way the code didn’t expect. This can allow an attacker to trick the kernel into writing outside of intended memory areas.

This problem was found in l2cap_config_req(). Here’s a simplified snip of the core logic from l2cap_core.c:

static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd)
{
    struct l2cap_conf_req *req = (struct l2cap_conf_req *) (cmd + 1);
    u16 flags = __le16_to_cpu(req->flags);
    u16 len = __le16_to_cpu(cmd->len);

    // This is where the problem lives:
    if (len < sizeof(*req))
        return -EINVAL;

    // Subtracting out the struct size from total len:
    len -= sizeof(*req);
    if (len > L2CAP_CONF_MAX_SIZE)
        return -EINVAL;

    // Problems if len is so big this goes negative or wraps around
    // ...
}

If cmd->len is a maliciously chosen large value, subtracting sizeof(*req) could make len wrap around and become a small or even negative value (which becomes a large unsigned value), making the kernel overwrite memory it shouldn’t.

How Could an Attack Work?

If a remote attacker connects via Bluetooth and sends a crafted L2CAP_CONF_REQ packet to your device, they could trigger the integer overflow. This might let them:

Pseudocode attack sketch

# Pseudocode, not actual exploit
send_packet(
    type="L2CAP_CONF_REQ",
    len=xFFFF,  # Maximum value to trigger wraparound
    payload=evil_bytes
)

A real attacker would need to get the payload just right, but anyone within Bluetooth range could try crashing your device.

- Mitre CVE-2022-45934 Details
- Full Bug Report / Patch

How To Fix and Protect Yourself

The official fix is very simple: make sure any incoming length doesn’t cause wraparound, and don’t trust user-supplied lengths.

What did patch look like?  
From the patch:

if (len < sizeof(*req) || (len - sizeof(*req) > L2CAP_CONF_MAX_SIZE))
    return -EINVAL;

- This checks both that length isn’t too small, and that after subtracting struct size, there’s no overflow.

If you run Linux:

Conclusion

CVE-2022-45934 is a classic case of “never trust input, especially from the network.” Even tiny mistakes in how programmers check values can lead to big security holes. Always keep your software updated and be wary of unnecessary services like Bluetooth when you don’t need them.

References

- CVE-2022-45934 at NIST
- Linux Kernel Patch Commit
- Bluetooth L2CAP RFC

*Stay safe—always patch and audit code, especially in the kernel!*

Timeline

Published on: 11/27/2022 04:15:00 UTC
Last modified on: 04/11/2023 18:15:00 UTC