Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpftool: corrige comportamiento indefinido en qsort(NULL, 0, ...) Cuando netfilter no tiene ninguna entrada para mostrar, se llama a qsort con qsort(NULL, 0, ...). Esto da como resultado un comportamiento indefinido, como informa UBSan: net.c:827:2: error en tiempo de ejecución: puntero nulo pasado como argumento 1, que se declara que nunca será nulo Aunque el estándar C no indica explícitamente si llamar a qsort con un puntero NULL cuando el tamaño es 0 constituye un comportamiento indefinido, la Sección 7.1.4 del estándar C (Uso de funciones de librería) menciona: "Cada una de las siguientes afirmaciones se aplica a menos que se indique explícitamente lo contrario en las descripciones detalladas que siguen: si un argumento de una función tiene un valor no válido (como un valor fuera del dominio de la función, o un puntero fuera del espacio de direcciones del programa, o un puntero nulo, o un puntero a almacenamiento no modificable cuando el parámetro correspondiente no está calificado como constante) o un tipo (después de la promoción) no esperado por una función con un número variable de argumentos, el comportamiento es indefinido". Para evitar esto, agregue un retorno temprano cuando nf_link_info sea NULL para evitar llamar a qsort con un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: agregar refcnt a la estructura ksmbd_conn Al enviar una solicitud de interrupción de oplock, se utiliza opinfo->conn, pero freed ->conn se puede utilizar en multicanal. Este parche agrega un recuento de referencia a la estructura ksmbd_conn para que se pueda liberar cuando ya no se utiliza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/hdcp: Verificar la validez de la estructura GSC En ocasiones, xe_gsc no se inicializa cuando se verifica en la verificación de capacidad HDCP. Agregar verificación de estructura gsc para evitar errores de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige el bloqueo potencial si se llama a qi_submit_sync con un recuento de 0 Si se invoca qi_submit_sync() con 0 descriptores de invalidación (por ejemplo, para fines de vaciado de DMA), podemos encontrarnos con un error en el que un hilo de envío no detecta la finalización de invalidation_wait. Posteriormente, esto condujo a un bloqueo suave. Actualmente, este error no tiene impacto en los usuarios existentes porque ningún llamante está enviando invalidaciones con 0 descriptores. Esta corrección permitirá a los futuros usuarios (como DMA drain) llamar a qi_submit_sync() con un recuento de 0. Supongamos que el hilo T1 invoca qi_submit_sync() con descriptores distintos de cero, mientras que, al mismo tiempo, el hilo T2 llama a qi_submit_sync() con cero descriptores. Ambos hilos entran entonces en un bucle while, esperando a que se completen sus respectivos descriptores. T1 detecta su finalización (es decir, el estado invalidation_wait de T1 cambia a QI_DONE por HW) y procede a llamar a reclaim_free_desc() para recuperar todos los descriptores, incluyendo potencialmente los adyacentes de otros subprocesos que también están marcados como QI_DONE. Durante este tiempo, mientras T2 espera adquirir el qi->q_lock, el hardware IOMMU puede completar la invalidación para T2, estableciendo su estado en QI_DONE. Sin embargo, si la ejecución de reclaim_free_desc() por parte de T1 libera el descriptor invalidation_wait de T2 y cambia su estado a QI_FREE, T2 no observará el estado QI_DONE para su invalidation_wait y permanecerá bloqueado indefinidamente. Este bloqueo suave no ocurre cuando solo se envían descriptores distintos de cero. En tales casos, los descriptores de invalidación se intercalan entre los descriptores de espera con el estado QI_IN_USE, actuando como barreras. Estas barreras evitan que el código de recuperación libere por error descriptores que pertenecen a otros remitentes. Considere la siguiente línea de tiempo de ejemplo: T1 T2 ========================================= ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 nunca ve QI_DONE en WD2 Donde: ID = descriptor de invalidación WD = descriptor de espera * Escrito por hardware La raíz del problema es que el indicador de estado del descriptor QI_DONE se usa para dos propósitos conflictivos: 1. señalar que un descriptor está listo para ser recuperado (para ser liberado) 2. señalar por el hardware que un descriptor de espera está completo La solución (en este parche) es la separación de estados mediante el uso del indicador QI_FREE para #1. Una vez que los descriptores de invalidación de un hilo están completos, su estado se establecería en QI_FREE. La función reclaim_free_desc() solo liberaría los descriptores marcados como QI_FREE en lugar de los marcados como QI_DONE. Este cambio asegura que T2 (del ejemplo anterior) observará correctamente la finalización de su invalidation_wait (marcada como QI_DONE).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: protección contra el desbordamiento de búfer de cadena Smatch informa que copiar media_name e if_name a name_parts puede sobrescribir el destino. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' demasiado grande para 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' demasiado grande para 'name_parts->if_name' (1010102 vs 16) Este parece ser el caso, así que protéjase contra esta posibilidad usando strscpy() y fallando si ocurre un truncamiento. Introducido por el commit b97bf3fd8f6a ("[TIPC] Fusión inicial") Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Arreglar la configuración del indicador de respuesta del servidor En afs_wait_for_operation(), configuramos la transcripción del indicador de respuesta de llamada en el registro del servidor que usamos después de realizar el bucle de iteración del servidor de archivos, pero es posible salir del bucle después de haber recibido una respuesta del servidor que descartamos (por ejemplo, devolvió un aborto o comenzamos a recibir datos, pero la llamada no se completó). Esto significa que op->server podría ser NULL, pero no lo verificamos antes de intentar configurar el indicador del servidor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir desbordamiento de entero en BLKSECDISCARD Descubrí de forma independiente el commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 bloque: corregir desbordamiento en blk_ioctl_discard() pero para borrado seguro. Mismo problema: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); entrará en un bucle casi infinito dentro de blkdev_issue_secure_erase(): a.out: intento de acceso más allá del final del dispositivo loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 devoluciones de llamadas suprimidas

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige el desbordamiento de búfer al analizar los puntos de análisis de NFS ReparseDataLength es la suma del tamaño de InodeType y el tamaño de DataBuffer. Por lo tanto, para obtener el tamaño de DataBuffer, es necesario restar el tamaño de InodeType de ReparseDataLength. La función cifs_strndup_from_utf16() está accediendo actualmente a buf->DataBuffer en la posición después del final del búfer porque no resta el tamaño de InodeType de la longitud. Solucione este problema y reste correctamente la variable len. El miembro InodeType solo está presente cuando el búfer de análisis es lo suficientemente grande. Verifique ReparseDataLength antes de acceder a InodeType para evitar otro acceso no válido a la memoria. Los valores rdev principales y secundarios también están presentes solo cuando el búfer de análisis es lo suficientemente grande. Verifique el tamaño del búfer de análisis antes de llamar a reparse_mkdev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se soluciona el problema de doble liberación durante la descarga del módulo amdgpu Los endpoints flexibles usan DIG de endpoints inflexibles disponibles, por lo que solo es necesario liberar los codificadores de enlaces inflexibles. De lo contrario, puede ocurrir un problema de doble liberación al descargar el módulo amdgpu. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Seguimiento de llamadas: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [279.190601]? do_error_trap+0x73/0xa0 [279.190605]? __slab_free+0x152/0x2f0 [279.190609]? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [279.191102]? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] /0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] ister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939 ] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: x86-android-tablets: Se corrige el use after free en errores platform_device_register() x86_android_tablet_remove() libera la matriz pdevs[], por lo que no se debe utilizar después de llamar a x86_android_tablet_remove(). cuando falla platform_device_register(), almacena el valor PTR_ERR() de pdevs[x] en la variable ret local antes de llamar a x86_android_tablet_remove() para evitar usar pdevs[] después de que se haya liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: amdkfd_free_gtt_mem borra el puntero correcto. Pase la referencia del puntero a amdgpu_bo_unref para borrar el puntero correcto; de lo contrario, amdgpu_bo_unref borra la variable local, el puntero original no está establecido en NULL, esto podría causar un error de use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/stm: Evite problemas de use after free con crtc y plane ltdc_load() llama a las funciones drm_crtc_init_with_planes(), drm_universal_plane_init() y drm_encoder_init(). Estas funciones no deben llamarse con parámetros asignados con devm_kzalloc() para evitar problemas de use after free [1]. Use asignaciones administradas por el framework DRM. Encontrado por Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/