Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la desreferencia del puntero NULL en ice_update_vsi_tx_ring_stats() Es posible realizar la desreferencia del puntero NULL en la rutina que actualiza las estadísticas del anillo Tx. Actualmente, solo se actualizan las estadísticas y los bytes cuando el puntero del anillo es válido, pero más adelante se accede al anillo para propagar las estadísticas de Tx recopiladas en las estadísticas de VSI. Cambie la lógica existente para pasar al siguiente anillo cuando el anillo sea NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la condición de ejecución durante la esclavitud de la interfaz. El commit 5dbbbd01cbba83 ("ice: evita el bloqueo RTNL al recrear el dispositivo auxiliar") cambia el proceso de recreación del dispositivo auxiliar para que ice_plug_aux_dev( ) se llama desde el contexto ice_service_task(). Desafortunadamente, esto abre una ventana de ejecución que puede resultar en un punto muerto cuando la interfaz sale de LAG e inmediatamente ingresa a LAG nuevamente. Reproductor: ``` #!/bin/sh enlace ip agregar lag0 tipo modo de enlace 1 miimon 100 enlace ip configurar lag0 para n en {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` Esto da como resultado: [20976.208697] Cola de trabajo: ice ice_service_task [ice] [20976.213422] Seguimiento de llamadas: [20976.215871] __schedule+0x2d1/ 0x830 [20976.219364] programación+0x35/0xa0 [20976.222510] programación_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_de v_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core ] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] 0976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] sonda_bus_auxiliar+ 0x45/0x70 [20976.289790] very_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] adjuntar+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] dispositivo_add+0x43c/ 0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] 1] proceso_un_trabajo+0x1a7/0x360 [20976.350536] hilo_trabajador+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] tarea:ip estado:D pila: 0 pid:213658 ppid:213627 banderas:0x00004084 [20976.446469] Seguimiento de llamadas: 76.448921] __programación+0x2d1/ 0x830 [20976.452414] programación+0x35/0xa0 [20976.455559] programación_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364 dispositivo_del+0x36/0x 3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [hielo] [20976.472313 ] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0 x1790 [vinculación] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529 /0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] _unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] call_64+0x5b/0x1a0 [20976.613598] Entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Comando 'ip link... set nomaster' provoca que se llame a ice_plug_aux_dev() desde el contexto ice_service_task(), se crea el dispositivo auxiliar y se toma el dispositivo asociado->bloqueo. 2. El comando 'ip link... set master...' llama al notificador de ice bajo bloqueo RTNL y ese notificador llama a ice_unplug_aux_dev(). Esa función intenta tomar el dispositivo auxiliar->bloqueo, pero esto ya lo tomó ice_plug_aux_dev() en el paso 1 3. Más tarde, ice_plug_aux_dev() intenta tomar el bloqueo RTNL pero esto ya lo tomó en el paso 2 4. Bloqueo muerto El parche soluciona esto problema mediante los siguientes cambios: - El bit ICE_FLAG_PLUG_AUX_DEV se mantiene configurado durante la llamada a ice_plug_aux_dev() en ice_service_task() - El bit se verifica en ice_clear_rdma_cap() y solo si no está configurado, se llama a ice_unplug_aux_dev(). l ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_core: corrige la fuga de sent_cmd skb La memoria sent_cmd no se libera antes de liberar hci_dev, lo que provoca que se filtre su contenido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: MIPS: smp: complete los mapas de hermanos y núcleos antes Después de habilitar CONFIG_SCHED_CORE (aterrizado durante el ciclo 5.14), se inició interAptiv de 2 núcleos y 2 subprocesos por núcleo (controlado por CPS) emitiendo lo siguiente: [0.025698] La revisión de CPU1 es: 0001a120 (MIPS interAptiv (multi)) [0.048183] ------------[ cortar aquí ]------------ [0.048187] ADVERTENCIA: CPU: 1 PID: 0 en kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [0.048220] Módulos vinculados en: [0.048233] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 5.17 .0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [0.048247] Pila: 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc 4 00000000 00000000 00000000 00000000 00000000 [ 0,048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... 0.048396] Seguimiento de llamadas: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60 /0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] 198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting +0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] _secundario+0xbc/0x280 [ 0,048539] [ 0,048543] - --[ end trace 0000000000000000 ]--- [ 0.048636] Sincronizar contadores para CPU 1: hecho. ...para cada uno menos CPU 0/arranque. Las impresiones de depuración básicas justo antes de la línea mencionada dicen: [0.048170] CPU: 1, smt_mask: Entonces smt_mask, que obviamente es una máscara hermana, está vacía al ingresar a la función. Esto es crítico, ya que sched_core_cpu_starting() calcula los parámetros de programación central solo una vez por inicio de CPU, y es crucial tener todos los parámetros completados en ese momento (al menos usa cpu_smt_mask() que de hecho es `&cpu_sibling_map[cpu]` en MIPS). Un poco de depuración me llevó a que set_cpu_sibling_map() realizaba el cálculo del mapa real, se invocaba después de notify_cpu_start(), y exactamente la última función inicia la ronda de devolución de llamada de CPU HP (sched_core_cpu_starting() es básicamente una devolución de llamada de CPU HP). Si bien el flujo es el mismo en ARM64 (mapas después del notificador, aunque antes de llamar a set_cpu_online()), x86 comenzó a calcular mapas de hermanos antes de iniciar las devoluciones de llamada de CPU HP en Linux 4.14 (consulte [0] para la referencia). Ni yo ni mis breves pruebas pudimos encontrar posibles advertencias al calcular los mapas justo después de realizar la calibración de retraso, pero el símbolo WARN ya no está. Las mismas impresiones de depuración ahora producen exactamente lo que esperaba de ellas: [0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips /linux.git/commit/?id=76ce7cfe35ef

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: liberar estructuras rq qos para cola sin disco blkcg_init_queue() puede agregar estructuras rq qos para solicitar cola, previamente blk_cleanup_queue() llama a rq_qos_exit() para liberarlas, pero commit 8e141f9eb803 ( "bloque: drenar la E/S del sistema de archivos en del_gendisk") mueve rq_qos_exit() a del_gendisk(), por lo que la pérdida de memoria se debe a que es posible que las colas no tengan disco, como los luns scsi no presentes, la cola de administración de nvme, ... solucione el problema agregando rq_qos_exit() a blk_cleanup_queue() nuevamente. Por cierto, v5.18 ya no necesitará este parche ya que movemos blkcg_init_queue()/blkcg_exit_queue() al controlador de asignación/liberación de disco, y los parches han estado en for-5.18/block.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: watch_queue: corrige la verificación del límite del filtro En watch_queue_set_filter(), hay un par de lugares donde verificamos que el valor del tipo de filtro no exceda lo que puede contener el mapa de bits type_filter. Un lugar calcula el número de bits mediante: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) lo cual está bien, pero el segundo sí: if (tf[i].type >= sizeof( wfilter->type_filter) * BITS_PER_LONG) que no lo es. Esto puede provocar un par de escrituras fuera de los límites debido a un tipo demasiado grande: (1) __set_bit() en wfilter->type_filter (2) Escribir más elementos en wfilter->filters[] de los que asignamos. Solucione este problema simplemente usando el WATCH_TYPE__NR adecuado, que es la cantidad de tipos que realmente conocemos. El error puede provocar un error parecido a: ERROR: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740 Escritura de tamaño 4 en la dirección ffff88800d2c66bc mediante la tarea watch_queue_oob/611... Seguimiento de llamadas: dump_stack_lvl+ 0x45/0x59 print_address_description.constprop.0+0x1f/0x150 ... kasan_report.cold+0x7f/0x11b ... watch_queue_set_filter+0x659/0x740 ... __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entrada_ SYSCALL_64_after_hwframe+0x44/0xae Asignado por tarea 611: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 watch_queue_set_filter+0x23a/0x740 __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x 44/0xae La dirección con errores pertenece al objeto en ffff88800d2c66a0 que pertenece al caché kmalloc-32 de tamaño 32 La dirección con errores se encuentra a 28 bytes dentro de la región de 32 bytes [ffff88800d2c66a0, ffff88800d2c66c0)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vrr: establezca la propiedad con capacidad de VRR solo si está conectada al conector. La propiedad con capacidad de VRR no está conectada de manera predeterminada al conector. Se conecta solo si se admite VRR. Entonces, si el controlador intenta llamar a la función drm core set prop sin que esté adjunta, eso causa una desreferencia NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: omite la advertencia de bytes reservados al desmontar después de un error en la limpieza del registro Después de los cambios recientes realizados por El commit c2e39305299f01 ("btrfs: borra la actualización del búfer de extensión cuando no podemos escribirlo") y su corrección de seguimiento, commit 651740a5024117 ("btrfs: verifique WRITE_ERR al intentar leer un búfer de extensión"), ahora podemos terminar sin limpiar las reservas de espacio de los búferes de extensión del árbol de registro después de que se produzca una cancelación de transacción, además de no limpiar los búferes de extensión aún sucios. Esto sucede porque si falla la reescritura para un búfer de extensión de árbol de registro, entonces hemos borrado el bit EXTENT_BUFFER_UPTODATE del búfer de extensión y también hemos configurado el bit EXTENT_BUFFER_WRITE_ERR en él. Más adelante, al intentar liberar el árbol de registro con free_log_tree(), que itera sobre el árbol, podemos terminar obteniendo un error -EIO al intentar leer un nodo o una hoja, ya que read_extent_buffer_pages() devuelve -EIO si es una extensión. El búfer no tiene EXTENT_BUFFER_UPTODATE establecido y tiene el bit EXTENT_BUFFER_WRITE_ERR establecido. Obtener eso -EIO significa que regresamos inmediatamente ya que no podemos iterar sobre todo el árbol. En ese caso, nunca actualizamos el espacio reservado para un búfer de extensión en el grupo de bloques respectivo y el objeto space_info. Cuando esto sucede, obtenemos los siguientes rastros al desmontar el fs: [174957.284509] BTRFS: error (dispositivo dm-0) en cleanup_transaction:1913: errno=-5 IO Failure [174957.286497] BTRFS: error (dispositivo dm-0) en free_log_tree :3420: errno=-5 Fallo de E/S [174957.399379] ------------[ cortar aquí ]------------ [174957.402497] ADVERTENCIA: CPU: 2 PID: 3206883 en fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.407523] Módulos vinculados en: btrfs overlay dm_zero (...) [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tain Ted: GW 5.16.0-rc5-btrfs-next-109 #1 [174957.426689] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 [174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.429717] Código: 21 48 8b bd (...) [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206 [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8 [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000 [174957.436068] RBP: b0758edd000 R08: 0000000000000000 R09: 0000000000000000 [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: 8148 [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15 : muerto000000000100 [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000 [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0 [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [174957.443076] DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 000000400 [174957.443948] Seguimiento de llamadas: [174957.444264] [174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs] [174957.445238] close_ctree+0x301 /0x357 [btrfs] [174957.445803] ? call_rcu+0x16c/0x290 [174957.446250] generic_shutdown_super+0x74/0x120 [174957.446832] kill_anon_super+0x14/0x30 [174957.447305] btrfs_kill_super+0x12/0x20 [btrfs] 957.447890] desactivar_locked_super+0x31/0xa0 [174957.448440] cleanup_mnt+0x147/0x1c0 [174957.448888 ] task_work_run+0x5c/0xa0 [174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0 [174957.449934] syscall_exit_to_user_mode+0x16/0x40 [174957.450512] do_syscall_64+0x48/0 xc0 [174957.450980] Entry_SYSCALL_64_after_hwframe+0x44/0xae [174957.451605] RIP: 0033:0x7f328fdc4a97 [174957.452059] Código : 03 0c 00 f7 (...) [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ---truncado- --

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: usbtmc: corrige un error en la dirección de la tubería para las transferencias de control. El syzbot fuzzer informó un error menor en el controlador usbtmc: usb 5-1: directorio de control BOGUS, la tubería 80001e80 no coincide con bRequestType 0 ADVERTENCIA: CPU: 0 PID: 3813 en drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Módulos vinculados en: CPU: 0 PID: 3813 Comm : syz-executor122 No contaminado 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Seguimiento de llamadas: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core /message.c:102 [en línea] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [en línea] El problema es que usbtmc_ioctl_request() usa usb_rcvctrlpipe( ) para todas sus transferencias, ya sean de entrada o de salida. Es fácil de arreglar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: evitar doble fput() en copia de usuario fallida. Si la copia al área de usuario falla para FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), no debemos asumir que 'buf->dmabuf' aun es válido. De hecho, dma_buf_fd() llamó a fd_install() antes, es decir, "consumió" una referencia, dejándonos sin ninguna. Por lo tanto, llamar a dma_buf_put() colocará una referencia que ya no poseemos, lo que conducirá a una entrada válida en la tabla de descripción de archivos para un objeto 'archivo' ya publicado que es un use-after-free directo. Simplemente evite llamar a dma_buf_put() y confíe en el código de salida del proceso para realizar la limpieza necesaria, si es necesario, es decir, si el descriptor del archivo aún es válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: f_fs: corrige el use-after-free para epfile Considere un caso en el que se llama a ffs_func_eps_disable desde ffs_func_disable como parte del cambio de composición y al mismo tiempo se llama a ffs_epfile_release desde el espacio de usuario. ffs_epfile_release liberará el búfer de lectura y llamará a ffs_data_closed, que a su vez destruirá ffs->epfiles y lo marcará como NULL. Mientras esto sucedía, el controlador ya inicializó el archivo ep local en ffs_func_eps_disable, que ahora está liberado y esperando adquirir el spinlock. Una vez adquirido el spinlock, el controlador continúa con el valor obsoleto de epfile e intenta liberar el búfer de lectura ya liberado, lo que provoca un use-after-free. La siguiente es la ilustración de la ejecución: CPU1 CPU2 ffs_func_eps_disable epfiles (copia local) ffs_epfile_release ffs_data_closed if (último archivo cerrado) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock desreferenciar epfiles Arregle estas ejecucións tomando la copia local de epfiles y asignándola bajo spinlock y si epfiles(local) es null luego actualícelo en ffs->epfiles y finalmente destrúyalo. Ampliar el alcance más allá de la ejecución, proteger las estructuras relacionadas con ep y los accesos concurrentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: se solucionó el problema de recuento cuando se recibe el logotipo durante TMF. Se observó un seguimiento de llamada de tarea colgada durante el procesamiento del logotipo. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: RESET LUN emitido... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222 [0000] :00:00.0]:[qedf_initiate_tmf:2438 ]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: informe 016900: Solicitud de logotipo recibida mientras estaba en estado Listo [ 974.309627] host1: informe 016900: Eliminar puerto [ 974.309642] host1: Informe 016900: evento de trabajo 3 [ 974.309644] host1: informe 016900: devolución de llamada lld ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport se está cargando, no ejecutando descarga. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: comando de gestión de tarea exitoso... [ 984.031088] INFORMACIÓN: tarea jbd2/dm-15-8:7645 bloqueada durante más de 120 segundos. [ 984.031136] No contaminado 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Seguimiento de llamadas: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [984.031233]? bit_wait_timeout+0x90/0x90 [ 984.031235] programación+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] 80 [984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? terminar_esperar+0x80/0x80 [984.031291]? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 Hubo un problema de recuento de referencias cuando se recibe el logotipo durante TMF. Esto lleva a que una de las E/S se cuelgue con el controlador. Arreglar el recuento de árbitros.