Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracefs: usar RCU de inodo genérico para sincronizar la liberación con la aleatorización del diseño de la estructura habilitada para 'struct inode', debemos evitar superponer cualquiera de los miembros de RCU utilizados o inicializados solo una vez, por ejemplo, i_lru o i_sb_list para no dañar los recorridos de listas relacionadas al hacer uso de rcu_head. En caso de una disposición desafortunada de la estructura 'struct inode', podemos terminar con el siguiente resultado al ejecutar las pruebas automáticas de ftrace: [<...>] corrupción de list_del, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [objeto slab]) es NULL (prev es tracefs_inode_cache+0x78/0x4e0 [objeto slab]) [<...>] ------------[ cortar aquí ]------------ [<...>] ¡ERROR del kernel en lib/list_debug.c:54! [<...>] código de operación no válido: 0000 [#1] PREEMPT SMP KASAN [<...>] CPU: 3 PID: 2550 Comm: mount Contaminado: GN 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65 [<...>] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [<...>] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0 [<...>] Código: 48 b8 99 fb 65 f2 ff ff ff es e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 es ff es ff es ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 es ff es ff es ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f [<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283 [<...>] RAX: 000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000 [<...>] RDX: RSI: ffffffff89dd8b60 RDI: 0000000000000001 [<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25 [<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d [<...>] R13: 000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000 [<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [objeto de losa] [<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0 [<...>] RSI: __func__.47+0x4340/0x4400 [<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [objeto de losa] [<...>] RSP: proceso kstack fffffe80416afaf0+0x7af0/0x8000 [montaje 2550 2550] [<...>] R09: sombra de kasan del proceso kstack fffffe80416af928+0x7928/0x8000 [montaje 2550 2550] [<...>] R10: proceso kstack fffffe80416af92f+0x792f/0x8000 [montaje 2550 2550] [<...>] R14: tracefs_inode_cache+0x78/0x4e0 [objeto de losa] [<...>] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000 [<...>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 sombra CR4: 0000000000360ef0 [<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [<...>] DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [<...>] ASID: 0003 [<...>] Pila: [<...>] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0 [<...>] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f [<...>] 000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392 [<...>] Rastreo de llamadas: [<...>] [<...>] [] ? liberación_de_bloqueo+0x175/0x380 fffffe80416afaf0 [<...>] [] lista_lru_del+0x152/0x740 fffffe80416afb48 [<...>] [] lista_lru_del_obj+0x113/0x280 fffffe80416afb88 [<...>] [] ? __dentry_kill+0x23c/0xf00 fffffe80416afc40 [<...>] [] ? __esta_comprobación_previa_de_cpu+0x1f/0xa0 fffffe80416afc48 [<...>] [] ? lista_de_reducción_dentry+0x1c5/0x760 fffffe80416afc70 [<...>] [] ? lista_dentry_shrink+0x51/0x760 fffffe80416afc78 [<...>] [] lista_dentry_shrink+0x288/0x760 fffffe80416afc80 [<...>] [] lista_dentry_shrink+0x155/0x420 fffffe80416afcc8 [<...>] [] ? id_procesador_smp_depuración+0x23/0xa0 fffffe80416afce0 [<...>] [] ? do_one_tre ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: reenviar errores de recuperación suave al espacio de usuario Como discutimos antes [1], la recuperación suave debe reenviarse al espacio de usuario, o podemos llegar a un estado realmente malo donde las aplicaciones seguirán enviando búferes de comandos colgados que nos llevarán a un reinicio completo. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (seleccionado de el commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)