Vulnerabilidades

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: 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: 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.

Twisted es un framework basado en eventos para aplicaciones de Internet, compatible con Python 3.6+. El servidor HTTP 1.0 y 1.1 proporcionado por twisted.web podría procesar solicitudes HTTP canalizadas desordenadas, lo que posiblemente resulte en la divulgación de información. Esta vulnerabilidad se soluciona en 24.7.0rc1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: evitar payload de double free especial Si es necesario volver a intentar una solicitud de descarte y ese reintento puede fallar antes de agregar un nuevo payload especial, se producirá un double free. Borre RQF_SPECIAL_LOAD cuando se limpie la solicitud.

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 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 resolvió la siguiente vulnerabilidad: drm/amd/display: Corrección de índice de matriz fuera de los límites en dml2/FCLKChangeSupport [Por qué] Posible acceso fuera de los límites en dml2_calculate_rq_and_dlg_params() porque se usó el valor de out_lowest_state_idx como índice para la matriz FCLKChangeSupport puede ser mayor que 1. [Cómo] Actualmente, el núcleo dml2 especifica valores idénticos para todos los elementos FCLKChangeSupport. Utilice siempre el índice 0 en la condición para evitar el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_core: cancelar todos los trabajos en hci_unregister_dev() syzbot informa que llamar a hci_release_dev() desde hci_error_reset() debido a hci_dev_put() desde hci_error_reset() puede causar un punto muerto en destroy_workqueue( ), porque hci_error_reset() se llama desde hdev->req_workqueue y destroy_workqueue() necesita vaciarse. Necesitamos asegurarnos de que hdev->{rx_work,cmd_work,tx_work} que están en cola en hdev->workqueue y hdev->{power_on,error_reset} que están en cola en hdev->req_workqueue ya no se estén ejecutando en el momento destroy_workqueue( hdev->cola de trabajo); destroy_workqueue(hdev->req_workqueue); se llaman desde hci_release_dev(). Llame a cancel_work_sync() en estos elementos de trabajo desde hci_unregister_dev() tan pronto como se elimine hdev->list de hci_dev_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: incluir en la lista blanca el objeto dtl slub para copiarlo en el espacio de usuario. La lectura del registro de seguimiento de envío desde /sys/kernel/debug/powerpc/dtl/cpu-* da como resultado un ERROR() cuando la configuración CONFIG_HARDENED_USERCOPY está habilitada como se muestra a continuación. ¡ERROR del kernel en mm/usercopy.c:102! Vaya: Excepción en modo kernel, sign: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Módulos vinculados en: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror _region_hash dm_log dm_mod fusible CPU: 27 PID: 1815 Comm: python3 No contaminado 6.10.0-rc3 #85 Nombre de hardware: IBM,9040-MRX POWER10 (sin procesar) 0x800200 0xf000006 de:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR : 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 No contaminado (6.10.0-rc3) MSR: 8000000000029033 CR: 2828220f XER: 0000000e CFAR: 00000001fdc80 MÁSCARA IRQ: 0 [ .. GPR omitidos... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Seguimiento de llamadas: usercopy_abort+0x74/0xb0 (no confiable) __check_heap_object+0xf8/0x 120 check_heap_object+0x218/0x240 __check_object_size+0x84/ 0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupción: 3000 0x7fff81f3ab34 Confirmación 6d07d1cd300f ("copia de usuario: restringir cachés que no sean de copia de usuario) a tamaño 0") requiere que solo las áreas incluidas en la lista blanca en objetos de losa/slub se puedan copiar al espacio de usuario cuando el refuerzo de copia de usuario está habilitado usando CONFIG_HARDENED_USERCOPY. Dtl contiene eventos de envío del hipervisor que se espera que sean leídos por usuarios privilegiados. Por lo tanto, marque esto como seguro para el acceso de los usuarios. Especifique useroffset=0 y usersize=DISPATCH_LOG_BYTES para incluir todo el objeto en la lista blanca.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: Scrub: maneja correctamente el error de búsqueda RST [ERROR] Al ejecutar btrfs/060 con la función RST forzada, bloquearía el siguiente ASSERT() dentro de Scrub_read_endio(): ASSERT(sector_nr < raya->nr_sectors); Antes de eso, tendríamos un volcado de árbol de btrfs_get_raid_extent_offset(), ya que no pudimos encontrar la entrada RST para el rango. [CAUSA] Dentro de Scrub_submit_extent_sector_read() cada vez que asignamos un nuevo bbio llamamos inmediatamente a btrfs_map_block() para asegurarnos de que hubiera algún rango RST que cubriera el objetivo de limpieza. Pero si btrfs_map_block()fallo, inmediatamente llamamos a endio para el bbio, mientras el bbio está recién asignado, está completamente vacío. Luego, dentro de Scrub_read_endio(), revisamos los bvecs para encontrar el número del sector (ya que bi_sector ya no es confiable si la biografía se envía a capas inferiores). Y dado que la biografía está vacía, dicha iteración de bvecs no encontraría ningún sector que coincida con el sector y devolvería sector_nr == stripe->nr_sectors, lo que activaría ASSERT(). [FIX] En lugar de llamar a btrfs_map_block() después de asignar un nuevo bbio, llame primero a btrfs_map_block(). Dado que nuestro único objetivo al llamar a btrfs_map_block() es solo actualizar stripe_len, realmente no hay necesidad de hacerlo después de btrfs_alloc_bio(). Este nuevo tiempo evitaría por completo el problema de manejar bbio vacío y, de hecho, soluciona una posible ventana de ejecuciónpara el código anterior, donde si el hilo de envío es el único propietario de pendiente_io, la limpieza nunca terminaría (ya que no lo hicimos). disminuir el contador pendiente_io). Aunque aún es necesario abordar la causa raíz del error de búsqueda de RST.