Vulnerabilidades

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: iio: se corrige una posible escritura fuera de límite. El búfer está configurado a 20 caracteres. Si quien llama escribe más caracteres, el recuento se trunca al espacio máximo disponible en "simple_write_to_buffer". Para protegerse del acceso fuera de límite, compruebe que el tamaño de entrada se ajuste al búfer y añada un terminador cero después de copiar, al final de los datos copiados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "drm/gem-shmem: Usar dma_buf de la instancia del objeto GEM". Esto revierte el commit 1a148af06000e545e714fe3210af3d77ff903c11. 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-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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: rechaza tipos de archivo no válidos al leer inodos. Para evitar que los inodos con tipos de archivo no válidos se filtren en el sistema de archivos virtual (VFS) y provoquen fallos de funcionamiento o de aserción, se ha añadido una comprobación de depuración al leer un inodo desde un dispositivo de bloque. Si el tipo de archivo no es válido, se considera un error del sistema de archivos.

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`.