Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "drm/gem-dma: Usar dma_buf de la instancia del objeto GEM". Esto revierte el commit e8afa1557f4f963c9a511bd2c6074a941c308685. El campo dma_buf en la estructura drm_gem_object no es estable durante la vida útil de la instancia del objeto. El campo se vuelve nulo cuando el espacio de usuario libera el identificador GEM final en el objeto de búfer. Esto resultó en una desreferencia de puntero nulo. Las soluciones alternativas en los commit 5307dce878d4 ("drm/gem: Adquirir referencias en identificadores GEM para framebuffers") y f6bfc9afc751 ("drm/framebuffer: Adquirir referencias internas en identificadores GEM") solo resolvieron el problema parcialmente. En particular, no funcionan con objetos de búfer sin un framebuffer DRM asociado. Por lo tanto, volvemos a utilizar .import_attach->dmabuf. v3: - cc estable

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "drm/gem-framebuffer: Usar dma_buf de la instancia del objeto GEM". Esto revierte el commit cce16fcd7446dcff7480cd9d2b6417075ed81065. El campo dma_buf en la estructura drm_gem_object no es estable durante la vida útil de la instancia del objeto. El campo se vuelve nulo cuando el espacio de usuario libera el identificador GEM final en el objeto de búfer. Esto resultó en una desreferencia de puntero nulo. Las soluciones alternativas en los commit 5307dce878d4 ("drm/gem: Adquirir referencias en identificadores GEM para framebuffers") y f6bfc9afc751 ("drm/framebuffer: Adquirir referencias internas en identificadores GEM") solo resolvieron el problema parcialmente. En particular, no funcionan con objetos de búfer sin un framebuffer DRM asociado. Por lo tanto, volvemos a utilizar .import_attach->dmabuf. v3: - cc estable

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/entry: Mask DAIF en cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` y `call_on_irq_stack()` manipulan SP para cambiar a diferentes pilas junto con Shadow Call Stack si está habilitado. Estos dos cambios de pila no se pueden realizar de forma automática y ambas funciones pueden ser interrumpidas por SErrors o Debug Exceptions, lo que, aunque poco probable, es muy problemático: si se interrumpe, podemos terminar con pilas desajustadas y Shadow Call Stack, lo que lleva a pilas dañadas. En `cpu_switch_to()`, puede ocurrir cuando SP_EL0 apunta a la nueva tarea, pero x18 todavía apunta al SCS de la tarea anterior. Cuando el manejador de interrupciones intenta guardar el puntero SCS de la tarea, guardará el antiguo puntero SCS de la tarea (x18) en la nueva estructura de la tarea (apuntada por SP_EL0), bloqueándola. En `call_on_irq_stack()`, puede suceder al cambiar de la pila de tareas a la pila de IRQ y al volver a cambiar. En ambos casos, podemos ser interrumpidos cuando el puntero SCS apunta al SCS de IRQ, pero SP apunta a la pila de tareas. El manejador de interrupciones anidado empuja sus direcciones de retorno en el SCS de IRQ. Luego detecta que SP apunta a la pila de tareas, llama a `call_on_irq_stack()` y bloquea el puntero SCS de la tarea con el puntero SCS de IRQ, ¡que también usará! Esto lleva a que las tareas regresen a direcciones en el SCS incorrecto, o incluso en el SCS de IRQ, lo que desencadena pánicos del kernel a través de CONFIG_VMAP_STACK o FPAC si está habilitado. Esto es posible en una configuración predeterminada, pero poco probable. Sin embargo, al habilitar CONFIG_ARM64_PSEUDO_NMI, DAIF se desenmascara y, en su lugar, el GIC se encarga de filtrar las interrupciones que la CPU debería recibir según su prioridad. Dado el objetivo de emular NMI, la CPU puede recibir pseudo-NMI incluso en `cpu_switch_to()` y `call_on_irq_stack()`, posiblemente con mucha frecuencia según la configuración del sistema y la carga de trabajo, lo que provoca pánicos de kernel impredecibles. Enmascare completamente DAIF en `cpu_switch_to()` y restáurelo al regresar. Haga lo mismo en `call_on_irq_stack()`, pero restáurelo y enmascare alrededor de la rama. Enmascare DAIF incluso si CONFIG_SHADOW_CALL_STACK no está habilitado para mantener la coherencia entre todas las configuraciones. Introduzca y utilice una macro de ensamblaje para guardar y enmascarar DAIF, ya que la existente guarda pero solo enmascara las interrupciones IF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: appletalk: Corrección del use-after-free en la sonda de proxy AARP. La rutina de sonda de proxy AARP (aarp_proxy_probe_network) envía una sonda, libera el bloqueo aarp_lock, se suspende y luego vuelve a adquirir el bloqueo. Durante ese período, un subproceso del temporizador de expiración (__aarp_expire_timer) puede eliminar y ejecutar kfree() en la misma entrada, lo que provoca un use-after-free. condición de ejecución: cpu 0 | cpu 1 atalk_sendmsg() | atif_proxy_probe_device() aarp_send_ddp() | aarp_proxy_probe_network() mod_timer() | lock(aarp_lock) // ¡BLOQUEO! tiempo de espera de unos 200 ms | alloc(aarp_entry) y luego llamar a | proxies[hash] = aarp_entry aarp_expire_timeout() | aarp_send_probe() | unlock(aarp_lock) // ¡DESBLOQUEAR! lock(aarp_lock) // ¡BLOQUEAR! | msleep(100); __aarp_expire_timer(&proxies[ct]) | free(aarp_entry) | unlock(aarp_lock) // ¡DESBLOQUEAR! | | lock(aarp_lock) // ¡BLOQUEAR! | UAF aarp_entry !! ====================================================================== ERROR: KASAN: slab-use-after-free en aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 Lectura de tamaño 4 en la dirección ffff8880123aa360 por la tarea repro/13278 CPU: 3 UID: 0 PID: 13278 Comm: repro No contaminado 6.15.2 #3 PREEMPT(full) Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [en línea] print_report+0xc1/0x630 mm/kasan/report.c:521 kasan_report+0xca/0x100 mm/kasan/report.c:634 aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 atif_proxy_probe_device net/appletalk/ddp.c:332 [en línea] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 sock_do_ioctl+0xdc/0x260 net/socket.c:1190 sock_ioctl+0x239/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:906 [en línea] __se_sys_ioctl fs/ioctl.c:892 [en línea] __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea] do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Asignado: aarp_alloc net/appletalk/aarp.c:382 [en línea] aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468 atif_proxy_probe_device net/appletalk/ddp.c:332 [en línea] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 Liberado: kfree+0x148/0x4d0 mm/slub.c:4841 __aarp_expire net/appletalk/aarp.c:90 [inline] __aarp_expire_timer net/appletalk/aarp.c:261 [inline] aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317 La dirección con errores pertenece al objeto en ffff8880123aa300 que pertenece a la caché kmalloc-192 de tamaño 192 La dirección con errores se encuentra 96 bytes dentro de la región liberada de 192 bytes [ffff8880123aa300, ffff8880123aa3c0) Estado de la memoria alrededor de la dirección con errores: ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880123aa380: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: qup: se sale del bucle en caso de tiempo de espera. La lógica original solo establece el valor de retorno, pero no se sale del bucle si un cliente mantiene activo el bus. Esto es inesperado. Un cliente i2c malicioso o con errores puede bloquear el kernel en este caso, por lo que debe evitarse. Esto se observó durante una prueba prolongada con un extensor GPIO PCA953x. Para solucionarlo, cambie la lógica para que no solo establezca el valor de retorno, sino que también se salga del bucle y regrese al llamador con -ETIMEDOUT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: core: fix NULL dereference al desvincular debido a datos de acoplamiento obsoletos. Si no se restablece coupled_desc.n_coupled tras liberar coupled_rdevs, se puede producir una desreferencia de punteros nulos al acceder a los reguladores después de la desvinculación. Esto puede ocurrir durante la gestión de proyectos en tiempo de ejecución u otras operaciones del regulador que dependen de metadatos de acoplamiento. Por ejemplo, en ridesx4, desvincular el dispositivo de plataforma 'reg-dummy' activa un pánico en regulator_lock_recursive() debido a un estado de acoplamiento obsoleto. Asegúrese de que n_coupled esté establecido en 0 para evitar el acceso a punteros no válidos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: No más autorrecuperación. Cuando un nodo se retira y resulta ser el único que tiene montado el sistema de archivos, gfs2 intenta reproducir el diario local para restablecer la consistencia del sistema de archivos. Esto no solo es una pésima idea, sino que nunca ha funcionado, ya que gfs2_recover_func() se niega a hacer nada durante una retirada. Sin embargo, incluso antes de llegar a este punto, gfs2_recover_func() desreferencia sdp->sd_jdesc->jd_inode. Esto era un use-after-free antes del commit 04133b607a78 ("gfs2: Evitar doble entrada para el diario en caso de error") y, desde entonces, es una desreferencia de puntero nulo. Simplemente elimine la autorrecuperación para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: [ceph] parse_longname(): strrchr() espera una cadena terminada en NUL... y parse_longname() no lo garantiza. Por eso usa kmemdup_nul() para construir el argumento de kstrtou64(); el problema es que kstrtou64() no es el único que lo necesita. Simplemente obtenga una copia terminada en NUL de todo el conjunto y listo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/x86: alienware-wmi-wmax: Se corrige la matriz `dmi_system_id`. Se agrega un miembro vacío faltante a `awcc_dmi_table`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8365-dai-i2s: pasar el tamaño correcto a mt8365_dai_set_priv. Dado mt8365_dai_set_priv, se asigna espacio priv_size para copiar priv_data, lo que significa que debemos pasar mt8365_i2s_priv[i] o "struct mtk_afe_i2s_priv" en lugar de afe_priv, cuyo tamaño es "struct mt8365_afe_private". De lo contrario, la queja de KASAN. [ 59.389765] ERROR: KASAN: global fuera de los límites en mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] ... [ 59.394789] Rastreo de llamadas: [ 59.395167] dump_backtrace+0xa0/0x128 [ 59.395733] show_stack+0x20/0x38 [ 59.396238] dump_stack_lvl+0xe8/0x148 [ 59.396806] print_report+0x37c/0x5e0 [ 59.397358] kasan_report+0xac/0xf8 [ 59.397885] kasan_check_range+0xe8/0x190 [59.398485] asan_memcpy+0x3c/0x98 [59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] [59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm] [59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm] [59.401873] platform_probe+0xcc/0x228 [ 59.402442] really_probe+0x340/0x9e8 [ 59.402992] driver_probe_device+0x16c/0x3f8 [ 59.403638] driver_probe_device+0x64/0x1d8 [ 59.404256] driver_attach+0x1dc/0x4c8 [ 59.404840] bus_for_each_dev+0x100/0x190 [ 59.405442] driver_attach+0x44/0x68 [ 59.405980] bus_add_driver+0x23c/0x500 [ 59.406550] driver_register+0xf8/0x3d0 [ 59.407122] registro_del_controlador_de_plataforma+0x68/0x98 [59.407810] inicio_del_controlador_del_pcm_mt8365_afe+0x2c/0xff8 [snd_soc_mt8365_pcm]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: netlink: can_changelink(): corrige la desreferencia del puntero NULL de struct can_priv::do_set_mode Andrei Lalaev informó de una desreferencia del puntero NULL cuando un dispositivo CAN se reinicia desde Bus Off y el controlador no implementa la devolución de llamada struct can_priv::do_set_mode. Hay 2 rutas de código que llaman a struct can_priv::do_set_mode: - directamente mediante un reinicio manual desde el espacio de usuario, a través de can_changelink() - reinicio automático retrasado después de apagar el bus (desactivado de forma predeterminada) Para evitar la deferencia del puntero NULL, rechace un reinicio manual o configure el retraso del reinicio automático en can_changelink() e informe del error a través de extack al espacio de usuario. Como medida de seguridad adicional, deje que can_restart() devuelva un error si can_priv::do_set_mode no está configurado en lugar de desreferenciarlo sin marcar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige una desreferencia de puntero nulo en ice_copy_and_init_pkg(). Se agrega una verificación para el valor de retorno de devm_kmemdup() para evitar una posible desreferencia de puntero nulo.