Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: recursos isb libres en el momento adecuado Cuando se utiliza la interrupción MSI/INTx, las interrupciones compartidas todavía se manejan en la rutina de eliminación del dispositivo, antes de las IRQ libres. Por lo tanto, la memoria isb todavía se lee después de liberarla. Por lo tanto, mueva wx_free_isb_resources() de txgbe_close() a txgbe_remove(). Y corrija la acción gratuita de isb incorrecta en la ruta de manejo de errores txgbe_open().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: inicializa num_q_vectors para interrupciones MSI/INTx Cuando se utilizan interrupciones MSI/INTx, wx->num_q_vectors no está inicializado. Por lo tanto, habrá pánico en el kernel en wx_alloc_q_vectors() para asignar vectores de cola.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: igc: corrige una entrada de registro usando netdev no inicializado. Durante la prueba exitosa, igc registra esto: [5.133667] igc 0000:01:00.0 (net_device sin nombre) (sin inicializar): PHC agregado ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ La razón es que igc_ptp_init() se llama muy temprano, incluso antes de Register_netdev( ) ha sido llamado. Entonces la llamada netdev_info() funciona en un netdev parcialmente no inicializado. Solucione este problema llamando a igc_ptp_init() después de Register_netdev(), justo después de la verificación de detección automática de medios, tal como en igb. Añade un comentario, como en igb. Ahora el mensaje de registro está bien: [5.200987] igc 0000:01:00.0 eth0: PHC agregado

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige las comprobaciones del rango de números de inodos. Serie de parches "nilfs2: soluciona posibles problemas relacionados con los inodos reservados". Esta serie corrige un problema de use after free reportado por syzbot, causado por la exposición del inodo interno de nilfs2 en el espacio de nombres de un sistema de archivos corrupto, y un par de fallos que causan problemas si el número inicial de inodos no reservados escritos en el -El superbloque de disco se cambia intencionalmente (o de forma corrupta) de su valor predeterminado. Este parche (de 3): En la implementación actual de nilfs2, "nilfs->ns_first_ino", que proporciona el primer número de inodo no reservado, se lee del superbloque, pero no se verifica su límite inferior. Como resultado, si en el parámetro de superbloque se establece un número que se superpone con el rango de números de inodos reservados, como el directorio raíz o los archivos de metadatos, las macros de prueba de números de inodos (NILFS_MDT_INODE y NILFS_VALID_INODE) no funcionarán correctamente. Además, estas macros de prueba utilizan cálculos de desplazamiento de bits a la izquierda utilizando el número de inodo como recuento de desplazamiento a través de la macro BIT, pero el resultado de un cálculo de desplazamiento que excede el ancho de bits de un número entero no está definido en la especificación C, por lo que si "ns_first_ino" está configurado en un valor grande distinto del valor predeterminado NILFS_USER_INO (=11), es posible que las macros no funcionen correctamente según el entorno. Solucione estos problemas verificando el límite inferior de "nilfs->ns_first_ino" y evitando cambios de bits iguales o mayores que la constante NILFS_USER_INO en las macros de prueba de número de inodo. Además, cambie el tipo de "ns_first_ino" de entero con signo a entero sin signo para evitar la necesidad de conversión de tipos en comparaciones como la verificación de límite inferior introducida esta vez.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet_diag: inicializa el campo pad en la estructura inet_diag_req_v2 KMSAN informó acceso de valor uninit en raw_lookup() [1]. Diag para sockets sin formato utiliza el campo pad en struct inet_diag_req_v2 para el protocolo subyacente. Este campo corresponde al campo sdiag_raw_protocol en la estructura inet_diag_req_raw. inet_diag_get_exact_compat() convierte inet_diag_req en inet_diag_req_v2, pero deja el campo pad sin inicializar. Entonces el problema ocurre cuando raw_lookup() accede al campo sdiag_raw_protocol. Solucione este problema inicializando el campo pad en inet_diag_get_exact_compat(). Además, haga la misma corrección en inet_diag_dump_compat() para evitar problemas similares en el futuro. [1] ERROR: KMSAN: valor uninit en raw_lookup net/ipv4/raw_diag.c:49 [en línea] ERROR: KMSAN: valor uninit en raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4 /raw_diag.c:49 [en línea] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/ inet_diag.c :1404 [en línea] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670. c:2564 sock_diag_rcv+0x35 /0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [en línea] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c :1905 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket. c:2639 __sys_sendmsg net/socket.c:2668 [en línea] __do_sys_sendmsg net/socket.c:2677 [en línea] __se_sys_sendmsg net/socket.c:2675 [en línea] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x13 5e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se almacenó en la memoria en: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag .c:1404 [en línea] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:256 4 calcetín_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [en línea] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:263 9 __sys_sendmsg neto/ socket.c:2668 [en línea] __do_sys_sendmsg net/socket.c:2677 [en línea] __se_sys_sendmsg net/socket.c:2675 [en línea] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/ 0x3ce0 arch/x86 /include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Variable local req.i creado en: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [en línea] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c: 282 procesadores: 1 PID: 8888 Comm: syz-executor.6 No contaminado 6.10.0-rc4-00217-g35bb670d65fc #32 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 01/04/2014

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: vaciar incondicionalmente el trabajo pendiente antes de que el notificador syzbot informe: KASAN: slab-uaf en nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf en nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Lectura de tamaño 2 en la dirección ffff88802b0051c4 por tarea kworker/1:1/45 [..] ue : eventos nf_tables_trans_destroy_work Seguimiento de llamadas: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [en línea] nft_commit_release net/netfilter/nf_tables_api.c:9530 [en línea] nf_tables_trans_destroy_work+0x152b/0x1750 s_api.c:9597 El problema es que el notificador realiza un vaciado condicional, pero es posible que las transacciones que procesa el trabajador aún hagan referencia a la tabla que se va a eliminar, por lo que debemos realizar un vaciado incondicional. Podríamos hacer que flux_work dependa de si encontramos una tabla para eliminar en nf-next para evitar el vaciado en la mayoría de los casos. AFAICS, este problema solo se expone en nf-next, con la confirmación e169285f8c56 ("netfilter: nf_tables: no almacenar nft_ctx en objetos de transacción"), con esta confirmación aplicada hay una búsqueda incondicional de tabla->familia que es lo que desencadena lo anterior salpicar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ntb_netdev: Mover ntb_netdev_rx_handler() para llamar a netif_rx() desde __netif_rx() Lo siguiente se emite cuando se utiliza idxd (DSA) dmanegine como transportador de datos para ntb_transport que utiliza ntb_netdev. [74412.546922] ERROR: usar smp_processor_id() en código interrumpible [00000000]: irq/52-idxd-por/14526 [74412.556784] la persona que llama es netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 6 Comunicaciones: irq/52- idxd-por No contaminado 6.9.5 #5 [74412.569870] Nombre de hardware: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 08/02/2024 [74412.581699] Seguimiento de llamadas: [74412.584514] [ 74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] 0/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x 2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? hilo_irq+0xa8/0x290 [74412.642218] hilo_irq+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? __pfx_kthread+0x10/0x10 [74412.668639] ret_from_fork+0x31/0x50 [74412.672716] ? __pfx_kthread+0x10/0x10 [74412.676978] ret_from_fork_asm+0x1a/0x30 [74412.681457] La causa se debe a que el controlador de finalización de interrupciones del controlador idxd utiliza interrupciones de subprocesos y el controlador de subprocesos no es un contexto de interrupción dura o suave. Sin embargo, __netif_rx() solo se puede llamar desde el contexto de interrupción. Cambie la llamada a netif_rx() para permitir la finalización a través del contexto normal para los controladores dmaengine que utilizan el manejo de irq por subprocesos. Si bien la siguiente confirmación cambió de netif_rx() a __netif_rx(), baebdf48c360 ("net: dev: se asegura de que netif_rx() pueda invocarse en cualquier contexto."), el cambio debería haber sido un fracaso. Sin embargo, el código que precede a esta solución debería haber usado netif_rx_ni() o netif_rx_any_context().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: restringir los valores de NL80211_ATTR_TXQ_QUANTUM syzbot puede activar bloqueos suaves, configurando NL80211_ATTR_TXQ_QUANTUM en 2^31. Tuvimos un problema similar en sch_fq, solucionado con la confirmación d9e15a273306 ("pkt_sched: fq: no acepte el tonto TCA_FQ_QUANTUM") guardián: ERROR: bloqueo suave - ¡CPU#1 bloqueada durante 26 segundos! [kworker/1:0:24] Módulos vinculados en: irq event stamp: 131135 hardirqs habilitados por última vez en (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last habilitado en (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs deshabilitado por última vez en (131135): [] __el1_irq arch/arm64/kernel/entry -common.c:533 [inline] hardirqs deshabilitado por última vez en (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs habilitado por última vez en (125892): [< ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [en línea] softirqs habilitado por última vez en (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs deshabilitado por última vez en (12589 6) : [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 No contaminado 6.9.0-rc7-syzkaller-gfda5695d692c #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Cola de trabajo: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: __list_del include/linux/list.h :195 [en línea] pc: __list_del_entry include/linux/list.h:218 [en línea] pc: list_move_tail include/linux/list.h:310 [en línea] pc: fq_tin_dequeue include/net/fq_impl.h:112 [en línea] pc: ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr: __list_del_entry include/linux/list.h:218 [en línea] lr: list_move_tail include/linux/list.h:310 [en línea] lr: fq_tin_dequeue incluye /net/fq_impl.h:112 [en línea] lr: ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp: ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 00000000000 0d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 00000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 000ff0100 x9: 0000000000000000 x8: 0000000000000000 x7: 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0 032470 Seguimiento de llamadas: __list_del include/linux/list.h:195 [en línea] __list_del_entry include/linux/list.h:218 [en línea] list_move_tail include/linux/list.h:310 [en línea] fq_tin_dequeue include/net/fq_impl.h:112 [en línea] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [ en línea] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [en línea] Schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [en línea] ieee80211_queue_skb+0x18e8/ 0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_x mit+0xab8/0x122c net/mac80211/tx.c :4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c :3531 [en línea] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] neigh_resolve_output+0x558/ 0x658---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jffs2: corrija el posible acceso ilegal a la dirección en jffs2_free_inode Durante la prueba de esfuerzo del sistema de archivos jffs2, se encontraron las siguientes impresiones anormales: [2430.649000] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0069696969696948 [ 2430.649622] Información de cancelación de memoria: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (EL actual), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: error de traducción de nivel 0 [ 2430.651446] Información de cancelación de datos: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] dirección entre usuario y kernel rangos de direcciones [2430.653265] Error interno: Ups: 96000004 [#1] PREEMPT SMP [2430.654512] CPU: 2 PID: 20919 Comm: cat No contaminado 5.15.25-g512f31242bf6 #33 [2430.655008] Nombre de hardware: tonto-virt ( DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051]sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.65943 4] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 00000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000 820a1 x12: 00000000000d1b19 [2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9: ffff8000084f0d14 [2430.662025] x8: bf9a6b40 x7: ffff0000bf9a6b48 x6: 0000000003470302 [2430.662695 ] x5: ffff00002e41dcc0 x4: ffff0000bf9aa3b0 x3: 0000000003470342 [2430.663486] x2: 0000000000000000 x1: ffff8000084f0d14 x0: ffffc0000000 000 [2430.664217] Rastreo de llamadas: [2430.664528] kfree+0x78/0x348 [2430.664855] jffs2_free_inode+0x24/0x48 [2430.665233] i_callback+0x24 /0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 El parámetro pasado a kfree fue 5a5a5a5a, que corresponde al campo de destino de la estructura jffs_inode_info. Se encontró que todas las variables en la estructura jffs_inode_info eran 5a5a5a5a, excepto el primer miembro sem. Se sospecha que estas variables no se inicializan porque se configuraron en 5a5a5a5a durante la prueba de memoria, lo que pretende detectar memoria no inicializada. La variable sem se inicializa en la función jffs2_i_init_once, mientras que otros miembros se inicializan en la función jffs2_init_inode_info. La función jffs2_init_inode_info se llama después de iget_locked, pero en la función iget_locked, se activa el proceso destroy_inode, que libera el inodo y, en consecuencia, el miembro objetivo del inodo no se inicializa. En escenarios concurrentes de alta presión, iget_locked puede ingresar a la rama destroy_inode como descrito en el código. Dado que la funcionalidad destroy_inode de jffs2 solo libera el objetivo, el método de reparación es establecer el objetivo en NULL en jffs2_i_init_once.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Solo libera el búfer VA que no es NULL En el controlador MediaTek vcodec, mientras que mtk_vcodec_mem_free() se llama principalmente solo cuando el búfer a liberar existe, hay algunas casos que no hicieron la verificación y activaron advertencias en la práctica. Creemos que esos cheques se olvidaron sin querer. Vuelva a agregar las comprobaciones para corregir las advertencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige la desreferenciación no válida del puntero de datos CCW indirecto. Se corrige la desreferenciación no válida del puntero de datos CCW indirecto en dasd_eckd_dump_sense() que genera pánico en el kernel en casos de error. Cuando se utiliza direccionamiento indirecto para DASD CCW (IDAW), el puntero CCW CDA no contiene la dirección de datos en sí, sino un puntero al IDAL. Esto también debe traducirse de físico a virtual antes de usarlo. Esta desreferenciación también se usa para dasd_page_cache y también se corrige, aunque es muy poco probable que esta ruta de código se use alguna vez.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: common: no llame a hw_to_ccu_common en hw sin common Para establecer el rango de velocidad de un hw, sunxi_ccu_probe llama a hw_to_ccu_common() asumiendo todas las entradas en desc- >ccu_clks están contenidos en una estructura ccu_common. Esta suposición es incorrecta y, en consecuencia, provoca desreferencias de punteros no válidas. Eliminar la llamada defectuosa. En su lugar, agregue un bucle más que itere sobre ccu_clks y establezca el rango de velocidad, si es necesario.