Live › vulnerability › CVE-2026-99010
Go to dashboardWhen a Bluetooth RFCOMM connection has no owning socket, incoming data frames are handed to a callback that never frees them, so the kernel leaks memory on every frame. A nearby remote device that keeps sending data can keep growing that leak until the kernel runs out of memory.
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 where a remote device can open an RFCOMM channel, including those with the rfcomm module loaded. Hosts without Bluetooth hardware or with the RFCOMM module absent are not exposed. The sources do not say which kernel versions are affected.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds listed by your distribution.lsmod | grep rfcomm; if the module is not loaded, the code path is not reachable.modprobe -r rfcomm on hosts that do not need Bluetooth serial.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: free the skb when the DLC has no owner
rfcomm_recv_data() hands the skb to d->data_ready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device:
static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) { struct rfcomm_dev *dev = dlc->owner;
if (!dev) {
kfree_skb(skb);
return;
}
The socket implementation returns without freeing it, and the skb is leaked.
A connected DLC can have no owner: rfcomm_sock_destruct() clears d->owner, while the DLC itself stays on the session until it is closed. Data frames that arrive in that window still find d->state == BT_CONNECTED in rfcomm_recv_data() and are handed to the callback, one leaked skb each.
The leak does not stop on its own either. The remote runs out of credits only once RFCOMM_RX_THROTTLED is set, and for a socket the only place that sets it is rfcomm_sk_data_ready() itself, below the return. rfcomm_process_dlcs() keeps granting credits, so the remote keeps sending and the leak keeps growing.
Free the skb, as the tty side does.
This page as .md · .json · in your agent: get_signal("CVE-2026-99010")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.