Vulnerabilidad en kernel de Linux (CVE-2025-38493)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/osnoise: corrige fallo en timerlat_dump_stack() Hemos observado pánicos en el kernel al usar timerlat con guardado de pila, con la siguiente salida de dmesg: memcpy: desbordamiento de búfer detectado: escritura de 88 bytes de tamaño de búfer 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() construye la entrada de la pila ftrace de la siguiente manera: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Desde el commit e7186af7fb26 ("rastreo: Agregar la lógica de FORTIFY_SOURCE a la estructura de eventos kernel_stack"), struct stack_entry marca su campo de llamada con __counted_by(size). Al ejecutar memcpy, entry->size contiene información no válida del búfer de anillo, que en algunas circunstancias es cero, lo que desencadena un pánico del núcleo por desbordamiento del búfer. Rellene el campo de tamaño antes de ejecutar memcpy para que la comprobación de fuera de los límites conozca el tamaño correcto. Esto es análogo a __ftrace_trace_stack().