Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-am62: corrige el comportamiento de descarga/recarga del módulo. Como el PM en tiempo de ejecución está habilitado, el tiempo de ejecución del módulo se puede suspender cuando se llama a .remove(). Realice pm_runtime_get_sync() para asegurarse de que el módulo esté activo antes de realizar cualquier operación de registro. Hacer pm_runtime_put_sync() debería deshabilitar refclk, por lo que no es necesario deshabilitarlo nuevamente. Corrige la siguiente advertencia al eliminar el módulo. [39.705310] ------------[ cortar aquí ]------------ [ 39.710004] clk:162:3 ya deshabilitado [ 39.713941] ADVERTENCIA: CPU: 0 PID : 921 en drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 Llamamos a of_platform_populate() en .probe(), así que llame a la función de limpieza of_platform_depopulate() en .remove(). Deshágase del ahora innecesario dwc3_ti_remove_core(). Sin esto, la recarga del módulo no funciona correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: agregar manejo de errores en xhci_map_urb_for_dma Actualmente, xhci_map_urb_for_dma() crea un búfer temporal y copia la lista SG en el nuevo búfer lineal. Pero si kzalloc_node() falla, entonces el siguiente sg_pcopy_to_buffer() puede provocar un fallo ya que intenta memcpy al puntero NULL. Entonces devuelve -ENOMEM si kzalloc devuelve un puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: corrige UAF en escrituras directas En producción hemos estado recibiendo la siguiente advertencia constantemente ------------[ cortar aquí ]----- ------- refcount_t: desbordamiento insuficiente; use-after-free. ADVERTENCIA: CPU: 17 PID: 1800359 en lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Cola de trabajo: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Llamada Seguimiento: ? __advertir+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0? report_bug+0xcc/0x150? handle_bug+0x3d/0x70? exc_invalid_op+0x16/0x40? asm_exc_invalid_op+0x16/0x20? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] Process_one_work+0x12f/0x4a0 trabajador_thread+0x14e/0x3b0? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 Esto se debe a que estamos completando nfs_direct_request dos veces seguidas. La fuente de esto es cuando tenemos que enviar nuestras solicitudes de confirmación, las procesamos y las enviamos, y luego en la ruta de finalización para las solicitudes de confirmación tenemos if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); Sin embargo, dado que enviamos solicitudes asincrónicas, a veces tenemos una que se completa antes de enviar la siguiente, por lo que terminamos llamando a complete en nfs_direct_request dos veces. El único otro lugar donde usamos nfs_generic_commit_list() es en __nfs_commit_inode, que envuelve esta llamada en nfs_commit_begin(); nfs_commit_end(); Este es un patrón común para este estilo de manejo de finalización, uno que también se repite en el código directo con llamadas get_dreq()/put_dreq() en el lugar donde procesamos eventos, así como en las rutas de finalización. Solucione este problema utilizando el mismo patrón para las solicitudes de confirmación. Antes, con mi estrés de rocksdb de 200 nodos ejecutándose, esta advertencia aparecía cada 10 minutos. Con mi parche, la prueba de esfuerzo ha estado funcionando durante varias horas sin aparecer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: swap: corrige la ejecución entre free_swap_and_cache() y swapoff() Anteriormente existía una ventana teórica donde swapoff() podía ejecutar y desmantelar un swap_info_struct mientras se realizaba una llamada a free_swap_and_cache(). corriendo en otro hilo. Esto podría causar, entre otras malas posibilidades, que swap_page_trans_huge_swapped() (llamado por free_swap_and_cache()) acceda a la memoria liberada para swap_map. Este es un problema teórico y no he podido provocarlo a partir de un caso de prueba. Pero ha habido un acuerdo basado en la revisión del código de que esto es posible (ver enlace a continuación). Solucionarlo usando get_swap_device()/put_swap_device(), lo que detendrá swapoff(). Hubo una verificación adicional en _swap_info_get() para confirmar que la entrada de intercambio no era gratuita. Esto no está presente en get_swap_device() porque en general no tiene sentido debido a la ejecución entre obtener la referencia y el intercambio. Así que agregué una verificación equivalente directamente en free_swap_and_cache(). Detalles de cómo provocar un posible problema (gracias a David Hildenbrand por derivar esto): --8<----- __swap_entry_free() podría ser el último usuario y dar como resultado "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() se detendrá tan pronto como si->inuse_pages==0. Entonces la pregunta es: ¿alguien podría reclamar la publicación y activar si->inuse_pages==0, antes de que completemos swap_page_trans_huge_swapped()? Imagine lo siguiente: folio de 2 MiB en el swapcache. Sólo 2 subpáginas siguen siendo referencias mediante entradas de intercambio. El proceso 1 todavía hace referencia a la subpágina 0 mediante la entrada de intercambio. El proceso 2 todavía hace referencia a la subpágina 1 mediante la entrada de intercambio. El proceso 1 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE [luego, adelantado en el hipervisor, etc.] El proceso 2 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE El proceso 2 continúa, pasa swap_page_trans_huge_swapped() y llama a __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); ¿Qué impide que el intercambio tenga éxito después de que el proceso 2 recuperó el caché de intercambio pero antes de que el proceso 1 terminara su llamada a swap_page_trans_huge_swapped()? --8<-----

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac802154: corrige la liberación de recursos de clave llsec en mac802154_llsec_key_del mac802154_llsec_key_del() puede liberar recursos de una clave directamente sin seguir las reglas de RCU para esperar antes del final de un período de gracia. Esto puede llevar a un use-after-free en caso de que llsec_lookup_key() esté recorriendo la lista de claves en paralelo con una eliminación de clave: refcount_t: suma en 0; use-after-free. ADVERTENCIA: CPU: 4 PID: 16000 en lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Módulos vinculados en: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Nombre de hardware: PC estándar QEMU ( i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Seguimiento de llamadas: llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_ cifrar+ 0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __ sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Además, Las estructuras ieee802154_llsec_key_entry no son liberadas por mac802154_llsec_key_del(): objeto sin referencia 0xffff8880613b6980 (tamaño 64): comm "iwpan", pid 2176, jiffies 4294761134 (edad 60,475 s) volcado hexadecimal (primeros 32 bytes): 8 0d 8f 18 80 88 y siguientes y siguientes 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ........... ..... retroceso: [] __kmem_cache_alloc_node+0x1e2/0x2d0 [] kmalloc_trace+0x25/0xc0 [] mac802154_llsec_key_add+0xac9/0xcf0 ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [] nl802154_add_llsec_key+0x426/0x5b0 [] genl_family_rcv_msg_doit+0x1fe/0x2f0 [] genl_rcv_msg+0x531/0x7d0 [] netlink_rcv_skb+0x169/0x440 [] genl_rcv+0x28/0x40 [] netlink_unicast+0x53c/0x820 [] netlink_sendmsg+0x93b/0xe60 [] ____sys_sendmsg+0xac5/0xca0 [] ___sys_sendmsg+0x11d/0 x1c0 [] __sys_sendmsg+0xfa/0x1d0 [] do_syscall_64+0x45/0xf0 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Maneja la liberación adecuada de recursos en la función de devolución de llamada de RCU mac802154_llsec_key_del_rcu(). Tenga en cuenta que si llsec_lookup_key() encuentra una clave, obtiene un recuento a través de llsec_key_get() y copia localmente la identificación de la clave de key_entry (que es un elemento de la lista). Por lo tanto, es seguro llamar a llsec_key_put() y liberar la entrada de la lista después de que transcurra el período de gracia de RCU. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-msm8974: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-apq8084: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: previene el error del kernel en submit_bh_wbc(). Se corrige un error por el cual nilfs_get_block() devuelve un estado exitoso cuando la búsqueda y la inserción del bloque especificado fallan de manera inconsistente. Si este comportamiento inconsistente no se debe a un error solucionado previamente, entonces se está produciendo una ejecución inesperada, por lo que se devuelve un error temporal -EAGAIN. Esto evita que llamadores como __block_write_begin_int() soliciten una lectura en un búfer que no está asignado, lo que provocaría que falle la verificación BUG_ON del indicador BH_Mapped en submit_bh_wbc().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error al detectar daños en DAT en btree y asignaciones directas Serie de parches "nilfs2: corrige el error del kernel en submit_bh_wbc()". Esto resuelve un ERROR del kernel informado por syzbot. Dado que hay dos fallas involucradas, hice un parche para cada uno por separado. El primer parche por sí solo resuelve el error reportado por syzbot, pero creo que ambas correcciones deberían enviarse a estable, así que las etiqueté como tales. Este parche (de 2): Syzbot ha informado de un error en el kernel en submit_bh_wbc() al escribir datos de archivos en un sistema de archivos nilfs2 cuyos metadatos están dañados. Hay dos errores involucrados en este tema. El primer defecto es que cuando nilfs_get_block() localiza un bloque de datos usando btree o mapeo directo, si la rutina de traducción de direcciones de disco nilfs_dat_translate() falla con el código interno -ENOENT debido a la corrupción de los metadatos DAT, se puede devolver a nilfs_get_block(). Esto hace que nilfs_get_block() identifique erróneamente un bloque existente como inexistente, lo que provoca que tanto la búsqueda como la inserción del bloque de datos fallen de manera inconsistente. El segundo defecto es que nilfs_get_block() devuelve un estado exitoso en este estado inconsistente. Esto hace que la persona que llama __block_write_begin_int() u otros soliciten una lectura aunque el búfer no esté asignado, lo que resulta en una verificación BUG_ON para el indicador BH_Mapped en submit_bh_wbc() que falla. Esto soluciona el primer problema cambiando el valor de retorno al código -EINVAL cuando falla una conversión usando DAT con el código -ENOENT, evitando la condición conflictiva que conduce al error del kernel descrito anteriormente. Aquí, el código -EINVAL indica que se detectó corrupción de metadatos durante la búsqueda del bloque, lo que se manejará adecuadamente como un error del sistema de archivos y se convertirá a -EIO al pasar a través de la capa bmap nilfs2.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wireguard: netlink: acceda al dispositivo a través de ctx en lugar de peer. el commit anterior solucionó un error que provocaba que se desreferenciara un dispositivo NULL peer->. En realidad, es más fácil y rápido en cuanto a rendimiento obtener el dispositivo desde ctx->wg. Esto también tiene más sentido semánticamente, ya que ctx->wg->peer_allowedips.seq se compara con ctx->allowedips_seq, basándose ambos en ctx. Esto también actúa como una defensa en profundidad contra los pares liberados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: netlink: verifique si hay pares pendientes a través de is_dead en lugar de una lista vacía. Si todos los pares se eliminan a través de wg_peer_remove_all(), en lugar de configurar peer_list como vacío, el par se agrega a una lista temporal. lista con un encabezado en la pila de wg_peer_remove_all(). Si se reanuda un volcado de netlink y el par seleccionado es uno que se eliminó mediante wg_peer_remove_all(), iterará desde ese par y luego intentará volcar los pares liberados. Para solucionar este problema, marque peer->is_dead, que se creó explícitamente para este propósito. También suba la aserción de bloqueo de dispositivo_update_lock, ya que la lectura is_dead depende de eso. Se puede reproducir mediante un pequeño script como: echo "Configuración de configuración..." ip link add dev wg0 tipo wireguard wg setconf wg0 /big-config (mientras sea verdadero; haga echo "Mostrando configuración..." wg showconf wg0 > / dev/null done) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resultando en: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x182a/0x1b20 Lectura de tamaño 8 en la dirección ffff88811956ec70 mediante la tarea wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c /0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige posibles límites cuando el desplazamiento del búfer no es válido. Encontré posibles límites cuando los campos de desplazamiento del búfer de algunas solicitudes no son válidos. Este parche establece el valor mínimo del campo de compensación del búfer en ->Desplazamiento del búfer para validar la longitud del búfer.