CVE-2026-98600 Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()

What is CVE-2026-98600?

CVE-2026-98600 is a denial of service vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()

While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2).

When a 4-byte RFCOMM frame with EA == 0 arrives: 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false). 2. Trimming the FCS byte decrements skb->len to 3. 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data. 4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0.

Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len).

Which versions are affected by CVE-2026-98600?

How do I fix CVE-2026-98600?

Apply the vendor's patch.

Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.

Is CVE-2026-98600 being exploited?

There is no known exploitation of CVE-2026-98600 in the wild and no public exploit code.

Sources

• CVE record
• NVD
• OSV
• GitHub advisory
• How this page is made

Also known as BELL-CVE-2026-98600, DEBIAN-CVE-2026-98600, GHSA-hpgr-cqmv-php2, UBUNTU-CVE-2026-98600.