Vulnerabilidades

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.

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: cifs: evitar longitudes de salida incorrectas en smb2_ioctl_query_info() Al llamar a smb2_ioctl_query_info() con smb_query_info::flags=PASSTHRU_FSCTL y smb_query_info::output_buffer_length=0, lo siguiente devolvería 0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); } en lugar de un puntero válido, lo que hace que la comprobación de IS_ERR() falle. Esto provocaría una deferencia ptr NULL en @buffer al acceder a él más tarde en smb2_ioctl_query_ioctl(). Mientras tanto, evite tener un @buffer más pequeño que 8 bytes para manejar correctamente las solicitudes SMB2_SET_INFO FileEndOfFileInformation cuando smb_query_info::flags=PASSTHRU_SET_INFO. Aquí hay un pequeño reproductor de C que activa un ptr NULL en @buffer cuando pasa un smb_query_info::flags no válido #include #include #include #include #include #include #define die(s) perror(s), exit(1) #define QUERY_INFO 0xc018cf07 int main(int argc, char *argv[]) { int fd; if (argc < 2) exit(1); fd = open(argv[1], O_RDONLY); si (fd == -1) morir("abrir"); si (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1) morir("ioctl"); cerrar(fd); devolver 0; } mount.cifs //srv/share /mnt -o ... gcc repro.c && ./a.out /mnt/f0 [ 114.138620] fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.139310] KASAN: null-ptr-deref en rango [0x000000000000000-0x0000000000000007] [ 114.139775] CPU: 2 PID: 995 Comm: a.out No contaminado 5.17.0-rc8 #1 [ 114.140148] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 [ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs] [ 114.141221] Código: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24 [ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256 [ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: fffffffa020580d [ 114.143119] RDX: 00000000000000000 RSI: 000000000000000004 RDI: fffffffa043a380 [ 114.143544] PBR: ffff888115503278 R08: 0000000000000001 R09: 00000000000000003 [ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288 [ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000 [ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:00000000000000000 [ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0 [ 114.146131] Seguimiento de llamadas: [ 114.146291] [ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs] [ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs] [ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs] [ 114.147775] ? dentry_path_raw+0xa6/0xf0 [ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs] [ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs] [ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs] [ 114.149371] ? lock_downgrade+0x6f0/0x6f0 [ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs] [ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0 [ 114.150562] ? __up_read+0x192/0x710 [ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0 [ 114.151025] ? __x64_sys_openat+0x11f/0x1d0 [ 114.151296] __x64_sys_ioctl+0x127/0x190 [ 114.151549] do_syscall_64+0x3b/0x90 [ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 114.152079] RIP: 0033:0x7f7aead043df [ 114.152306] Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Arreglar un posible bloqueo AB/BA con buffer_mutex y mmap_lock syzbot capturó un posible punto muerto entre PCM runtime->buffer_mutex y mm->mmap_lock. Fue provocado por la corrección reciente para cubrir la lectura/escritura acelerada y otras ioctl, y en esa confirmación, pasé por alto un caso extremo (con suerte el único) que puede tomar el bloqueo de reversión, es decir, el mmap de OSS. La operación mmap de OSS permite excepcionalmente reconfigurar los parámetros dentro de la llamada al sistema mmap de OSS, donde ya se mantiene mm->mmap_mutex. Mientras tanto, las llamadas copy_from/to_user en operaciones de lectura/escritura también toman el mm->mmap_lock internamente, por lo tanto, puede llevar a un punto muerto AB/BA. Ya se vio un problema similar en el pasado y lo arreglamos con un refcount (en el commit b248371628aa). La corrección anterior solo cubría las rutas de llamadas con lectura/escritura de OSS y controles ioctl de OSS, mientras que ahora necesitamos cubrir el acceso concurrente a través de las API de ALSA y OSS. Este parche soluciona el problema anterior al reemplazar el bloqueo buffer_mutex en las operaciones de lectura/escritura con un refcount similar al que hemos usado para OSS. El nuevo campo, runtime->buffer_accessing, mantiene el número de operaciones de lectura/escritura concurrentes. A diferencia de la protección buffer_mutex anterior, esto protege solo alrededor de las llamadas copy_from/to_user(); los otros códigos están básicamente protegidos por el bloqueo de flujo PCM. El refcount puede ser negativo, lo que significa que está bloqueado por los controles ioctl. Si se ve un valor negativo, la lectura/escritura se cancela con -EBUSY. En el lado de los controles ioctl, por otro lado, también verifican este refcount y lo establecen en un valor negativo para bloquear a menos que ya se esté accediendo a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: pl031: se corrige la desreferencia de puntero nulo de las funciones rtc Cuando no hay una línea de interrupción, la función de alarma rtc se desactiva. La eliminación del bit de la función de alarma se realizaba antes de las asignaciones del dispositivo ldata->rtc, lo que generaba una desreferencia de puntero nulo. Borre RTC_FEATURE_ALARM después de que se asigne el dispositivo rtc.