Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: estructura de gadget libre solo después de liberar los puntos finales. Como parte de el commit e81a7018d93a ("usb: dwc3: asignar estructura de gadget dinámicamente"), se agregó dwc3_gadget_release() que libere la estructura dwc->gadget al retirar el dispositivo cuando se llama a usb_del_gadget_udc() en dwc3_gadget_exit(). Sin embargo, simplemente liberar el gadget da como resultado una situación de puntero colgante: los puntos finales creados en dwc3_gadget_init_endpoints() tienen sus miembros dep->endpoint.ep_list encadenados fuera del list_head anclado en dwc->gadget->ep_list. Por lo tanto, cuando se libera dwc->gadget, el primer dwc3_ep de la lista ahora tiene un puntero anterior colgante y lo mismo ocurre con el siguiente puntero de dwc3_ep al final de la lista. El dwc3_gadget_free_endpoints() que sigue dará como resultado un use-after-free cuando llame a list_del(). Esto se detectó habilitando KASAN y realizando una desvinculación del controlador. La reciente confirmación 568262bf5492 ("usb: dwc3: core: Add Shutdown Callback for dwc3") también expone esto como un pánico durante el apagado. Hay algunas posibilidades para solucionar este problema. Una podría ser realizar un list_del() del propio gadget->ep_list que lo elimine del resto de la cadena dwc3_ep. Otro enfoque es lo que hace este parche, al dividir la llamada usb_del_gadget_udc() en sus componentes separados "del" y "put". Esto permite llamar a dwc3_gadget_free_endpoints() antes de que el gadget se libere finalmente con usb_put_gadget().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: userfaultfd: publicar página en ruta de error para evitar BUG_ON Considere la siguiente secuencia de eventos: 1. Userspace emite un ioctl UFFD, que termina llamando a shmem_mfill_atomic_pte(). Contamos con éxito los bloques, usamos shmem_alloc_page(), pero luego copy_from_user() falla. Volvemos -ENOENT. No publicamos la página que asignamos. 2. Nuestra persona que llama detecta este código de error, intenta copiar_from_user() después de descartar mmap_lock y vuelve a intentarlo, volviendo a llamar a shmem_mfill_atomic_pte(). 3. Mientras tanto, digamos que otro proceso llenó los tmpfs que se estaban utilizando. 4. Entonces shmem_mfill_atomic_pte() no logra bloquear la cuenta esta vez y regresa inmediatamente, sin liberar la página. Esto desencadena un BUG_ON en nuestra persona que llama, que afirma que la página siempre debe consumirse, a menos que se devuelva -ENOENT. Para solucionar este problema, detectar si tenemos esa página "colgante" cuando falla la contabilidad y, en caso afirmativo, liberarla antes de regresar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hfsplus: evita la corrupción al reducir y truncar Creo que hay algunos problemas introducidos por el commit 31651c607151 ("hfsplus: evita el punto muerto en el truncamiento de archivos") HFS+ tiene registros de extensión que siempre contienen 8 extensiones. En caso de que el primer registro de extensión en el archivo de catálogo se llene, se asignan nuevos registros desde el archivo de desbordamiento de extensiones. En caso de que se produzca un truncamiento reducido en la mitad de un registro de extensión que se ubica en un archivo de desbordamiento de extensiones, la lógica en hfsplus_file_truncate() se cambió para que la llamada a hfs_brec_remove() ya no esté protegida. La acción correcta sería simplemente liberar las extensiones que exceden el nuevo tamaño dentro del registro de extensión llamando a hfsplus_free_extents() y luego verificar si se debe eliminar todo el registro de extensión. Sin embargo, dado que la guardia (blk_cnt > start) está ahora después de la llamada a hfs_brec_remove(), esto tiene el efecto desafortunado de que el último registro de extensión coincidente se elimina incondicionalmente. Para reproducir este problema, cree un archivo que tenga al menos 10 extensiones y luego realice un truncamiento reducido hasta la mitad del último registro de extensión, de modo que el número de extensiones restantes no sea menor o divisible por 8. Esto hace que el último registro de extensión ( 8 extensiones) para eliminarse por completo en lugar de truncarse a la mitad. Por tanto, esto provoca corrupción y pérdida de datos. La solución para esto es simplemente verificar si el nuevo final truncado está debajo del inicio de este registro de extensión, lo que hace que sea seguro eliminar el registro de extensión completo. Sin embargo, la llamada a hfs_brec_remove() no se puede mover a su lugar anterior ya que estamos eliminando ->tree_lock y puede provocar una condición de ejecución y la invalidación de la información almacenada en caché, posiblemente corrompiendo los datos del nodo. Otro tema está relacionado con éste. Al ingresar al bloque (blk_cnt > start) no mantenemos ->tree_lock. Salimos del bucle sin mantener el bloqueo, pero hfs_find_exit() lo desbloquea. No estoy seguro de si es posible que otra persona tome el bloqueo bajo nuestros pies, pero puede causar errores difíciles de depurar y desbloqueo prematuro. Aunque no exista ningún riesgo real, el bloqueo siempre debe mantenerse en equilibrio. Tomando así el candado ahora justo antes del control.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: soluciona fallas al alternar la barrera de descarga de entrada. La mitigación de descarga de entrada se puede habilitar/deshabilitar en tiempo de ejecución a través de un archivo debugfs (entry_flush), lo que hace que el kernel se parchee a sí mismo. habilitar/deshabilitar las mitigaciones relevantes. Sin embargo, dependiendo de la mitigación que estemos usando, puede que no sea seguro aplicar ese parche mientras otras CPU están activas. Por ejemplo, el siguiente bloqueo: durmiente[15639]: segfault (11) en c000000000004c20 nip c000000000004c20 lr c000000000004c20 Muestra que regresamos al espacio de usuario con un LR corrupto que apunta al kernel, debido a la ejecución de la llamada parcialmente parcheada a la entrada de respaldo descarga ( es decir, nos perdimos la restauración de LR). Arréglelo haciendo el parche debajo de detener la máquina. Las CPU que no estén aplicando los parches girarán en el núcleo de la lógica de detención de la máquina. Actualmente, eso es suficiente para nuestros propósitos, porque ninguno de los parches que hacemos se aplica a ese código ni a ningún lugar cercano.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se corrige use-after-free en i40e_client_subtask() Actualmente la llamada a i40e_client_del_instance libera el objeto pf->cinst, sin embargo se accede a pf->cinst->lan_info después de gratis. Solucione este problema agregando la declaración que falta. Direcciones-Cobertura: ("Leer desde el puntero después de estar libre")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: evitar desbordamientos en nft_hash_buckets() Número de depósitos almacenados en variables de 32 bits, debemos asegurarnos de que no se produzcan desbordamientos en nft_hash_buckets() syzbot inyectó un tamaño == 0x40000000 e informó: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack +0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [en línea] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [en línea] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [en línea] nf_tables_newset+0xe62 /0x3110 net/filtro de red /nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/ netlink/af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg +0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d /0x70 arco/x86/entry/common.c:46

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched: corrige el acceso fuera de los límites en uclamp Util-clamp coloca las tareas en diferentes depósitos según sus valores de fijación por razones de rendimiento. Sin embargo, el tamaño de los depósitos se calcula actualmente mediante una división de redondeo, lo que puede provocar un error de uno por uno en algunas configuraciones. Por ejemplo, con 20 depósitos, el tamaño del depósito será 1024/20=51. Una tarea con una abrazadera de 1024 se asignará al ID del depósito 1024/51=20. Lamentablemente, los índices correctos están en el rango [0,19], lo que provoca un acceso a la memoria fuera de los límites. Sujete la identificación del depósito para solucionar el problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcp251x: corregir la reanudación desde la suspensión antes de que se activara la interfaz. Desde 8ce8c0abcba3, las colas de controladores funcionan a través de priv->restart_work cuando se reanudan después de la suspensión, incluso cuando la interfaz no estaba habilitada previamente. Esto provoca un error de desreferencia nula ya que la cola de trabajo solo se asigna e inicializa en mcp251x_open(). Para solucionar este problema, movemos el inicio de la cola de trabajo a mcp251x_can_probe() ya que no hay razón para hacerlo más tarde y repetirlo cada vez que se llama a mcp251x_open(). [mkl: corregir el manejo de errores en mcp251x_stop()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcp251xfd: mcp251xfd_probe(): corrige una desreferencia de puntero de error en la sonda Cuando convertimos este código para usar dev_err_probe() eliminamos accidentalmente un retorno. Significa que si devm_clk_get() generará un Ups cuando llamemos a clk_get_rate() en la siguiente línea.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto al clonar extensiones en línea y usar qgroups. Hay algunos casos excepcionales en los que la clonación de una extensión en línea necesita copiar los datos de la extensión en línea en una página del inodo de destino. Cuando esto sucede, terminamos iniciando una transacción mientras tenemos una página sucia para el inodo de destino y también tenemos el rango bloqueado en el iotree del inodo de destino. Debido a que al reservar espacio de metadatos para una transacción, es posible que necesitemos vaciar la delalloc existente en caso de que no haya suficiente espacio libre, contamos con un mecanismo para evitar un punto muerto, que se introdujo en el commit 3d45f221ce627d ("btrfs: corrige el punto muerto al clonar en línea extensión y poco espacio libre para metadatos"). Sin embargo, cuando se utilizan qgroups, una transacción también reserva espacio de metadatos en qgroup, lo que también puede provocar la eliminación de delalloc en caso de que no haya suficiente espacio disponible en este momento. Cuando esto sucede, nos bloqueamos, ya que vaciar delalloc requiere bloquear el rango de archivos en el iotree del inodo y el rango ya estaba bloqueado al comienzo de la operación de clonación, antes de intentar iniciar la transacción. Cuando ocurre este problema, se informan seguimientos de pila como los siguientes: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs- 1142) [72747.556271] Seguimiento de llamadas: [72747.556273] __schedule+0x296/0x760 [72747.556277] Schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __ lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extend_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extend_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747 .556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410 ] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] proceso_one_work+0x1aa/0x340 [72747.556426] trabajador_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Cola de trabajo: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Seguimiento de llamadas: [72747.566964] __s programar+0x296/0x760 [72747.566968] ? terminar_esperar+0x80/0x80 [72747.566970] programar+0x3c/0xa0 [72747.566995] esperar_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? Finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051]? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extend_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extend_writepages+0x44/0xa0 [btrfs] [72747.567137]? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs ] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] proceso_one_work+0x1aa/ 0x340 [72747.567202] hilo_trabajador+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211]? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] tarea:fsstress estado:D pila: ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: xiic: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en xiic_xfer y xiic_i2c_remove. Sin embargo, pm_runtime_get_sync incrementará el recuento de referencias de PM incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. Reemplácelo con pm_runtime_resume_and_get para mantener el contador de uso equilibrado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: stm32f7: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en estas funciones serias stm32f7_i2c_xx. Sin embargo, pm_runtime_get_sync incrementará el recuento de referencias de PM incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. Reemplácelo con pm_runtime_resume_and_get para mantener el contador de uso equilibrado.