Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: soluciona el comportamiento incorrecto sin descriptor. ENA tiene dos tipos de colas TX: - colas que solo procesan paquetes TX que llegan desde la pila de red - colas que solo procesan paquetes TX reenviados a mediante instrucciones XDP_REDIRECT o XDP_TX. Ena_free_tx_bufs() recorre todos los descriptores en una cola de TX y desasigna + libera todos los descriptores que aún no han sido reconocidos por el dispositivo (transacciones de TX incompletas). La función supone que la cola TX procesada es necesariamente de la primera categoría enumerada anteriormente y termina usando napi_consume_skb() para los descriptores que pertenecen a una cola XDP específica. Este parche resuelve un error por el cual, en caso de restablecer VF, los descriptores no se liberan correctamente, lo que provoca fallos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Asunto: [PATCH] drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Si algunas páginas o la asignación de sgt fallaron, No deberíamos publicar la referencia de páginas que obtuvimos anteriormente, de lo contrario terminaremos con llamadas get/put_pages() desequilibradas. En su lugar, deberíamos dejar todo en su lugar y dejar que la función de liberación de BO se encargue de una limpieza adicional cuando se destruya el objeto, o dejar que el controlador de fallos lo intente nuevamente la próxima vez que se llame.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/ast: corrige el bloqueo suave. Hay un bucle while en ast_dp_set_on_off() que podría generar un bucle infinito. Esto se debe a que el registro, VGACRI-Dx, marcado en esta API es un registro temporal en realidad controlado por una MCU, denominada DPMCU, en BMC. Estos registros de scratch están protegidos por scu-lock. Si suc-lock no está desactivado, DPMCU no puede actualizar estos registros y luego el host tendrá un bloqueo suave debido a que el estado nunca se actualizó. DPMCU se utiliza para controlar DP y los registros relativos al protocolo de enlace con el controlador VGA del host. Incluso la tarea que consume más tiempo, el entrenamiento de enlaces de DP, dura menos de 100 ms. 200 ms deberían ser suficientes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: accel/ivpu: corrige el punto muerto en context_xa ivpu_device->context_xa está bloqueado tanto en el subproceso del kernel como en el contexto IRQ. Requiere que se pase el indicador XA_FLAGS_LOCK_IRQ durante la inicialización; de lo contrario, el bloqueo podría adquirirse de un subproceso e interrumpirse mediante una IRQ que lo bloquee por segunda vez, provocando el punto muerto. Este punto muerto fue informado por lockdep y observado en pruebas internas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: sg: Evite la ejecución de desmontaje del dispositivo sg sg_remove_sfp_usercontext() no debe usar sg_device_destroy() después de llamar a scsi_device_put(). sg_device_destroy() está accediendo al scsi_device principal request_queue que ya estará configurado en NULL cuando la llamada anterior a scsi_device_put() eliminó la última referencia al scsi_device principal. La excepción de puntero NULL resultante bloqueará el kernel.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kprobes: soluciona un posible problema de use after free en el registro de kprobe Al descargar un módulo, su estado cambia MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Cada cambio llevará un tiempo. `is_module_text_address()` y `__module_text_address()` funcionan con MODULE_STATE_LIVE y MODULE_STATE_GOING. Si usamos `is_module_text_address()` y `__module_text_address()` por separado, existe la posibilidad de que el primero tenga éxito pero el siguiente falle porque module->state se convierte en MODULE_STATE_UNFORMED entre esas operaciones. En `check_kprobe_address_safe()`, si el segundo `__module_text_address()` falla, se ignora porque esperaba una dirección kernel_text. Pero es posible que haya fallado simplemente porque módulo->estado se cambió a MODULE_STATE_UNFORMED. En este caso, arm_kprobe() intentará modificar la dirección de texto del módulo que no existe (use after free). Para solucionar este problema, no debemos usar `is_module_text_address()` y `__module_text_address()` separados, sino usar solo `__module_text_address()` una vez y hacer `try_module_get(module)` que solo está disponible con MODULE_STATE_LIVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: corrige WARN_ON en la ruta de sondeo de iommu. La confirmación 1a75cc710b95 ("iommu/vt-d: usa rbtree para rastrear los dispositivos sondeados por iommu") agrega todos los dispositivos sondeados por iommu. controlador en un rbtree indexado por el ID de origen de cada dispositivo. Se supone que cada dispositivo tiene una identificación de fuente única. Esta suposición es incorrecta y la especificación VT-d tampoco establece este requisito. La razón para usar un rbtree para rastrear dispositivos es buscar el dispositivo con bus PCI y devfunc en las rutas de manejo del error de tiempo de espera de invalidación de ATS y las fallas de la página PRI I/O. Ambos están relacionados con la función PCI ATS. Realice un seguimiento únicamente de los dispositivos que tengan capacidades PCI ATS en el rbtree para evitar WARN_ON innecesario en la ruta de la sonda iommu. De lo contrario, en algunas plataformas inferiores al kernel se mostrará el símbolo y la sonda iommu dará como resultado un error. ADVERTENCIA: CPU: 3 PID: 166 en drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90 Seguimiento de llamadas: ? __warn+0x7e/0x180 ? intel_iommu_probe_device+0x319/0xd90? report_bug+0x1f8/0x200? handle_bug+0x3c/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? intel_iommu_probe_device+0x319/0xd90? debug_mutex_init+0x37/0x50 __iommu_probe_device+0xf2/0x4f0 iommu_probe_device+0x22/0x70 iommu_bus_notifier+0x1e/0x40 notifier_call_chain+0x46/0x150 blocking_notifier_call_chain+0x42/0x60 bus_notify+0 x2f/0x50 device_add+0x5ed/0x7e0 platform_device_add+0xf5/0x240 mfd_add_devices+0x3f9/0x500 ? preempt_count_add+0x4c/0xa0? up_write+0xa2/0x1b0? __debugfs_create_file+0xe3/0x150 intel_lpss_probe+0x49f/0x5b0? pci_conf1_write+0xa3/0xf0 intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci] pci_device_probe+0x95/0x120 really_probe+0xd9/0x370? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x73/0x150 driver_probe_device+0x19/0xa0 __driver_attach+0xb6/0x180 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x77/0xd0 bus_add_driver+0x114/0x210 driver_register+0x5b/0x110 ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci] do_one_initcall+0x57/0x2b0? kmalloc_trace+0x21e/0x280? do_init_module+0x1e/0x210 do_init_module+0x5f/0x210 load_module+0x1d37/0x1fc0 ? init_module_from_file+0x86/0xd0 init_module_from_file+0x86/0xd0 idempotent_init_module+0x17c/0x230 __x64_sys_finit_module+0x56/0xb0 do_syscall_64+0x6e/0x140 Entry_SYSCALL_64_after_hwframe+0x71 /0x79

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: qgroup: corrige la fuga de rsv prealloc de qgroup en operaciones de subvolumen Crear subvolumen, crear instantánea y eliminar subvolumen, todos usan btrfs_subvolume_reserve_metadata() para reservar metadatos para los cambios realizados en el árbol fs del subvolumen principal , que no se puede mediar de la forma normal a través de start_transaction. Cuando los grupos de cuotas (squota o qgroups) están habilitados, esto reserva metadatos de qgroup de tipo PREALLOC. Una vez asociada la operación a una transacción, convertimos PREALLOC a PERTRANS, que se compensa de forma masiva al final de la transacción. Sin embargo, las rutas de error de estas tres operaciones no implementaban este ciclo de vida correctamente. Convirtieron incondicionalmente PREALLOC a PERTRANS en un paso de limpieza genérico, independientemente de los errores o de si la operación estaba completamente asociada a una transacción o no. Esto resultó en rutas de error que ocasionalmente convertían este rsv a PERTRANS sin llamar exitosamente a record_root_in_trans, lo que significaba que, a menos que algún otro hilo registrara esa raíz en la transacción, el final de la transacción no liberaría el PERTRANS de esa raíz, filtrándolo. En última instancia, esto resultó en un aviso de ADVERTENCIA en las compilaciones CONFIG_BTRFS_DEBUG al desmontar la reserva filtrada. La solución es garantizar que cada reserva PREALLOC de qgroup observe las siguientes propiedades: 1. cualquier falla antes de que se llame exitosamente a record_root_in_trans resulta en la liberación de la reserva PREALLOC. 2. después de record_root_in_trans, convertimos a PERTRANS, y ahora la transacción es dueña de la reserva. Este parche aplica esas propiedades en las tres operaciones. Sin él, generic/269 con cuotas habilitadas en el momento mkfs fallaría en ~5-10 ejecuciones en mi sistema. Con este parche, se ejecutó exitosamente 1000 veces seguidas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: asegúrese de que WRITTEN esté configurado en todos los bloques de metadatos. Anteriormente llamaríamos a btrfs_check_leaf() si teníamos el código de verificación de integridad habilitado, lo que significaba que solo podíamos ejecutar la hoja extendida. comprueba si teníamos ESCRITO configurado en las banderas del encabezado. Esto deja un vacío en nuestra verificación, porque podríamos terminar con corrupción en el disco donde ESCRITO no está configurado en la hoja, y luego no se ejecutan las verificaciones extendidas de la hoja, en las que confiamos para validar todos los punteros de elementos a asegúrese de no acceder a la memoria fuera del búfer de extensión. Sin embargo, desde 732fab95abe2 ("btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option") ya no llamamos a btrfs_check_leaf() desde btrfs_mark_buffer_dirty(), lo que significa que solo lo llamamos en bloques que se están escribiendo y, por lo tanto, tienen configurado WRITTEN. o que se están leyendo, que deberían tener configurado ESCRITO. Agregue comprobaciones para asegurarse de que hemos escrito ESCRITO correctamente y luego asegúrese de que __btrfs_check_leaf() siempre realice la verificación del elemento. Esto nos protegerá de sistemas de archivos que se han corrompido y ya no tienen ESCRITO configurado en algunos de los bloques. Esto se produjo en una imagen diseñada que modificaba el bit ESCRITO y KASAN lo informó como acceso fuera de los límites en los descriptores de acceso eb. El ejemplo es un elemento de directorio al final de un eb. [2.042] Advertencia BTRFS (bucle de dispositivo 1): inicio de miembro eb incorrecto: ptr 0x3fff inicio 30572544 desplazamiento de miembro 16410 tamaño 2 [2.040] falla de protección general, probablemente para dirección no canónica 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537 ] KASAN: tal vez acceso a memoria salvaje en el rango [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) ), BIOS 1.15.0-1 01/04/2014 [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621 ] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e 8 [2.621] FS : 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] : 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Seguimiento de llamadas: [2.621] [2.621] ? show_regs+0x74/0x80 [2.621] ? die_addr+0x46/0xc0 [2.621] ? exc_general_protection+0x161/0x2a0 [2.621] ? asm_exc_general_protection+0x26/0x30 [2.621]? btrfs_get_16+0x33a/0x6d0 [2.621] ? btrfs_get_16+0x34b/0x6d0 [2.621] ? btrfs_get_16+0x33a/0x6d0 [2.621] ? __pfx_btrfs_get_16+0x10/0x10 [2.621] ? __pfx_mutex_unlock+0x10/0x10 [2.621] btrfs_match_dir_item_name+0x101/0x1a0 [2.621] btrfs_lookup_dir_item+0x1f3/0x280 [2.621] ? __pfx_btrfs_lookup_dir_item+0x10/0x10 [2.621] btrfs_get_tree+0xd25/0x1910 [copiar más detalles del informe]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: Protege completamente los modos[] con dev->mode_config.mutex. La matriz modes[] contiene punteros a los modos en las listas de modos de los conectores, que están protegidos por dev- >mode_config.mutex. Por lo tanto, necesitamos extender modes[] la misma protección o, cuando la usemos, es posible que los elementos ya estén apuntando a la memoria liberada/reutilizada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcachefs: comprueba si hay entradas de diario que sobrepasen el final de la sección de limpieza de sb. Corrige una comprobación de límites faltantes en la validación de superbloque. Tenga en cuenta que todavía no tenemos un código de reparación para este caso; el código de reparación para elementos individuales generalmente tiene una prioridad baja, ya que todo el superbloque se suma, se valida antes de escribir y tenemos copias de seguridad.

Una vulnerabilidad ha sido encontrada en PHPGurukul Directory Management System 1.0 y clasificada como problemática. Una función desconocida del archivo /admin/search-directory.php es afectada por esta operación. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-265212.