Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: uniphier-sd: corrige una fuga de recursos en la función de eliminación Falta una llamada 'tmio_mmc_host_free()' en la función de eliminación, para equilibrar un 'tmio_mmc_host_alloc()' llamar a la sonda. Esto se hace en la ruta de manejo de errores de la sonda, pero no en la función de eliminación. Agrega la llamada faltante.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/drivers/cpufreq_cooling: solucionar el problema de Slab OOB El problema de Slab OOB es escaneado por KASAN en cpu_power_to_freq(). Si la potencia se limita por debajo de la potencia de OPP0 en la tabla EM, provocará un problema de losa fuera de los límites con un índice de matriz negativo. Devuelve la frecuencia más baja si la potencia limitada no puede encontrar un OPP adecuado en la tabla EM para solucionar este problema. Seguimiento inverso: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x 248/0x3f0 [] el1_dbg+0x14 /0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114 /0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] térmico _zone_device_check+0xe4/0x154 [] proceso_one_work+0x5e4 /0xe28 [] work_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvbdev: corrige la pérdida de memoria en dvb_media_device_free() dvb_media_device_free() está perdiendo memoria. Libere `dvbdev->adapter->conn` antes de configurarlo en NULL, como se documenta en include/media/media-device.h: "La instancia media_entity debe ser liberada explícitamente por el controlador si es necesario".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm rq: corrige la liberación doble de blk_mq_tag_set en dev y se elimina después de que falla la carga de la tabla Al cargar una tabla de mapeador de dispositivos para un dispositivo mapeado basado en solicitudes y la asignación/inicialización de blk_mq_tag_set Si el dispositivo falla, la siguiente eliminación del dispositivo provocará una doble liberación. Por ejemplo, (dmesg): mapeador de dispositivos: núcleo: no se puede inicializar la cola para el dispositivo asignado dm-mq basado en solicitudes mapeador de dispositivos: ioctl: no se puede configurar la cola de dispositivos para una nueva tabla. No se puede manejar la desreferencia del puntero del kernel en el espacio de direcciones virtual del kernel Dirección fallida: 0305e098835de000 TEID: 0305e098835de803 Fallo en el modo de espacio de inicio mientras se usa el kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Ups: 0038 ilc:3 [#1] Módulos SMP vinculados en: ... muchos módulos ... Compatible: Sí, CPU externa: 0 PID: 7348 Comm: multipathd Kdump: cargado Contaminado: GWX 5.3.18-53-default #1 SLE15-SP3 Nombre de hardware: IBM 8561 T01 7I2 (LPAR) Krnl PSW: 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Clave:0 M :1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 00000000000000000 000000025e520270 000000025 e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 0 00003ff80138650 000000025e5202a2 000003e00396faa8 Código Krnl: 000000025e368eb8: c4180041e100 lgrl % r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310 b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Seguimiento de llamadas: [<0 00000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/ 0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x1 50/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe /0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [ <000000025e8c15ac>] system_call+0xd8/0x2c8 Última dirección del evento de última hora: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Pánico del kernel: no se sincroniza: excepción grave: pánico_on_oops Cuando la asignación/inicialización de blk_mq_tag_set falla en d m_mq_init_request_queue(), no está inicializado/liberado, pero el puntero no se restablece a NULL; entonces, cuando dev_remove() ingresa más tarde a dm_mq_cleanup_mapped_device(), ve el puntero e intenta desinicializarlo y liberarlo nuevamente. Solucione este problema estableciendo el puntero en NULL en el manejo de errores dm_mq_init_request_queue(). También configúrelo en NULL en dm_mq_cleanup_mapped_device().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: reestructurar trace_clock_global() para no bloquear nunca. Se informó que una solución a la detección de recursividad del búfer circular provocaría que la máquina se bloqueara al realizar pruebas de suspensión/reanudación. El siguiente seguimiento se extrajo de la depuración de ese caso: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7 /0xf0? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0? trace_clock_global+0x91/0xa0? __rb_reserve_next+0x237/0x460? ring_buffer_lock_reserve+0x12a/0x3f0? trace_event_buffer_lock_reserve+0x3c/0x120? trace_event_buffer_reserve+0x6b/0xc0? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0? dpm_run_callback+0x3b/0xc0? pm_ops_is_empty+0x50/0x50? platform_get_irq_byname_opcional+0x90/0x90? trace_device_pm_callback_start+0x82/0xd0? dpm_run_callback+0x49/0xc0 Con el siguiente RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Dado que la solución a la detección de recursión permitiría que ocurriera una sola recursión durante el seguimiento, esto llevó a trace_clock_global() a tomar un bloqueo de giro y luego intentarlo para tomarlo de nuevo: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* bloqueo tomado */ (algo más es rastreado por la función de seguimiento del gráfico) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath () { /* ¡BLOQUEO MUERTO! */ El rastreo *nunca* debe bloquearse, ya que puede provocar bloqueos extraños como el anterior. Reestructura el código trace_clock_global() para que, en lugar de simplemente tomar un bloqueo para actualizar el "prev_time" registrado, simplemente lo uses, ya que dos eventos suceden en dos CPU diferentes que llaman a esto al mismo tiempo, realmente no importa cuál va primero. Utilice un trylock para obtener el bloqueo para actualizar prev_time y, si falla, simplemente inténtelo de nuevo la próxima vez. Si no se pudo tomar, eso significa que algo más ya lo está actualizando. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: herramientas/turbostat de potencia: soluciona el problema de desbordamiento de compensación en la conversión de índice. La función idx_to_offset() devuelve el tipo int (32 bits firmado), pero MSR_PKG_ENERGY_STAT es u32 y se interpretaría como negativo. número. El resultado final es que alcanza la verificación if (offset < 0) en update_msr_sum(), lo que evita que la devolución de llamada del temporizador actualice la estadística en segundo plano cuando se utilizan duraciones prolongadas. Existe un problema similar en offset_to_idx() y update_msr_sum(). Solucione este problema convirtiendo 'int' a 'off_t' en consecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: core: Realiza un reinicio suave del núcleo al cambiar de modo Según la guía de programación, para cambiar el modo del controlador DRD, el controlador debe hacer lo siguiente. Para cambiar de dispositivo a host: 1. Reinicie el controlador con GCTL.CoreSoftReset 2. Configure GCTL.PrtCapDir (modo de host) 3. Reinicie el host con USBCMD.HCRESET 4. Luego siga con la secuencia de inicialización de registros del host Para cambiar de host a dispositivo: 1. Reinicie el controlador con GCTL.CoreSoftReset 2. Configure GCTL.PrtCapDir (modo de dispositivo) 3. Reinicie el dispositivo con DCTL.CSftRst 4. Luego siga con la secuencia de inicialización de registros Actualmente nos falta el paso 1) para hacer GCTL .CoreSoftReset y paso 3) de cambio de host a dispositivo. John Stult informó un problema de bloqueo observado con la plataforma HiKey960 sin estos pasos[1]. Se observa un problema similar con la plataforma de pruebas de Ferry[2]. Entonces, aplique los pasos requeridos junto con algunas correcciones a la versión de Yu Chen y John Stultz. Las principales correcciones a sus versiones son la falta de espera para la sincronización de los relojes antes de borrar GCTL.CoreSoftReset y solo aplicar DCTL.CSftRst al cambiar de host a dispositivo. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7- 9cd4-0695-64fc927e01f1@gmail.com/

La validación de entrada incorrecta permite la inyección de encabezado en la librería MIME4J cuando se usa MIME4J DOM para redactar mensajes. Un atacante puede aprovechar esto para agregar encabezados no deseados a los mensajes MIME.

Vulnerabilidad de inyección SQL en linlinjava litemall v.1.8.0 permite a un atacante remoto obtener información confidencial a través de los parámetros apodo, consignatario, orderSN, orderStatusArray del componente AdminOrdercontroller.java.

En el módulo "Administrador de cuentas | Representante de ventas y distribuidores | CRM" (prestasalesmanager) hasta 9.0 de Presta World para PrestaShop, un invitado puede descargar información personal sin restricciones realizando un ataque de path traversal.

En el módulo "So Flexibilite" (soflexibilite) de Common-Services para PrestaShop < 4.1.26, un invitado (cliente autenticado) puede realizar una inyección Cross Site Scripting (XSS).

En el módulo "Importar/Actualizar producto masivo desde cualquier archivo Csv/Excel Pro" (ba_importer) hasta la versión 1.1.28 de Comprar complementos para PrestaShop, un invitado puede realizar inyección SQL en las versiones afectadas.