CVE-2026-99010 in Linux
Sumário
de VulDB • 24/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
Bluetooth: RFCOMM: liberar o skb quando o DLC não tiver proprietário
rfcomm_recv_data() transfere o skb para d->data_ready() e retorna 0 sem libertá-lo, de modo que o callback assume a posse do skb a partir desse ponto. A implementação tty libera-o quando o DLC é desanexado do seu 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; } ```
A implementação do socket retorna sem libertar o skb, resultando em um vazamento de memória (leak).
Um DLC conectado pode não ter proprietário: rfcomm_sock_destruct() limpa d->owner, enquanto o próprio DLC permanece na sessão até ser fechado. Quadros de dados que chegam nesse intervalo ainda encontram d->state == BT_CONNECTED em rfcomm_recv_data() e são transferidos para o callback, gerando um skb vazado por cada quadro.
O vazamento também não se autodetém. O sistema remoto fica sem créditos apenas quando RFCOMM_RX_THROTTLED é definido, e para um socket, o único local que define essa flag é rfcomm_sk_data_ready() próprio, abaixo do retorno. rfcomm_process_dlcs() continua concedendo créditos, de modo que o sistema remoto continua enviando dados e o vazamento cresce continuamente.
Libere o skb, conforme feito pelo lado tty.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.