Vulnerabilidades

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: 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: 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: 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---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: realizar una depuración de folio adecuada cuando falla run_delalloc_nocow() [ERROR] Con CONFIG_DEBUG_VM establecido, el caso de prueba genérico/476 tiene alguna posibilidad de bloquearse con el siguiente VM_BUG_ON_FOLIO(): BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28 BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28 page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664 aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774" flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff) page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) ------------[ cut here ]------------ kernel BUG at mm/page-writeback.c:2992! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G OE 6.12.0-rc7-custom+ #87 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : folio_clear_dirty_for_io+0x128/0x258 lr : folio_clear_dirty_for_io+0x128/0x258 Call trace: folio_clear_dirty_for_io+0x128/0x258 btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs] __process_folios_contig+0x154/0x268 [btrfs] extent_clear_unlock_delalloc+0x5c/0x80 [btrfs] run_delalloc_nocow+0x5f8/0x760 [btrfs] btrfs_run_delalloc_range+0xa8/0x220 [btrfs] writepage_delalloc+0x230/0x4c8 [btrfs] extent_writepage+0xb8/0x358 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x178/0x3a8 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] The first two lines of extra debug messages show the problem is caused by the error handling of run_delalloc_nocow(). E.g. we have the following dirtied range (4K blocksize 4K page size): 0 16K 32K |//////////////////////////////////////| | Pre-allocated | And the range [0, 16K) has a preallocated extent. - Enter run_delalloc_nocow() for range [0, 16K) Which found range [0, 16K) is preallocated, can do the proper NOCOW write. - Enter fallback_to_fow() for range [16K, 32K) Since the range [16K, 32K) is not backed by preallocated extent, we have to go COW. - cow_file_range() failed for range [16K, 32K) So cow_file_range() will do the clean up by clearing folio dirty, unlock the folios. Now the folios in range [16K, 32K) is unlocked. - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow() Which is called with PAGE_START_WRITEBACK to start page writeback. Pero los folios solo se pueden marcar como escritura diferida cuando están correctamente bloqueados, por lo que esto activó VM_BUG_ON_FOLIO(). Además, hay otro error oculto pero común: run_delalloc_nocow() no borra las banderas de folio sucio en su ruta de gestión de errores. Este es el error común compartido entre run_delalloc_nocow() y cow_file_range(). [FIX] - Limpiar el folio sucio para el rango [@start, @cur_offset) Introducir un ayudante, cleanup_dirty_folios(), que encontrará y bloqueará el folio en el rango, limpiará la bandera sucia y comenzará/finalizará la escritura diferida, con el manejo adicional para @locked_folio. - Introducir un ayudante para limpiar el folio sucio, iniciar y finalizar la escritura diferida - Introducir un ayudante para registrar el último final del rango COW fallido Esto es para rastrear qué rango debemos omitir, para evitar el doble desbloqueo. - Omitir el rango COW fallido para el e ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: realiza una limpieza de folio adecuada cuando falla cow_file_range() [ERROR] Al probar con la corrección de COW marcada como BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Desafortunadamente, este error de gestión de errores se remonta a la introducción de btrfs. Afortunadamente, con el abuso de la corrección de COW, al menos no bloqueará el kernel. [SOLUCIÓN] En lugar de desbloquear inmediatamente la extensión y los folios, mantenemos la extensión y los folios bloqueados hasta que se produzca un error o hasta que finalice todo el rango de deslocalización. Cuando finaliza todo el rango de deslocalización sin errores, simplemente desbloqueamos todo el rango con PAGE_SET_ORDERED (y PAGE_UNLOCK para los casos !keep_locked) ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rdma/cxgb4: Evitar un posible desbordamiento de enteros en 32 bits La variable "gl->tot_len" está controlada por el usuario. Proviene de process_responses(). En sistemas de 32 bits, la adición "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" podría tener un error de envoltura de enteros. Utilice size_add() para evitar esto.