Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btbcm: Se ha corregido la desreferencia NULL en btbcm_get_board_name(). devm_kstrdup() puede devolver un puntero NULL en caso de error, pero este valor devuelto en btbcm_get_board_name() no se comprueba. Se ha añadido la comprobación NULL en btbcm_get_board_name() para controlar el error de desreferencia de puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: se corrige la comprobación de deref NULL en mt7925_change_vif_links. En mt7925_change_vif_links(), devm_kzalloc() puede devolver NULL, pero este valor devuelto no se comprueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: core: Fix posture that Resolution Multipliers must be in Logical Collections Se descubrió que un informe de 2019 del fuzzer syzbot estaba relacionado con dos errores en el núcleo de HID asociados con Resolution Multipliers. Uno de los errores se solucionó con el commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multipler."), pero el otro no se solucionó. Este error surge porque hid_apply_multipler() asume que cada control Resolution Multiplier está contenido en una colección lógica, es decir, no hay forma de que la rutina pueda establecer multiplier_collection en NULL. Esto es a pesar del hecho de que la función comienza con un gran comentario que dice: * "El control Multiplicador de resolución debe estar contenido en la misma * Colección lógica que el control o los controles a los que se aplicará. ... * Si no se define ninguna Colección lógica, el Multiplicador de resolución se asocia con todos los * controles del informe". * Tabla de uso de HID, v1.12, Sección 4.3.1, p30 * * Por lo tanto, busque desde la colección actual hacia arriba hasta que encontremos una * colección lógica... El comentario y el código pasan por alto la posibilidad de que ninguna de las colecciones encontradas pueda ser una Colección lógica. La solución es establecer el puntero multiplier_collection en NULL si la colección encontrada no es una Colección lógica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: th1520: Se corrige la corrupción de memoria debido a un tamaño de matriz incorrecto Las funciones th1520_mbox_suspend_noirq y th1520_mbox_resume_noirq tienen como objetivo guardar y restaurar los registros de máscara de interrupción en MBOX ICU0. Sin embargo, la matriz utilizada para almacenar estos registros tenía un tamaño incorrecto, lo que provocaba una corrupción de memoria al acceder a los cuatro registros. Esta confirmación corrige el tamaño de la matriz para acomodar los cuatro registros de máscara de interrupción, lo que evita la corrupción de memoria durante las operaciones de suspensión y reanudación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: dw: Arregla el use after free en el controlador dw_i3c_master debido a una condición de ejecución En dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work. If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dw_i3c_hj_work dw_i3c_common_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Solucione el problema asegurándose de que el trabajo se cancele antes de continuar con la depuración en dw_i3c_common_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: qcom: scm: Limpieza de la variable global '__scm' en caso de fallos en la sonda Si el controlador SCM hace que la sonda falle, no debería dejar asignada la variable global '__scm', porque los usuarios externos de este controlador asumirán que la sonda finalizó correctamente. Por ejemplo, las partes TZMEM ('__scm->mempool') se inicializan más tarde en la sonda, pero los usuarios de esta (__scm_smc_call()) dependen de la variable '__scm'. Esto corrige la excepción teórica del puntero NULL, activada mediante la introducción de un aplazamiento de la sonda en el controlador SCM con seguimiento de llamadas: qcom_tzmem_alloc+0x70/0x1ac (P) qcom_tzmem_alloc+0x64/0x1ac (L) qcom_scm_assign_mem+0x78/0x194 qcom_rmtfs_mem_probe+0x2d4/0x38c platform_probe+0x68/0xc8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: state: fix out-of-limits read during lookup lookup and resize can run in parallel. El xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Solucione esto al precargar state_hmask y los punteros asociados. El reintento de seqlock xfrm_state_hash_generation asegurará que el puntero y el hmask sean consistentes. Los ayudantes existentes, como xfrm_dst_hash(), ahora no son seguros para el lado de RCU, agregue afirmaciones lockdep para documentar que solo son seguros para el lado de inserción. xfrm_state_lookup_byaddr() usa el bloqueo giratorio en lugar de RCU. AFAICS esto es un descuido de cuando la búsqueda de estado se convirtió a RCU, este bloqueo debe reemplazarse con RCU en un parche futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: uvcvideo: Se soluciona la doble liberación en la ruta de error Si la función uvc_status_init() no puede asignar el int_urb, liberará el puntero dev->status pero no restablecerá el puntero a NULL. Esto hace que la llamada kfree() en uvc_status_cleanup() intente liberar la memoria dos veces. Arréglelo restableciendo el puntero dev->status a NULL después de liberarlo. Revisado por: Ricardo Ribalda

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pps: Se corrige un error de use after free. En una placa que ejecuta ntpd y gpsd, veo un error de use after free constante en sys_exit() desde gpsd al reiniciar: pps pps1: eliminado ------------[ cortar aquí ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...seguido de más síntomas de corrupción, con pilas similares: refcount_t: desbordamiento; use after free. ¡ERROR del kernel en lib/list_debug.c:62! Pánico del kernel - no sincroniza: Vaya - ERROR: Excepción fatal Esto sucede porque pps_device_destruct() libera el pps_device con el cdev integrado inmediatamente después de llamar a cdev_del(), pero, como señala el comentario anterior a cdev_del(), los fops para cdevs abiertos previamente aún se pueden llamar incluso después de que cdev_del() regrese. Creo que este error siempre ha estado ahí: no puedo explicar por qué de repente empezó a suceder cada vez que reinicio esta placa en particular. En el commit d953e0e837e6 ("pps: Arreglar un error de use after free al anular el registro de una fuente"), George Spelvin sugirió eliminar el cdev integrado. Esa parece la forma más sencilla de solucionarlo, así que he implementado su sugerencia, utilizando __register_chrdev() con pps_idr convirtiéndose en la fuente de verdad para la cual el menor corresponde a qué dispositivo. Pero ahora que pps_idr define la visibilidad del espacio de usuario en lugar de cdev_add(), debemos asegurarnos de que el recuento de referencias pps->dev no pueda llegar a cero mientras que el espacio de usuario aún pueda encontrarlo de nuevo. Entonces, la llamada idr_remove() se mueve a pps_unregister_cdev(), y pps_idr ahora contiene una referencia a pps->dev. pps_core: la fuente serial1 obtuvo cdev (251:1) <...> pps pps1: eliminado pps_core: anulando el registro de pps1 pps_core: desasignando pps1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Fix NULL pointer dereference on certain command aborts Si un comando se pone en cola en el TRB utilizable final de un segmento de anillo, el puntero de encolado avanza al TRB de enlace posterior y no más allá. Si el comando se aborta más tarde, cuando se maneja la finalización del aborto, el puntero de desencolado avanza al primer TRB del siguiente segmento. Si no se ponen en cola más comandos, xhci_handle_stopped_cmd_ring() ve que los punteros de anillo son desiguales y supone que hay un comando pendiente, por lo que llama a xhci_mod_cmd_timer() que se bloquea si cur_cmd era NULL. No intente configurar el temporizador si cur_cmd es NULL. El timbre de puerta posterior probablemente también sea innecesario, pero es inofensivo. Déjelo en paz. Probablemente se trate del error 219532, pero no se ha recibido confirmación. El problema se ha reproducido de forma independiente y se ha confirmado que se ha solucionado utilizando una MCU USB programada para anular la etapa de estado de SET_ADDRESS para siempre. Todo siguió funcionando normalmente después de varios fallos evitados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: tps6594: Corregir desbordamiento de enteros en sistemas de 32 bits El problema es que esto se multiplica en tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; La variable "tmp" es un s64 pero "offset" es un long en el rango (-277774)-277774. En sistemas de 32 bits, un long puede contener números de hasta aproximadamente dos mil millones. El número de TICKS_PER_HOUR es realmente grande, (32768 * 3600) o aproximadamente cien millones. Cuando comienza a multiplicar por cien millones, no tarda mucho en desbordar la marca de dos mil millones. Probablemente, la forma más segura de solucionar esto es cambiar el tipo de TICKS_PER_HOUR a long long porque es un número muy grande.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: lidiar con la ejecución entre el cambio de dirección del socket UDP y el rehash Si un socket UDP cambia su dirección local mientras recibe datagramas, como resultado de connect(), hay un período durante el cual una operación de búsqueda podría fallar en encontrarlo, después de que se cambie la dirección pero antes de que se actualicen el hash secundario (puerto y dirección) y el hash de cuatro tuplas (puertos y direcciones locales y remotos). Las cadenas de hash secundarias fueron introducidas por el commit 30fff9231fad ("udp: optimización de bind()") y, como resultado, se necesitó una operación de rehash para hacer que un socket enlazado sea accesible nuevamente después de un connect(). Esta operación fue introducida por el commit 719f835853a9 ("udp: agregar rehash en connect()") que, sin embargo, no es una solución completa: el socket se encontrará una vez que se complete el rehash, pero no mientras esté pendiente. Esto se nota con un servidor socat(1) en modo UDP4-LISTEN y un cliente que le envía datagramas. Después de que el servidor recibe el primer datagrama (cf. _xioopen_ipdgram_listen()), emite un connect() a la dirección del remitente, para establecer un flujo dirigido. Ahora, si el cliente, que se ejecuta en un subproceso de CPU diferente, envía un datagrama (posterior) mientras el socket del servidor cambia su dirección, pero aún no se vuelve a procesar, esto dará como resultado una búsqueda fallida y un error de puerto inalcanzable entregado al cliente, como se desprende del siguiente reproductor: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null done donde el cliente eventualmente obtendrá ECONNREFUSED en un write() (normalmente el segundo o tercero de una iteración dada): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection denied Este problema se observó por primera vez como una falla poco frecuente en las pruebas de Podman que verificaban la funcionalidad de UDP mientras se usaba pasta(1) para conectar el espacio de nombres de red del contenedor, lo que nos lleva a un reproductor con el error de búsqueda que resulta en un paquete ICMP en un dispositivo tap: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ: char 8193, line 29 we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp---truncada---