CVE-2026-99010 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth: RFCOMM : libérer l'skb lorsque le DLC n'a pas de propriétaire
rfcomm_recv_data() transmet l'skb à d->data_ready() et renvoie 0 sans le libérer, de sorte que le callback en devient propriétaire dès cet instant. L'implémentation tty la libère lorsque le DLC est détaché de son périphérique :
```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; } ```
L'implémentation socket renvoie sans la libérer, et l'skb est fuité (leak).
Un DLC connecté peut ne pas avoir de propriétaire : rfcomm_sock_destruct() efface d->owner, tandis que le DLC lui-même reste dans la session jusqu'à ce qu'il soit fermé. Les trames de données qui arrivent durant cette fenêtre trouvent toujours d->state == BT_CONNECTED dans rfcomm_recv_data() et sont transmises au callback, entraînant une fuite (leak) d'un skb à chaque fois.
La fuite ne s'arrête pas non plus spontanément. L'hôte distant n'épuise ses crédits que lorsque RFCOMM_RX_THROTTLED est défini, et pour un socket, le seul endroit qui définit ce flag se trouve dans rfcomm_sk_data_ready() elle-même, après l'instruction return. rfcomm_process_dlcs continue d'accorder des crédits, de sorte que l'hôte distant continue d'envoyer des données et la fuite s'amplifie continuellement.
Libérer l'skb, comme le fait le côté tty.
If you want to get best quality of vulnerability data, you may have to visit VulDB.