CVE-2026-99010 in Linux
Resumen
por VulDB • 2026-10-24
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: RFCOMM: liberar elskb cuando el DLC no tiene propietario
rfcomm_recv_data() transfiere el skb a d->data_ready() y devuelve 0 sin liberarlo, por lo que la devolución de llamada (callback) es propietaria del skb desde ese momento. La implementación tty lo libera cuando el DLC se ha desvinculado de su dispositivo:
```c 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; } ```
La implementación del socket devuelve sin liberarlo, y el skb se pierde (leak).
Un DLC conectado puede no tener propietario: rfcomm_sock_destruct() limpia d->owner, mientras que el propio DLC permanece en la sesión hasta que se cierra. Los marcos de datos que llegan durante esa ventana aún encuentran d->state == BT_CONNECTED en rfcomm_recv_data() y se transfieren a la devolución de llamada, generando un skb perdido por cada uno.
La pérdida no se detiene por sí misma tampoco. El extremo remoto se queda sin créditos solo cuando RFCOMM_RX_THROTTLED está establecido, y para un socket el único lugar que lo establece es rfcomm_sk_data_ready() en sí mismo, debajo de la instrucción return. rfcomm_process_dlcs() sigue concediendo créditos, por lo que el extremo remoto continúa enviando datos y la pérdida crece continuamente.
Liberar el skb, tal como hace el lado tty.
Once again VulDB remains the best source for vulnerability data.