Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige la advertencia de kmemleak para el mapa hash de percpu Vlad Poenaru informó el siguiente problema de kmemleak: objeto sin referencia 0x606fd7c44ac8 (tamaño 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Una investigación más profunda muestra que la razón se debe a un almacenamiento no alineado de 8 bytes del puntero por CPU en htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Tenga en cuenta que la alineación completa de htab_elem es 8 (para x86_64). Si key_size es 4, significa que pptr se almacena en una ubicación que está alineada con 4 bytes pero no con 8 bytes. En mm/kmemleak.c, scan_block() escanea la memoria basándose en un paso de 8 bytes, por lo que no detectará por encima de pptr, por lo que informa la pérdida de memoria. En htab_map_alloc(), ya tenemos htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); Por lo tanto, almacenar pptr con alineación de 8 bytes no causará ningún problema y también puede solucionar la fuga de kmem. El problema también se puede reproducir con la autoprueba de BPF: 1. Habilite la configuración CONFIG_DEBUG_KMEMLEAK. 2. Añada un getchar() antes de skel destroy en test_hash_map() en prog_tests/for_each.c. El objetivo es mantener el mapa disponible para que se pueda detectar la fuga de kmem. 3. Ejecute './test_progs -t for_each/hash_map &' y se debería informar de una fuga de kmem.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Mantener las operaciones de escritura atómicas. syzbot reportó una desreferencia de puntero nulo en __generic_file_write_iter. [1] Antes de completar la operación de escritura, el usuario ejecuta ioctl[2] para borrar el indicador de compresión del archivo, lo que provoca que la sentencia is_compressed() devuelva 0, lo que provoca que el programa acceda al proceso incorrecto y llame a la operación incorrecta ntfs_aops_cmpr, lo que desencadena la desreferencia de puntero nulo de write_begin. Utilice el bloqueo de inodo para sincronizar ioctl y write y evitar este caso. [1] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000086000006 EC = 0x21: IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: error de traducción de nivel 2 usuario pgtable: 4k páginas, VAs de 48 bits, pgdp=000000011896d000 [000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000 Error interno: Oops: 0000000086000006 [#1] PREEMPT Módulos SMP vinculados: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 No contaminado 6.13.0-rc3-syzkaller-g573067a5a685 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055 sp : ffff80009d4978a0 x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8 x26: 00000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68 x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000 x20: 0000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001 x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0 x11: 0000000000ff0100 x10: 0000000000ff0100 x9: 0000000000000000 x8: 0000000000000000 x7: 0000000000000000 x6: 0000000000000000 x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000 x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0 Rastreo de llamada: 0x0 (P) __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156 ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x920/0xcf4 fs/read_write.c:679 ksys_write+0x15c/0x26c fs/read_write.c:731 __do_sys_write fs/read_write.c:742 [inline] __se_sys_write fs/read_write.c:739 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-imx: Agregar verificación para spi_imx_setupxfer() Agregar verificación para el valor de retorno de spi_imx_setupxfer(). El puntero de función spi_imx->rx y spi_imx->tx puede ser NULL cuando spi_imx_setupxfer() devuelve un error y hace que el puntero se desreferencia a NULL. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Rastreo de llamadas: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: corrige un problema de desbordamiento del tamaño de búfer durante la creación de udmabuf al convertir size_limit_mb a u64 al calcular pglimit.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sound/virtio: Se corrigen las advertencias de cancel_sync en work_structs no inicializados Betty informó haber recibido la siguiente advertencia: [ 8.709131][ T221] ADVERTENCIA: CPU: 2 PID: 221 en kernel/workqueue.c:4182 ... [ 8.713282][ T221] Rastreo de llamadas: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... Parece que estamos llegando a la ruta de error en virtsnd_probe(), que activa un virtsnd_remove() que itera sobre los subflujos que llaman a cancel_work_sync() en el elapsed_period work_struct. Mirando el código anterior: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() Establecemos snd->nsubstreams, asignamos los snd->substreams y, si encontramos un error en la asignación de información o algo en virtsnd_ctl_query_info() falla, saldremos sin haber inicializado el work_struct elapsed_period. Cuando se deshaga esa ruta de error, llamamos a virtsnd_remove() que, mientras la matriz de substreams esté asignada, iterará llamando a cancel_work_sync() en la estructura de trabajo no inicializada que encuentre esta advertencia. Takashi Iwai sugirió esta solución, que inicializa la estructura de substreams justo después de la asignación, de modo que, si encontramos las rutas de error, evitamos intentar limpiar los datos no inicializados. Nota: Todavía no he logrado reproducir el problema yo mismo, por lo que este parche ha tenido pruebas limitadas. ¡Se agradecerían sus comentarios o ideas!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige una posible desreferencia de puntero nulo en dev_uevent(). Si el espacio de usuario lee el atributo de dispositivo "uevent" al mismo tiempo que otro subproceso desvincula el dispositivo de su controlador, cambiar de un puntero válido a nulo en dev->driver puede provocar un fallo. Se soluciona esto usando READ_ONCE() al obtener el puntero y bloqueando la lista de k de los controladores del bus para garantizar que la instancia del controlador no desaparezca al acceder a ella. Use WRITE_ONCE() al configurar el puntero del controlador para evitar cortes.

El complemento Event Manager, Events Calendar, Tickets, Registrations – Eventin para WordPress es vulnerable a la lectura de archivos arbitrarios en todas las versiones hasta la 4.0.26 incluida, mediante la función proxy_image(). Esto permite a atacantes no autenticados leer el contenido de archivos arbitrarios en el servidor, que pueden contener información confidencial.

El tema Wolmart | Multi-Vendor Marketplace WooCommerce para WordPress es vulnerable a la ejecución de shortcodes arbitrarios en todas las versiones hasta la 1.8.11 incluida. Esto se debe a que el software permite a los usuarios ejecutar una acción que no valida correctamente un valor antes de ejecutar do_shortcode. Esto permite que atacantes no autenticados ejecuten shortcodes arbitrarios.

Se descubrió un problema en Django 4.2 (anterior a 4.2.21), 5.1 (anterior a 5.1.9) y 5.2 (anterior a 5.2.1). La función django.utils.html.strip_tags() es vulnerable a una posible denegación de servicio (rendimiento lento) al procesar entradas que contienen grandes secuencias de etiquetas HTML incompletas. El filtro de plantilla striptags también es vulnerable, ya que está basado en strip_tags().

i-Educar es un software de gestión escolar gratuito y totalmente en línea. La versión 2.9 de la aplicación no valida ni depura correctamente la información proporcionada por el usuario, lo que genera una vulnerabilidad de cross site scripting almacenado en el campo de entrada "Tipo de Usuário". A través de este vector de ataque, un usuario malicioso podría obtener información de otro usuario, lo que podría provocar la filtración de información confidencial u otras acciones maliciosas. Al momento de la publicación, no se conocían versiones parcheadas.

Craft CMS almacena contenido arbitrario proporcionado por usuarios no autenticados en archivos de sesión. Este contenido podría ser accedido y ejecutado, posiblemente aprovechando una vulnerabilidad independiente. Craft CMS redirige las solicitudes que requieren autenticación a la página de inicio de sesión y genera un archivo de sesión en el servidor, en `/var/lib/php/sessions`. Estos archivos de sesión se denominan `sess_[session_value]`, donde `[session_value]` se proporciona al cliente en un encabezado de respuesta `Set-Cookie`. Craft CMS almacena la URL de retorno solicitada por el cliente sin parámetros de limpieza. Por lo tanto, un cliente no autenticado puede introducir valores arbitrarios, como código PHP, en una ubicación de archivo local conocida en el servidor. Se han publicado las versiones 5.7.5 y 4.15.3 de Craft CMS para solucionar este problema.

Rack es una interfaz modular de servidor web Ruby. En versiones anteriores a la 2.2.14, la 3.0.16 y la 3.1.14, `Rack::QueryParser` analiza cadenas de consulta y cuerpos `application/x-www-form-urlencoded` en estructuras de datos Ruby sin imponer ningún límite en el número de parámetros, lo que permite a los atacantes enviar solicitudes con una cantidad extremadamente grande de parámetros. La vulnerabilidad surge porque `Rack::QueryParser` itera sobre cada par clave-valor separado por `&` y lo añade a un hash sin imponer un límite superior en el número total de parámetros. Esto permite a un atacante enviar una sola solicitud con cientos de miles (o más) de parámetros, lo que consume demasiada memoria y CPU durante el análisis. Un atacante puede provocar una denegación de servicio enviando solicitudes HTTP manipuladas específicamente, lo que puede causar el agotamiento de la memoria o la sobrecarga de recursos de la CPU, bloqueando o bloqueando el servidor Rack. Esto provoca una interrupción total del servicio hasta que se reinicia el trabajador afectado. Las versiones 2.2.14, 3.0.16 y 3.1.14 solucionan el problema. Existen otras mitigaciones. Se puede usar middleware para imponer un tamaño máximo de cadena de consulta o un número máximo de parámetros, o emplear un proxy inverso (como Nginx) para limitar el tamaño de las solicitudes y rechazar cadenas o cuerpos de consulta demasiado grandes. Limitar el tamaño del cuerpo de la solicitud y la longitud de las cadenas de consulta a nivel de servidor web o CDN es una mitigación eficaz.