Vulnerabilidades

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: ALSA: oss: Fix PCM OSS buffer assignment overflow Tenemos informes de syzbot que alcanzan un desbordamiento de INT_MAX en la asignación de vmalloc() que se llama desde snd_pcm_plug_alloc(). Aunque aplicamos las restricciones a los parámetros de entrada, se basa solo en hw_params del dispositivo PCM subyacente. Dado que la capa PCM OSS asigna un búfer temporal para la conversión de datos, el tamaño puede volverse inesperadamente grande cuando se dan más canales o velocidades más altas; en el caso informado, superó INT_MAX, por lo tanto, alcanza WARN_ON(). Este parche es un intento de evitar dicho desbordamiento y una asignación para búferes demasiado grandes. En primer lugar, agrega el límite de 1 MB como límite superior para bytes de período. Esto debe ser lo suficientemente grande para todos los casos de uso, y realmente no queremos manejar un búfer temporal más grande que este tamaño. La comprobación del tamaño se realiza en dos lugares: donde se calculan los bytes del período original y donde se calcula el tamaño del búfer del complemento. Además, el controlador utiliza array_size() y array3_size() para las multiplicaciones con el fin de detectar desbordamientos en el tamaño del período convertido y los bytes del búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: llamar a genl_unregister_family() primero en nbd_cleanup() De lo contrario, puede haber una ejecución entre la eliminación del módulo y la gestión del comando netlink, lo que puede provocar los errores que se muestran a continuación: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000098 Error: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Contaminado: GE 5.14.0-rc4 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Rastreo de llamadas: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Módulos vinculados en: nbd(E-)

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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Arregla ejecuciones entre llamadas hw_params y hw_free concurrentes Actualmente no tenemos ni la comprobación adecuada ni la protección contra las llamadas concurrentes de las ioctl hw_params y hw_free de PCM, lo que puede resultar en un UAF. Dado que el bloqueo de flujo de PCM existente no se puede utilizar para proteger todas las operaciones ioctl, necesitamos un nuevo mutex para proteger esas llamadas con ejecuciones. Este parche introdujo un nuevo mutex, runtime->buffer_mutex, y lo aplica a las rutas de código de ioctl hw_params y hw_free. Junto con él, ambas funciones se modifican ligeramente (la comprobación mmap_count se mueve al bloque state-check) para simplificar el código.

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.