Vulnerabilidades

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 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: plataforma/x86: think-lmi: corregir fuga de referencia Si se encuentra un atributo duplicado usando kset_find_obj(), se devuelve una referencia a ese atributo que debe eliminarse en consecuencia usando kobject_put( ). Mueva la validación del nombre de la configuración a una función separada para permitir este cambio sin tener que duplicar el código de limpieza para esta configuración. Como nota al margen, se solucionó un error muy similar en el commit 7295a996fdab ("plataforma/x86: dell-sysman: corregir fuga de referencia"), por lo que parece que el error se copió de ese controlador. Compilación probada únicamente.

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: media: uvcvideo: Fix OOB read Si el índice proporcionado por el usuario es mayor que el tamaño de la máscara, podríamos hacer una lectura fuera de los límites.

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: 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 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: wifi: mac80211: soluciona el posible Use After Free de la clave Cuando ieee80211_key_link() es llamado por ieee80211_gtk_rekey_add() pero devuelve 0 debido a la protección KRACK (reinstalación de clave idéntica), ieee80211_gtk_rekey_add() aún devolverá un puntero a la clave, en un posible Use After Free. Esto normalmente no sucede ya que iwlwifi solo lo llama en caso de descarga de recodificación de WoWLAN, que tiene su propia protección KRACK, pero aún es mejor solucionarlo, hágalo devolviendo un código de error y convirtiéndolo en exitoso solo en el límite cfg80211, dejando el error para personas que llaman mal de ieee80211_gtk_rekey_add().

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().