Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs, fscache: Prevenir Ups en fscache_put_cache() Esta función desreferencia "caché" y luego verifica si es IS_ERR_OR_NULL(). Primero verifique y luego elimine la referencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/rds: Corrección de UBSAN: array-index-out-of-bounds en rds_cmsg_recv El bloqueo de Syzcaller UBSAN ocurre en rds_cmsg_recv(), que dice inc->i_rx_lat_trace[j + 1] con índice 4 (3 + 1), pero con tamaño de matriz de 4 (RDS_RX_MAX_TRACES). Aquí 'j' se asigna desde rs->rs_rx_trace[i] y, a su vez, desde trace.rx_trace_pos[i] en rds_recv_track_latency(), con ambas matrices de tamaño 3 (RDS_MSG_RX_DGRAM_TRACE_MAX). Así que arregle la verificación de los límites fuera de uno en rds_recv_track_latency() para evitar un posible fallo en rds_cmsg_recv(). Encontrado por syzcaller: ================================================ =================== UBSAN: índice de matriz fuera de los límites en net/rds/recv.c:585:39 el índice 4 está fuera de rango para el tipo 'u64 [4]' CPU: 1 PID: 8058 Comm: syz-executor228 No contaminado 6.6.0-gd2f51b3516da #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/ Seguimiento de llamadas de 2014: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [en línea] __ubsan_handle_out_of_bounds+0xd5/0x130 lib/ubsan. c:348 rds_cmsg_recv+0x60d/0x700 net/rds/recv.c:585 rds_recvmsg+0x3fb/0x1610 net/rds/recv.c:716 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0xe2/0x1 60 netos/toma .c:1066 __sys_recvfrom+0x1b6/0x2f0 net/socket.c:2246 __do_sys_recvfrom net/socket.c:2264 [en línea] __se_sys_recvfrom net/socket.c:2260 [en línea] __x64_sys_recvfrom+0xe0/0x1b0 net/socket .c:2260 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x63/0x6b =============== ==================================================== ==

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: asegúrese de iniciar los spinlocks de Accept_queue una vez. Cuando ejecuto el programa C de reproducción de syz localmente, causa el siguiente problema: pvqspinlock: ¡el bloqueo 0xffff9d181cd5c660 tiene un valor corrupto 0x0! ADVERTENCIA: CPU: 19 PID: 21160 en __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Nombre del hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt .h :508) Código: 73 56 3a ff 90 c3 cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000 00000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 00000000000000000 R13: ffff9d181cd5c660 R14: ffff9d181 3a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Seguimiento de llamadas: _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c: 1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234 ) __netif_receive_skb_one_core (net/core/dev.c:5529) Process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c: 381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release _calcetín (. /include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/ af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/ socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S: 129) QEPD: 0033:0x7fa10ff05a3d Código: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4 c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007FA110183E20 R08: 000000000000000000 R09: 000000000000000000 R10: 0000000000000000000000000000000000000000202 R12: 00007FA1101846440000000000000000000000000000000000000000000000000000000000000SEN 00007FA10FE8B060 R15: 00007FFFF73E23B20 El proceso de activación del problema se analiza de la siguiente manera: subhifique un subproceso b tcp_v4_rcv / /recibir acuse de recibo del paquete TCP inet_shutdown tcp_check_req tcp_disconnect //desconectar calcetín... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance... inet_csk_reqsk_queue_add ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige el acceso ilegal a rmb_desc en el volcado de conexiones SMC-D Se encontró un bloqueo al volcar conexiones SMC-D. Se puede reproducir mediante los siguientes pasos: - ejecute la prueba nginx/wrk: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Conexión: Cerrar' - volcar continuamente las conexiones SMC-D en paralelo: watch -n 1 'smcss -D' ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: cargado Contaminado: GE 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+ 0x5e5/0x620 [smc_diag] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x66/0x150? exc_page_fault+0x69/0x140? asm_exc_page_fault+0x26/0x30? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+ 0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____s ys_sendmsg+0x24e/0x300? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160? do_read_fault+0x5f/0x100? do_fault+0xb0/0x110? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Es posible que la conexión esté en proceso de establecerse cuando la volcamos. Se supone que la conexión ha sido registrada en un grupo de enlaces por smc_conn_create() pero rmb_desc aún no ha sido inicializado por smc_buf_create(), lo que provoca el acceso ilegal a conn->rmb_desc. Así que solucionelo comprobando antes del volcado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: limpieza: evita el use-after-free cuando la longitud del fragmento no está alineada con 64 K [ERROR] Hay un informe de error que indica que, en un btrfs convertido a ext4, la limpieza conduce a varios problemas, que incluyen: - Errores "no se puede encontrar el mapa de fragmentos" Información BTRFS (dispositivo vdb): limpieza: iniciado en el devid 1 BTRFS crítico (dispositivo vdb): no se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 4096 BTRFS crítico (dispositivo vdb): No se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 45056. Esto provocaría errores irreparables. - Informes KASAN de uso gratuito: =========================================== ========================= ERROR: KASAN: slab-use-after-free en __blk_rq_map_sg+0x18f/0x7c0 Lectura de tamaño 8 en la dirección ffff8881013c9040 por tarea btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 2023.11-2 24/12/2023 Seguimiento de llamadas : dump_stack_lvl+0x43/0x60 print_report+0xcf/0x640 kasan_report+0xa6/0xd0 __blk_rq_map_sg+0x18f/0x7c0 virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02ed fad39bb9ddee07dcdaff] virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blk_mq_flush_plug_list.part. 0+0x780/0x860 __blk_flush_plug+0x1ba/0x220 blk_finish_plug+0x3b/0x60 submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Flush_scrub_stripes+0x38 e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_chunk+0x178/0x200 [btrfs e579 87a360cama82fe8756dcd3e0de5406ccfe965 ] Scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btr fs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] __x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b QEPD: 0033:0x7f47e5e0952b - Fallo , principalmente debido al use-after-free anterior [CAUSA] El fs convertido tiene el siguiente diseño de fragmento de datos: clave del elemento 2 (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 tamaño del elemento 80 longitud 86016 propietario 2 stripe_len 65536 tipo DATOS|single Para el bytenr lógico anterior 2214744064 , está al final del fragmento (2214658048 + 86016 = 2214744064). Esto significa que btrfs_submit_bio() dividiría la biografía y activaría la función endio para ambas mitades. Sin embargo, Scrub_submit_initial_read() solo esperaría que la función endio se llamara una vez, ya no. Esto significa que la primera función endio ya liberaría bbio::bio, dejando libre el bvec, por lo que la segunda llamada a endio conduciría a use-after-free. [FIX] - Asegúrese de que Scrub_read_endio() solo actualice los bits en su rango. Dado que podemos leer menos de 64 K al final del fragmento, no debemos tocar los bits más allá del límite del fragmento. - Asegúrese de que Scrub_submit_initial_read() solo lea el rango de fragmentos. Esto se hace calculando el número real de sectores que necesitamos leer y agregando sector por sector a la biografía. Afortunadamente, la ruta de reparación de lectura de limpieza no necesitará correcciones adicionales: - Scrub_stripe_submit_repair_read() Con las correcciones anteriores, no actualizaremos el bit de error para el rango más allá del fragmento, por lo tanto, Scrub_stripe_submit_repair_read() nunca debería enviar ninguna lectura más allá del fragmento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: mover el mecanismo de notificación mmu dentro del bloqueo mm Mueva el mecanismo de notificación mmu dentro del bloqueo mm para evitar condiciones de ejecución en otros componentes que dependen de él. El notificador invalidará el rango de memoria. Dependiendo del número de iteraciones, se invalidarían diferentes rangos de memoria. Este parche eliminaría la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 5067 en arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/ x86/kvm/../../../virt/kvm/kvm_main.c:734 No hay cambios de comportamiento ni de rendimiento con este parche cuando no hay ningún componente registrado con el notificador mmu. [akpm@linux-foundation.org: reduzca el alcance del `rango', según Sean]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige el orden libre de carga del módulo. Orden inverso de las llamadas kfree para resolver el error de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/vfio-ap: filtra siempre toda la matriz AP La función vfio_ap_mdev_filter_matrix se llama cada vez que se asigna un nuevo adaptador o dominio al mdev. El propósito de la función es actualizar la configuración del AP del invitado filtrando la matriz de adaptadores y dominios asignados al mdev. Cuando se asigna un adaptador o dominio, solo se inspeccionan los APQN asociados con el APID del nuevo adaptador o APQI del nuevo dominio. Si un APQN no hace referencia a un dispositivo de cola vinculado al controlador de dispositivo vfio_ap, entonces su APID se filtrará de la matriz de mdev al actualizar la configuración de AP del invitado. Inspeccionar solo el APID del nuevo adaptador o APQI del nuevo dominio dará como resultado que se pasen colas de AP a un invitado que no está vinculado al controlador de dispositivo vfio_ap en determinadas circunstancias. Considere lo siguiente: configuración de AP del invitado (todas también asignadas a la matriz de mdev): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 desasignar dominio 4 desvincular cola 16.0005 asignar dominio 4 Cuando se reasigna el dominio 4, dado que solo se inspeccionará el dominio 4, los APQN que se examinará será: 14.0004 16.0004 Dado que ambos APQN hacen referencia a dispositivos de cola que están vinculados al controlador de dispositivo vfio_ap, no se filtrará nada de la matriz de mdev al actualizar la configuración de AP del invitado. En consecuencia, la cola 16.0005 pasará a pesar de no estar vinculada al conductor. Esto viola el requisito del modelo de dispositivo Linux de que a un invitado solo se le dará acceso a los dispositivos vinculados al controlador del dispositivo que facilita su paso. Para resolver este problema, cada adaptador y dominio asignado al mdev se inspeccionará al filtrar la matriz del mdev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/sme: salir siempre de sme_alloc() antes de tiempo con el almacenamiento existente. Cuando se llama a sme_alloc() con el almacenamiento existente y no estamos vaciando, siempre asignaremos nuevo almacenamiento, y ambos filtrarán el almacenamiento existente, almacenamiento y corrupción del estado. Solucione este problema separando los controles de descarga y de almacenamiento existente como lo hacemos con SVE. Las personas que llaman que se reasignan (por ejemplo, debido al cambio de la longitud del vector) deben llamar ellos mismos a sme_free().

El complemento User Registration de WordPress anterior a 2.12 no impide que los usuarios con al menos el rol de colaborador muestren códigos cortos confidenciales, lo que les permite generar y filtrar URL válidas para restablecer contraseñas, que pueden usar para hacerse cargo de cualquier cuenta.

El complemento de WordPress de Photos and Files Contest Gallery anterior a 21.3.1 no sanitiza ni escapa a algunos parámetros, lo que podría permitir a los usuarios con un rol tan bajo como el de autor realizar ataques de Cross-Site Scripting.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige el oob global en ksmbd_nl_policy Similar a un problema reportado (verifique el commit b33fb5b801c6 ("net: qualcomm: rmnet: corrige el oob global en rmnet_policy"), mi fuzzer local encuentra otra Lectura global fuera de los límites para la política ksmbd_nl_policy. Consulte el seguimiento del error a continuación: ==================================== ================================ ERROR: KASAN: global fuera de los límites en validar_nla lib/nlattr.c :386 [en línea] ERROR: KASAN: global fuera de los límites en __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Lectura de tamaño 1 en addr ffffffff8f24b100 por tarea syz-executor.1/62810 CPU: 0 PID: 62810 Comm: syz-executor.1 Contaminado: GN 6.1.0 #3 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [en línea] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report +0xbb/0x1c0 mm/kasan/report.c:495 validar_nla lib/nlattr.c:386 [en línea] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 __nlmsg_parse incluir /net/netlink.h:748 [en línea] genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565 genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734 genl_family_rcv_msg net/netlink/genetlink. c:833 [en línea] genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net /netlink/af_netlink.c:1319 [en línea] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket. c:2565 do_syscall_x64 arco /x86/entry/common.c:50 [en línea] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdd66a8f359 Código: 28 00 00 00 75 05 48 8 3 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff f ff f7 d8 64 89 01 48 RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8 f359 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003 RBP: 00007fdd66ada493 R08: 00000000000000000 R09: 00000000000000000 R 10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 La dirección del error pertenece a la variable: ksmbd_nl_policy+0x 100/0xa80 La dirección del error pertenece a la página física: página:0000000034f47940 refcount:1 mapcount:0 mapeo: 0000000000000000 índice: 0x0 pfn: 0x1ccc4b banderas: 0x200000000001000 (reservado | nodo = 0 | zona = 2) sin formato: 02000000000001000 ffffea00073312c8 ffffea00073312c8 000000000 0000000 raw: 0000000000000000 00000000000000000 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: ffffffff8f24b000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff8f24b100 : f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9 ^ ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05 ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9 ======== = ==================================================== ======= Para solucionarlo, agregue un marcador de posición llamado __KSMBD_EVENT_MAX y truncado