Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-pci: Se corrige el tamaño del resultado devuelto para la finalización del comando admin El tamaño del resultado devuelto por virtio_pci_admin_dev_parts_get() es 8 bytes más grande que el tamaño real de los datos del resultado. Esto ocurre porque el campo result_sg_size del comando se llena con la longitud del resultado de virtqueue_get_buf(), que incluye tanto el tamaño de los datos como 8 bytes adicionales de estado. Este tamaño de resultado sobredimensionado causa dos problemas: 1. El estado transferido al destino incluye 8 bytes de datos adicionales al final. 2. El búfer asignado en el kernel puede ser más pequeño que el tamaño devuelto, lo que provoca fallas al leer más allá del tamaño asignado. La confirmación corrige esto restando el tamaño del estado del resultado de virtqueue_get_buf(). Esta corrección se ha probado a través de migraciones en vivo con dispositivos virtio-net, virtio-net-transitional y virtio-blk.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: eliminar el bloqueo crítico. Eliminar el bloqueo crítico. Esto nos libera de la lógica propensa a errores de try_locks. Gracias a netdev_lock() de Jakub, ahora es fácil, y en la mayoría de los casos ya estábamos protegidos por él: reemplazar el bloqueo crítico por el bloqueo netdev cuando no era el caso. Lockdep informa que debemos cancelar el trabajo bajo crit_lock [splat1], y ese fue el esquema que hemos seguido principalmente desde [1] de Slawomir. Pero una vez hecho esto, seguimos teniendo interbloqueos [splat2]. Así que, en lugar de eso, deberíamos analizar el problema más grave, es decir, el "bloqueo/programación extraño" de iavf. El primer paso para solucionarlo es eliminar el bloqueo crítico. Seguiré con una serie de -next que simplifica la programación/tareas. Cancelar el trabajo sin el bloqueo de netdev (un esquema extraño de desbloqueo y bloqueo) para corregir el [splat2] (que sería un desastre si hubiéramos mantenido el bloqueo crítico). Extender la parte protegida de iavf_watchdog_task() para incluir la programación de más trabajo. Tenga en cuenta que el comentario eliminado en iavf_reset_task() estaba mal ubicado; pertenecía a la condición if eliminada, por lo que ya no está. [splat1] - sin este parche - El bloqueo durante la eliminación de VF: ADVERTENCIA: se detectó una posible dependencia de bloqueo circular sh/3825 está intentando adquirir el bloqueo: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, en: start_flush_work+0x1a1/0x470 pero la tarea ya tiene el bloqueo: (&adapter->crit_lock){+.+.}-{4:4}, en: iavf_remove+0xd1/0x690 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [splat2] - al cancelar trabajo bajo bloqueo crítico, sin esta serie, vea [2] para el intento de curita ADVERTENCIA: posible dependencia de bloqueo circular detectada sh/3550 está intentando adquirir el bloqueo: ((wq_completion)iavf){+.+.}-{0:0}, en: touch_wq_lockdep_map+0x26/0x90 pero la tarea ya tiene el bloqueo: (&dev->lock){+.+.}-{4:4}, en: iavf_remove+0xa6/0x6e0 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [1] fc2e6b3b132a ("iavf: Rehacer mutexes para mejor sincronización") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se corrige la deferencia de puntero NULL en eir_get_service_data El parámetro len se considera opcional, por lo que puede ser NULL y, por lo tanto, no se puede usar para saltar a la siguiente entrada de EIR_SERVICE_DATA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: eliminar la lógica de comprobación de ptp->n_vclocks en ptp_vclock_in_use(). No hay desacuerdo en que debemos comprobar tanto ptp->is_virtual_clock como ptp->n_vclocks para comprobar si el reloj virtual ptp está en uso. Sin embargo, al adquirir ptp->n_vclocks_mux para leer ptp->n_vclocks en ptp_vclock_in_use(), observamos un bloqueo recursivo en el seguimiento de llamadas a partir de n_vclocks_store(). ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 6.15.0-rc6 #1 No contaminado -------------------------------------------- syz.0.1540/13807 está intentando adquirir el bloqueo: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [en línea] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 pero la tarea ya tiene el bloqueo: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** BLOQUEO INTERMEDIO *** .... ============================================== La mejor manera de resolver esto es eliminar la lógica que comprueba ptp->n_vclocks en ptp_vclock_in_use(). Esto es apropiado porque cualquier ruta que use ptp->n_vclocks debe comprobar incondicionalmente si ptp->n_vclocks es mayor que 0 antes de anular el registro de vclocks, y todas las funciones ya están escritas de esta manera. En la función que usa ptp->n_vclocks, ya obtenemos ptp->n_vclocks_mux antes de anular el registro de vclocks. Por lo tanto, necesitamos eliminar la comprobación redundante de ptp->n_vclocks en ptp_vclock_in_use() para evitar el bloqueo recursivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: Se corrige la validación de direcciones de siguiente salto. El kernel actualmente valida que la longitud de la dirección de siguiente salto proporcionada no supere la longitud especificada. Esto puede provocar que el kernel lea memoria no inicializada si el espacio de usuario proporcionó una longitud menor que la especificada. Se corrige validando que la longitud proporcionada coincida exactamente con la especificada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/fhandle.c: se corrige una ejecución en la llamada a has_locked_children(). may_decode_fh() llama a has_locked_children() sin bloqueos. Esta es una ejecución que puede fallar. El resto de los invocadores están seguros, ya que mantienen namespace_sem y se les garantiza un recuento de referencias positivo en el montaje en cuestión. Cambie el nombre de has_locked_children() actual a __has_locked_children(), conviértalo en estático y cambie los usuarios de fs/namespace.c a él. Convierta has_locked_children() en un contenedor para __has_locked_children(), invocándolo bajo read_seqlock_excl(&mount_lock).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vm: mover xe_svm_init() antes. En xe_vm_close_and_put(), debemos poder llamar a xe_svm_fini(); sin embargo, durante la creación de la máquina virtual, podemos llamarlo en la ruta de error, antes de haber inicializado realmente el estado de svm, lo que provoca varios splats seguidos de un NPD fatal. (seleccionado del commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Se corrige la posible desreferencia de PTR nula al inicializar hardware. El resultado de la búsqueda de avs_dai_find_path_template() debe verificarse antes de usarse. Dado que "template" ya se conoce al ejecutar avs_hw_constraints_init(), se omite la búsqueda por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Verificar el contenido devuelto por parse_int_array(). El primer elemento de la matriz devuelta almacena su longitud. Si es 0, cualquier manipulación más allá del elemento en el índice 0 termina con null-ptr-deref.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: eir: Se solucionan posibles fallos en eir_create_adv_data eir_create_adv_data puede intentar agregar EIR_FLAGS y EIR_TX_POWER sin verificar si encajan.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/skx_common: Corregir fallo de protección general Después de cargar i10nm_edac (que carga automáticamente skx_edac_common), si solo se descarga i10nm_edac, luego se vuelve a cargar y se realizan pruebas de inyección de errores, puede ocurrir un fallo de protección general: mce: [Error de hardware]: Se registraron eventos de comprobación de la máquina Oops: fallo de protección general ... ... Cola de trabajo: eventos mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Rastreo de llamadas: ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... El problema surgió porque la variable 'adxl_component_count' (dentro de skx_edac_common), que cuenta los componentes ADXL, no se restableció. Durante la recarga de i10nm_edac, el recuento se incrementó de nuevo según el número real de componentes ADXL, lo que resultó en un recuento que duplicó el número real de componentes ADXL. Esto provocó una referencia fuera de los límites a la matriz de componentes ADXL, lo que provocó el fallo de protección general mencionado anteriormente. Solucione este problema restableciendo 'adxl_component_count' en adxl_put(), que se llama durante la descarga de {skx,i10nm}_edac.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: sun8i-ce-cipher - corrección del manejo de errores en sun8i_ce_cipher_prepare(). Se corrigen dos problemas de limpieza de DMA en la ruta de error en sun8i_ce_cipher_prepare(): 1] Si dma_map_sg() falla para areq->dst, el controlador del dispositivo intentaría liberar memoria DMA que no había asignado inicialmente. Para corregir esto, en la ruta de error "theend_sgs", ejecute dma unmap solo si la asignación de DMA correspondiente se realizó correctamente. 2] Si falla la llamada a dma_map_single() para el IV, el controlador del dispositivo intentará liberar una dirección de memoria DMA no válida en la ruta "theend_iv": ------------[ cortar aquí ]------------ DMA-API: sun8i-ce 1904000.crypto: el controlador del dispositivo intenta liberar una dirección de memoria DMA no válida ADVERTENCIA: CPU: 2 PID: 69 en kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Módulos vinculados: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: GO 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Nombre del hardware: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Rastreo de llamada: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ fin del rastreo 000000000000000 ]--- Para solucionar esto, verifique !dma_mapping_error() antes de llamar dma_unmap_single() en la ruta "theend_iv".