Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: erofs: corrige la pérdida de memoria de la deduplicación comprimida global LZMA Al estresar las imágenes microLZMA EROFS con la nueva función de deduplicación comprimida global habilitada (`-Ededupe`), encontré algunas páginas temporales de corta duración no se publicaron correctamente, lo que podría causar OOM inesperados horas más tarde. Solucionémoslo ahora (LZ4 y DEFLATE no tienen este problema).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4, ipv6: se corrigió el manejo de transhdrlen en __ip{,6}_append_data() Incluir el transhdrlen en longitud es un problema cuando el paquete está parcialmente lleno (por ejemplo, algo como enviar(MSG_MORE ) sucedió anteriormente) al agregarlo a un paquete IPv4 o IPv6, ya que no queremos repetir el encabezado de transporte ni contabilizarlo dos veces. Esto puede suceder en algunas circunstancias, como al realizar un empalme en un zócalo L2TP. El síntoma observado es una advertencia en __ip6_append_data(): ADVERTENCIA: CPU: 1 PID: 5042 en net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 que ocurre cuando MSG_SPLICE_PAGES se utiliza para agregar más datos a un skbuff que ya está parcialmente ocupado. La advertencia se produce cuando 'copiar' es mayor que la cantidad de datos en el iterador del mensaje. Esto se debe a que la longitud solicitada incluye la longitud del encabezado de transporte cuando no debería hacerlo. Esto puede desencadenarse, por ejemplo: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); enlazar(sfd, ...); // ::1 conectar(sfd, ...); // ::1 puerto 7 enviar(sfd, buffer, 4100, MSG_MORE); enviar archivo (sfd, dfd, NULL, 1024); Solucione este problema agregando solo transhdrlen a la longitud si la cola de escritura está vacía en l2tp_ip6_sendmsg(), de manera análoga a cómo hace las cosas UDP. Parece que l2tp_ip_sendmsg() no sufrirá este problema ya que construye el paquete UDP por sí mismo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: usb: smsc75xx: corrigió el acceso a valores uninit en __smsc75xx_read_reg syzbot informó el siguiente problema de acceso a valores uninit: =============== ====================================== ERROR: KMSAN: valor uninit en controladores smsc75xx_wait_ready/net /usb/smsc75xx.c:975 [en línea] ERROR: KMSAN: valor uninit en smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 No contaminado 5.8.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x21c/ 0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [en línea ] smsc75xx_bind+0x5c9/0x11e0 controladores/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 controladores/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 controladores/usb/core/driver.c:374 very_probe +0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/ bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 dispositivo_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/base/bus.c:491 dispositivo_add+0x3b0e /0x40d0 controladores/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 controladores/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 controladores/usb/core/generic.c:241 usb_probe_device+0x311/0x490 controladores/ usb/core/driver.c:272 Actually_probe+0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c: 807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 device_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/ base/bus.c:491 dispositivos_add+0x3b0e/0x40d0 controladores/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 controladores/usb/core/hub.c:2554 hub_port_connect controladores/usb/core/hub.c:5208 [ en línea] hub_port_connect_change drivers/usb/core/hub.c:5348 [en línea] port_event drivers/usb/core/hub.c:5494 [en línea] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 Process_one_work+ 0x1688/0x2140 kernel/workqueue.c:2269 trabajador_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Variable local ----buf.i87@smsc75xx_bind creada en: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 drivers /net/usb/smsc75xx.c:1482 __smsc75xx_read_reg controladores/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready controladores/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 controladores/net/usb /smsc75xx.c:1482 Este problema se debe a que usbnet_read_cmd() lee menos bytes de los solicitados (cero bytes en el reproductor). En este caso, 'buf' no se completa correctamente. Este parche soluciona el problema devolviendo -ENODATA si usbnet_read_cmd() lee menos bytes de los solicitados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: sony: solucione una posible pérdida de memoria en sony_probe() Si se produce un error después de una llamada exitosa a usb_alloc_urb(), se debe llamar a usb_free_urb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un problema de corrupción de memoria Unas pocas líneas arriba, se kzalloc()'ed espacio para: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof (struct ieee80211_rate) 'mvm->nvm_data' es una 'struct iwl_nvm_data', por lo que está bien. Al final de esta estructura, se encuentra la matriz flexible de 'canales'. Cada elemento es de tipo 'struct ieee80211_channel'. Entonces solo se asigna 1 elemento en esta matriz. Al hacer: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; Apuntamos al primer elemento de la matriz flexible 'canales'. Entonces esto está bien. Sin embargo, al hacer: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); debido a la conversión "(u8 *)", agregamos solo 1 a la dirección del comienzo de la matriz flexible. Es probable que queramos apuntar a la 'estructura ieee80211_rate' asignada justo después. Retire la fundición espuria para que la aritmética del puntero funcione como se esperaba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: corrige el manejo de errores de TX CQE Para un tipo de error de TX CQE desconocido (probablemente de un hardware más nuevo), aún libere el SKB, actualice la cola de cola, etc.; de lo contrario, la contabilidad estará equivocada. Además, los errores de TX pueden desencadenarse al inyectar paquetes corruptos, así que reemplace WARN_ONCE para registrar errores con velocidad limitada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: evitar la asignación de memoria en iommu_suspend() La devolución de llamada de suspensión de syscore iommu_suspend() se invoca con IRQ deshabilitado. La asignación de memoria con el indicador GFP_KERNEL puede volver a habilitar las IRQ durante la devolución de llamada de suspensión, lo que puede causar problemas intermitentes de suspensión/hibernación con los siguientes seguimientos del kernel: Llamando a iommu_suspend+0x0/0x1d0 ------------[ cut aquí ]------------ ADVERTENCIA: CPU: 0 PID: 15 en kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Contaminado : GUE 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Seguimiento de llamadas: tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 asm _sysvec_apic_timer_interrupt+0x1f/0x30 ... ---------- --[ cortar aquí ]------------ Interrupciones habilitadas después de iommu_suspend+0x0/0x1d0 ADVERTENCIA: CPU: 0 PID: 27420 en drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU : 0 PID: 27420 Comunicaciones: rtcwake Contaminado: GUWE 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 ... Seguimiento de llamadas: hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr _tienda +0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0 x90 Entry_SYSCALL_64_after_hwframe+0x72/0xdc Dado que sólo se necesitan 4 palabras de memoria, evite el asignación de memoria en iommu_suspend().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/damon/vaddr-test: corrige la pérdida de memoria en damon_do_test_apply_tres_regions() Cuando CONFIG_DAMON_VADDR_KUNIT_TEST=y y se hace CONFIG_DEBUG_KMEMLEAK=y y CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, se detecta la siguiente pérdida de memoria. Desde el commit 9f86d624292c ("mm/damon/vaddr-test: eliminar variables innecesarias"), damon_destroy_ctx() se elimina, pero aún se llama a damon_new_target() y damon_new_region(), la damon_region asignada por kmem_cache_alloc() en damon_new_region() y el damon_target asignado por kmalloc en damon_new_target() no se libera. Y el damon_region que está asignado en damon_new_region() en damon_set_regions() tampoco se libera. Entonces use damon_destroy_target para liberar todos los damon_regions y damon_target. objeto sin referencia 0xffff888107c9a940 (tamaño 64): comm "kunit_try_catch", pid 1069, jiffies 4294670592 (edad 732,761 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b... .........kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `................. backtrace: [] kmalloc_trace +0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_tres_regiones.constprop.0+0x95/0x3e0 [] damon_test_apply_tres_regiones1+0x21e/ 0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [< ffffffff81237cf6>] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 objeto sin referencia 0xffff8881079cc740 (tamaño 56): comm "kunit_try_catch", pid 1069, santiamén 4294670592 (edad 732,761 s ) volcado hexadecimal (primeros 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk retroceso: [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_tres_regiones.constprop.0+0xd1/0x3e0 [] damon_test_apply_tres_regiones1+0x21e/0x260 [ ] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_ fork_asm+0x11/0x20 objeto sin referencia 0xffff888107c9ac40 (tamaño 64): comm "kunit_try_catch ", pid 1071, santiamén 4294670595 (edad 732,843 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........xv.... rastreo: [] kmalloc_trace+0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_tres_regiones.constprop.0+0x95/0x3e0 [] damon_test_apply_tres_regiones2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4 a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork +0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 objeto sin referencia 0xffff8881079ccc80 (tamaño 56): comm "kunit_try_catch", pid 1071, jiffies 4294670595 (edad 732.843 s) volcado hexadecimal (primero 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk retroceso : [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_tres_regiones.constprop.0+0xd1/0x3e0 [] damon_test_apply_tres_regiones2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: dts: qcom: sdm845-db845c: marcar la región de memoria de inicio continua como reservada Agregar una región de memoria reservada para la memoria framebuffer (la región de memoria de inicio configurada por el gestor de arranque). Soluciona un problema de pánico en el kernel (arm-smmu: fallo de contexto no controlado en esta región de memoria en particular) informado en DB845c que ejecuta v5.10.y.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab_common: corrige la corrupción de la lista slab_caches después de kmem_cache_destroy() Después de el commit en Correcciones:, si un módulo que creó un caché de losa no libera todos sus objetos asignados antes de destruir el cache (en el momento rmmod), podríamos terminar liberando el objeto kmem_cache sin eliminarlo de la lista slab_caches, corrompiendo así la lista ya que kmem_cache_destroy() ignora el valor de retorno de Shutdown_cache(), que a su vez nunca elimina el objeto kmem_cache de slabs_list en caso __kmem_cache_shutdown() no puede liberar todas las losas del caché. Esto es fácilmente observable en un kernel construido con CONFIG_DEBUG_LIST=y ya que después de ese lanzamiento, el sistema activará inmediatamente las aserciones list_add o list_del, similares a la que se muestra a continuación tan pronto como se cree o destruya otro kmem_cache: [ 1041.213632] list_del corrupción. siguiente->anterior debería ser ffff89f596fb5768, pero era 52f1e5016aeee75d. (siguiente=ffff89f595a1b268) [1041.219165] ------------[ cortar aquí ]------------ [ 1041.221517] ¡ERROR del kernel en lib/list_debug.c:62! [ 1041.223452] código de operación no válido: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: cargado Contaminado: GBW OE 6.5.0 #15 [ 1041.228244] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 24/05/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Otra forma rápida de desencadenar este problema, en un kernel con CONFIG_SLUB=y, es configurar slub_debug para envenenar los objetos liberados y luego simplemente ejecutar cat /proc/slabinfo después de eliminar el módulo que filtra los objetos slab, en cuyo caso el kernel entrará en pánico: [50.954843] falla de protección general, probablemente para la dirección no canónica 0xa56b6b6b6b6b6b8b: 0000 [#1 ] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: cargado Contaminado: GBW OE 6.5.0 #15 [ 50.966808] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS edk2-20230524- 3.fc37 24/05/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 Este parche soluciona este problema verificando correctamente el valor de retorno de Shutdown_cache() antes de tomar la rama kmem_cache_release().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/meson: corrige la pérdida de memoria en ->hpd_notify callback El EDID devuelto por drm_bridge_get_edid() debe liberarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "tty: n_gsm: fix UAF in gsm_cleanup_mux" Esto revierte el commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. el commit anterior se revierte porque no resolvió el problema original. gsm_cleanup_mux() intenta liberar los ttys virtuales llamando a gsm_dlci_release() para cada DLCI disponible. Allí, se llama a dlci_put() para disminuir el contador de referencia para el DLCI a través de tty_port_put() que finalmente llama a gsm_dlci_free(). Esto ya borra el puntero que se está verificando en gsm_cleanup_mux() antes de llamar a gsm_dlci_release(). Por lo tanto, no es necesario borrar este puntero en gsm_cleanup_mux() como se hizo en el commit revertida. el commit introduce una desreferencia de puntero nulo: ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420? search_exception_tables+0x37/0x50? fixup_exception+0x21/0x310? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x26/0x30? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm] release_one_tty+0x37/0xe0 proceso_one_work+0x1e6/0x3e0 trabajador_thread+0x4c/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 El problema real es que nada protege a dlci_put() de ser llamado varias veces mientras el controlador tty se activó pero aún no terminó de llamar a gsm_dlci_free().