Live › vulnerability › CVE-2026-98600
Go to dashboardA malformed 4-byte RFCOMM frame with the extended-length bit clear is not rejected, so the kernel passes the unparsed 3-byte header on as application data or as a multiplexer control command. The sources do not say what an attacker can do beyond this, so the impact is unconfirmed.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with Bluetooth RFCOMM support enabled and a Bluetooth adapter in use are the ones to look at. The sources do not say which kernel versions are vulnerable or whether an attacker needs to be paired or nearby, so systems with Bluetooth disabled or the bluetooth module not loaded can likely skip it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len).
This page as .md · .json · in your agent: get_signal("CVE-2026-98600")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.