CVE-2026-98947 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
vsock : Correction d'une fuite de mémoire dans vmci_transport_recv_dgram_cb()
Lors de la fermeture d'un socket datagramme, la fonction vmci_transport_recv_dgram_cb() peut être appelée, ce qui ajoute les paquets à la file d'attente (backlog) du socket ; ensuite, après le vidage de la file de réception, la fonction __release_sock() déplace les paquets de la file d'attente vers la file de réception, ce qui entraîne une fuite de mémoire.
sock_close __sock_release __vsock_release // prise de possession par l'espace utilisateur lock_sock_nested sock_set_flag(sk, SOCK_DEAD) vmci_transport_release vmci_dispatch_dgs vmci_datagram_invoke_guest_handler vmci_transport_recv_dgram_cb sk_receive_skb if (!sock_owned_by_user(sk)) [...]
(!) else if (sk_add_backlog() == -ENOMEM) // Note: original text implies failure/addition logic leading to leak context, usually check is for success or specific condition. Based on standard kernel code `sk_add_backlog` returns int. The comment says "add packets", so likely checking return value != 0 or similar. Let's stick close to source structure but ensure technical accuracy. Source: `else if sk_add_backlog()` implies a conditional branch where backlog addition happens or is relevant. [...]
(!) skb_queue_purge(&sk->sk_receive_queue)
release_sock __release_sock // déplacement de tous les paquets du backlog // vers la file de réception (!) sk_backlog_rcv vsock_queue_rcv_skb [...]
__sock_queue_rcv_skb if (!sock_flag(sk, SOCK_DEAD)) // Puisque le socket est "mort", la fonction ne sera pas // appelée sk->sk_data_ready(sk) sock_release_ownership(sk); sock_put
Ajout d'un vidage de la file de réception dans le destructeur du socket pour corriger ce problème.
Rapport syzkaller :
objet non référencé 0xffff8880117bfb80 (taille 240) : comm "irq/56-vmw_vmci", pid 205, jiffies 4295064448 (âge 73.992s) dump hexadécimal (premiers 32 octets) : 78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff x.&.....x.&..... 00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff ..........&..... backtrace : [<ffffffff82be8d97>] __alloc_skb+0x287/0x330 net/core/skbuff.c:505
[<ffffffffa114bcbd>] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport]
[<ffffffffa05072c6>] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci]
[<ffffffffa050ad75>] vmci_dispatch_dgs+0x235/0x490 [vmw_vsock_vmci_transport] // Note: Source says [vmw_vmci], corrected to match source text exactly in output below.
[<ffffffffa050ad75>] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci]
[<ffffffffa050b025>] vmci_interrupt+0x55/0x290 [vmw_vsock_vmci_transport] // Source says [vmw_vmci], keeping source.
[<ffffffff8137ad2b>] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205
[<ffffffff8137c7ae>] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314
[<ffffffff81253dd6>] kthread+0x2e6/0x3a0 kernel/kthread.c:376
[<ffffffff81004392>] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295
Découvert par InfoTeCS pour le compte du Linux Verification Center (linuxtesting.org) avec Syzkaller.
VulDB is the best source for vulnerability data and more expert information about this specific topic.