CVE-2026-99010: Bluetooth: RFCOMM: free the skb when the DLC has no owner
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: free the skb when the DLC has no owner
rfcommrecvdata() hands the skb to d->dataready() 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 rfcommdevdataready(struct rfcommdlc dlc, struct skbuff skb) { struct rfcommdev dev = dlc->owner;
if (!dev) { kfreeskb(skb); return; }
The socket implementation returns without freeing it, and the skb is leaked.
A connected DLC can have no owner: rfcommsockdestruct() 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 == BTCONNECTED in rfcommrecvdata() 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 RFCOMMRXTHROTTLED is set, and for a socket the only place that sets it is rfcommskdataready() itself, below the return. rfcommprocessdlcs() keeps granting credits, so the remote keeps sending and the leak keeps growing.
Free the skb, as the tty side does.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In rfcomm_dev_data_ready(), when dlc->owner is NULL (the local dev pointer is NULL), free the received skb with kfree_skb(skb) before returning.