Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: agregar exclusión mutua en proc_sctp_do_udp_port() Debemos serializar las llamadas a sctp_udp_sock_stop() y sctp_udp_sock_start() o corremos el riesgo de un bloqueo como informó syzbot: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 No contaminado 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(completo) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/02/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 Rastreo de llamadas: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [en línea] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [en línea] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [en línea] __se_sys_sendfile64 fs/read_write.c:1415 [en línea] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlabel: Se corrige la excepción de puntero nulo causada por CALIPSO en sockets IPv4. Al llamar a netlbl_conn_setattr(), se utiliza addr->sa_family para determinar el comportamiento de la función. Si sk es un socket IPv4, pero se llama a la función connect con una dirección IPv6, se activa la función calipso_sock_setattr(). Dentro de esta función, se ejecuta el siguiente código: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Dado que sk es un socket IPv4, pinet6 es NULL, lo que provoca una desreferencia de puntero nulo. Este parche corrige el problema comprobando si inet6_sk(sk) devuelve un puntero nulo antes de acceder a pinet6.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: Se corrige el error "Oops" tras la desconexión en USB de Agilent. Si se desconecta la llave USB de Agilent, las llamadas posteriores al controlador provocan una desreferencia "Oops" nula, ya que bus_interface se establece en nulo al desconectarse. Este problema se originó al configurar "usb_dev" desde bus_interface para los mensajes "dev_xxx". Anteriormente, bus_interface solo se verificaba para detectar valores nulos en las funciones que invocaban directamente usb_fill_bulk_urb o usb_control_msg. Compruebe que bus_interface sea válido en todos los puntos de entrada de la interfaz y devuelva -ENODEV si es nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: Se corrige el error "Oops" tras la desconexión en ni_usb. Si la llave USB se desconecta, las llamadas posteriores al controlador provocan una desreferencia "Oops" a NULL, ya que bus_interface se establece en NULL al desconectarse. Este problema se introdujo al configurar "usb_dev" desde bus_interface para los mensajes "dev_xxx". Anteriormente, bus_interface solo se verificaba para NULL en las funciones que llamaban directamente a usb_fill_bulk_urb o usb_control_msg. Compruebe si bus_interface es válido en todos los puntos de entrada de la interfaz y devuelva -ENODEV si es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ibmveth: hacer que veth_pool_store deje de bloquearse v2: - Se creó un único error al gestionar el desbloqueo y la salida en veth_pool_store - Mensaje de confirmación muy ampliado con texto previo solo explicativo Resumen: Use rtnl_mutex para sincronizar veth_pool_store consigo mismo, ibmveth_close e ibmveth_open, lo que impide varias llamadas seguidas a napi_disable. Antecedentes: Dos (o más) subprocesos podrían llamar a veth_pool_store escribiendo en /sys/devices/vio/30000002/pool*/*. Puede hacerlo fácilmente con un pequeño script de shell. Esto provoca un bloqueo. Configuré LOCKDEP, compilé ibmveth.c con DEBUG y compilé un nuevo kernel. Ejecuté esta prueba nuevamente y vi: Configurando pool0/active a 0 Configurando pool1/active a 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: cerrar iniciando Configurando pool1/active a 1 Configurando pool1/active a 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: cerrar iniciando [ 73.916056][ T4365] ibmveth 30000002 eth0: cerrar completo [ 73.916064][ T4365] ibmveth 30000002 eth0: abrir iniciando [ 110.808564][ T712] systemd-journald[712]: Se envió la notificación WATCHDOG=1. [ 230.808495][ T712] systemd-journald[712]: Se envió la notificación WATCHDOG=1. [ 243.683786][ T123] INFO: la tarea stress.sh:4365 estuvo bloqueada durante más de 122 segundos. [ 243.683827][ T123] No contaminado 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [ 243.683838][ T123] tarea:stress.sh estado:D pila:28096 pid:4365 tgid:4365 ppid:4364 indicadores_de_tarea:0x400040 indicadores:0x00042000 [ 243.683852][ T123] Rastreo de llamadas: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (no confiable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [243.683913][T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [243.683921][T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [243.683928][T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Mostrando todos los bloqueos mantenidos en el sistema: [ 243.684095][ T123] 1 bloqueo mantenido por khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, en: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 bloqueos mantenidos por stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, en: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, en: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, en: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, en: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 bloqueos mantenidos por stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, en: ksys_write+0x88/0x150 [ 243. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: BPF: No anule el valor de retorno del subprograma La prueba del verificador `calls: div by 0 in subprog` desencadena un pánico en la instrucción ld.bu. La instrucción ld.bu insn intenta cargar un byte desde la dirección de memoria devuelta por el subprograma. El subprograma en realidad estableció la dirección correcta en el registro a5 (registro dedicado para valores de retorno de BPF). Pero en el commit 73c359d1d356 ("LoongArch: BPF: Valores de retorno con signo extendido") también firmamos a5 extendido en el registro a0 (valor de retorno en LoongArch). Para la instrucción de llamada a función insn, luego propagamos el registro a0 de vuelta al registro a5. Esto es correcto para llamadas nativas, pero incorrecto para llamadas bpf2bpf que esperan un valor de retorno extendido cero en el registro a5. Por lo tanto, solo mueva a0 a a5 para llamadas nativas (es decir, no BPF_PSEUDO_CALL).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/microcode/AMD: Se corrige el valor de retorno de __apply_microcode_amd() Cuando verify_sha256_digest() falla, __apply_microcode_amd() debe propagar la falla devolviendo falso (y no -1 que se promueve a verdadero).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uprobes/x86: endurecer la llamada al sistema uretprobe trampoline check Jann informó un posible problema cuando trampoline_check_ip devuelve una dirección cerca del final del espacio de direcciones que puede llamar a la llamada al sistema si no se configuran uretprobes: https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf Aunque las restricciones de dirección mínima de mmap normalmente evitarán la creación de asignaciones allí, asegurémonos de que la llamada al sistema uretprobe lo verifique.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Aumentar ARCH_DMA_MINALIGN hasta 16. ARCH_DMA_MINALIGN es 1 por defecto, pero algunos dispositivos específicos de LoongArch (como APBDMA) requieren una alineación de 16 bytes. Cuando la longitud del búfer de datos es demasiado pequeña, el hardware puede cometer un error al escribir la línea de caché. Por lo tanto, es peligroso asignar un búfer de memoria pequeño para DMA. Siempre es seguro definir ARCH_DMA_MINALIGN como L1_CACHE_BYTES, pero no es necesario (kmalloc() requiere objetos de memoria pequeños). Por lo tanto, simplemente auméntelo a 16.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet:fix NPE durante rx_complete. Falta la comprobación usbnet_going_away en la ruta crítica. La función usb_submit_urb carece de la validación usbnet_going_away, mientras que __usbnet_queue_skb sí la incluye. Esta inconsistencia crea una condición de ejecución donde: una solicitud URB puede ser exitosa, pero los datos SKB correspondientes no se ponen en cola. Los procesos posteriores (p. ej., rx_complete ? defer_bh ? __skb_unlink(skb, list)) intentan acceder a skb->next, lo que provoca una desreferencia de puntero nulo (pánico del kernel).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arcnet: Se ha añadido una comprobación de valores NULL en com20020pci_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, com20020pci_probe() no realiza la comprobación en este caso, lo que provoca una desreferencia de puntero NULL. Se ha añadido una comprobación de valores NULL después de devm_kasprintf() para evitar este problema y garantizar que no queden recursos asignados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix geneve_opt length entire entire struct geneve_opt usa una longitud de 5 bits para cada opción, lo que significa que cada opción de tamaño variable debe ser menor a 128 bytes. Sin embargo, ninguna de las políticas Netlink actuales relacionadas puede garantizar esta condición de longitud, y el atacante puede explotar una opción de tamaño exacto de 128 bytes para simular una opción de longitud cero y confundir la lógica de análisis, lo que a su vez provoca una lectura fuera de los límites del montón. Un ejemplo de registro de fallos es el siguiente: [3.905425] ======================================================================= [3.905925] ERROR: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Solucione estos problemas aplicando la condición de longitud correcta en las políticas relacionadas.