Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: reiserfs: evite tocar el directorio renombrado si el padre no cambia. El VFS no bloqueará el directorio movido si su padre no cambia. Cambie el código de cambio de nombre de reiserfs para evitar tocar el directorio renombrado si su padre no cambia, sin bloquearlo, lo que puede dañar el sistema de archivos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: libbpf: corrige la desreferencia del puntero NULL en bpf_object__collect_prog_relos Se produjo un problema al leer un archivo ELF en libbpf.c durante la fuzzing: el programa recibió la señal SIGSEGV, falla de segmentación. 0x0000000000958e97 en bpf_object.collect_prog_relos () en libbpf.c:4206 4206 en libbpf.c (gdb) bt #0 0x0000000000958e97 en bpf_object.collect_prog_relos () en libbpf.c:4206 #1 0x0 00000000094f9d6 en bpf_object.collect_relos () en libbpf.c :6706 #2 0x000000000092bef3 en bpf_object_open () en libbpf.c:7437 #3 0x000000000092c046 en bpf_object.open_mem () en libbpf.c:7497 #4 0x0000000000924afa en LLVMFuzzerTest OneInput () en fuzz/bpf-object-fuzzer.c:16 # 5 0x000000000060be11 en testblitz_engine::fuzzer::Fuzzer::run_one () #6 0x000000000087ad92 en tracing::span::Span::in_scope () #7 0x00000000006078aa en testblitz_engine::fuzzer::util::walkdir () #8 0x00000000005f3217 en testblitz_engine::entrypoint::main::{{closure}} () #9 0x00000000005f2601 en main () (gdb) scn_data era nulo en este código (tools/lib/bpf/src/libbpf.c): if (rel ->r_offset % BPF_INSN_SZ || rel->r_offset >= scn_data->d_size) { Los scn_data se derivan del código anterior: scn = elf_sec_by_idx(obj, sec_idx); scn_data = elf_sec_data(obj, scn); relo_sec_name = elf_sec_str(obj, shdr->sh_name); nombre_sec = nombre_sec_elf(obj, scn); if (!relo_sec_name || !sec_name)// no verifica si scn_data es NULL return -EINVAL; En ciertos escenarios especiales, como la lectura de un archivo ELF con formato incorrecto, es posible que scn_data sea un puntero nulo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wfx: corrige la posible desreferencia del puntero NULL en wfx_set_mfp_ap() Dado que 'ieee80211_beacon_get()' puede devolver NULL, 'wfx_set_mfp_ap()' debe verificar el valor de retorno antes de examinar los datos de skb. Así que convierta este último para que devuelva un código de error apropiado y propáguelo para que regrese también desde 'wfx_start_ap()'. Compilación probada únicamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spmi: mediatek: reparar UAF en la eliminación del dispositivo. Los datos del controlador pmif que contienen los relojes se asignan junto con spmi_controller. Al eliminar el dispositivo, primero se liberará spmi_controller y luego se limpiarán los devres, incluidos los relojes. Esto lleva a UAF porque al poner los relojes se accederá a los relojes en los datos del controlador pmif, que ya están liberados junto con spmi_controller. Esto se puede reproducir habilitando DEBUG_TEST_DRIVER_REMOVE y compilando el kernel con KASAN. Solucione el problema de UAF utilizando clk_bulk_get() no administrado y poniendo los relojes antes de liberar spmi_controller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige una posible desreferencia NULL en amdgpu_ras_query_error_status_helper() Devuelve un código de error no válido -EINVAL para una identificación de bloque no válida. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 error amdgpu_ras_query_error_status_helper(): anteriormente asumimos que la 'información' podría ser nula (consulte la línea 1176)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: agregue un bloqueo mutex en el control vblank irq. Agregue un bloqueo mutex para controlar vblank irq para sincronizar las operaciones de activación/desactivación de vblank que ocurren desde diferentes subprocesos para evitar condiciones de ejecución durante el registro. /anular el registro de la devolución de llamada vblank irq. v4: -Se eliminó vblank_ctl_lock de dpu_encoder_virt, por lo que es solo un parámetro de dpu_encoder_phys. -Cambiar de refcnt atómico a un contador int simple ya que ahora se ha agregado mutex v3: por error no cambió la redacción en la última versión. Ya está hecho. v2: redacción ligeramente modificada del mensaje de confirmación Patchwork: https://patchwork.freedesktop.org/patch/571854/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/ipoib: corrige el bloqueo de la lista mcast Al liberar `priv->lock` mientras se itera `priv->multicast_list` en `ipoib_mcast_join_task()`, se abre una ventana para `ipoib_mcast_dev_flush( )` para eliminar los elementos mientras se encuentra en medio de la iteración. Si se elimina mcast mientras se elimina el bloqueo, el bucle for gira para siempre, lo que resulta en un bloqueo total (como se informó en el kernel RHEL 4.18.0-372.75.1.el8_6): Tarea A (kworker/u72:2 a continuación) | Tarea B (kworker/u72:0 a continuación) -----------------------------------+---- ------------------------------- ipoib_mcast_join_task(trabajo) | ipoib_ib_dev_flush_light(trabajo) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, lista) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->bloquear) | | spin_lock_irqsave(&priv->bloqueo, banderas) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, lista) | list_del(&mcast->lista); | list_add_tail(&mcast->lista, &remove_list) | spin_unlock_irqrestore(&priv->bloquear, banderas) spin_lock_irq(&priv->bloquear) | | ipoib_mcast_remove_list(&remove_list) (Aquí, `mcast` ya no está en | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` y seguimos | remove_list, list) girando en `remove_list` de | >>> wait_for_completion(&mcast ->hecho) el otro hilo que está bloqueado | y la lista sigue siendo válida | en su pila.) Solucione este problema manteniendo el bloqueo mantenido y cambiando a GFP_ATOMIC para evitar eventuales suspensiones. Desafortunadamente, no pudimos reproducir el bloqueo y confirmar esta solución, pero según la revisión del código, creo que esta solución debería abordar dichos bloqueos. crash> bc 31 PID: 747 TAREA: ff1c6a1a007e8000 CPU: 31 COMANDO: "kworker/u72:2" -- [excepción RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 000000 02 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 00000000000000000 trabajo (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff 1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (también conocido como head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 en ffffff ffc0944ac1 [ ib_ipoib] #6 [ff646f199a8c7e98] Process_one_work+0x1a7 en ffffffff9bf10967 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> lista -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (vacío) falla> ipoib_dev_priv.mcast_task.work. func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID: 8 TAREA: ff1c69998efec000 CPU: 33 COMANDO: "kworker/u72:0" -- #3 [ff646f1980153d50] wait_for_completion+0x96 en ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 en ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_ mcast_dev_flush+0x1a7 en ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 en ffffffffc09431a4 [ib_ipoib] # 7 [ff ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: corrección para etiquetar el indicador gcing en la página durante la migración de bloques. Es necesario agregar el indicador gcing faltante en la página durante la migración de bloques, para garantizar que los datos migrados persistan durante el punto de control; de lo contrario, no estarán disponibles. La persistencia del orden entre los datos y el nodo puede provocar daños en los datos después de SPOR. Se solucionó un problema similar mediante el commit 2d1fe8a86bf5 ("f2fs: corrección para etiquetar el indicador gcing en la página durante la desfragmentación del archivo").

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ceph: corrige el punto muerto o el código muerto por uso incorrecto de dget() El orden de bloqueo es incorrecto entre denty y su padre, siempre debemos asegurarnos de que el padre obtenga el bloqueo primero. Pero dado que este código muerto nunca se usa y el directorio principal siempre será configurado por quienes llaman, simplemente eliminémoslo.

El tema Total para WordPress es vulnerable a modificaciones no autorizadas de datos debido a una falta de verificación de capacidad en la función total_order_sections() en todas las versiones hasta la 2.1.59 incluida. Esto hace posible que los atacantes autenticados, con acceso de nivel de suscriptor y superior, repitan secciones en la página de inicio.

El complemento Social Sharing Plugin – Sassy Social Share para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del código corto 'Sassy_Social_Share' del complemento en todas las versiones hasta la 3.3.58 incluida debido a una sanitización de entrada insuficiente y a un escape de salida en los atributos proporcionados por el usuario. como "URL". Esto hace posible que atacantes autenticados con permisos de nivel de colaborador y superiores inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

El complemento Appointment Booking Calendar — Simply Schedule Appointments Booking Plugin para WordPress es vulnerable a Cross-Site Request Forgery en todas las versiones hasta la 1.6.6.20 incluida. Esto se debe a una validación nonce faltante o incorrecta en la función ssa_factory_reset(). Esto hace posible que atacantes no autenticados restablezcan la configuración del complemento mediante una solicitud falsificada, siempre que puedan engañar al administrador del sitio para que realice una acción como hacer clic en un enlace.