Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: sch_sfq: no permitir límite de 1 paquete La implementación actual no funciona correctamente con un límite de 1. iproute2 en realidad verifica esto y este parche también agrega la verificación en el kernel. Esto corrige el siguiente fallo informado por syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. En este punto, asumiendo que no hay más paquetes en cola, cuando sch_dequeue se ejecute nuevamente, disminuirá el qlen para la ranura vacía actual, lo que provocará un desbordamiento y el posterior acceso fuera de límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wcn36xx: se corrige el tamaño de asignación de memoria de la encuesta de canal KASAN informó un problema de asignación de memoria en wcn->chan_survey debido a un cálculo de tamaño incorrecto. Esta confirmación utiliza kcalloc para asignar memoria para wcn->chan_survey, lo que garantiza una inicialización adecuada y evita el uso de valores no inicializados cuando no hay marcos en el canal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: OPP: agregar comprobación de índice a assert para evitar el desbordamiento de búfer en _read_freq() Pasar el índice freq a la función assert para asegurarnos de que no leemos un freq de la tabla opp->rates[] cuando se llama desde las variantes indexadas: dev_pm_opp_find_freq_exact_indexed() o dev_pm_opp_find_freq_ceil/floor_indexed(). Agregar un parámetro secundario a la función assert, no utilizado para assert_single_clk() y luego agregar assert_clk_index() que verificará el índice del reloj cuando se llame desde las funciones de búsqueda _indexed().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: verificación de NULL en btrtl_setup_realtek() Si se inserta un dispositivo USB cuyo chip no se mantiene en ic_id_table, se alcanzará el punto NULL al que se accedió. Agregue una verificación de punto nulo para evitar el error de kernel.

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