Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: permite que la sonda falle cuando no se puede habilitar la cola de trabajo. La cola de trabajo se habilita cuando se carga el controlador apropiado y se deshabilita cuando se elimina el controlador. Cuando se elimina el controlador, se supone que la cola de trabajo se habilitó correctamente y procede a liberar las asignaciones realizadas durante la habilitación de la cola de trabajo. La falla durante la habilitación de la cola de trabajo no impide que se cargue el controlador. Esto se debe a que la ruta de error dentro de drv_enable_wq() devuelve éxito a menos que se encuentre una segunda falla durante la ruta de error. Al devolver el éxito, es posible cargar el controlador incluso si no se puede habilitar la cola de trabajo y se intenta liberar las asignaciones que no existen durante la eliminación del controlador. Algunos ejemplos de flujos problemáticos: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): en el flujo anterior, si idxd_wq_request_irq() falla, se llama a idxd_wq_unmap_portal() en la ruta de salida de error, pero drv_enable_wq() devuelve 0 porque idxd_wq_disable() tiene éxito. De este modo, el controlador se carga correctamente. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() El flujo anterior al descargar el controlador activa la ADVERTENCIA en devm_iounmap() porque el recurso del dispositivo ya se eliminó durante la ruta de error de drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): en el flujo anterior, si idxd_wq_request_irq() falla, nunca se llama a idxd_wq_init_percpu_ref() para inicializar el contador de percpu, pero el controlador se carga correctamente porque drv_enable_wq() devuelve 0 idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): El flujo anterior en la descarga del controlador desencadena un ERROR al intentar eliminar la referencia inicial de la referencia percpu no inicializada: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 Corrija el drv_enable_wq(. ) ruta de error al devolver el error original que indica un error al habilitar la cola de trabajo. Esto garantiza que la sonda falle cuando se encuentre un error y que las rutas de eliminación del controlador solo se intenten cuando la cola de trabajo se habilitó correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadgetfs: corrige la ejecución entre montar y desmontar Syzbot fuzzer y Gerald Lee han identificado un error de use-after-free en el controlador gadgetfs, que involucra procesos que montan y desmontan simultáneamente los gadgetfs. sistema de archivos. En particular, gadgetfs_fill_super() puede competir con gadgetfs_kill_sb(), provocando que este último desasigne the_device mientras el primero lo está usando. El resultado de KASAN dice, en parte: ERROR: KASAN: use-after-free en instrument_atomic_read_write include/linux/instrumented.h:102 [en línea] ERROR: KASAN: use-after-free en atomic_fetch_sub_release include/linux/atomic/atomic -instrumented.h:176 [en línea] ERROR: KASAN: uso después de liberación en __refcount_sub_and_test include/linux/refcount.h:272 [en línea] ERROR: KASAN: uso después de liberación en __refcount_dec_and_test include/linux/refcount.h :315 [en línea] ERROR: KASAN: uso después de liberación en refcount_dec_and_test include/linux/refcount.h:333 [en línea] ERROR: KASAN: uso después de liberación en put_dev drivers/usb/gadget/legacy/inode.c :159 [en línea] ERROR: KASAN: use-after-free en gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 Escritura de tamaño 4 en la dirección ffff8880276d7840 mediante la tarea syz-executor126/18689 CPU: 0 PID: 18689 Comunicación: syz-executor126 No contaminado 6.1.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Seguimiento de llamadas: ... atomic_fetch_sub_release include/linux/ atomic/atomic-instrumented.h:176 [en línea] __refcount_sub_and_test include/linux/refcount.h:272 [en línea] __refcount_dec_and_test include/linux/refcount.h:315 [en línea] refcount_dec_and_test include/linux/refcount.h:333 [en línea ] put_dev drivers/usb/gadget/legacy/inode.c:159 [en línea] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs /super.c:1190 [en línea] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [en línea] La solución más sencilla es garantizar que gadgetfs_fill_super() y gadgetfs_kill_sb() se serializan haciendo que ambos adquieran un nuevo mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: corrige posible null-ptr-defer en spk_ttyio_release Ejecute las siguientes pruebas en la plataforma qemu: syzkaller:~# modprobe Speakup_audptr input: Speakup as /devices/virtual/input/input4 dispositivo inicializado: /dev/synth, nodo (MAJOR 10, MINOR 125) Speakup 3.1.6: el nombre del sintetizador inicializado en la entrada es: (nulo) la sonda de sintetizador spk_ttyio_initialise_ldisc falló porque tty_kopen_exclusive devolvió un error (errno -16), luego elimine el módulo, obtendremos un problema de aplazamiento de ptr nulo, como sigue: syzkaller:~# modprobe -r Speakup_audptr liberando sintetizador audptr ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000080 #PF: acceso de escritura del supervisor en modo kernel #PF: código_error(0x0002 ) - página no presente PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 204 Comm: modprobe No contaminado 6.1.0-rc6-dirty #1 RIP: 0010:mutex_lock+0x14/0x30 Llamada Seguimiento: spk_ttyio_release+0x19/0x70 [speakup] synth_release.part.6+0xac/0xc0 [speakup] synth_remove+0x56/0x60 [speakup] __x64_sys_delete_module+0x156/0x250? fpregs_assert_state_consistent+0x1d/0x50 do_syscall_64+0x37/0x90 entry_syscall_64_after_hwframe+0x63/0xcd módulos vinculados en: sheakup_audptr (-) volcando ftrace búfer: in_synth->> nth-> dev para corregir este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: serial: qcom-geni-serial: corrige los límites fuera de los límites en el búfer RX FIFO La sonda del controlador asigna memoria para RX FIFO (puerto->rx_fifo) según el valor predeterminado Profundidad FIFO de RX, por ejemplo, 16. Más adelante, durante el inicio en serie, qcom_geni_serial_port_setup() actualiza la profundidad FIFO de RX (puerto->rx_fifo_profundidad) para que coincida con las capacidades reales del dispositivo, por ejemplo, a 32. El código de identificador de RX UART leerá el número "puerto->rx_fifo_profundidad" de palabras en el búfer "port->rx_fifo", excediendo así los límites. Esto se puede observar en ciertas configuraciones con el dispositivo Qualcomm Bluetooth HCI UART y KASAN: Bluetooth: hci0: QCA ID de producto: 0x00000010 Bluetooth: hci0: QCA SOC Version: 0x400a0200 Bluetooth: hci0: QCA ROM Version: 0x00000200 Bluetooth: hci0: QCA Patch Version :0x00000d2b Bluetooth: hci0: versión del controlador QCA 0x02000200 Bluetooth: hci0: QCA Descargando qca/htbtfw20.tlv bluetooth hci0: La carga directa del firmware para qca/htbtfw20.tlv falló con el error -2 Bluetooth: hci0: QCA No se pudo solicitar el archivo: qca/ htbtfw20.tlv (-2) Bluetooth: hci0: QCA Error al descargar el parche (-2) =============================== ==================================== ERROR: KASAN: losa fuera de los límites en handle_rx_uart+ 0xa8/0x18c Escritura de tamaño 4 en la dirección ffff279347d578c0 mediante task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Nombre de hardware: Qualcomm Technologies, Inc Robótica RB5 (DT) Seguimiento de llamadas: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa. 8/0x18c qcom_geni_serial_handle_rx+ 0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 Si la profundidad FIFO de RX cambia después sonda, asegúrese de cambiar el tamaño del búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corrige la condición de ejecución de use-after-free para mapas. Es posible que entre llamadas a fastrpc_map_get() hasta que se tome map->fl->lock en fastrpc_free_map() , otro hilo puede llamar a fastrpc_map_lookup() y obtener una referencia a un mapa que está a punto de ser eliminado. Vuelva a escribir fastrpc_map_get() para aumentar solo el recuento de referencias de un mapa si no es cero. Propague esto a las personas que llaman para que puedan saber si un mapa está a punto de ser eliminado. Corrige esta advertencia: refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 5 PID: 10100 en lib/refcount.c:25 refcount_warn_saturate... Rastreo de llamadas: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_sy llamar

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: no elimine el mapa en creater_process y device_release. No elimine el mapa de la lista en la ruta de error en fastrpc_init_create_process; en su lugar, llame a fastrpc_map_put para evitar el use-after-free. Tampoco lo elimine en fastrpc_device_release; en su lugar, llame a fastrpc_map_put. fastrpc_free_map es el único lugar adecuado para eliminar el mapa. Esto se llama solo después de que el recuento de referencias sea 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corrige use-after-free y ejecución en fastrpc_map_find Actualmente, hay una ventana de ejecución entre el punto en el que se desbloquea el mutex en fastrpc_map_lookup y el recuento de referencias aumenta (fastrpc_map_get ) en fastrpc_map_find, lo que también puede generar use-after-free. Entonces, fusionemos fastrpc_map_find con fastrpc_map_lookup, lo que nos permite proteger la lista de mapas tomando también el &fl->lock spinlock y el recuento de referencias, ya que el spinlock se liberará solo después. Agregue el argumento take_ref para que sea adecuado para todas las personas que llaman.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: sdata puede ser NULL durante el inicio de AMPDU. ieee80211_tx_ba_session_handle_start() puede obtener NULL para sdata cuando se está realizando una desautenticación. Aquí un rastro que desencadena la ejecución con la prueba hostapd multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 está en drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 podría_dormir(); 394 395 sdata = get_bss_sdata(sdata); 396 si (!check_sdata_in_driver(sdata)) 397 retorno -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: mover STA 02:00:00:00:03:00 al estado 3 wlan0: wlan0 asociado: desautenticar desde 02:00:00:00:03:00 por elección local (Razón: 3=DEAUTH_LEAVING) wlan3.sta1 : Sesión de BA abierta solicitada para 02:00:00:00:00:00 tid 0 wlan3.sta1: cuadro eliminado a 02:00:00:00:00:00 (puerto no autorizado) wlan0: moviendo STA 02:00:00 :00:03:00 al estado 2 wlan0: moviendo STA 02:00:00:00:03:00 al estado 1 wlan0: STA eliminada 02:00:00:00:03:00 wlan0: STA destruida 02:00: 00:00:03:00 ERROR: no se puede manejar el error de página para la dirección: fffffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted : GW 6.1.0-rc8-wt+ #59 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 01/04/2014 Cola de trabajo: phy3 ieee80211_ba_session_work [mac80211] RIP: _ampdu_acción +0x46/0x280 [mac80211] Código: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 00000000000000001 R11: 0000000000000000 R12: 888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) 0000000000000 CS: 0010 DS: 0000 ES : 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Seguimiento de llamadas: ieee80211_tx_ba_session_handle_start+0xd0/0x190 11] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] Process_one_work+0x29f/0x620 trabajador_thread+0x4d/0x3d0? proceso_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la inicialización de rx->link y rx->link_sta Hay algunas rutas de código que no inicializan rx->link_sta correctamente. Esto provoca un bloqueo en lugares que asumen que rx->link_sta es válido si rx->sta es válido. Una instancia conocida se activa cuando se llama a __ieee80211_rx_h_amsdu desde fast-rx. Resulta en un bloqueo como este: ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000a8 #PF: acceso de escritura del supervisor en modo kernel #PF: código_error(0x0002) - página no presente PGD 0 P4D 0 Ups: 0002 [#1 ] PREEMPT SMP PTI CPU: 1 PID: 506 Comm: mt76-usb-rx phy Contaminado: GE 6.1.0-debian64x+1.7 #3 Nombre del hardware: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 21/05/2014 RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211] Código: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 08 48 y siguientes 03 48 83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 <48> 83 84 d0 a8 00 00 00 01 41 8b 86 c0 11 00 00 8d 50 fd 83 fa 01 RSP:ffff999040803b10 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000000000 RBP: ffff999040803ce0 R08: 00000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900 R13: 000000000000004a R14: 98ed89c0 R15: ffff8d2198ed8000 FS: 0000000000000000(0000) GS:ffff8d24afe80000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001 706e0 Seguimiento de llamadas: __ieee80211_rx_h_amsdu+0x1b5/0x240 [mac80211] ? ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]? __local_bh_enable_ip+0x3b/0xa0 ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]? prepare_transfer+0x109/0x1a0 [xhci_hcd] ieee80211_rx_list+0xa80/0xda0 [mac80211] mt76_rx_complete+0x207/0x2e0 [mt76] mt76_rx_poll_complete+0x357/0x5a0 [mt76u_rx_worker] +0x4f5/0x600 [mt76_usb] ? mt76_get_min_avg_rssi+0x140/0x140 [mt76] __mt76_worker_fn+0x50/0x80 [mt76] kthread+0xed/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Dado que la inicialización de rx->link y rx->link_sta es bastante complicada y duplicada en muchos lugares, límpiela usando una función auxiliar para configurarla. [eliminar comprobación innecesaria de rx->sta->sta.mlo]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: evitemos el pánico si no se crea extend_tree. Este parche evita el siguiente pánico. pc: __lookup_extent_tree+0xd8/0x760 lr: f2fs_do_write_data_page+0x104/0x87c sp: ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 : ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e9090 0x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: 02da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9: ffffff8023195800 x8: ffffff802da49078 x7: 0000000000000001 x6: 0000000000000000 x5 000000000000006 x4: ffffffc010cbba28 x3: 0000000000000000 x2: ffffffc010cbb480 x1: 0000000000000000 x0: ffffff8803e7ed40 Rastreo de llamadas: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f 2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c Process_one_work+0x24c/0x5bc trabajador_thread+0x3e8/0xa 50 khilo+0x150/0x1b4

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_qca: corrige el apagado del controlador en serdev cerrado La devolución de llamada de apagado del controlador (que envía EDL_SOC_RESET al dispositivo a través de serdev) no debe invocarse cuando el dispositivo HCI no está abierto (por ejemplo, si hci_dev_open_sync () falló), porque el serdev y su TTY tampoco están abiertos. Omita también este paso si el dispositivo está apagado (qca_power_shutdown()). La devolución de llamada de apagado provoca use-after-free durante el reinicio del sistema con Qualcomm Atheros Bluetooth: no se puede manejar la solicitud de paginación del kernel en la dirección virtual 0072662f67726fd7... CPU: 6 PID: 1 Comm: systemd-shutdow Contaminado: GW 6.1.0-rt5- 00325-g8a5f56bcfcca #8 Nombre del hardware: Qualcomm Technologies, Inc. Robotics RB5 (DT) Rastreo de llamadas: tty_driver_flush_búfer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x2 60 kernel_restart+0x48/0xac KASAN informe: ERROR: KASAN: use-after-free en tty_driver_flush_búfer+0x1c/0x50 Lectura de tamaño 8 en la dirección ffff16270c2e0018 por tarea systemd-shutdow/1 CPU: 7 PID: 1 Comunicaciones: systemd-shutdow No contaminado 6.1.0-next- 20221220-00014-gb85aaf97fb01-dirty #28 Nombre del hardware: Qualcomm Technologies, Inc. Robotics RB5 (DT) Rastreo de llamadas: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 puerto +0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_búfer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 dispositivo_shutdown+0x1e8/0x3 50 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall +0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: corrige NULL-deref en la ruta de error de inicio En los casos en los que los servicios de ejecución no son compatibles o se han deshabilitado, la cola de trabajo de los servicios de ejecución nunca se habrá asignado. No intente destruir la cola de trabajo incondicionalmente en el improbable caso de que la inicialización de EFI no pueda evitar la desreferenciación de un puntero NULL.