Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ixgbe: repara la fuga de recuento de dispositivos pci Como dice el comentario de pci_get_domain_bus_and_slot(), devuelve un dispositivo PCI con el recuento de referencia incrementado, cuando termine de usarlo, la persona que llama debe disminuir el recuento de referencias en llamando a pci_dev_put(). En ixgbe_get_first_secondary_devfn() y ixgbe_x550em_a_has_mii(), se llama a pci_dev_put() para evitar fugas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64/mm: corrige file_map_count incorrecto para pmd no válido. La verificación de la tabla de páginas activa BUG_ON() inesperadamente cuando se divide una página enorme: ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/page_table_check.c:119! Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer vacío) Módulos vinculados en: CPU: 7 PID: 210 Comm: transhuge-stres No contaminado 6.1.0-rc3+ #748 Nombre de hardware: linux ,dummy-virt (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: page_table_check_set.isra.0+0x398/0x468 lr: page_table_check_set.isra.0+0x1c0/0x468 [...] Rastreo de llamadas: page_table_check_set.isra.0+0x398/0x468 __page_table_check_pte_set+0x160/0x1c0 __split_huge_pmd_locked+0x900/0x1648 __split_huge_pmd+0x28c/0x3b8 unmap_page_range+0x428/0x858 single_vma+0xf4/0x1c8 zap_page_range+0x2b0/0x410 madvise_vma_behavior+0xc44 /0xe78 do_madvise+0x280/0x698 __arm64_sys_madvise+0x90/0xe8 invoke_syscall.constprop.0+0xdc/0x1d8 do_el0_svc+0xf4/0x3f8 el0_svc+0x58/0x120 el0t_64_sync_handler+0x b8/0xc0 el0t_64_sync+0x19c/0x1a0 [...] En arm64, pmd_leaf () devolverá verdadero incluso si el pmd no es válido debido a la verificación pmd_present_invalid(). Entonces, en pmdp_invalidate() file_map_count no solo disminuirá una vez sino que también aumentará una vez. Luego, en set_pte_at(), file_map_count aumenta nuevamente y, por lo tanto, activa BUG_ON() inesperadamente. Agregue !pmd_present_invalid() check in pmd_user_accessible_page() para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dp: no complete dp_aux_cmd_fifo_tx() si irq no es para transferencia auxiliar. Hay 3 posibles fuentes de interrupción que son manejadas por el controlador DP, HPDstatus, los cambios de estado del controlador y Aux. transacción de lectura/escritura. En cada irq, el controlador DP debe verificar el estado isr de cada fuente de interrupción y atender la interrupción si sus bits de estado isr muestran que hay interrupciones pendientes. Existe una posible condición de ejecución que puede ocurrir en la implementación actual del controlador aux isr, ya que siempre está completo dp_aux_cmd_fifo_tx(), incluso irq no es para transacciones de lectura o escritura auxiliar. Esto puede causar que la transacción de lectura auxiliar regrese prematuramente si la lectura de datos auxiliares del host está en medio de la espera de que el receptor complete la transferencia de datos al host mientras ocurre la irq. Esto hará que el búfer de recepción del host contenga datos inesperados. Este parche soluciona este problema verificando aux isr y regresa inmediatamente al controlador aux isr si no hay ningún bit de estado isr establecido. Actualmente hay un informe de error que indica que la corrupción de eDP edid ocurre durante el inicio del sistema. Después de una larga depuración, descubrí que la interrupción VIDEO_READY se activaba continuamente durante el inicio del sistema, lo que provocaba que dp_aux_isr() completara dp_aux_cmd_fifo_tx() prematuramente para recuperar datos del búfer de hardware auxiliar que aún no contiene la transferencia completa de datos desde el receptor. Esto provocó corrupción. A continuación se muestra la firma en los registros del kernel cuando ocurre un problema, EDID tiene el panel de encabezado corrupto-simple-dp-aux aux-aea0000.edp: No se pudo identificar el panel a través de EDID Cambios en v2: - complete si (ret == IRQ_HANDLED) ay dp-aux_isr() - agregar más texto de confirmación Cambios en v3: - agregar Stephen sugerido - dp_aux_isr() devolver IRQ_XXX a la persona que llama - dp_ctrl_isr() devolver IRQ_XXX a la persona que llama Cambios en v4: - dividir en dos parches Cambios en v5: - eliminar línea vacía entre etiquetas Cambios en v6: - eliminar "eso" adicional y línea fija de más de 75 caracteres en el texto de confirmación Patchwork: https://patchwork.freedesktop.org/patch/516121/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: corrige la creación del identificador GEM. El espacio de usuario UAF puede adivinar el valor del identificador e intentar acelerar la creación de objetos GEM con el cierre del identificador, lo que resulta en un use-after-free si desreferenciamos el objeto después de soltar la referencia del identificador. Por esa razón, la eliminación de la referencia del identificador debe realizarse *después* de que hayamos terminado de desreferenciar el objeto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gsmi: corrige null-deref en gsmi_get_variable Podemos obtener variables EFI sin recuperar el atributo, por lo que debemos permitir eso en gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access Layer") agregó una nueva llamada get_variable con attr=NULL, lo que desencadena pánico en gsmi.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_ncm: corrige potencial NULL ptr deref en ncm_bitrate() En el error interno de Google 265639009 hemos recibido un informe de fallo (hasta ahora) irreproducible de un aarch64 GKI 5.10. Dispositivo en ejecución 149-android13. AFAICT, el código fuente está en: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 La pila de llamadas es: ncm_close() -> ncm_notify() - > ncm_do_notify() con el bloqueo en: ncm_do_notify+0x98/0x270 Código: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) El cual creo que se desmonta (no conozco el ensamblaje de ARM, pero me parece bastante sensato...): / / almacén de media palabra (16 bits) presumiblemente en evento->wLength (en el desplazamiento 6 de la estructura usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // almacén de palabra (32 bits) presumiblemente en req->Longitud (en el desplazamiento 8 de la estructura usb_request) 6C 0A 00 B9 str w12, [x19, #8] // aquí se leyó x10 (NULL) desde el desplazamiento 0 del puntero válido x9 // En mi humilde opinión, estamos leyendo 'cdev->gadget' y obtener NULL // el gadget está de hecho en el desplazamiento 0 de la estructura usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // cargando el puntero req->buf, que está en el desplazamiento 0 de la estructura usb_request 69 02 40 F9 ldr x9, [x19 ] // x10 es nulo, falla, parece ser un intento de leer cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] que parece alinearse con ncm_do_notify() caso NCM_NOTIFY_SPEED fragmento de código: evento ->wLongitud = cpu_to_le16(8); solicitud->longitud = NCM_STATUS_BYTECOUNT; /* Los datos SPEED_CHANGE son velocidades de subida/bajada en bits/seg. */ data = req->buf + sizeof *event; datos[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); Mi análisis de los registros y la compensación de fallas de NULL ptr deref (no se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 000000000000005c) sugiere en gran medida que la falla se debe a que 'cdev->gadget' es NULL al ejecutar: datos[0] = cpu_to_le32(ncm_bitrate (cdev->gadget)); que llama: ncm_bitrate(NULL) que luego llama: gadget_is_superspeed(NULL) que lee ((struct usb_gadget *)NULL)->max_speed y entra en pánico. AFAICT, si estoy contando bien, el desplazamiento de max_speed es de hecho 0x5C. (recuerde que hay una reserva GKI KABI de 16 bytes en la estructura work_struct) No me queda del todo claro cómo se supone que funciona todo esto... pero devolver 0 parece mucho mejor que entrar en pánico...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: Limpieza de fallas parciales en el descubrimiento del motor Si abortamos la inicialización del controlador en medio del descubrimiento de gt/engine, algunos motores estarán completamente configurados y otros no. Esos motores configurados de forma incompleta solo tienen 'motor->liberación == NULL' y, por lo tanto, filtrarán cualquiera de los objetos comunes asignados. v2: - Suelta el ayudante destroy_pinned_context() por ahora. Realmente no vale la pena con un solo sitio de llamada en este momento. (Janusz)

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