Vulnerabilidades

Motivo del rechazo: esta autoridad de numeración CVE ha rechazado o retirado esta ID CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: No finalizar la CSA en modo IBSS si el estado es desconectado. Cuando no estamos conectados a un canal, enviar el anuncio de cambio de canal no tiene sentido. En ese caso, la lista BSS está vacía. Esto provoca que se omita el bucle for en cfg80211_get_bss(), por lo que la función devuelve NULL (consulte la línea 1424 de net/wireless/scan.c), lo que provoca la activación de WARN_ON() en ieee80211_ibss_csa_beacon() (consulte la línea 500 de net/mac80211/ibss.c), lo que se informó en el panel de control de syzkaller. Por lo tanto, se debe comprobar si existe una conexión antes de generar la baliza CSA en ieee80211_ibss_finish_csa().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Se corrige una oscura violación de lockdep para udc_mutex. Una confirmación reciente que expandió el alcance del mutex udc_lock en el núcleo del gadget logró causar una oscura y ligeramente extraña violación de lockdep. En forma abreviada: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.19.0-rc7+ #12510 No contaminado ------------------------------------------------------ udevadm/312 está intentando adquirir el bloqueo: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, en: usb_udc_uevent+0x54/0xe0 pero la tarea ya tiene el bloqueo: ffff000002277548 (kn->active#4){++++}-{0:0}, en: kernfs_seq_start+0x34/0xe0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (mutex_lista_regulador){+.+.}-{3:3}: adquisición_bloqueo+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidentemente, esto se debió a que el alcance de udc_mutex era demasiado grande. El mutex solo protege udc->driver, entre otras cosas. Hasta donde sé, no hay razón para que el mutex se mantenga mientras el núcleo del gadget llama a la rutina ->bind o ->unbind de un controlador de gadget, ni mientras se inicia o detiene un UDC. (Esto explica el enlace n.º 1 de la cadena anterior, donde el mutex se mantiene mientras se inicia dwc2_hsotg_udc como parte del sondeo del controlador). Las devoluciones de llamada ->disconnect de los controladores de gadget son problemáticas. Aunque usb_gadget_disconnect() ahora adquirirá el udc_mutex, existe un margen en usb_gadget_bind_driver() entre el momento en que se libera el mutex y se invoca la devolucion de llamada ->bind. Si se produjera una desconexión durante ese margen, podríamos llamar a la rutina ->disconnect del controlador antes que a su rutina ->bind. Para evitarlo, será necesario impedir que un UDC se conecte mientras no tenga un controlador de gadget. Esto ya debería estar hecho, pero no parece estarlo; actualmente, usb_gadget_connect() no lo comprueba. Esta comprobación deberá añadirse más adelante. Se requiere cierto grado de exclusión mutua en soft_connect_store(), que puede desreferenciar udc->driver en cualquier momento, ya que es una devolución de llamada de sysfs. La solución es adquirir el bloqueo del dispositivo del gadget en lugar del udc_mutex. Dado que el núcleo del controlador garantiza que el bloqueo del dispositivo se mantenga siempre durante la vinculación y desvinculación del controlador, esto hará que los accesos en soft_connect_store() sean mutuamente excluyentes con cualquier cambio en udc->driver. Por último, resulta que hay un lugar que debería contener el udc_mutex, pero actualmente no lo hace: la rutina function_show() necesita protección mientras desreferencia udc->driver. Se añaden las llamadas de bloqueo y desbloqueo que faltan.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "usb: typec: ucsi: añadir una función común ucsi_unregister_connectors()". La reciente confirmación 87d0e2f41b8c ("usb: typec: ucsi: añadir una función común ucsi_unregister_connectors()") introdujo una regresión que provocaba una desreferencia nula al leer el archivo sysfs de la fuente de alimentación. Se trata de una entrada obsoleta del archivo sysfs que debería haberse eliminado, pero que permanece con operaciones nulas. el commit modificó la gestión de errores para omitir las entradas después de un comando con->wq nulo, lo que deja el dispositivo de alimentación sin liberar. Para solucionar la regresión, se aplica la reversión directa. Se pueden realizar mejoras de código desde cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (gpio-fan) Corrección de acceso fuera de los límites a una matriz. El controlador no comprueba si el estado de refrigeración transferido a gpio_fan_set_cur_state() supera el estado de refrigeración máximo almacenado en fan_data->num_speeds. Dado que el estado de refrigeración se utiliza posteriormente como índice de matriz en set_fan_speed(), puede producirse un acceso fuera de los límites a una matriz. Esto se puede explotar configurando el estado del dispositivo de refrigeración térmica con valores arbitrarios, lo que provoca, por ejemplo, un error en el kernel al acceder a memoria no disponible de esta forma. Ejemplo de error de kernel: [807.987276] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffff80d0588064 [807.987369] Información de aborto de memoria: [807.987398] ESR = 0x96000005 [807.987428] EC = 0x25: DABT (EL actual), IL = 32 bits [807.987477] SET = 0, FnV = 0 [807.987507] EA = 0, S1PTW = 0 [807.987536] FSC = 0x05: error de traducción de nivel 1 [807.987570] Información de aborto de datos: [ 807.987398] ESR = 0x96000005 [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits [ 807.987477] SET = 0, FnV = 0 [ 807.987507] EA = 0, S1PTW = 0 [ 807.987536] FSC = 0x05: level 1 translation fault [ 807.987570] Data abort info: [ 807.987763] ISV = 0, ISS = 0x00000005 [ 807.987801] CM = 0, WnR = 0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575 [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc008cf3bd0 [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000 [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920 [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000 [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70 [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009 [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8 [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060 [ 807.989084] Call trace: [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.989199] cur_state_store+0x84/0xd0 [ 807.989221] dev_attr_store+0x20/0x38 [ 807.989262] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 807.989315] vfs_write+0x254/0x378 [ 807.989362] ksys_write+0x70/0xf8 [ 807.989379] __arm64_sys_write+0x24/0x30 [ 807.989424] invoke_syscall+0x4c/0x110 [ 807.989442] ---truncado---

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.