Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_flat: Se corrige la corrupción cuando no se compensa el inicio de los datos. El commit 04d82a6d0881 ("binfmt_flat: permitir no compensar el inicio de los datos") introdujo una variante específica de RISC-V del formato FLAT que no asigna ningún espacio para la matriz (obsoleta) de punteros de librería compartida. Sin embargo, no deshabilitó el código que inicializa la matriz, lo que resultó en la corrupción de sizeof(long) bytes antes del segmento DATA, generalmente el final del segmento TEXT. Introduzca MAX_SHARED_LIBS_UPDATE que depende del estado de CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET para proteger la inicialización de la región del puntero de la librería compartida de modo que solo se inicialice si se reserva espacio para ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mgag200: vincular la vida útil de I2C al dispositivo DRM La limpieza administrada con devm_add_action_or_reset() liberará el adaptador I2C cuando el dispositivo Linux subyacente desaparezca. Pero el conector aún hace referencia a él, por lo que esta limpieza deja un puntero obsoleto en struct drm_connector.ddc. Vincule la vida útil del adaptador I2C a la vida útil del conector mediante la liberación administrada de DRM. Cuando el dispositivo DRM desaparezca (después del dispositivo Linux), DRM primero limpiará el conector y luego limpiará el adaptador I2C.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tick/broadcast: mover el acceso al puntero por CPU a la sección atómica La solución reciente para hacer que la toma de control del temporizador de difusión sea más fiable recupera un puntero por CPU en un contexto preemptible. Esto pasó desapercibido ya que los compiladores elevan el acceso a la región no preemptible donde realmente se usa el puntero. Pero, por supuesto, es válido que el compilador lo mantenga en el lugar donde lo pone el código, lo que activa correctamente: ERROR: usar smp_processor_id() en código preemptible [00000000]: el llamador es hotplug_cpu__broadcast_tick_pull+0x1c/0xc0 Muévalo al sitio de uso real que está en una región no preemptible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/sclp: Impedir la liberación de búfer en E/S Cuando se interrumpe una tarea que espera la finalización de una operación de almacenamiento de datos, se intenta detener esta operación. Si este intento falla debido a un problema de hardware o firmware, existe la posibilidad de que la función SCLP almacene datos en búferes a los que hace referencia la operación original en un momento posterior. Maneje esta situación al no liberar los búferes de datos a los que hace referencia si el intento de detención falla. Para los casos de uso actuales, esto podría resultar en una pérdida de algunas páginas de memoria en caso de un mal funcionamiento poco común del hardware o firmware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: SHAMPO, soluciona la desvinculación de la lista enlazada de WQ no válida Cuando se han consumido todos los pasos en un WQE, el WQE se desvincula de la lista enlazada de WQ (mlx5_wq_ll_pop()). Para SHAMPO, es posible recibir CQE con 0 pasos consumidos para el mismo WQE incluso después de que el WQE se haya consumido por completo y se haya desvinculado. Esto desencadena una desvinculación adicional para el mismo wqe que corrompe la lista enlazada. Solucione este escenario aceptando pasos consumidos de tamaño 0 sin desvincular el WQE nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: bcm_sf2: Se corrige una posible pérdida de memoria en bcm_sf2_mdio_register() bcm_sf2_mdio_register() llama a of_phy_find_device() y luego a phy_device_remove() en un bucle para eliminar los dispositivos PHY existentes. of_phy_find_device() finalmente llama a bus_find_device(), que llama a get_device() en el struct device * devuelto para incrementar el refcount. La implementación actual no disminuye el refcount, lo que causa una pérdida de memoria. Esta confirmación agrega la llamada phy_device_free() faltante para disminuir el refcount a través de put_device() para equilibrar el refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: fix TX fifo democracy A veces, cuando se recibe un paquete en el canal A casi al mismo tiempo que se va a transmitir un paquete en el canal B, observamos con un analizador lógico que el paquete recibido en el canal A se transmite en el canal B. En otras palabras, los datos del búfer de Tx en el canal B están dañados con datos del canal A. El problema apareció desde el commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), que cambió el bloqueo de EFR para que funcione en cada canal en lugar de en todo el chip. Este commit ha introducido una regresión, porque el bloqueo de EFR se utiliza no solo para proteger el acceso a los registros de EFR, sino también, de una forma muy oscura y no documentada, para proteger el acceso al búfer de datos, que es compartido por los manejadores de Tx y Rx, pero también por cada canal del IC. Primero, solucione esta regresión cambiando a kfifo_out_linear_ptr() en sc16is7xx_handle_tx() para eliminar la necesidad de un búfer Rx/Tx compartido. En segundo lugar, reemplace el búfer Rx por chip con un búfer Rx separado para cada canal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige uevent_show() frente a la ejecución de desconexión del controlador uevent_show() quiere desreferenciar dev->driver->name. No hay una forma clara de que un atributo de dispositivo desreferenciar dev->driver a menos que ese atributo se defina mediante (struct device_driver).dev_groups. En cambio, el antipatrón de tomar device_lock() en el controlador de atributos corre el riesgo de bloqueos con rutas de código que eliminan los atributos del dispositivo mientras mantienen el bloqueo. Este interbloqueo es típicamente invisible para lockdep dado que device_lock() está marcado como lockdep_set_novalidate_class(), pero algunos subsistemas asignan una clave lockdep local para que @dev->mutex revele informes del formato: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 está intentando adquirir el bloqueo: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, en: __kernfs_remove+0xde/0x220 pero la tarea ya tiene el bloqueo: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, en: device_release_driver_internal+0x39/0x210 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Sin embargo, la observación es que los objetos de controlador suelen tener una vida útil mucho más larga que los objetos de dispositivo. Es razonable realizar una desreferencia sin bloqueo de un puntero @driver incluso si está compitiendo por desconectarse de un dispositivo. Dada la poca frecuencia de anulación del registro de un controlador, usesynchronous_rcu() en module_remove_driver() para cerrar cualquier ejecución potencial. Es potencialmente excesivo sufrirsynchronous_rcu() solo para manejar el raro evento uevent_show() de ejecución de eliminación de módulo. Gracias a Tetsuo Handa por el análisis de depuración del informe de syzbot [1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Se corrige un bloqueo durante la actualización de RTC. Hay un bloqueo cuando la suspensión en tiempo de ejecución espera la limpieza del trabajo de RTC y el trabajo de RTC llama a ufshcd_rpm_get_sync() para esperar la reanudación del tiempo de ejecución. Aquí está el backtrace del bloqueo: kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff __switch_to+0x1a8/0x2d4 __schedule+0x684/0xa98 schedule+0x48/0xc8 schedule_timeout+0x48/0x170 do_wait_for_common+0x108/0x1b0 wait_for_completion+0x44/0x60 __flush_work+0x39c/0x424 __cancel_work_sync+0xd8/0x208 cancel_delayed_work_sync+0x14/0x28 __ufshcd_wl_suspend+0x19c/0x480 ufshcd_wl_runtime_suspend+0x3c/0x1d4 scsi_runtime_suspend+0x78/0xc8 __rpm_callback+0x94/0x3e0 rpm_suspend+0x2d4/0x65c __pm_runtime_suspend+0x80/0x114 scsi_runtime_idle+0x38/0x6c rpm_idle+0x264/0x338 __pm_runtime_idle+0x80/0x110 ufshcd_rtc_work+0x128/0x1e4 process_one_work+0x26c/0x650 worker_thread+0x260/0x3d8 kthread+0x110/0x134 ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: No hacer referencia a dc_sink en is_dsc_need_re_compute [Por qué] Cuando se desconecta uno de los monitores conectados después del concentrador mst, se produce una desreferencia de puntero nulo. Esto se debe a que dc_sink se libera inmediatamente en early_unregister() o detect_ctx(). Cuando se confirma un nuevo estado que hace referencia directa a la información almacenada en dc_sink, se producirá una desreferencia de puntero nulo. [Cómo] Eliminar la condición de comprobación redundante. La condición relevante ya debería estar cubierta comprobando si dsc_aux es nulo o no. También se restablece dsc_aux a NULL cuando se desconecta el conector.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/preempt_fence: agrandar la sección crítica de la cerca Es realmente fácil introducir bloqueos sutiles en preempt_fence_work_func() ya que operamos en un solo wq ordenado global para señalar nuestras cercas de preempción detrás de escena, por lo que incluso aunque señalemos una cerca en particular, todo en la devolución de llamada debe estar en la sección crítica de la cerca, ya que el bloqueo en la devolución de llamada evitará que otras cercas publicadas señalicen. Si agrandamos la sección crítica de la cerca para cubrir toda la devolución de llamada, entonces lockdep debería poder entender esto mejor y quejarse si tomamos un bloqueo sensible como vm->lock, que también se mantiene cuando se espera en cercas de preempción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: privcmd: Cambiar de mutex a spinlock para irqfds irqfd_wakeup() obtiene EPOLLHUP, cuando es llamado por eventfd_release() por medio de wake_up_poll(&ctx->wqh, EPOLLHUP), que se llama bajo spin_lock_irqsave(). No podemos usar un mutex aquí ya que conduciría a un interbloqueo. Arréglelo cambiando a un spinlock.