Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: convierte de _raw_ a _noinc_ funciones regmap para FIFO El IC SC16IS7XX admite un modo de ráfaga para acceder a los FIFO donde se envía la dirección de registro inicial ($00), seguida de todas los datos FIFO sin tener que reenviar la dirección de registro cada vez. En este modo, el IC no incrementa la dirección de registro para cada byte de lectura/escritura. regmap_raw_read() y regmap_raw_write() son funciones que pueden realizar IO en múltiples registros. Actualmente se utilizan para leer/escribir desde/hacia FIFO y, aunque funcionan correctamente en este modo de ráfaga en el bus SPI, dañarían el caché de regmap si no se desactivara manualmente. La razón es que cuando el tamaño de lectura y escritura es superior a 1 byte, estas funciones asumen que la dirección del registro se incrementa y manejan la caché en consecuencia. Convierta las funciones FIFO R/W para usar las versiones regmap _noinc_ para eliminar el control de caché manual, que era una solución alternativa al usar las versiones _raw_. Los registros FIFO se declaran correctamente como volátiles, por lo que la caché no se utilizará ni se actualizará para los accesos FIFO.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/sparsemem: corrige la carrera al acceder a la sección_memoria->uso La siguiente carrera se observa en un PFN que cae en la región de memoria del dispositivo con la configuración de memoria del sistema donde los PFN son tales que [ ZONA_NORMAL ZONA_DISPOSITIVO ZONA_NORMAL]. Dado que el pfn de inicio y fin de zona normal también contiene los PFN de la memoria del dispositivo, la compactación activada probará también los PFN de la memoria del dispositivo aunque terminen en NOP (porque pfn_to_online_page() devuelve NULL para las secciones de memoria ZONE_DEVICE). Cuando desde otro núcleo, las asignaciones de sección se eliminan para la región ZONE_DEVICE, a la que pertenece el PFN en cuestión, en la que se está operando la compactación actualmente, se produce el bloqueo del kernel con CONFIG_SPASEMEM_VMEMAP habilitado. Los registros de fallos se pueden ver en [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()/ /return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Libere la matriz ms->usage y establezca ms->usage = NULL] pfn_section_valid() [Acceda a ms->usage que es NULL] NOTA: De lo anterior se puede decir que la carrera se reduce a entre pfn_valid()/pfn_section_valid() y la sección desactivada con SPASEMEM_VMEMAP habilitado. La confirmación b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") intentó solucionar el mismo problema borrando SECTION_HAS_MEM_MAP con la expectativa de que valid_section() devuelva false, por lo que no se accede a ms->usage. Solucione este problema siguiendo los pasos a continuación: a) Borre SECTION_HAS_MEM_MAP antes de liberar el ->uso. b) La sección crítica del lado de lectura protegida por RCU devolverá NULL cuando se borre SECTION_HAS_MEM_MAP o podrá acceder con éxito a ->uso. c) Libere ->usage con kfree_rcu() y establezca ms->usage = NULL. No se intentará acceder a ->uso después de esto, ya que SECTION_HAS_MEM_MAP se borra, por lo que valid_section() devuelve falso. Gracias a David/Pavan por sus aportes en este parche. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ En Snapdragon SoC, con la configuración de memoria mencionada de PFN como [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], pueden ver una gran cantidad de problemas diariamente mientras realizan pruebas en una granja de dispositivos. Para este problema en particular, a continuación se encuentra el registro. Aunque el siguiente registro no apunta directamente a pfn_section_valid(){ ms->usage;}, cuando cargamos este volcado en la herramienta Lauterbach T32, sí apunta. [ 540.578056] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 540.578068] Información de cancelación de memoria: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT ( EL actual), IL = 32 bits [ 540.578077] SET = 0 , FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: error de traducción de nivel 1 [ 540.578085] Información de cancelación de datos: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088 ] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x10 58 [540.579460] sp: ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:00000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:00000000000000000 [ 540.579483] x20: 0 000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 00000000000000 00 x12:0000000000000001 [ 540.579501]---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: migrar: se corrigió la asignación de página incorrecta durante la migración de la página Al ejecutar la prueba de estrés, encontramos el siguiente bloqueo del kernel después de unas horas: No se puede manejar la desreferencia del puntero NULL del kernel en virtual dirección 0000000000000000 pc: dentry_name+0xd8/0x224 lr: puntero+0x22c/0x370 sp: ffff800025f134c0 ...... Rastreo de llamadas: dentry_name+0xd8/0x224 puntero+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprint f+0x2c/0x60 vprintk_store+ 0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x22 4 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memoria_block_offline+ 0x44/0xf4 Memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ...... Después de analizar vmcore, descubrí que este problema se debe a la migración de la página. El escenario es que un hilo está realizando la migración de la página y usaremos el campo ->mapping de la página de destino para guardar el puntero 'anon_vma' entre la desasignación de la página y el movimiento de la página, y ahora la página de destino está bloqueada y el recuento es 1. Actualmente, Hay otro subproceso estresante que realiza una conexión en caliente de la memoria, intentando desconectar la página de destino que se está migrando. Descubre que el refcount de esta página de destino es 1, impidiendo la operación fuera de línea, procediendo así a volcar la página. Sin embargo, page_mapping() de la página de destino puede devolver una asignación de archivos incorrecta para bloquear el sistema en dump_mapping(), ya que la página de destino->mapping solo guarda el puntero 'anon_vma' sin configurar el indicador PAGE_MAPPING_ANON. Hay varias formas de solucionar este problema: (1) Configurar el indicador PAGE_MAPPING_ANON para la página de destino ->mapping al guardar 'anon_vma', pero esto puede confundir a PageAnon() para los usuarios de PFN, ya que la página de destino aún no ha creado asignaciones. (2) Hacer que el bloqueo de página llame a page_mapping() en __dump_page() para evitar bloquear el sistema; sin embargo, todavía hay algunos caminantes PFN que llaman a page_mapping() sin mantener el bloqueo de página, como la compactación. (3) Usar página de destino->campo privado para guardar el puntero 'anon_vma' y el estado de la página de 2 bits, tal como página->mapping registra una página anónima, lo que puede eliminar el impacto de page_mapping() para los caminantes de PFN y también parece una solución simple forma. Así que elijo la opción 3 para solucionar este problema, y esto también puede solucionar otros problemas potenciales para los caminantes PFN, como la compactación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mtk-jpeg: Se corrigió el error de use-after-free debido al manejo de la ruta de error en mtk_jpeg_dec_device_run En mtk_jpeg_probe, &jpeg->job_timeout_work está vinculado con mtk_jpeg_job_timeout_work. En mtk_jpeg_dec_device_run, si ocurre un error en mtk_jpeg_set_dec_dst, finalmente iniciará el trabajador mientras marca el trabajo como finalizado invocando v4l2_m2m_job_finish. Hay dos métodos para activar el error. Si eliminamos el módulo, llamará a mtk_jpeg_remove para realizar la limpieza. La secuencia posible es la siguiente, lo que provocará un error de use-after-free. CPU0 CPU1 mtk_jpeg_dec_... | empezar trabajador | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Si cerramos el descriptor de archivo, que llamará a mtk_jpeg_release, tendrá una secuencia similar. Corrija este error iniciando el trabajador de tiempo de espera solo si inició el trabajador jpegdec exitosamente. Entonces v4l2_m2m_job_finish solo se llamará en mtk_jpeg_job_timeout_work o mtk_jpeg_dec_device_run.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: corrige el puntero NULL en la función de cancelación del registro del canal __dma_async_device_channel_register() puede fallar. En caso de falla, chan->local se libera (con free_percpu()) y chan->local se anula. Cuando se llama a dma_async_device_unregister() (debido a una API administrada o intencionalmente por el controlador del controlador DMA), los canales se anulan incondicionalmente, lo que lleva a este puntero NULL: [1.318693] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000d0 [...] [ 1.484499] Seguimiento de llamadas: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Mire la ruta de error de la función dma_async_device_register(), cancelación del registro del dispositivo La ración se realiza sólo si chan->local es no nulo. Luego agregue la misma condición al comienzo de la función __dma_async_device_channel_unregister(), para evitar problemas de puntero NULL cualquiera que sea la API utilizada para alcanzar esta función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: Eliminar el bloqueo de canal antes de poner en cola los búferes asegúrese de que los bloqueos de lectura y escritura para el canal no se tomen en sucesión eliminando el bloqueo de lectura de parse_xfer_event() de manera que se pueda realizar una devolución de llamada dado al cliente puede potencialmente poner en cola los búferes y adquirir el bloqueo de escritura en ese proceso. Cualquier puesta en cola de búferes debe realizarse sin adquirir el bloqueo de lectura del canal, ya que puede generar múltiples bloqueos y un bloqueo suave. [mani: etiqueta de correcciones agregada y copia estable]

En Santesoft Sante FFT Imaging versiones 1.4.1 y anteriores, una vez que un usuario abre un archivo DCM malicioso en las instalaciones de FFT Imaging afectadas, un atacante local podría realizar una escritura fuera de los límites, lo que podría permitir la ejecución de código arbitrario.

En access_secure_service_from_temp_bond de btm_sec.cc, existe una forma posible de lograr la inyección de pulsaciones de teclas debido a una validación de entrada incorrecta. Esto podría conducir a una escalada de privilegios remota (proximal/adyacente) sin necesidad de privilegios de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.

En attp_build_value_cmd de att_protocol.cc, hay una posible escritura fuera de los límites debido a una verificación de los límites faltantes. Esto podría conducir a la ejecución remota de código sin necesidad de privilegios de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.

En createSessionInternal de PackageInstallerService.java, existe una posible ejecución como cualquier aplicación debido a una validación de entrada incorrecta. Esto podría conducir a una escalada local de privilegios sin necesidad de permisos de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.

En smp_proc_sec_req de smp_act.cc, existe una posible lectura fuera de los límites debido a una validación de entrada incorrecta. Esto podría conducir a la divulgación de información remota (próxima/adyacente) sin necesidad de privilegios de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.

En installExistingPackageAsUser de InstallPackageHelper.java, existe una posible omisión de restricción del operador debido a un error lógico en el código. Esto podría conducir a una escalada local de privilegios sin necesidad de permisos de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.