Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: rpi: Impedir acceso fuera de los límites. El bucle while en raspberrypi_discover_clocks() asume que el ID del último elemento de reloj es cero. Dado que estos datos provienen del firmware de Videocore y no garantizan dicho comportamiento, esto podría provocar un acceso fuera de los límites. Para solucionarlo, se debe proporcionar un elemento centinela.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección de la desreferencia alloc->vma_vm_mm null-ptr. Syzbot informó de un par de problemas introducidos por el commit 44e602b4e52f ("binder_alloc: añadir llamadas mmap_lock faltantes al usar la VMA"), en el que se intenta adquirir mmap_lock cuando alloc->vma_vm_mm aún no se ha inicializado. Esto puede ocurrir si un binder_proc recibe una transacción sin haber llamado previamente a mmap() para configurar el espacio binder_proc->alloc en [1]. Además, se produce un problema similar mediante binder_alloc_print_pages() al intentar volcar el archivo de estadísticas de binder debugfs en [2]. Ejemplo de informe de fallos de syzbot: ======================================================================= KASAN: null-ptr-deref en el rango [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 No contaminado 6.0.0-rc1-next-20220819-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 22/07/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Rastreo de llamadas: lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 down_read+0x98/0x450 kernel/locking/rwsem.c:1499 mmap_read_lock include/linux/mmap_lock.h:117 [inline] binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline] binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593 binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199 binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986 binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ================================================================== Solucione estos problemas configurando el puntero alloc->vma_vm_mm durante la operación open() y almacenando en caché directamente desde current->mm. Esto garantiza una referencia válida para tomar mmap_lock en los escenarios descritos anteriormente.. [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: Borrar la selección antes de cambiar la fuente. Al cambiar la fuente de la consola con ioctl(KDFONTOP), el nuevo tamaño de fuente puede ser mayor que el anterior. Por lo tanto, una selección anterior podría quedar fuera del nuevo tamaño de pantalla y, por lo tanto, provocar accesos fuera de los límites a la memoria gráfica si se elimina la selección en vc_do_resize(). Para evitar estos accesos fuera de memoria, elimine la selección antes de llamar a los controladores de consola con_font_set().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige una fuga de memoria durante la carga de firmware. En la carga de firmware, se asigna una instancia de la estructura fw_upload en firmware_upload_register(). Estos datos deben liberarse en fw_dev_release(). Cree una nueva función fw_upload_free() en sysfs_upload.c para gestionar las liberaciones de memoria específicas de la carga de firmware e incorpore la llamada kfree que falta para la estructura fw_upload.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: arreglo UAF de ref->proc causado por condición de ejecución Una transacción de tipo BINDER_TYPE_WEAK_HANDLE puede fallar al incrementar la referencia para un nodo. En este caso, el proc objetivo normalmente libera la referencia fallida al cerrar como se espera. Sin embargo, si el objetivo está muriendo en paralelo la llamada competirá con binder_deferred_release(), por lo que el objetivo podría haber liberado todas sus referencias por ahora dejando la limpieza de la nueva referencia fallida sin manejar. La transacción entonces termina y el proc objetivo se libera haciendo que ref->proc ahora sea un puntero colgante. Más tarde, ref->node se cierra e intentamos tomar spin_lock(&ref->proc->inner_lock), lo que lleva al error de Use-After-Free reportado a continuación. Vamos a arreglar esto limpiando la referencia fallida en el acto en lugar de depender de que el objetivo lo haga. ====================================================================== ERROR: KASAN: Use-After-Free en _raw_spin_lock+0xa8/0x150 Escritura de tamaño 4 en la dirección ffff5ca207094238 por la tarea kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 No contaminado 5.19.0-rc8 #10 Nombre del hardware: linux,dummy-virt (DT) Cola de trabajo: eventos binder_deferred_func Rastreo de llamadas: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: añadir comprobación de validez para gsm->receive en gsm_receive_buf(). Se puede producir una desreferencia de puntero nulo al intentar acceder a la función "gsm->receive()" en gsmld_receive_buf(). Actualmente, el código asume que gsm->recieve solo se llama después de la activación del MUX. Dado que se puede acceder a la función gsmld_receive_buf() sin necesidad de inicializar el MUX, esta función no se activará y se producirá una desreferencia de puntero nulo. Para solucionar esto, se debe evitar la llamada a "gsm->receive()" si la función no se inicializa mediante una comprobación de validez. Rastreo de llamadas: gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [en línea] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/dma-resv: comprobar si la nueva valla es realmente posterior. Anteriormente, al añadir una valla a un objeto dma_resv, siempre suponíamos que era más reciente que todas las vallas existentes. Gracias al trabajo de Jason para añadir una UAPI a la exportación/importación explícita, esto ya no es necesario. Por lo tanto, sin esta comprobación, permitiríamos que el espacio de usuario forzara al kernel a un error de Use-After-Free. Dado que el cambio es muy pequeño y defensivo, probablemente sea buena idea retroportarlo también a los kernels estables, por si acaso otros utilizan el objeto dma_resv de la misma manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: núcleo: evitar llamadas de reinicio de dispositivo anidadas. El fuzzing automático del kernel reveló una violación de bloqueo recursivo en usb-storage: ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 5.18.0 #3 No contaminado -------------------------------------------- kworker/1:3/1205 está intentando adquirir el bloqueo: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 pero la tarea ya está manteniendo el bloqueo: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... seguimiento de pila: CPU: 1 PID: 1205 Comm: kworker/1:3 No contaminado 5.18.0 #3 Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 Resultó que esto no era un error en usb-storage sino más bien un intento de reinicio de dispositivo anidado. Es decir, como el controlador rtl8712 se estaba desvinculando de un dispositivo compuesto en preparación para un reinicio USB no relacionado (ese controlador no tiene devoluciones de llamada pre_reset o post_reset), su rutina ->remove llamó a usb_reset_device() - anidando así una llamada de reinicio dentro de otra. Realizar un reinicio como parte del procesamiento de desconexión es una práctica cuestionable en el mejor de los casos. Sin embargo, el informe de errores señala que el núcleo USB no tiene ninguna protección contra reinicios anidados. Agregar un indicador reset_in_progress y probarlo evitará tales errores en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mceusb: Utilizar nuevas rutinas usb_control_msg_*() El fuzzing automático del kernel provocó una ADVERTENCIA sobre una dirección de tubería no válida en el controlador mceusb: ------------[ cortar aquí ]------------ usb 6-1: directorio de control FALSO, la tubería 80000380 no coincide con bRequestType 40 ADVERTENCIA: CPU: 0 PID: 2465 en drivers/usb/core/urb.c:410 usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Módulos vinculados: CPU: 0 PID: 2465 Comm: kworker/0:2 No contaminado 5.19.0-rc4-00208-g69cb6c6556ad #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Código: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 y siguientes 41 RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 RAX: 000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 000000000000000 R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 Seguimiento de llamadas: usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807 El motivo de la advertencia es bastante claro; el controlador envía una solicitud de lectura inusual en el endpoint 0 pero no establece el bit USB_DIR_IN en el campo bRequestType. Más importante aún, se puede evitar toda la situación y simplificar el controlador al convertirlo a las relativamente nuevas rutinas usb_control_msg_recv() y usb_control_msg_send(). Esto es lo que hace esta corrección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige una pequeña pérdida de mempool en SMB2_negotiate() En algunos casos de falla (desajustes de dialecto) en SMB2_negotiate(), después de enviar la solicitud, las verificaciones devolverían -EIO cuando deberían establecer rc = -EIO y saltar a neg_exit para liberar el búfer de respuesta de mempool.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Se ha corregido el UAF en ieee80211_scan_rx(). ieee80211_scan_rx() intenta acceder a scan_req->flags tras una comprobación nula, pero se observa un UAF al finalizar el escaneo y se ejecuta __ieee80211_scan_completed(), que a su vez llama a cfg80211_scan_done(), lo que libera scan_req. Dado que scan_req está desreferenciado mediante rcu_dereference(), se debe evitar la aceleración en __ieee80211_scan_completed() asegurándose de que, desde el punto de vista de mac80211, ya no se acceda a él desde una sección crítica de lectura de RCU antes de llamar a cfg80211_scan_done().

El complemento Target Video Easy Publish para WordPress es vulnerable a Cross-Site Scripting almacenado a través del parámetro "width" en todas las versiones hasta la 3.8.5 incluida, debido a una depuración de entrada y un escape de salida insuficientes. Esto permite a atacantes autenticados, con acceso de colaborador o superior, inyectar scripts web arbitrarios en páginas que se ejecutarán al acceder un usuario a una página inyectada.