Vulnerabilidades

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)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: Apagar el temporizador y evitar el rearme cuando se descarga el controlador. Al descargar el controlador btnxpuart, se eliminará su temporizador asociado. Si el temporizador se modifica en este momento, hace que el kernel llame a este temporizador incluso después de que se haya descargado el controlador, lo que provoca un pánico del kernel. Utilice timer_shutdown_sync() en lugar de del_timer_sync() para evitar el rearme. registro de pánico: Error interno: Ups: 0000000086000007 [#1] Módulos PREEMPT SMP vinculados en: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [última descarga: [btnxpuart] CPU: 5 PID: 723 Comm: memtester Contaminado: GO 6.6.23-lts-next-06207-g4aef2658ac28 #1 Nombre del hardware: Placa NXP i.MX95 19X19 (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Rastreo de llamadas: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c llamada_a_pila_irq+0x24/0x4c do_softirq_propia_pila+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Código: ???????? ???????? ???????? ???????? (???????) ---[ fin del seguimiento 0000000000000000 ]--- Pánico del núcleo: no se sincroniza: Vaya: Excepción fatal en la interrupción SMP: deteniendo las CPU secundarias Desplazamiento del núcleo: deshabilitado Funciones de la CPU: 0x0,c0000000,40028143,1000721b Límite de memoria: ninguno ---[ fin del seguimiento 0 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no hacer BUG_ON() al liberar un bloque de árbol después de un error Al liberar un bloque de árbol, en btrfs_free_tree_block(), si no podemos crear una referencia retrasada, no nos ocupamos del error y simplemente hacemos un BUG_ON(). El error más probable que ocurra es -ENOMEM, y tenemos un comentario que menciona que solo puede ocurrir -ENOMEM, pero eso no es cierto, porque en caso de que los qgroups estén habilitados, cualquier error devuelto por btrfs_qgroup_trace_extent_post() (puede ser -EUCLEAN o cualquier cosa devuelta por btrfs_search_slot(), por ejemplo) se puede propagar de vuelta a btrfs_free_tree_block(). Así que deja de hacer un BUG_ON() y devuelve el error a los llamadores y haz que aborten la transacción para evitar fugas de espacio. Syzbot estaba activando esto, probablemente debido a la inyección de fallo de asignación de memoria.