Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: cambiar ipsec_lock de spin lock a mutex en el commit citado, se agrega bond->ipsec_lock para proteger ipsec_list, por lo tanto, se llaman xdo_dev_state_add y xdo_dev_state_delete dentro de este bloqueo. Como ipsec_lock es un spin lock y tales operaciones xfrmdev pueden dormir, se activará "programación mientras es atómica" al cambiar el esclavo activo de bond. [ 101.055189] ERROR: programación mientras es atómica: bash/902/0x00000200 [ 101.055726] Módulos vinculados en: [ 101.058211] CPU: 3 PID: 902 Comm: bash No contaminado 6.9.0-rc4+ #1 [ 101.058760] Nombre del hardware: [ 101.059434] Seguimiento de llamadas: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? opción_almacenamiento_sysfs_bonding+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] cambio_enlace_esclavo_activo+0x392/0x900 [enlace] [ 101.069868] opción_enlace_esclavo_activo_conjunto+0x1c2/0x240 [enlace] [ 101.070454] __opción_enlace_conjunto+0xa6/0x430 [enlace] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [vinculación] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [vinculación] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [vinculación] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Como bond_ipsec_add_sa_all y bond_ipsec_del_sa_all solo se llaman desde bond_change_active_slave, que requiere mantener el bloqueo RTNL. Y bond_ipsec_add_sa y bond_ipsec_del_sa son API xdo_dev_state_add y xdo_dev_state_delete de estado xfrm, que están en el contexto del usuario. Por lo tanto, ipsec_lock no tiene que ser un bloqueo de giro; cámbielo a mutex y, por lo tanto, se puede resolver el problema anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: comprobar la presencia del dispositivo al obtener la configuración del enlace Un lector sysfs puede competir con un reinicio o eliminación del dispositivo, intentando leer el estado del dispositivo cuando este no está realmente presente. p. ej.: [excepción RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings en ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings en ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings en ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show en ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show en ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show en ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read en ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read en ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read en ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 en ffffffff98a052fb bloqueo> estructura net_device.state ffff9a9d21336000 estado = 5, el estado 5 es __LINK_STATE_START (0b1) y __LINK_STATE_NOCARRIER (0b100). El dispositivo no está presente, note la falta de __LINK_STATE_PRESENT (0b10). Este es el mismo tipo de pánico que se observa en el commit 4224cfd7fb65 ("net-sysfs: agregar verificación de presencia de netdevice a speed_show"). Hay muchos otros invocadores de __ethtool_get_link_ksettings() que no tienen una verificación de presencia de dispositivo. Mueva esta verificación a ethtool para proteger a todos los invocadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: corrige un bloqueo aleatorio observado al eliminar el controlador Esto corrige el bloqueo aleatorio del kernel observado al eliminar el controlador, al ejecutar la prueba de carga/descarga en múltiples iteraciones. 1) modprobe btnxpuart 2) hciconfig hci0 reset 3) hciconfig (verifique que la interfaz hci0 esté activa con una dirección BD válida) 4) modprobe -r btnxpuart Repita los pasos 1 a 4 La llamada ps_wakeup() en btnxpuart_close() programa psdata->work(), que se programa después de que se elimina el módulo, lo que provoca un bloqueo del kernel. Este problema oculto se destacó después de habilitar el Ahorro de energía de forma predeterminada en 4183a7be7700 (Bluetooth: btnxpuart: Habilitar la función Ahorro de energía al inicio). El nuevo ps_cleanup() anula la interrupción de UART inmediatamente al cerrar el dispositivo serdev, cancela cualquier ps_work programado y destruye el mutex ps_lock. [ 85.884604] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffffd4a61638f258 [ 85.884624] Información de aborto de memoria: [ 85.884625] ESR = 0x0000000086000007 [ 85.884628] EC = 0x21: IABT (EL actual), IL = 32 bits [ 85.884633] SET = 0, FnV = 0 [ 85.884636] EA = 0, S1PTW = 0 [ 85.884638] FSC = 0x07: error de traducción de nivel 3 [ 85.884642] tabla de páginas del intercambiador: 4k páginas, VA de 48 bits, pgdp=0000000041dd0000 [ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000 [ 85.884662] Error interno: Oops: 0000000086000007 [#1] PREEMPT SMP [ 85.890932] Módulos vinculados en: algif_hash algif_skcipher af_alg superposición fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 error de seguridad de caam snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv fusible rc_core [última descarga: btnxpuart(O)] [ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Contaminado: GO 6.1.36+g937b1be4345a #1 [ 85.936176] Nombre del hardware: Placa EVK FSL i.MX8MM (DT) [ 85.936182] Cola de trabajo: eventos 0xffffd4a61638f380 [ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 85.952817] pc : 0xffffd4a61638f258 [ 85.952823] lr : 0xffffd4a61638f258 [ 85.952827] sp : ffff8000084fbd70 [ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000 [ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305 [ 85.963119] ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970 [ 85.977382] x20: 00000000000000000 x19: ffff4bf1c8540880 x18: 00000000000000 00 [ 85.977391] x17: 0000000000000000 x16: 00000000000000133 x15: 0000ffffe2217090 [ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139 [ 85.977407] x11: 000000000000001 x10: 0000000000000a60 x9: ffff8000084fbc50 [ 85.977417] x8: ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8 [ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000 [ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000 [ 85.977443] Rastreo de llamadas: [ 85.977446] 0xffffd4a61638f258 [ 85.977451] 0xffffd4a61638f3e8 [ 85.977455] process_one_work+0x1d4/0x330 [ 85.977464] worker_thread+0x6c/0x430 [ 85.977471] kthread+0x108/0x10c [ 85.977476] ret_from_fork+0x10/0x20 [ 85.977488] Código: valor de PC incorrecto [ 85.977491] ---[ fin de seguimiento 0000000000000000 ]--- Preestablecido desde v6.9.11

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pktgen: uso de cpus_read_lock() en pg_net_init() He visto que WARN_ON(smp_processor_id() != cpu) se activa en pktgen_thread_worker() durante las pruebas. Debemos usar cpus_read_lock()/cpus_read_unlock() alrededor del bucle for_each_online_cpu(cpu). Mientras estamos en ello, use WARN_ON_ONCE() para evitar una posible inundación de syslog.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: st: fix probed platform device ref count on probe error path La función de sonda nunca realiza ninguna asignación de dispositivo de plataforma, por lo que la ruta de error "undo_platform_dev_alloc" es completamente falsa. Elimina el recuento de referencia del dispositivo de plataforma que se está sondeando. Si se activa la ruta de error, esto provocará recuentos de referencia de dispositivo desequilibrados y una liberación prematura de los recursos del dispositivo, por lo que es posible que se produzca un use-after-free al liberar los recursos restantes administrados por devm.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: se corrige una posible desreferencia de puntero NULL Cuando sockfd_lookup() falla, gtp_encap_enable_socket() devuelve un puntero NULL, pero sus invocadores solo comprueban los punteros de error, por lo que pasan por alto el caso del puntero NULL. Arréglelo devolviendo un puntero de error con el código de error que lleva sockfd_lookup(). (Encontré este error durante la inspección del código).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: evitar pánico para archivos cerrados nfsv4.0 en nfs4_show_open Antes del commit 3f29cc82a84c ("nfsd: separar sc_status de sc_type") states_show() dependía de que el campo sc_type fuera de un tipo válido antes de llamar a una subfunción para mostrar el contenido de un stateid en particular. A partir de esa confirmación, dividimos la validez del stateid en sc_status y ya no cambiamos sc_type a 0 mientras deshacemos el hash del stateid. Esto resultó en un error del kernel para las aperturas nfsv4.0 que permanecen y en nfs4_show_open() se desreferenciaba sc_file que era NULL. En cambio, para los stateids abiertos y cerrados, renunciamos a mostrar información que depende de tener un sc_file válido. Para reproducir: monte el servidor con 4.0, lea y cierre un archivo y luego en el servidor cat /proc/fs/nfsd/clients/2/states [ 513.590804] Rastreo de llamadas: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [513.592241] ksys_read+0xcc/0x178

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: evitar UAF alrededor de la cerca de preempción El bloqueo de la cerca es parte de la cola, por lo tanto, en el diseño actual, cualquier cosa que bloquee la cerca también debe contener una referencia a la cola para evitar que la cola se libere. Sin embargo, actualmente parece que le enviamos una señal a la cerca y luego descartamos la referencia de la cola, pero si algo está esperando en la cerca, el que espera es expulsado para que se despierte en algún momento posterior, donde al despertarse primero toma el bloqueo antes de verificar el estado de la cerca. Pero si ya descartamos la referencia de la cola, entonces el bloqueo ya podría estar liberado como parte de la cola, lo que lleva a uaf. Para evitar esto, mueva el bloqueo de la cerca a la cerca misma para que no nos encontremos con problemas de duración de vida. La alternativa podría ser tener un bloqueo a nivel de dispositivo, o solo liberar la cola en la devolución de llamada de liberación de la cerca, sin embargo, eso podría requerir enviar a otro trabajador para evitar problemas de bloqueo. Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (seleccionada del commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)

Las aplicaciones que brindan recursos estáticos a través de los marcos web funcionales WebMvc.fn o WebFlux.fn son vulnerables a ataques de path traversal. Un atacante puede crear solicitudes HTTP maliciosas y obtener cualquier archivo en el sistema de archivos que también sea accesible para el proceso en el que se ejecuta la aplicación Spring. Específicamente, una aplicación es vulnerable cuando se cumplen las dos condiciones siguientes: * la aplicación web usa RouterFunctions para brindar recursos estáticos * el manejo de recursos está configurado explícitamente con una ubicación FileSystemResource Sin embargo, las solicitudes maliciosas se bloquean y rechazan cuando se cumple alguna de las siguientes condiciones: * el firewall HTTP de Spring Security https://docs.spring.io/spring-security/reference/servlet/exploits/firewall.html está en uso * la aplicación se ejecuta en Tomcat o Jetty

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: aacraid: Fix double-free on probe failure aac_probe_one() llama a funciones init específicas del hardware a través del puntero aac_driver_ident::init, todas las cuales eventualmente invocan a aac_init_adapter(). Si aac_init_adapter() falla después de asignar memoria para aac_dev::queues, libera la memoria pero no borra ese miembro. Después de que la función init específica del hardware devuelve un error, aac_probe_one() recorre una ruta de error que libera la memoria a la que apunta aac_dev::queues, lo que da como resultado una doble liberación.

El complemento WPFactory Helper para WordPress es vulnerable a ataques Cross-Site Scripting reflejado debido al uso de add_query_arg sin el escape adecuado en la URL en todas las versiones hasta la 1.7.0 incluida. Esto permite que atacantes no autenticados inyecten secuencias de comandos web arbitrarias en páginas que se ejecutan si logran engañar a un usuario para que realice una acción como hacer clic en un enlace.

IBM Concert 1.0 no establece el atributo seguro en tokens de autorización o cookies de sesión. Los atacantes pueden obtener los valores de las cookies enviando un enlace http:// a un usuario o colocando este enlace en un sitio al que accede el usuario. La cookie se enviará al enlace inseguro y el atacante puede obtener el valor de la cookie espiando el tráfico.