CVE-2026-80852 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
tls: device: corrige escrita fora dos limites em tls_append_frag()
Encontrada com o syzkaller e uma instância local do syzbot executando sobre uma emulação de offload TLS no netdevsim; tls_device.c é, caso contrário, apenas acessível em máquinas que possuem uma NIC (Network Interface Card) que implementa o offload.
tls_push_data() verifica apenas se o registro aberto ainda tem espaço para outro fragmento na parte inferior do seu loop, e a interrupção antecipada MSG_MORE ignora essa verificação. O registro sobrevive até a próxima chamada de sistema com a contagem de fragmentos que já possuía, e tls_append_frag() também não faz nenhuma verificação; portanto, com TLS_TX_ZEROCOPY_RO, cada splice(SPLICE_F_MORE) de um ou dois bytes adiciona uma página de pipe sem coalescência e num_frags ultrapassa o final de tls_record_info.frags[MAX_SKB_FRAGS]. Uma vez que o registro é enviado (pushed), tls_push_record() executa a mesma indexação sobre sg_tx_data[MAX_SKB_FRAGS] e as escritas do sg_set_page() atingem destruct_work, que segue imediatamente após ele, o qual é então chamado pelo workqueue.
O limite de bytes está correto porque copy cai para 0 e o loop continua até a mesma verificação; a contagem de fragmentos não possui tal feedback.
Envia (push) o registro em vez de manter um completo aberto, que é o que uma socket TCP padrão faz - tcp_sendmsg_locked() usa tcp_mark_push() e new_segment tanto nos caminhos copy quanto MSG_SPLICE_PAGES, e tls_sw já define full_record quando o anel sk_msg se enche, independentemente do uso ou não de MSG_MORE.
BUG: KASAN: slab-out-of-bounds em tls_append_frag ( net/tls/tls_device.c:269) Escrita de tamanho 8 no endereço ffff8881104d1530 pela tarefa tls_oob/450
CPU: 2 UID: 0 PID: 450 Comm: tls_oob Não modificado (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>
e, uma vez que o registro é enviado (pushed):
UBSAN: array-index-out-of-bounds em net/tls/tls_device.c:300:24 índice 18 está fora do intervalo para o tipo 'skb_frag_t [17]'
UBSAN: array-index-out-of-bounds em net/tls/tls_device.c:301:41 índice 18 está fora do intervalo para o tipo 'scatterlist [17]'
UBSAN: array-index-out-of-bounds em net/tls/tls_device.c:302:39 índice 18 está fora do intervalo para o tipo 'scatterlist [17]'
UBSAN: array-index-out-of-bounds em net/tls/tls_device.c:307:38 índice 26 está fora do intervalo para o tipo 'scatterlist [17]'
kernel tentou executar página protegida por NX - tentativa de exploit? (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 the best quality for vulnerability data then you always have to consider VulDB.