Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: agrega check_func_arg_reg_off() faltante para evitar accesos a memoria fuera de los límites. Actualmente, es posible pasar un CONST_PTR_TO_DYNPTR modificado a una función global como argumento. Los efectos adversos de esto es que los asistentes de BPF pueden continuar haciendo uso de este CONST_PTR_TO_DYNPTR modificado desde dentro del contexto de la función global, lo que puede resultar involuntariamente en accesos a la memoria fuera de los límites y, por lo tanto, comprometer la estabilidad general del sistema, es decir, [244.157771] ERROR : KASAN: losa fuera de los límites en bpf_dynptr_data+0x137/0x140 [244.161345] Lectura de tamaño 8 en la dirección ffff88810914be68 por tarea test_progs/302 [244.167151] CPU: 0 PID: 302 Comm: test_progs Contaminado: GOE 6.10.0- rc3-00131-g66b586715063 #533 [244.174318] Seguimiento de llamadas: [244.175787] [244.177356] dump_stack_lvl+0x66/0xa0 [244.179531] print_report+0xce/0x670 [244. 182314] ? __virt_addr_valid+0x200/0x3e0 [ 244.184908] kasan_report+0xd7/0x110 [ 244.187408] ? bpf_dynptr_data+0x137/0x140 [244.189714]? bpf_dynptr_data+0x137/0x140 [ 244.192020] bpf_dynptr_data+0x137/0x140 [ 244.194264] bpf_prog_b02a02fdd2bdc5fa_global_call_bpf_dynptr_data+0x22/0x26 [ 244. 198044] bpf_prog_b0fe7b9d7dc3abde_callback_adjust_bpf_dynptr_reg_off+0x1f/0x23 [ 244.202136] bpf_user_ringbuf_drain+0x2c7/0x570 [ 244.204744] ? 0xffffffffc0009e58 [244.206593]? __pfx_bpf_user_ringbuf_drain+0x10/0x10 [ 244.209795] bpf_prog_33ab33f6a804ba2d_user_ringbuf_callback_const_ptr_to_dynptr_reg_off+0x47/0x4b [ 244.215922] 2502480+0x43/0xe3 [ 244.218691] __x64_sys_prlimit64+0x9/0xf0 [ 244.220912] do_syscall_64+0xc1/0x1d0 [ 244.223043] Entry_SYSCALL_64_after_hwframe+0x77/0x7f [244.226458] QEPD: 0033:0x7ffa3eb8f059 [ 244.228582] Código: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f 1d 0d 00 f7 d8 64 89 01 48 [ 244.241307] RSP: 002b:00007ffa3e9c6eb8 EFLAGS: 00000206 ORIG_RAX: 0000000012e [ 244.246474] RAX: ffffffffffffffda RBX: 00007ffa3e9c7cdc RCX: 00007ffa3eb8f059 [ 244.250478] RDX: 00007ffa3eb162b4 RSI: 0000000000000000 RDI: 00007ffa3e9c7fb0 [ 244.255396] RBP: 00007ffa3e9c6ed0 R08: 00007ffa3e9c76c0 R 09: 0000000000000000 [ 244.260195] R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffff80 [ 244.264201] R13: 000000000000001c R 14: 00007ffc5d6b4260 R15: 00007ffa3e1c7000 [ 244.268303 ] Agregue un check_func_arg_reg_off() a la ruta en la que el verificador BPF verifica los argumentos de las funciones globales, específicamente aquellos que toman un argumento de tipo ARG_PTR_TO_DYNPTR | MEM_RDONLY. Además, Process_dynptr_func() no parece realizar ninguna coincidencia de tipos explícita y estricta en el tipo de registro proporcionado, por lo que también hagamos cumplir que un registro del tipo PTR_TO_STACK o CONST_PTR_TO_DYNPTR esté a cargo de la persona que llama.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: no permite configurar anchos de canal AP especiales. La configuración del ancho del canal AP está manipulada para usarse con la progresión normal de ancho de canal de 20/40/... MHz y alternar entre No se admiten S1G ni canales estrechos. No permitir eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: evite BUG_ON() mientras continúa la remodelación después del reensamblaje. Actualmente, mdadm admite --revert-reshape para cancelar la remodelación mientras se reensambla, como muestra la prueba 07revert-grow. Sin embargo, la prueba puede activar el siguiente BUG_ON(): kernel ERROR en drivers/md/raid5.c:6278! código de operación no válido: 0000 [#1] PREEMPT SMP PTI sello de evento irq: 158985 CPU: 6 PID: 891 Comm: md0_reshape No contaminado 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Seguimiento de llamadas: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 La causa principal es que --revert-resha pe actualizar los raid_disks de 5 a 4, mientras la posición de remodelación aún está establecida, y después de volver a ensamblar la matriz, la posición de remodelación se leerá desde el superbloque, luego, durante la remodelación, fallará la verificación de 'writepos' calculada por la posición de remodelación anterior. Primero solucione este pánico de la manera más fácil, convirtiendo BUG_ON() en WARN_ON() y detenga la remodelación si las comprobaciones fallan. Se señaló que mdadm también debe corregir --revert-shape, y probablemente md/raid también debería mejorar la validación de metadatos; sin embargo, esto significa que el reensamblaje fallará y debe haber herramientas de usuario para corregir los metadatos incorrectos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: idpf: corrige UAF al destruir las colas. La segunda confirmación etiquetada comenzaba a veces (muy raramente, pero posible) arrojando ADVERTENCIAS desde net/core/page_pool.c:page_pool_disable_direct_recycling(). Resultó que idpf libera los vectores de interrupción con NAPI incorporadas *antes* de liberar las colas, lo que hace que los punteros NAPI de page_pools conduzcan a la memoria liberada antes de que Libeth destruya estos grupos. No está claro si hay otros accesos a los vectores liberados al destruir las colas, pero de todos modos, generalmente liberamos vectores de cola/interrupción solo cuando las colas se destruyen y se garantiza que no se hará referencia a las NAPI en ninguna parte. Invierta la lógica de asignación y liberación haciendo que los vectores de cola/interrupción se asignen primero y se liberen al final. Los vectores no requieren la presencia de colas, por lo que esto es seguro. Además, este cambio permite eliminar esa cola inútil->limpieza del puntero q_vector, ya que los vectores siguen siendo válidos al liberar las colas (+ ambos se liberan dentro de una función, por lo que no está claro por qué anular los punteros).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la memoria fuera de los límites en bnxt_fill_hw_rss_tbl() Una confirmación reciente modificó el código en __bnxt_reserve_rings() para configurar la tabla de direccionamiento indirecto RSS predeterminada solo cuando el número de Los anillos RX están cambiando. Si bien esto funciona para firmware más nuevo que requiere reservas de anillo RX, provoca la regresión en firmware más antiguo que no requiere reservas de anillo RX (BNXT_NEW_RM() devuelve falso). Con firmware anterior, no se requieren reservas de anillo RX y, por lo tanto, hw_resc->resv_rx_rings no siempre está configurado en el valor adecuado. La comparación: if (old_rx_rings != bp->hw_resc.resv_rx_rings) en __bnxt_reserve_rings() puede ser falso incluso cuando los anillos RX están cambiando. Esto hará que __bnxt_reserve_rings() omita la configuración de la tabla de direccionamiento indirecto RSS predeterminada para que coincida con el número actual de anillos RX. Posteriormente, esto puede provocar que bnxt_fill_hw_rss_tbl() utilice un índice fuera de rango. Ya tenemos bnxt_check_rss_tbl_no_rmgr() para manejar exactamente este escenario. Solo necesitamos moverlo hacia arriba en bnxt_need_reserve_rings() para que se llame incondicionalmente cuando usemos firmware anterior. Sin la solución, si los anillos TX están cambiando, omitiremos la llamada a bnxt_check_rss_tbl_no_rmgr() y __bnxt_reserve_rings() también puede omitir la llamada a bnxt_set_dflt_rss_indir_tbl() por el motivo explicado en el último párrafo. Sin configurar la tabla de direccionamiento indirecto RSS predeterminada, se produce la regresión: ERROR: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40 Lectura de tamaño 2 en la dirección ffff8881c5809618 mediante la tarea ethtool/31525 Call Trace: __bnxt_hwrm_vnic_set_rss+0 xb79 /0xe40 bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460 __bnxt_setup_vnic_p5+0x12e/0x270 __bnxt_open_nic+0x2262/0x2f30 bnxt_open_nic+0x5d/0xf0 ethnl_set_channels+0x5d4/0 xb30 ethnl_default_set_doit+0x2f1/0x620

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mcast: espere los ciclos de gc anteriores al eliminar el puerto syzbot alcanzó un use-after-free [1] que se debe a que el puente no se asegura de que todos Se ha recogido basura anterior al eliminar un puerto. Lo que sucede es: CPU 1 CPU 2 iniciar el ciclo de gc eliminar el puerto adquirir el bloqueo de gc primero esperar la llamada de bloqueo br_multicasg_gc() adquirir directamente el bloqueo ahora pero liberar el puerto el puerto se puede liberar mientras los temporizadores de grp aún se ejecutan Asegúrese de que todos los ciclos de gc anteriores hayan finalizado usando flush_work antes de liberar el puerto. [1] ERROR: KASAN: slab-use-after-free en br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Lectura de tamaño 8 en la dirección ffff888071d6d000 por tarea syz.5.1232/9699 CPU: 1 PID: 9699 Comm : syz.5.1232 No contaminado 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c :88 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm /kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [en línea] __run_timers +0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [en línea] __run_timer_base kernel/time/timer.c:2421 [en línea] run_timer_base+0x111/0x190 kernel/time/timer. c:2437

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: sctp: corrige null-ptr-deref en reuseport_add_sock(). syzbot informó un null-ptr-deref al acceder a sk2->sk_reuseport_cb en reuseport_add_sock(). [0] La reproducción primero crea un oyente con SO_REUSEPORT. Luego, crea otro oyente en el mismo puerto y al mismo tiempo cierra el primer oyente. El segundo listen() llama a reuseport_add_sock() con el primer oyente como sk2, donde no se espera que sk2->sk_reuseport_cb se borre al mismo tiempo, pero close() lo borra mediante reuseport_detach_sock(). El problema es que SCTP no sincroniza correctamente reuseport_alloc(), reuseport_add_sock() y reuseport_detach_sock(). La persona que llama a reuseport_alloc() y reuseport_{add,detach}_sock() debe proporcionar sincronización para los sockets que están clasificados en el mismo grupo de reuseport. De lo contrario, dichos sockets forman múltiples grupos de reutilización idénticos y todos los grupos excepto uno quedarían silenciosamente muertos. 1. Dos sockets llaman a listening() simultáneamente 2. No se encuentra ningún socket en el mismo grupo en sctp_ep_hashtable[] 3. Dos sockets llaman a reuseport_alloc() y forman dos grupos de reuseport 4. Solo un grupo que llega primero en __sctp_rcv_lookup_endpoint() recibe paquetes entrantes también, podría producirse el null-ptr-deref informado. TCP/UDP garantiza que eso no sucederá si se mantiene el bloqueo del depósito hash. Apliquemos la estrategia de bloqueo a __sctp_hash_endpoint() y __sctp_unhash_endpoint(). [0]: Vaya: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 230 Comm: syz-executor119 No contaminado 6.10.0-syzkaller-12585-g301927d2d2eb #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/ sock_reuseport.c:350 Código: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 < 42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 X: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 00000000000000001 RDI: 0000000000000012 RBP : 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: ffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 : 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __sctp_hash_endpoint net/sctp/input.c:762 [en línea] sctp_hash_endpoint +0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [en línea] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [en línea ] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea] __se_sys_listen net/socket.c:1900 [en línea] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 arco x64/ x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Código: 28 00 00 00 75 05 8 83 c4 28 c3 e8 91 1a 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: power: Supply: rt5033: traer de vuelta i2c_set_clientdata Commit 3a93da231c12 ("power: Supply: rt5033: Use devm_power_supply_register() helper") reelaboró el controlador para usar devm. Mientras lo hacía, i2c_set_clientdata se eliminó junto con la devolución de llamada de eliminación. Desafortunadamente, otras partes del controlador también dependen de los datos del cliente i2c, por lo que esto provoca fallos en el kernel. Devuelva la llamada para reparar el controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/x86: intel-vbtn: protege el controlador de notificación ACPI contra la recursividad desde el commit e2ffcda16290 ("ACPI: OSL: permitir que los controladores Notify () se ejecuten en todas las CPU") Controladores de notificación ACPI como intel-vbtn notify_handler() puede ejecutarse en múltiples núcleos de CPU que compiten entre sí. Esta ejecución se ve afectada en las tabletas Dell Venue 7140 al desacoplarlas del teclado, lo que hace que el controlador intente registrar priv->switches_dev dos veces, como se puede ver en el mensaje dev_info() que se registra dos veces: [83.861800] intel-vbtn INT33D6: 00: Registro de conmutadores virtuales Intel input-dev después de recibir un evento de conmutador [ 83.861858] entrada: Conmutadores virtuales Intel como /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17 [ 83.861865] intel-vbtn INT33D6:00: Registro de conmutadores virtuales Intel input-dev después de recibir un evento de cambio Después del cual las cosas van muy mal: [83.861872] sysfs: no se puede crear un nombre de archivo duplicado '/devices/pci0000:00/0000:00:1f .0/PNP0C09:00/INT33D6:00/input/input17' ... [83.861967] kobject: kobject_add_internal falló para input17 con -EEXIST, no intente registrar cosas con el mismo nombre en el mismo directorio. [83.877338] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000018... Proteja intel-vbtn notify_handler() para que no corra consigo mismo con un mutex para solucionar este problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme: apple: corrige el recuento de referencias del dispositivo Los controladores deben llamar a nvme_uninit_ctrl después de un nvme_init_ctrl exitoso. Divida el lado de la asignación para que sea más fácil navegar por el límite de manejo de errores. El controlador de Apple había estado haciendo esto mal, perdiendo la memoria del dispositivo controlador debido a una falla en el conjunto de etiquetas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la desreferencia NULL al comprobar la banda al iniciar la sesión tx ba En la conexión MLD, link_data/link_conf se asignan dinámicamente. No apuntan a vif->bss_conf. Entonces, no habrá ningún chanreq asignado a vif->bss_conf y luego el chan será NULL. Modifique el código para verificar ht_supported/vht_supported/has_he/has_eht en sta deflink. Registro de fallos (con la versión rtw89 bajo desarrollo MLO): [9890.526087] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 [9890.526102] #PF: acceso de lectura del supervisor en modo kernel [9890.526105] #PF: error_code(0x0000) - no presente página [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Ups: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: cargado Contaminado: G OE 6.9.0 #1 [ 0010: ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminador 1)) mac80211 [ 9890.526279] Código: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 Todo el código ======== 0: f7 e8 imul %eax 2: d5 (malo) 3: 93 xchg %eax,%ebx 4: 3e ea ds (malo) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b : 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,( %rax) <-- instrucción de captura 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c : 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Código que comienza con la instrucción errónea ======================== ==================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 prueba %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP : 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 00000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] X: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 00000000000000000 R09: 0000000000000873 [ 9 890.526304] R10: ffff9308e0d64800 R11 : 000000000000000002 R12: FFFF9308E5FF6E70 [9890.526308] R13: FFFF930952500E20 R14: FFFF9309192A8C00 R15: 000000000000000000 [9890.526313] 4E700000 (0000) KNLGS: 000000000000000000 [9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 00000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Seguimiento de llamadas: [ 9890.526324] [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [9890.526335]? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [9890.526347]? search_module_extables (kernel/module/main.c:3256 (discriminador ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: corrige el desbordamiento en get_free_elt() "tracing_map->next_elt" en get_free_elt() corre el riesgo de desbordarse. Una vez que se desborda, aún se pueden insertar nuevos elementos en tracing_map aunque se haya alcanzado el número máximo de elementos (`max_elts`). Continuar insertando elementos después del desbordamiento podría dar como resultado que tracing_map contenga elementos "tracing_map->max_size", sin dejar entradas vacías. Si se intenta insertar un elemento en un tracing_map completo usando `__tracing_map_insert()`, se producirá un bucle infinito con la preferencia deshabilitada, lo que provocará un problema de bloqueo de la CPU. Solucione este problema evitando incrementos adicionales en "tracing_map->next_elt" una vez que llegue a "tracing_map->max_elt".