Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: envuelve la devolución de llamada del volcado de tx reporter para extraer el sq. La función mlx5e_tx_reporter_dump_sq() lanza su argumento void * a la estructura mlx5e_txqsq *, pero en el flujo TX-timeout-recovery el argumento en realidad es de tipo struct mlx5e_tx_timeout_ctx *. mlx5_core 0000: 08: 00.1 enp8s0f1: tx timeout detectado mlx5_core 0000: 08: 00.1 enp8s0f1: tx timeout en cola: 1, sq: 0x11ec, cq: 0x146d, sq consecuencia: 0x0 sq prod: 0x1, usecs desde el último trans: 21565000 : la página de protección de pila fue visitada en 0000000093f1a2de (la pila es 00000000b66ea0dc..000000004d932dae) Desbordamiento de pila del kernel (fallo de página): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Contaminado: GW OE 5.13. 0_mlnx #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_ volcado_sq +0xd3/0x180 [mlx5_core] Seguimiento de llamadas: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [ml x5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550? set_next_entity+0x72/0x80? pick_next_task_fair+0x227/0x340? Finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] Process_one_work+0x1de/0x3a0 trabajador_thread+0x2d/0x3c0? proceso_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 --[ end trace 51ccabea504edaff ]--- RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU: 55555554 Pánico del kernel - no sincronizado: excepción fatal Compensación del kernel: final deshabilitado Pánico del kernel - no sincronizar : Excepción fatal Para corregir este error, agregue un contenedor para mlx5e_tx_reporter_dump_sq() que extrae el sq de la estructura mlx5e_tx_timeout_ctx y lo configura como devolución de llamada de volcado de flujo de recuperación de tiempo de espera de TX.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: appletouch: inicializa el trabajo antes del registro del dispositivo Syzbot ha informado una advertencia en __flush_work(). Esta advertencia es causada por work->func == NULL, lo que significa que falta la inicialización del trabajo. Esto puede suceder, ya que input_dev->close() llama a cancel_work_sync(&dev->work), pero la inicialización dev->work ocurre _después_ de la llamada input_register_device(). Entonces este parche mueve la inicialización dev->work antes de registrar el dispositivo de entrada

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: validar datos de usuario en compat ioctl Los datos de usuario incorrectos pueden causar advertencia en i2c_transfer(), ej: cero mensajes. El espacio de usuario no debería poder activar advertencias, por lo que este parche agrega comprobaciones de validación para los datos del usuario en ioctl compacto para evitar advertencias reportadas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: binder: corrige la contabilidad async_free_space para paquetes vacíos En 4.13, el commit 74310e06be4d ("android: binder: mover el búfer fuera del área compartida con el espacio del usuario") solucionó un problema de visibilidad de la estructura del kernel. Como parte de ese parche, se usó sizeof(void *) como tamaño de búfer para cargas de datos de longitud 0, de modo que el controlador pudiera detectar clientes abusivos que enviaran transacciones asincrónicas de longitud 0 a un servidor imponiendo límites en async_free_size. Desafortunadamente, en el lado "libre", la contabilidad de async_free_space no volvió a agregar el tamaño de (void *). El resultado fue que se filtraron hasta 8 bytes de async_free_space en cada transacción asíncrona de 8 bytes o menos. Estas pequeñas transacciones son poco comunes, por lo que este problema contable ha pasado desapercibido durante varios años. La solución es utilizar "buffer_size" (el tamaño del búfer asignado) en lugar de "size" (el tamaño del búfer lógico) al actualizar async_free_space durante la operación libre. Son iguales excepto por este caso de esquina de transacciones asincrónicas con payloads <8 bytes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: soluciona el pánico del kernel causado por la carrera de smc_sock. Se produce un bloqueo cuando smc_cdc_tx_handler() intenta acceder a smc_sock pero smc_release() ya lo ha liberado. [ 4570.695099] ERROR: no se puede manejar el error de página para la dirección: 000000002eae9e88 [ 4570.696048] #PF: acceso de escritura del supervisor en modo kernel [ 4570.696728] #PF: error_code(0x0002) - página no presente [ 4570.697401] PGD 0 P4D 0 [ 4 570.697716 ] Ups: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Nombre de hardware: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/ 0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Seguimiento de llamadas: [ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.7 12470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0x f0 [4570.714934] common_interrupt+0xba/0xe0 Aunque smc_cdc_tx_handler() comprobó la existencia de smc conexión, es posible que smc_release() ya haya descartado y liberado el socket smc antes de que smc_cdc_tx_handler() lo visite más. smc_cdc_tx_handler() |smc_release() si (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- último sock_put, | smc_sock liberó bh_lock_sock(&smc->sk) (pánico) | Para asegurarnos de que no recibiremos ningún mensaje CDC después de liberar el smc_sock, agregue un recuento en smc_connection para el mensaje CDC en vuelo (publicado en el QP pero no haya recibido el CQE relacionado) y no libere el smc_connection hasta que todo Los mensajes CDC a bordo se han realizado, tanto para los exitosos como para los fallidos. El uso de refcount en mensajes CDC trae otro problema: cuando el enlace se va a destruir, smcr_link_clear() restablecerá el QP, lo que luego eliminará todos los CQE pendientes relacionados con el QP en el CQ. Para asegurarse de que todos los CQE siempre regresen para que el recuento en smc_connection siempre pueda llegar a 0, smc_ib_modify_qp_reset() fue reemplazado por smc_ib_modify_qp_error(). Y elimine el tiempo de espera en smc_wr_tx_wait_no_pending_sends() ya que debemos esperar a que se completen todos los WQE pendientes, o podemos encontrarnos con use-after- free al manejar CQE. Para la rutina de eliminación del dispositivo IB, debemos esperar a que se destruyan todos los QP de ese dispositivo antes de poder destruir los CQ del dispositivo, o el recuento de referencia en smc_connection no llegará a 0 y smc_sock no podrá liberarse.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: Borrar ffs_eventfd en ffs_data_clear. ffs_data_clear se llama indirectamente desde ffs_fs_kill_sb y ffs_ep0_release, por lo que termina siendo llamado dos veces cuando el área de usuario cierra ep0 y luego desmonta f_fs. Si Userland proporcionó un eventfd junto con los descriptores USB de la función, termina llamando a eventfd_ctx_put tantas veces, provocando un desbordamiento insuficiente de recuento. NULL-ify ffs_eventfd para evitar estas llamadas extrañas eventfd_ctx_put. Además, establezca epfiles en NULL justo después de desasignarlo, para facilitar la lectura. Para completar, ffs_data_clear en realidad termina siendo llamado tres veces, la última llamada es antes de que se libere toda la estructura de ffs, por lo que cuando ocurre esta secuencia específica, se produce un segundo desbordamiento insuficiente (pero no se informa): /sys/kernel/debug/tracing # modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (dispositivo de configuración, función ejecutar y finalizar proceso de usuario, dispositivo de desmontaje) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed tarjeta inteligente -openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put Salida de advertencia correspondiente al seguimiento anterior: [ 1946.284139] ADVERTENCIA: CPU : 0 PID: 431 en lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: desbordamiento insuficiente; use-after-free. [1946.298164] Módulos vinculados en: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E ) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_b cm2835 (CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E ) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c (E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E ) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: tarjeta inteligente- openp Contaminado: GC OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Nombre de hardware: BCM2835 [ 1946.425442] Seguimiento inverso: [ 1946.432048] [] (dump_backtrace) de [] ( show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [] (show_stack) de [] (dump_ pila+0x28/0x30) [ 1946.470380] [< c08d9ab8>] (dump_stack) de [] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [] (__warn) de [] (warn_slowpath_fmt+0xa0/ 0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [] (warn_slowpath_fmt) de [] (refcount_war n_saturado+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [] (refcount_warn_saturate) de [] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [] (eventfd_ctx_put) de [] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [] (ffs_data_clear [usb_f_fs]) de [] ( ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [] (ffs_data_closed [usb_f_fs

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/qrwlock: corrige el orden en queued_write_lock_slowpath() Mientras este código se ejecuta con wait_lock retenido, un lector puede adquirir el bloqueo sin mantener wait_lock. El lado del escritor realiza un bucle para verificar el valor con atomic_cond_read_acquire(), pero solo adquiere realmente el bloqueo cuando la comparación e intercambio se completa con éxito, lo cual no está ordenado. Esto expone la ventana entre la adquisición y el cmpxchg a un problema ABA que permite que las lecturas posteriores a la adquisición del bloqueo observen los valores de forma especulativa antes de que se adquiera realmente el bloqueo de escritura. Hemos visto un problema en epoll donde el lector realiza un xchg mientras mantiene el bloqueo de lectura, pero el escritor puede ver un cambio de valor debajo de él. Escritor | Lector ------------------------------------------------- ------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->bloquear, banderas); --> (observa el valor antes de desbloquear) | cadena_epi_lockless() | | epi->siguiente = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->bloquear, banderas); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | Un núcleo puede ordenar la lectura de ovflist antes de atomic_cmpxchg_relaxed(). Cambiar cmpxchg para usar la semántica de adquisición soluciona este problema, momento en el que atomic_cond_read se puede cambiar para usar una semántica relajada. [peterz: utilice try_cmpxchg()]

El complemento Page Builder: Pagelayer de WordPress anterior a 1.8.1 no sanitiza ni escapa a algunas de sus configuraciones, lo que podría permitir a usuarios con privilegios elevados, como el administrador, realizar ataques de Cross-Site Scripting Almacenado incluso cuando la capacidad unfiltered_html no está permitida (por ejemplo, en una configuración multisitio).

El complemento Smart Forms de WordPress anterior a 2.6.87 no tiene autorización en varias acciones AJAX, lo que podría permitir a usuarios con un rol tan bajo como suscriptor llamarlos y realizar acciones no autorizadas, como eliminar entradas. El complemento también carece de comprobaciones CSRF en algunos lugares, lo que podría permitir a los atacantes hacer que los usuarios que han iniciado sesión realicen acciones no deseadas a través de ataques CSRF, como eliminar entradas.

El complemento JetBackup de WordPress anterior a 2.0.9.9 no utiliza archivos de índice para evitar la lista pública de directorios confidenciales en ciertas configuraciones, lo que permite a actores malintencionados filtrar archivos de respaldo.

El complemento WP JobSearch de WordPress anterior a 2.3.4 no valida los archivos que se cargarán, lo que podría permitir a atacantes no autenticados cargar archivos arbitrarios como PHP en el servidor.

El complemento WP JobSearch de WordPress anterior a 2.3.4 no impide que los atacantes inicien sesión como cualquier usuario con el único conocimiento de la dirección de correo electrónico de ese usuario.