Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/edid: En conector_bad_edid() cap num_of_ext por num_blocks leído En commit e11f5bd8228f ("drm: Agregar soporte para prueba de corrupción edid de cumplimiento de DP 1.4") la función conector_bad_edid() comenzó a asumir que la memoria para el EDID que se le pasó era lo suficientemente grande como para contener bloques de datos `edid[0x7e] + 1` (1 adicional para el bloque base). Ignoró por completo el hecho de que a la función se le pasó `num_blocks`, que indicaba cuánta memoria se había asignado para el EDID. Arreglemos esto agregando una verificación de los límites. Esto es importante para manejar el caso en el que hay un error en el primer bloque del EDID. En ese caso llamaremos a Connector_bad_edid() sin haber reasignado memoria en base a `edid[0x7e]`.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm: corrige la desreferencia del puntero nulo en el puntero edp. La inicialización del puntero dev desreferencias del puntero edp antes de edp se marca como nula, por lo que existe un posible problema de deferencia del puntero nulo. Solucione este problema eliminando la referencia a edp únicamente después de que se haya marcado como nulo. Direcciones-Cobertura: ("Desreferencia antes de verificación nula")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a4xx: corrige el manejo de errores en a4xx_gpu_init() Este código devuelve 1 en caso de error en lugar de un error negativo. Conduce a un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no puede ser verdadera porque "ret" está establecido en 1.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a3xx: corrige el manejo de errores en a3xx_gpu_init() Estas rutas de error devolvieron 1 en caso de falla, en lugar de un código de error negativo. Esto provocaría un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no funcionó porque "ret" estaba establecido en 1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige posible bloqueo en recvmsg() recvmsg() puede entrar en un bucle infinito si la persona que llama proporciona MSG_WAITALL, los datos presentes en la cola de recepción no son suficientes para cumplir con la solicitud y el par no recibe más datos. Cuando sucede lo anterior, mptcp_wait_data() siempre regresará sin espera, ya que el indicador MPTCP_DATA_READY verificado por dicha función se establece y nunca se borra en dicha ruta de código. Aprovechar el syzbot anterior fue capaz de desencadenar una parada de RCU: rcu: INFO: rcu_preempt parada autodetectada en la CPU rcu: 0-...!: (10499 marca este GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1 (t=10500 jiffies g=13089 q=109) rcu: rcu_preempt ¡kthread se quedó sin 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 rcu: A menos que rcu_preempt kthread obtenga suficiente tiempo de CPU, ahora se espera que OOM sea el comportamiento. rcu: Volcado de pila de kthread del período de gracia de RCU: tarea: rcu_preempt estado: R pila de tareas en ejecución: 28696 pid: 14 ppid: 2 banderas: 0x00004000 Seguimiento de llamadas: context_switch kernel/sched/core.c:4955 [en línea] __schedule+0x940/ 0x26f0 kernel/sched/core.c:6236 Schedule+0xd3/0x270 kernel/sched/core.c:6315 Schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c :1955 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 rcu: Volcado de pila donde RCU Última ejecución de GP kthread: Envío de NMI desde la CPU 0 a las CPU 1: seguimiento de NMI para la CPU 1 CPU: 1 PID: 8510 Comm: syz-executor827 No contaminado 5.15.0-rc2-next-20210920-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP : 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189 Código: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00 RSP: 0018:ffffc9000cd676c8 EFLAGS: 000283 RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX : ffffffff88ea062a RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870 RBP: ffffed100e9a110e R08: 0000000000000001 R09: d08877 R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000 R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: instrument_atomic_ lectura_escritura incluye/linux/ instrumented.h:101 [en línea] test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [en línea] mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016 release_sock+0xb4/0x1b0 net/core/ sock.c:3204 mptcp_wait_data net/mptcp/protocol.c:1770 [en línea] mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659 vmsg_nosec red/socket .c:944 [en línea] ____sys_recvmsg+0x527/0x600 net/socket.c:2626 ___sys_recvmsg+0x127/0x200 net/socket.c:2670 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764 net/socket.c: 2843 [en línea] __do_sys_recvmmsg net/socket.c:2866 [en línea] __se_sys_recvmmsg net/socket.c:2859 [en línea] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la lógica de aborto en btrfs_replace_file_extents Las pruebas de inyección de errores descubrieron un caso en el que terminaríamos con un sistema de archivos corrupto al que le faltaba una extensión en medio de un archivo. Esto ocurre porque la declaración if para decidir si debemos abortar es incorrecta. La única manera de abortar en este caso es si obtenemos un ret! = -EOPNOTSUPP y llamamos desde el código de clonación del archivo. Sin embargo, el código de preasignación también utiliza esta ruta. En lugar de eso, debemos abortar si hay un error, y el único error por el que _no_ abortamos es -EOPNOTSUPP y solo si venimos del código del archivo clonado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xhci: corrige la corrupción del puntero del anillo de comando al cancelar un comando. El puntero del anillo de comando está ubicado en los bits [6:63] del registro de control del anillo de comando (CRCR). Todos los bits de control, como el comando de parada y cancelación, se encuentran en bits [0:3]. Mientras abortamos un comando, leemos el CRCR, configuramos el bit de cancelación y escribimos en el CRCR. La lectura siempre dará un puntero de anillo de comando como todo ceros. Básicamente, escribimos sólo los bits de control. Dado que dividimos la escritura de 64 bits en dos escrituras de 32 bits, existe la posibilidad de que el anillo de comando xHC se detenga antes de que se escriba la palabra d superior (todo ceros). Si eso sucede, xHC actualiza la palabra clave superior de su puntero de anillo de comando interno con todo ceros. La próxima vez, cuando se reinicie el anillo de comando, veremos fallas de acceso a la memoria xHC. Solucione este problema escribiendo únicamente en la palabra clave inferior de CRCR donde se encuentran todos los bits de control.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm: corrige la ejecución del puntero NULL de mempool al completar IO dm_io_dec_pending() llama a end_io_acct() primero y luego dec md en vuelo conteo pendiente. Pero si una tarea intercambia la tabla DM al mismo tiempo, esto puede provocar un bloqueo debido a que mempool->elementos son NULL: tarea1 tarea2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 - >dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [67.330330] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000000 ...... [67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO ) [67.330510] pc: mempool_free+0x70/0xa0 [67.330515] lr: mempool_free+0x4c/0xa0 [67.330520] sp: ffffff8008013b20 [67.330524] x29: ffffff8008013b20 x28: 000000000000004 [ 67.330530] x27: fffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: 1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 00000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8: 0000000000000000 [67.330585] x7: 0000000000000000 x6: ffffff80148b5c1a [67.330590] x5: ffffff8008013ae0 x4: 000000001 [67.330596] x3: ffffff80080139c8 x2: ffffff801083bab8 [67.330601] x1: 0000000000000000 x0: ffffffdada34c970 [67.330609] Rastreo de llamadas: [67.330616] mempool_free+0x70/0xa0 [67.330627] 8/0x110 [67.330638] dec_pending+0x13c/0x230 [67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673 ] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688 ] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.3307 16] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq +0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] +0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4 /0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] second_start_kernel+0x160/0x170 Solucione este problema de la siguiente manera: 1) Estableciendo punteros a los miembros 'struct dm_io' en dm_io_dec_pending() para que puedan pasarse a end_io_acct() _después_ free_io() se llama. 2) Mover end_io_acct() después de free_io().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: musb: dsps: corrige la ruta del error de la sonda. El commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() después de inicializar musb") ha invertido las llamadas a dsps_setup_optional_vbus_irq() y dsps_create_musb_pdev() sin actualizar correctamente la ruta del error. dsps_create_musb_pdev() asigna y registra un nuevo dispositivo de plataforma que debe cancelarse y liberarse con platform_device_unregister(), y esto falta en el error dsps_setup_optional_vbus_irq(). Mientras que en la rama maestra parece no desencadenar ningún problema, observé un bloqueo del kernel debido a una desreferencia del puntero NULL con un kernel estable v5.10.70 donde el parche mencionado anteriormente estaba respaldado. Con esta versión del kernel, se devuelve -EPROBE_DEFER la primera vez que se llama a dsps_setup_optional_vbus_irq(), lo que provoca que la sonda genere un error sin cancelar el registro del dispositivo de plataforma. Desafortunadamente, en el Beagle Bone Black Wireless, el dispositivo de plataforma que aún se encuentra en el sistema está siendo utilizado por el controlador del dispositivo USB Ethernet, lo que durante la fase de arranque provoca el bloqueo. Mi conocimiento limitado del mundo musb me impide revertir este compromiso que fue enviado para silenciar una advertencia de robot que, hasta donde tengo entendido, no tiene sentido. El objetivo de este parche era evitar que se activara una IRQ antes de que se registrara el dispositivo de la plataforma. Creo que esto nunca puede suceder debido al hecho de que habilitar las interrupciones se realiza mediante la devolución de llamada ->enable() del dispositivo musb de la plataforma, y este dispositivo de plataforma ya debe estar registrado para que el núcleo o cualquier otro usuario pueda usar esto. llamar de vuelta. Por lo tanto, decidí corregir la ruta del error, lo que podría evitar futuros errores en los núcleos principales y al mismo tiempo corregir los más antiguos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adis16475: corrige el punto muerto en el conjunto de frecuencias Con el commit 39c024b51b560 ("iio: adis16475: mejora el manejo del modo de escala de sincronización"), se introdujeron dos puntos muertos: 1) La llamada a 'adis_write_reg_16 ()' no se cambió a su versión desbloqueada. 2) El bloqueo no se estaba liberando en la ruta exitosa de la función. Este cambio soluciona ambos problemas.

El complemento Elegant Addons para elementor para WordPress es vulnerable a Cross-Site Scripting Almacenado a través de los widgets Switcher, Slider e Iconbox del complemento en todas las versiones hasta la 1.0.8 incluida debido a una sanitización de entrada insuficiente y a un escape de salida en los atributos proporcionados por el usuario. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

El complemento Business Directory – Easy Listing Directories para WordPress es vulnerable a la inyección SQL basada en tiempo a través del parámetro 'listingfields' en todas las versiones hasta la 6.4.2 incluida debido a un escape insuficiente en el parámetro proporcionado por el usuario y a la falta de suficiente preparación en la consulta SQL existente. Esto hace posible que atacantes no autenticados agreguen consultas SQL adicionales a consultas ya existentes que pueden usarse para extraer información confidencial de la base de datos.