Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: evitar la desreferencia del puntero nulo en la búsqueda de regiones cxl_dpa_to_region() busca una región basada en memdev y DPA. Se supone erróneamente que un endpoint encontrado mapeando el DPA también pertenece a una región completamente ensamblada. Cuando no es cierto, se produce una desreferencia del puntero nulo al buscar el nombre de la región. Esto aparece durante la prueba de la búsqueda de regiones después de un error al ensamblar una región definida por el BIOS o si la búsqueda coincidió con el ensamblaje de la región definida por el BIOS. No limpiar las regiones definidas por el BIOS que fallan en el ensamblaje es un problema en sí mismo y una solución a ese problema aliviará parte del impacto. Esto no aliviará las condiciones de carrera, así que endurezcamos este camino. El cambio de comportamiento es que el kernel oops debido a una desreferencia de puntero nulo se reemplaza con un mensaje dev_dbg() que indica que se asignó un endpoint. Se agregan comentarios adicionales para que los futuros usuarios de esta función puedan comprender más claramente lo que proporciona.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/mem: no se corrige cxl_nvd durante el autoensamblaje de la región pmem. Cuando el subsistema CXL ensambla automáticamente una región pmem durante el sondeo del puerto del endpoint cxl, presione siempre debajo de calltrace. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000078 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x82/0x160? do_user_addr_fault+0x65/0x6b0? exc_page_fault+0x7d/0x170? asm_exc_page_fault+0x26/0x30? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem] cxl_bus_probe+0x1b/0x60 [cxl_core] really_probe+0x173/0x410? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x90/0x120 bus_for_each_drv+0x84/0xe0 __device_attach+0xbc/0x1f0 be_device+0x90/0xa0 device_add+0x51c/0x710 devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core] cxl_bus_probe+ 0x1b/0x60 [cxl_core] El cxl_nvd de memdev debe estar disponible durante el sondeo de la región pmem. Actualmente, cxl_nvd está registrado después de la sonda del puerto del endpoint. La sonda de endpoint, en el caso de autoensamblaje de regiones, puede provocar una sonda de región pmem que requiera el cxl_nvd aún no disponible. Ajuste la secuencia para que se cumpla esta dependencia. Esto requiere agregar un parámetro de puerto a cxl_find_nvdimm_bridge() que se puede usar para consultar el puerto raíz ancestro. El puerto del endpoint aún no está disponible, pero compartirá un ancestro común con su padre, así que inicie la consulta desde allí.

Magento-lts es una alternativa de soporte a largo plazo a Magento Community Edition (CE). Esta vulnerabilidad de XSS afecta las configuraciones del sistema design/header/welcome, design/header/logo_src, design/header/logo_src_small y design/header/logo_alt. Su objetivo es permitir a los administradores establecer un texto en los dos casos y definir una URL de imagen para los otros dos casos. Pero debido a que anteriormente faltaba el escape, se permitía ingresar HTML arbitrario y, como consecuencia, también JavaScript arbitrario. El problema se solucionó con la versión 20.10.1 o superior.

tgstation-server es una herramienta a escala de producción para la gestión de servidores BYOND. Antes de 6.8.0, los usuarios con permisos bajos que usaban el privilegio "Set .dme Path" podían configurar archivos .dme maliciosos existentes en la máquina host para compilarlos y ejecutarlos. Estos archivos .dme se pueden cargar a través del servidor tgstation (que requiere un privilegio aislado e independiente) o por algún otro medio. Un servidor configurado para ejecutarse en el nivel de seguridad confiable de BYOND (que requiere un tercer privilegio separado y aislado O que lo establezca otro usuario) podría llevar a que esto se convierta en una ejecución remota de código a través del proceso shell() de BYOND. La capacidad de ejecutar este tipo de ataque es un efecto secundario conocido de tener usuarios privilegiados de TGS, pero normalmente requiere múltiples privilegios con debilidades conocidas. Este vector no es intencional ya que no requiere control sobre el origen del código de implementación y _puede_ no requerir acceso de escritura remota al directorio "Configuration" de una instancia. Este problema se solucionó en las versiones 6.8.0 y superiores.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io_uring: soluciona posible punto muerto en io_register_iowq_max_workers() La función io_register_iowq_max_workers() llama a io_put_sq_data(), que adquiere el sqd->lock sin liberar uring_lock. De manera similar a la confirmación 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before adquiring sqd->lock"), esto puede conducir a una posible situación de punto muerto. Para resolver este problema, uring_lock se libera antes de llamar a io_put_sq_data() y luego se vuelve a adquirir después de la llamada a la función. Este cambio garantiza que los bloqueos se adquieran en el orden correcto, evitando la posibilidad de un punto muerto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: archivos de caché: establece el objeto para que se cierre si ondemand_id < 0 en copen. Si se llama maliciosamente a copen en el modo de usuario, puede eliminar la solicitud correspondiente a la identificación aleatoria. Y es posible que la solicitud aún no se haya leído. Tenga en cuenta que cuando el objeto está configurado para reabrirse, la solicitud de apertura se realizará con el estado aún reabierto en el caso anterior. Como resultado, la solicitud correspondiente a este objeto siempre se omite en la función select_req, por lo que la solicitud de lectura nunca se completa y bloquea otros procesos. Solucione este problema simplemente configurando el objeto para que se cierre si su id <0 en copen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: archivos de caché: agregue verificación de coherencia para copen/cread. Esto evita que procesos maliciosos completen solicitudes aleatorias de copen/cread y bloqueen el sistema. Las comprobaciones agregadas se enumeran a continuación: * Genérico, copen solo puede completar solicitudes abiertas y cread solo puede completar solicitudes de lectura. * Para copen, ondemand_id no debe ser 0, porque esto indica que el daemon no ha leído la solicitud. * Para cread, el objeto correspondiente a fd y req debe ser el mismo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFSv4: corrige la pérdida de memoria en nfs4_set_security_label Filtramos nfs_fattr y nfs4_label cada vez que configuramos un xattr de seguridad.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: btrfs:qgroup: arregla fuga de cuota raíz tras fallo de desactivación de cuota Si durante la desactivación de cuota fallamos al limpiar el árbol de cuotas o al borrar el root del árbol raíz, saltamos al etiqueta 'out' sin eliminar la referencia en la raíz de la cuota, lo que resulta en una pérdida de la raíz ya que fs_info->quota_root ya no apunta a la raíz (la hemos configurado en NULL justo antes de esos pasos). Solucione este problema realizando siempre una llamada btrfs_put_root() bajo la etiqueta 'out'. Este es un problema que existe desde que qgroups se agregaron por primera vez en 2012 mediante el compromiso bed92eae26cc ("Btrfs: implementación y prototipos de qgroup"), pero en aquel entonces nos perdimos un kfree en la cuota raíz y llamadas free_extent_buffer() en su raíz y en los nodos raíz de confirmación. , ya que en aquel entonces las raíces aún no se contaban como referencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: inicializar siempre cqe.result La especificación no exige que las dos primeras palabras dobles (también conocidas como resultados) para la entrada de la cola de comandos deban establecerse en 0 cuando no lo están usado (no especificado). Sin embargo, la implementación de destino devuelve 0 para TCP y FC, pero no para RDMA. Hagamos que RDMA se comporte igual y así inicialicemos explícitamente el campo de resultado. Esto evita la fuga de datos de la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: bloquear BH en ila_output() Como se explica en la confirmación 1378817486d6 ("tipc: bloquear BH antes de usar dst_cache"), los ayudantes net/core/dst_cache.c deben llamarse con BH desactivado. ila_output() se llama desde lwtunnel_output() posiblemente desde el contexto del proceso y bajo rcu_read_lock(). Podríamos ser interrumpidos por un softirq, volver a ingresar a ila_output() y dañar las estructuras de datos dst_cache. Arregle la carrera usando local_bh_disable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-fabrics: use etiqueta reservada para el comando de lectura/escritura de registro. En algunos escenarios, si el comando nvme emite demasiados comandos al mismo tiempo por las tareas del usuario, esto puede agotar todos etiquetas de admin_q. Si se produce un reinicio (reinicio de nvme o tiempo de espera de IO) antes de que finalicen estos comandos, es posible que la rutina de reconexión no actualice los registros de nvme debido a etiquetas insuficientes, lo que provocará que el kernel se cuelgue para siempre. Para solucionar este problema, tal vez podamos permitir que reg_read32()/reg_read64()/reg_write32() use etiquetas reservadas. Esto puede ser seguro para nvmf: 1. Para la ruta de activación ctrl/deshabilitar, no emitiremos el comando connect. 2. Para la ruta de activación ctrl/fw enable, ya que connect y reg_xx() se llaman en serie. Por lo tanto, las etiquetas reservadas pueden ser suficientes mientras reg_xx() usa etiquetas reservadas.