Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc2: gadget: no restablezca el controlador UDC del bus del gadget->controlador no debe tocar los componentes internos del controlador del gadget, especialmente no debe restablecer el controlador UDC del bus del gadget->controlador. Esto no fue dañino hasta ahora, pero desde el commit fc274c1e9973 ("USB: gadget: Agregar un nuevo bus para gadgets") el subsistema de gadget tiene su propio bus y jugar con ->bus desencadena la siguiente desreferencia de puntero NULL: dwc2 12480000.hsotg: controlador vinculado g_ether 8<--- corte aquí --- No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 00000000 [00000000] *pgd=00000000 Error interno: Oops: 5 [#1] Módulos SMP ARM vinculados en: ... CPU: 0 PID: 620 Comm: modprobe No contaminado 5.18.0-rc5-next-20220504 #11862 Nombre del hardware: Samsung Exynos (árbol de dispositivos aplanado) La PC está en module_add_driver+0x44/0xe8 LR está en sysfs_do_create_link_sd+0x84/0xe0 ... Procesar modprobe (pid: 620, límite de pila = 0x(ptrval)) ... module_add_driver desde bus_add_driver+0xf4/0x1e4 bus_add_driver desde driver_register+0x78/0x10c driver_register desde usb_gadget_register_driver_owner+0x40/0xb4 usb_gadget_register_driver_owner desde do_one_initcall+0x44/0x1e0 do_one_initcall desde do_init_module+0x44/0x1c8 do_init_module desde load_module+0x19b8/0x1b9c load_module desde sys_finit_module+0xdc/0xfc sys_finit_module de ret_fast_syscall+0x0/0x54 Pila de excepciones (0xf1771fa8 a 0xf1771ff0) ... dwc2 12480000.hsotg: el nuevo dispositivo es de alta velocidad ---[ fin de seguimiento 000000000000000 ]--- Solucione esto eliminando el restablecimiento de la entrada del bus del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: se corrige la ejecución entre nbd_alloc_config() y la eliminación del módulo Cuando se elimina el módulo nbd, nbd_alloc_config() puede ser llamado simultáneamente por nbd_genl_connect(), aunque try_module_get() devolverá falso, pero nbd_alloc_config() no lo maneja. La ejecución puede provocar la fuga de nbd_config y sus recursos relacionados (por ejemplo, recv_workq) y oops en nbd_read_stat() debido a la descarga del módulo nbd como se muestra a continuación: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 No contaminado 5.14.0+ #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) Cola de trabajo: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Rastreo de llamadas: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Lo solucionamos comprobando el valor de retorno de try_module_get() en nbd_alloc_config(). Como nbd_alloc_config() puede devolver ERR_PTR(-ENODEV), asigne nbd->config solo cuando nbd_alloc_config() tenga éxito para garantizar que el valor de nbd->config sea binario (válido o NULL). También se agregó un mensaje de depuración para comprobar el contador de referencia de nbd_config durante la eliminación del módulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: rtl8712: se corrige un valor no inicializado en usb_read8() y similares. Cuando r8712_usbctrl_vendorreq() devuelve un valor negativo, no se inicializarán los 'datos' en usb_read{8,16,32}. ERROR: KMSAN: valor no inicializado en string_nocheck lib/vsprintf.c:643 [en línea] ERROR: KMSAN: valor no inicializado en string+0x4ec/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:643 [en línea] string+0x4ec/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 va_format lib/vsprintf.c:1704 [en línea] pointer+0x18e6/0x1f70 lib/vsprintf.c:2443 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615 __dev_printk+0x3be/0x440 drivers/base/core.c:4627 _dev_info+0x1ea/0x22f drivers/base/core.c:4673 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [en línea] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [en línea] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5363 [en línea] hub_port_connect_change drivers/usb/core/hub.c:5507 [en línea] port_event drivers/usb/core/hub.c:5665 [en línea] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436 kthread+0x3c7/0x500 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Datos de la variable local creados en: usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29 KMSAN: valor no inicializado en r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: cuota: se corrige la condición de bucle en f2fs_quota_sync(). cnt debe pasarse a sb_has_quota_active() en lugar de type para verificar la cuota activa correctamente. Además, cuando el tipo es -1, el compilador con suficiente conocimiento en línea puede descartar por completo la comprobación sb_has_quota_active(), lo que provoca una desreferencia de puntero NULL en el siguiente inode_lock(dqopt->files[cnt]): [ 2.796010] No se puede manejar la desreferencia de puntero NULL del núcleo en la dirección virtual 00000000000000a0 [ 2.796024] Información de aborto de memoria: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (EL actual), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Aborto de datos información: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] usuario pgtable: 4k páginas, VA de 39 bits, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=000000000000000, pud=0000000000000000 [ 2.796051] Error interno: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Contaminado: GS 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Nombre del hardware: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: fffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 000000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 000000000000000 x0 : 000000000000000a0 [ 2.796098] Rastreo de llamadas: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Código: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ fin del seguimiento 96e942e8eb6a0b53 ]--- [ 2.800116] Pánico del núcleo: no se sincroniza: excepción fatal [ 2.800120] SMP: detención de CPU secundarias

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: sysfb: se corrige la fuga del dispositivo de plataforma en la ruta de error. Asegúrese de liberar el dispositivo de plataforma también en el improbable caso de que falle el registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: syscfg: Se corrige la fuga de memoria en caso de error de registro en cscfg_create_device device_register() llama a device_initialize(), según la documentación de device_initialize: Use put_device() para entregar su referencia en lugar de liberar * @dev directamente una vez que haya llamado a esta función. Para evitar una posible fuga de memoria, use put_device() para la gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: accel: mma8452: usa la lógica correcta para obtener mma8452_data La lógica original para obtener mma8452_data es incorrecta, el punto *dev al dispositivo pertenece a iio_dev. No podemos usar este dev para encontrar el i2c_client correcto. La lógica original funcionó porque finalmente usó dev->driver_data para obtener iio_dev. Aquí, usar la API to_i2c_client() es incorrecto y confunde al lector. Para corregir la lógica, debería ser así struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); Pero después de el commit 8b7651f25962 ("iio: iio_device_alloc(): eliminar drvdata propios innecesarios"), la lógica superior tampoco puede funcionar. Cuando se intenta mostrar la escala disponible en el espacio de usuario, se produce un volcado del kernel y una desreferencia del puntero NULL del manejador del kernel. Por lo tanto, se utiliza dev_to_iio_dev() para corregir la lógica. Dual corrige las etiquetas, ya que la segunda refleja cuándo se expuso el error, mientras que la primera refleja cuándo se introdujo el error original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: uso try_get_ops() en tpm-space.c Como parte de la conversión en serie para eliminar las operaciones TPM anidadas: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ se eliminó la exposición del chip->tpm_mutex de gran parte del código de nivel superior. En esta conversión, se pasó por alto tpm2_del_space(). Esto no importó mucho porque generalmente se llama poco después de una operación convertida, por lo que solo hay una ventana de ejecución muy pequeña donde se puede quitar el chip antes de que se realice el vaciado de espacio, lo que provoca una desreferencia NULL en el mutex. Sin embargo, hay informes de que esta ventana se alcanza en la práctica, así que solucione esto convirtiendo tpm2_del_space() para usar tpm_try_get_ops(), que realiza todas las comprobaciones de desmontaje antes de adquirir el mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: arreglo del recuento de referencias para struct tpm_chip La siguiente secuencia de operaciones genera una advertencia de recuento de referencias: 1. Abra el dispositivo /dev/tpmrm. 2. Elimine el módulo tpm_tis_spi. 3. Escriba un comando TPM en el descriptor de archivo abierto en el paso 1. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 1161 en lib/refcount.c:25 kobject_get+0xa0/0xa4 refcount_t: adición en 0; use-after-free. Módulos vinculados en: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4 brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm snd_timer genet snd phy_generic soundcore [última descarga: spi_bcm2835] CPU: 3 PID: 1161 Comm: hold_open No contaminado 5.10.0ls-main-dirty #2 Nombre del hardware: BCM2711 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) desde [] (dump_stack+0xc4/0xd8) [] (dump_stack) from [] (__warn+0x104/0x108) [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8) [] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4) [] (kobject_get) desde [] (tpm_try_get_ops+0x14/0x54 [tpm]) [] (tpm_try_get_ops [tpm]) desde[] (tpm_common_write+0x38/0x60 [tpm]) [] (tpm_common_write [tpm]) desde[] (vfs_write+0xc4/0x3c0) [] (vfs_write) desde[] (ksys_write+0x58/0xcc) [] (ksys_write) desde[] (ret_fast_syscall+0x0/0x4c) Pila de excepciones (0xc226bfa8 a 0xc226bff0) bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000 bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684 bfe0: 0000006c beafe648 0001056c b6eb6944 ---[ fin del seguimiento d4b8409def9b8b1f ]--- El motivo de esta advertencia es el intento de obtener el chip->dev referencia en tpm_common_write() aunque el contador de referencia ya es cero. Desde el commit 8979b02aaf1d ("tpm: Fix reference count to main device") la referencia adicional utilizada para evitar un contador cero prematuro nunca se toma, porque el indicador TPM_CHIP_FLAG_TPM2 requerido nunca se establece. Corrija esto moviendo la gestión del dispositivo de caracteres TPM 2 de tpm_chip_alloc() a tpm_add_char_device() que se llama en un punto posterior en el tiempo cuando el indicador se ha establecido en el caso de TPM2. el commit fdc915f7f719 ("tpm: exponer espacios a través de un enlace de dispositivo /dev/tpmrm") ya introdujo la función tpm_devs_release() para liberar la referencia adicional pero no implementó la función put en chip->devs requerida que da como resultado la llamada de esta función. Corrija esto colocando chip->devs en tpm_chip_unregister(). Finalmente, mueva la nueva implementación para la gestión de TPM 2 a una nueva función para evitar múltiples verificaciones del indicador TPM_CHIP_FLAG_TPM2 en los casos buenos y de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Se corrigen las ejecuciones entre las escrituras de procedimientos de preasignación simultáneas No tenemos protección contra los cambios simultáneos de preasignación de búfer PCM a través de archivos de procedimientos, y esto puede potencialmente llevar a UAF o algún otro problema extraño. Este parche aplica el open_mutex PCM a la operación de escritura de procedimientos para evitar las escrituras de procedimientos aceleradas y la apertura del flujo PCM (y otras operaciones).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uaccess: fix entire entiret overflow on access_ok() Tres arquitecturas comprueban el final de un acceso de usuario contra el límite de direcciones sin tener en cuenta un posible desbordamiento. Pasar una longitud negativa u otro desbordamiento aquí devuelve éxito cuando no debería. Utilice la implementación correcta más común aquí, que optimiza para un argumento de "tamaño" constante y convierte el caso común en una única comparación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: arregla una posible doble liberación al unirse a la malla Si bien el commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") corrigió una pérdida de memoria al salir/desmontar la malla, introdujo una posible corrupción de memoria causada por una doble liberación al volver a unirse a la malla: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); Esta doble liberación/kernel panics se puede reproducir usando wpa_supplicant con una malla cifrada (si se configura sin cifrado a través de "iw", entonces ifmsh->ie siempre es NULL, lo que evita este problema). Y luego llamar a: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Tenga en cuenta que normalmente estos comandos no se usan/funcionan cuando se usa wpa_supplicant. Y parece que wpa_supplicant o wpa_cli están pasando por un ciclo NETDEV_DOWN/NETDEV_UP entre un mesh leave y un mesh join donde NETDEV_UP restablece mesh.ie a NULL a través de un memcpy de default_mesh_setup en cfg80211_netdev_notifier_call, que luego también evita la corrupción de memoria. El problema se observó por primera vez en una aplicación que no usaba wpa_supplicant sino "Senf", que implementa sus propias llamadas a nl80211. Se solucionó el problema eliminando el kfree()'ing del IE de malla en la función de unión de malla y dejando únicamente en manos del mesh leave la liberación del IE de malla.