Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrige fugas de memoria y fallos al realizar un reinicio suave El segundo commit etiquetado introdujo un UAF, ya que eliminó la restauración de punteros q_vector->vport después de reinicializar las estructuras. Esto se debe a que todas las funciones de asignación de colas se realizan aquí con la nueva estructura vport temporal y esas funciones reescriben los punteros hacia atrás al vport. Luego, esta nueva estructura se libera y los punteros comienzan a no llevar a ninguna parte. Pero en términos generales, la lógica actual es muy frágil. Afirma ser más confiable cuando el sistema tiene poca memoria, pero de hecho, consume dos veces más memoria ya que en el momento de ejecutar esta función, hay dos vports asignados con sus colas y vectores. Además, afirma evitar que el controlador entre en "mal estado", pero de hecho, cualquier error durante la reconstrucción deja el antiguo vport en el estado parcialmente asignado. Finalmente, si la interfaz está inactiva cuando se llama a la función, siempre asigna un nuevo conjunto de colas, pero cuando el usuario decide habilitar la interfaz más adelante, vport_open() las asigna una vez más, es decir, hay una clara pérdida de memoria aquí. Simplemente no asigne un nuevo conjunto de colas cuando realice un reinicio, eso resuelve fallas y pérdidas de memoria. Vuelva a agregar el número de cola anterior y vuelva a abrir la interfaz en la reversión: eso resuelve los estados de limbo cuando el dispositivo se deja deshabilitado y/o sin colas de HW habilitadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: se corrige el acceso FIFO no válido con un conjunto de registros especiales. Al habilitar el acceso al conjunto de registros especiales, pueden producirse interrupciones de RHR y tiempo de espera del receptor. En este caso, el controlador IRQ intentará leer desde el FIFO a través del registro RHR en la dirección 0x00, pero la dirección 0x00 está asignada al registro DLL, lo que da como resultado una lectura FIFO errónea. Ejemplo de gráfico de llamadas: sc16is7xx_startup(): entrada sc16is7xx_ms_proc(): entrada sc16is7xx_set_termios(): entrada sc16is7xx_set_baud(): DLH/DLL = $009C --> acceder al conjunto de registros especiales sc16is7xx_port_irq() entrada --> IIR es 0x0C sc16is7xx_handle_rx() entrada sc16is7xx_fifo_read(): --> no se puede acceder a FIFO (RHR) porque está asignado a DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): salida --> Restaurar el acceso al conjunto de registros generales Solucione el problema reclamando el mutex efr_lock al acceder al conjunto de registros especiales.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: se corrige una posible corrupción de DMA ARCH_DMA_MINALIGN se definió como 16 - esto es demasiado pequeño - puede ser posible que dos asignaciones de 16 bytes no relacionadas compartan una línea de caché. Si una de estas asignaciones se escribe usando DMA y la otra se escribe usando escritura en caché, el valor que se escribió con DMA puede estar dañado. Esta confirmación cambia ARCH_DMA_MINALIGN a 128 en PA20 y 32 en PA1.1 - ese es el tamaño de línea de caché más grande posible. Como las diferentes microarquitecturas de parisc tienen diferentes tamaños de línea de caché, definimos arch_slab_minalign(), cache_line_size() y dma_get_cache_alignment() para que el kernel pueda ajustar los parámetros de caché de losa dinámicamente, según el tamaño de línea de caché detectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: line6: Fix racy access to midibuf Puede haber accesos concurrentes a midibuf de line6 tanto desde la devolución de llamada de finalización de URB como desde el acceso a la API rawmidi. Esto podría ser la causa de la advertencia KMSAN activada por syzkaller a continuación (así que se indica aquí). Este parche protege la llamada midibuf de la ruta de código anterior con un spinlock para evitar las posibles ejecuciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/smt: Corregir desequilibrio en sched_smt_present dec/inc Recibí el siguiente informe de advertencia mientras realizaba una prueba de estrés: etiqueta de salto: ¡recuento negativo! ADVERTENCIA: CPU: 3 PID: 38 en kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Seguimiento de llamadas: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Porque cuando cpuset_cpu_inactive() falla en sched_cpu_deactivate(), la CPU fuera de línea falló, pero sched_smt_present se decrementa antes de llamar a sched_cpu_deactivate(), esto genera un dec/inc desequilibrado, por lo que debe solucionarlo incrementando sched_smt_present en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: core: Comprobar si hay un descriptor no configurado Asegúrese de que el descriptor se haya configurado antes de consultar maxpacket. Esto soluciona un error de puntero nulo en este caso. Esto puede suceder si el gadget no configura correctamente el endpoint para la velocidad actual, o si los descriptores del gadget están mal formados y no se encuentra el descriptor para la velocidad/endpoint. No se conoce ningún controlador de gadget actual que tenga este problema, pero puede causar un error difícil de encontrar durante el desarrollo de nuevos gadgets.