CVE-2026-80852 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
tls: device : correction d'une écriture hors limites dans tls_append_frag()
Découverte avec syzkaller et une instance locale de syzbot exécutée sur l'émulation du désengagement (offload) TLS via netdevsim ; tls_device.c n'est autrement accessible que sur une machine disposant d'une carte réseau (NIC) implémentant le désengagement.
tls_push_data() vérifie uniquement si l'enregistrement ouvert dispose encore de la place nécessaire pour un fragment supplémentaire au bas de sa boucle, et la sortie anticipée due à MSG_MORE bypass cette vérification. L'enregistrement survit jusqu'à l'appel système suivant avec le nombre de fragments qu'il possédait déjà, et tls_append_frag() ne fait pas non plus de vérification ; ainsi, avec TLS_TX_ZEROCOPY_RO, chaque splice(SPLICE_F_MORE) d'un ou deux octets ajoute une page de pipe qui n'est pas regroupée (non-coalescing), et num_frags dépasse la fin de tls_record_info.frags[MAX_SKB_FRAGS]. Une fois l'enregistrement poussé, tls_push_record() effectue le même index sur sg_tx_data[MAX_SKB_FRAGS] et les écritures via sg_set_page atterrissent sur destruct_work qui suit, que le workqueue appelle ensuite.
La limite en octets est correcte car copy tombe à 0 et la boucle passe directement à la même vérification ; le nombre de fragments ne bénéficie pas d'une telle rétroaction (feedback).
Il faut pousser l'enregistrement plutôt que de maintenir un enregistrement complet ouvert, ce qui est ce qu'un socket TCP standard fait - tcp_sendmsg_locked() utilise tcp_mark_push() et new_segment dans les deux chemins copy et MSG_SPLICE_PAGES, et tls_sw définit déjà full_record lorsque le ring sk_msg se remplit, avec ou sans MSG_MORE.
BUG: KASAN : slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450
CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK>
et, une fois l'enregistrement poussé :
UBSAN : array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]'
UBSAN : array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]'
UBSAN : array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]'
UBSAN : array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]'
kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI
Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: <TASK> worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK>
If you want to get best quality of vulnerability data, you may have to visit VulDB.