Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg_write_event_control(): corrige un error que puede ser activado por el usuario. Oops, *no* tenemos garantía de que todo lo que esté más allá del NUL de terminación se asigne (y mucho menos se inicialice con algo sensato).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: se corrige la asignación de páginas si vm_area_alloc_pages() con un retroceso de orden superior al orden 0 __vmap_pages_range_noflush() asume que su argumento pages** contiene páginas con el mismo cambio de página. Sin embargo, desde el commit e9c3cda4d86e ("mm, vmalloc: se corrigen las asignaciones de orden superior __GFP_NOFAIL"), si gfp_flags incluye __GFP_NOFAIL con orden superior en vm_area_alloc_pages() y la asignación de páginas falla para el orden superior, pages** puede contener dos cambios de página diferentes (orden superior y orden 0). Esto podría provocar que __vmap_pages_range_noflush() realice asignaciones incorrectas, lo que podría provocar una corrupción de memoria. Los usuarios pueden encontrarse con esto de la siguiente manera (vmap_allow_huge = true, 2M es para PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> la asignación del pedido 9 falló y se vuelve al pedido 0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> ocurre una asignación incorrecta Podemos eliminar el código de respaldo porque si falla una asignación de orden alto, __vmalloc_node_range_noprof() volverá a intentarlo con el pedido 0. Por lo tanto, no es necesario volver al pedido 0 aquí. Por lo tanto, solucione esto eliminando el código de respaldo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: se corrige la corrupción de mapas de bits en close_range() con CLOSE_RANGE_UNSHARE Se espera que copy_fd_bitmaps(new, old, count) copie los primeros bits count/BITS_PER_LONG de old->full_fds_bits[] y rellene el resto con ceros. Lo que hace es copiar suficientes palabras (BITS_TO_LONGS(count/BITS_PER_LONG)), luego memsets el resto. Eso funciona bien, *si* todos los bits más allá del punto de corte están limpios. De lo contrario, corremos el riesgo de basura de la última palabra que habíamos copiado. Para la mayoría de los llamadores, esto es cierto: expand_fdtable() tiene count igual a old->max_fds, por lo que no hay descriptores abiertos más allá de count, y mucho menos palabras completamente ocupadas en ->open_fds[], que es a lo que corresponden los bits en ->full_fds_bits[]. El otro llamador (dup_fd()) pasa sane_fdtable_size(old_fdt, max_fds), que es el múltiplo más pequeño de BITS_PER_LONG que cubre todos los descriptores abiertos por debajo de max_fds. En el caso común (copiar en fork()) max_fds es ~0U, por lo que todos los descriptores abiertos estarán por debajo de él y estamos bien, por las mismas razones por las que la llamada en expand_fdtable() es segura. Desafortunadamente, hay un caso en el que max_fds es menor que eso y en el que, de hecho, podríamos terminar con basura en ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) con * tabla de descriptores que se comparte actualmente * 'to' está por encima de la capacidad actual de la tabla de descriptores * 'from' está justo debajo de algún trozo de descriptores abiertos. En ese caso, terminamos con un comportamiento observablemente incorrecto, por ejemplo, generar un hijo con CLONE_FILES, obtener todos los descriptores en el rango 0..127 abiertos, luego close_range(64, ~0U, CLOSE_RANGE_UNSHARE) y ver que dup(0) termina con el descriptor #128, a pesar de que #64 no está abierta observablemente. La solución mínimamente invasiva sería lidiar con eso en dup_fd(). Si esto demuestra agregar una sobrecarga medible, podemos ir por ese camino, pero intentemos arreglar copy_fd_bitmaps() primero. * nuevo ayudante: bitmap_copy_and_expand(to, from, bits_to_copy, size). * hacer que copy_fd_bitmaps() tome el tamaño del mapa de bits en palabras, en lugar de bits; Su argumento 'count' es siempre un múltiplo de BITS_PER_LONG, por lo que no perdemos ninguna información y de esa manera podemos usar el mismo asistente para los tres mapas de bits: el compilador verá que count es un múltiplo de BITS_PER_LONG para los grandes, por lo que generará memcpy()+memset() simple. Se agregó el reproductor a tools/testing/selftests/core/close_range_test.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: se corrige la recuperación de errores que provoca la corrupción de datos en dispositivos ESE Los volúmenes con aprovisionamiento ligero o Eficiencia de espacio de extensión (ESE) deben formatearse a pedido durante el procesamiento de E/S habitual. La función dasd_ese_needs_format comprueba los códigos de error que indican la inexistencia de un formato de pista adecuado. La comprobación de longitud incorrecta es demasiado imprecisa, ya que otros casos de error que provocan el transporte de datos insuficientes también tienen esta bandera activada. Esto puede provocar la corrupción de datos en ciertos casos de error, por ejemplo, durante el arranque en caliente de un servidor de almacenamiento. Se soluciona eliminando la comprobación de longitud incorrecta y reemplazándola por una comprobación explícita de formato de pista no válido en el modo de transporte. También se elimina la comprobación de archivo protegido, ya que este no es un caso válido de manejo de ESE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmc_test: Se corrige la desreferencia NULL en caso de error de asignación. Si la asignación "test->highmem = alloc_pages()" falla, al llamar a __free_pages(test->highmem) se obtendrá una desreferencia NULL. Cambie también el código de error a -ENOMEM en lugar de devolver un resultado positivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: tegra: No marcar dispositivos ACPI como seguros para irq En máquinas ACPI, el módulo tegra i2c encuentra un problema debido a que se llama a un mutex dentro de un spinlock. Esto lleva al siguiente error: BUG: función dormida llamada desde un contexto no válido en kernel/locking/mutex.c:585 ... Rastreo de llamada: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer El problema surge porque durante __pm_runtime_resume(), se adquiere el spinlock &dev->power.lock antes de que se llame a rpm_resume(). Más tarde, rpm_resume() invoca acpi_subsys_runtime_resume(), que se basa en mutexes, lo que activa el error. Para solucionar este problema, los dispositivos en ACPI ahora están marcados como no seguros para IRQ, considerando la dependencia de acpi_subsys_runtime_resume() en los mutex.

Las versiones 24.4.1, 23.6.6 y anteriores de Audition se ven afectadas por una vulnerabilidad de lectura fuera de los límites que podría provocar la divulgación de memoria confidencial. Un atacante podría aprovechar esta vulnerabilidad para eludir mitigaciones como ASLR. La explotación de este problema requiere la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

COMFAST CF-XR11 V2.7.2 tiene una vulnerabilidad de inyección de comandos en la función sub_424CB4. Los atacantes pueden enviar mensajes de solicitud POST a /usr/bin/webmgnt e inyectar comandos en el parámetro iface.

Una vulnerabilidad de cross site scripting (XSS) almacenado en la sección Discusión de Perfex CRM v1.1.0 permite a los atacantes ejecutar scripts web o HTML arbitrarios a través de un payload manipulado e inyectado en el parámetro Contenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/firmware: uso de asignador no coherente dma Actualmente, habilitar SG_DEBUG en el kernel hará que nouveau alcance un BUG() al iniciarse, cuando iommu está habilitado: kernel BUG en include/linux/scatterlist.h:187! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) No contaminado 6.9.0-rc3Lyude-Test+ #30 Nombre del hardware: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 22/01/2019 RIP: 0010:sg_init_one+0x85/0xa0 Código: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 00000000000000000 RDI: ffffa77680d87000 RBP: 0000000000000e000 R08: 0000000000000000 R09: 00000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Seguimiento de llamadas: ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nuevo] nvkm_falcon_fw_ctor+0x42/0x70 [nuevo] ga102_gsp_booter_ctor+0xb4/0x1a0 [nuevo] r535_gsp_oneinit+0xb3/0x15f0 [nuevo] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nuevo] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0 Solucione esto utilizando el asignador no coherente. Creo que podría haber una mejor respuesta para esto, pero implica destruir algunas API que usan listas sg.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: mover la detención de keep-alive a nvme_uninit_ctrl() el commit 4733b65d82bd ("nvme: iniciar keep-alive después de la configuración de la cola de administración") mueve el inicio de keep-alive de nvme_start_ctrl() a nvme_init_ctrl_finish(), pero no mueve la detención de keep-alive a nvme_uninit_ctrl(), por lo que el trabajo de keep-alive se puede iniciar y mantener pendiente después de un error al iniciar el controlador, finalmente, se activa el use-after-free si se descarga el controlador del host nvme. Este parche corrige el pánico del kernel al ejecutar nvme/004 en caso de que se active una falla de conexión, moviendo la detención de keep-alive a nvme_uninit_ctrl(). Esta forma es razonable porque keep-alive ahora se inicia en nvme_init_ctrl_finish().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/boot: Evitar la posible corrupción del segmento physmem_info Cuando se asigna memoria física para la imagen del kernel, no se tiene en cuenta la memoria adicional necesaria para compensar el inicio de la imagen para que coincida con los 20 bits inferiores de la dirección base virtual de KASLR. Eso podría provocar un acceso al kernel más allá de su rango de memoria.