Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: adv7842: Evitar posibles accesos a arrays fuera de límites en adv7842_cp_log_status()<br /> <br /> Es posible que cp_read() y hdmi_read() devuelvan -EIO. Esos valores se utilizan además como índices para acceder a arrays.<br /> <br /> Solucionar esto comprobando los valores de retorno donde sea necesario.<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeontx2-pf: corrige el &amp;#39;UBSAN: shift-out-of-bounds error&amp;#39;<br /> <br /> Este parche asegura que el tamaño del anillo RX (rx_pending) no se establezca por debajo de la longitud permitida. Esto evita errores de UBSAN shift-out-of-bounds cuando los usuarios pasan tamaños de anillo pequeños o cero a través de ethtool -G.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/msm/dpu: Añadir comprobación de puntero NULL faltante para la interfaz pingpong<br /> <br /> Se comprueba casi siempre en dpu_encoder_phys_wb_setup_ctl(), pero en un solo lugar falta la comprobación.<br /> También usar variables locales convenientes en lugar de phys_enc-&amp;gt;* donde esté disponible.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/693860/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> kernel/kexec: corregir IMA cuando la asignación se produce en el área CMA<br /> <br /> * Descripción del error *<br /> <br /> Cuando probé kexec con el kernel más reciente, me encontré con la siguiente advertencia:<br /> <br /> [ 40.712410] ------------[ cut here ]------------<br /> [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198<br /> [...]<br /> [ 40.816047] Call trace:<br /> [ 40.818498] kimage_map_segment+0x144/0x198 (P)<br /> [ 40.823221] ima_kexec_post_load+0x58/0xc0<br /> [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368<br /> [...]<br /> [ 40.855423] ---[ end trace 0000000000000000 ]---<br /> <br /> * Cómo reproducir *<br /> <br /> Este error solo se activa cuando la dirección de destino de kexec se asigna en el área CMA. Si no se reserva ningún área CMA en el kernel, use la opción &amp;#39;cma=&amp;#39; en la línea de comandos del kernel para reservar una.<br /> <br /> * Causa raíz *<br /> El commit 07d24902977e (&amp;#39;kexec: habilitar asignación contigua basada en CMA&amp;#39;) asigna la dirección de destino de kexec directamente en el área CMA para evitar la copia durante el salto. En este caso, no hay IND_SOURCE para el segmento kexec. Pero la implementación actual de kimage_map_segment() asume que las páginas IND_SOURCE existen y las mapea en una dirección virtual contigua mediante vmap().<br /> <br /> * Solución *<br /> Si el segmento IMA se asigna en el área CMA, use su page_address() directamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/tilcdc: Corrige las acciones de eliminación en caso de fallo de la sonda<br /> <br /> Las funciones auxiliares drm_kms_helper_poll_fini() y drm_atomic_helper_shutdown() solo deben ser llamadas cuando el dispositivo ha sido registrado exitosamente. Actualmente, estas funciones son llamadas incondicionalmente en tilcdc_fini(), lo que causa advertencias durante escenarios de aplazamiento de sonda.<br /> <br /> [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68<br /> ...<br /> [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108<br /> [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8<br /> [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144<br /> [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]<br /> [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]<br /> <br /> Soluciona esto reescribiendo la ruta de limpieza de la sonda fallida utilizando el patrón estándar de manejo de errores goto, lo que asegura que las funciones de limpieza solo sean llamadas en recursos inicializados exitosamente. Además, elimina la bandera is_registered ahora innecesaria.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: change all pageblocks migrate type on coalescing<br /> <br /> When a page is freed it coalesces with a buddy into a higher order page<br /> while possible. When the buddy page migrate type differs, it is expected<br /> to be updated to match the one of the page being freed.<br /> <br /> However, only the first pageblock of the buddy page is updated, while the<br /> rest of the pageblocks are left unchanged.<br /> <br /> That causes warnings in later expand() and other code paths (like below),<br /> since an inconsistency between migration type of the list containing the<br /> page and the page-owned pageblocks migration types is introduced.<br /> <br /> [ 308.986589] ------------[ cut here ]------------<br /> [ 308.987227] page type is 0, passed migratetype is 1 (nr=256)<br /> [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270<br /> [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)<br /> [ 308.987439] Unloaded tainted modules: hmac_s390(E):2<br /> [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT<br /> [ 308.987657] Tainted: [E]=UNSIGNED_MODULE<br /> [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)<br /> [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)<br /> [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3<br /> [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88<br /> [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300<br /> [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008<br /> [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0<br /> [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4<br /> 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60<br /> #00000349976fa5fc: af000000 mc 0,0<br /> &gt;00000349976fa600: a7f4ff4c brc 15,00000349976fa498<br /> 00000349976fa604: b9040026 lgr %r2,%r6<br /> 00000349976fa608: c0300088317f larl %r3,0000034998800906<br /> 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0<br /> 00000349976fa614: af000000 mc 0,0<br /> [ 308.987734] Call Trace:<br /> [ 308.987738] [] expand+0x240/0x270<br /> [ 308.987744] ([] expand+0x23c/0x270)<br /> [ 308.987749] [] rmqueue_bulk+0x71e/0x940<br /> [ 308.987754] [] __rmqueue_pcplist+0x1fe/0x2a0<br /> [ 308.987759] [] rmqueue.isra.0+0xb46/0xf40<br /> [ 308.987763] [] get_page_from_freelist+0x198/0x8d0<br /> [ 308.987768] [] __alloc_frozen_pages_noprof+0x198/0x400<br /> [ 308.987774] [] alloc_pages_mpol+0xb8/0x220<br /> [ 308.987781] [] folio_alloc_mpol_noprof+0x26/0xc0<br /> [ 308.987786] [] vma_alloc_folio_noprof+0x6c/0xa0<br /> [ 308.987791] [] vma_alloc_anon_folio_pmd+0x42/0x240<br /> [ 308.987799] [] __do_huge_pmd_anonymous_page+0x3a/0x210<br /> [ 308.987804] [

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: mediatek: vcodec: Usar spinlock para el bloqueo de protección de la lista de contextos<br /> <br /> Anteriormente se añadió un mutex para proteger las listas de contextos del codificador y decodificador de cambios inesperados originados por el bloque IP SCP, haciendo que el puntero de contexto se volviera inválido, resultando en una desreferencia de puntero NULL en el manejador IPI.<br /> <br /> Resulta que en el MT8173, el manejador IPI de la VPU es llamado desde el contexto de IRQ duro. Esto causa una gran advertencia del planificador. Esto fue reportado por primera vez en versiones derivadas en los kernels de ChromeOS, pero también es reproducible en la rama principal usando Fluster con los decodificadores FFmpeg v4l2m2m. Aunque el formato de captura real no es compatible, las rutas de código afectadas se activan.<br /> <br /> Dado que este bloqueo solo protege la lista de contextos y las operaciones sobre ella son muy rápidas, debería estar bien cambiar a un spinlock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ext4: corrige la copia de cadenas en parse_apply_sb_mount_options()<br /> <br /> strscpy_pad() no puede usarse para copiar una cadena no terminada en NUL en una cadena terminada en NUL de tamaño posiblemente mayor. El commit 0efc5990bca5 (&amp;#39;string.h: Introduce memtostr() y memtostr_pad()&amp;#39;) proporciona información adicional al respecto. Así que si esto ocurre, se observa la siguiente advertencia:<br /> <br /> strnlen: desbordamiento de búfer detectado: lectura de 65 bytes de un búfer de tamaño 64<br /> ADVERTENCIA: CPU: 0 PID: 28655 en lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032<br /> Módulos enlazados:<br /> CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 No contaminado 6.12.54-syzkaller-00144-g5f0270f1ba00 #0<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032<br /> Traza de llamada:<br /> <br /> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039<br /> strnlen include/linux/fortify-string.h:235 [en línea]<br /> sized_strscpy include/linux/fortify-string.h:309 [en línea]<br /> parse_apply_sb_mount_options fs/ext4/super.c:2504 [en línea]<br /> __ext4_fill_super fs/ext4/super.c:5261 [en línea]<br /> ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706<br /> get_tree_bdev_flags+0x387/0x620 fs/super.c:1636<br /> vfs_get_tree+0x93/0x380 fs/super.c:1814<br /> do_new_mount fs/namespace.c:3553 [en línea]<br /> path_mount+0x6ae/0x1f70 fs/namespace.c:3880<br /> do_mount fs/namespace.c:3893 [en línea]<br /> __do_sys_mount fs/namespace.c:4103 [en línea]<br /> __se_sys_mount fs/namespace.c:4080 [en línea]<br /> __x64_sys_mount+0x280/0x300 fs/namespace.c:4080<br /> do_syscall_x64 arch/x86/entry/common.c:52 [en línea]<br /> do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Dado que se espera que el espacio de usuario proporcione el campo s_mount_opts de una longitud máxima de 63 caracteres con el byte final terminado en NUL, use un búfer de 64 bytes que coincida con el tamaño de s_mount_opts, para que strscpy_pad() realice su trabajo correctamente. Devuelve un error si el usuario aún logró proporcionar una cadena no terminada en NUL aquí.<br /> <br /> Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/msm/a6xx: mover preempt_prepare_postamble después de la verificación de errores<br /> <br /> Mover la llamada a preempt_prepare_postamble() después de verificar que preempt_postamble_ptr es válido. Si preempt_postamble_ptr es NULL, desreferenciarlo en preempt_prepare_postamble() llevaría a un fallo.<br /> <br /> Este cambio evita llamar a la función de preparación cuando la asignación del postámbulo ha fallado, previniendo la desreferencia potencial de puntero NULL y asegurando un manejo de errores adecuado.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/687659/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tracing: No registrar eventos perf no soportados<br /> <br /> Los eventos sintéticos actualmente no tienen una función para registrar eventos perf.<br /> Esto lleva a llamar a las funciones de registro de tracepoint con un puntero de función NULL lo que dispara:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:tracepoint_add_func+0x357/0x370<br /> Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc &amp;lt;0f&amp;gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f<br /> RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000<br /> RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8<br /> RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780<br /> R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a<br /> R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78<br /> FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> tracepoint_probe_register+0x5d/0x90<br /> synth_event_reg+0x3c/0x60<br /> perf_trace_event_init+0x204/0x340<br /> perf_trace_init+0x85/0xd0<br /> perf_tp_event_init+0x2e/0x50<br /> perf_try_init_event+0x6f/0x230<br /> ? perf_event_alloc+0x4bb/0xdc0<br /> perf_event_alloc+0x65a/0xdc0<br /> __se_sys_perf_event_open+0x290/0x9f0<br /> do_syscall_64+0x93/0x7b0<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ? trace_hardirqs_off+0x53/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> En su lugar, hacer que el código devuelva -ENODEV, lo que no genera una advertencia y hace que perf falle con un error:<br /> <br /> # perf record -e synthetic:futex_wait<br /> Error:<br /> The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).<br /> "dmesg | grep -i perf" may provide additional information.<br /> <br /> Idealmente, perf debería soportar eventos sintéticos, pero por ahora solo hay que corregir la advertencia. El soporte puede venir después.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mptcp: evitar interbloqueo en el fallback mientras se reinjecta<br /> <br /> Jakub informó un interbloqueo MPTCP en el momento del fallback:<br /> <br /> WARNING: possible recursive locking detected<br /> 6.18.0-rc7-virtme #1 Not tainted<br /> --------------------------------------------<br /> mptcp_connect/20858 is trying to acquire lock:<br /> ff1100001da18b60 (&amp;amp;msk-&amp;gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280<br /> <br /> but task is already holding lock:<br /> ff1100001da18b60 (&amp;amp;msk-&amp;gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;amp;msk-&amp;gt;fallback_lock);<br /> lock(&amp;amp;msk-&amp;gt;fallback_lock);<br /> <br /> * DEADLOCK *<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by mptcp_connect/20858:<br /> #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0<br /> #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0<br /> #2: ff1100001da18b60 (&amp;amp;msk-&amp;gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)<br /> Hardware name: Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_deadlock_bug.cold+0xc0/0xcd<br /> validate_chain+0x2ff/0x5f0<br /> __lock_acquire+0x34c/0x740<br /> lock_acquire.part.0+0xbc/0x260<br /> _raw_spin_lock_bh+0x38/0x50<br /> __mptcp_try_fallback+0xd8/0x280<br /> mptcp_sendmsg_frag+0x16c2/0x3050<br /> __mptcp_retrans+0x421/0xaa0<br /> mptcp_release_cb+0x5aa/0xa70<br /> release_sock+0xab/0x1d0<br /> mptcp_sendmsg+0xd5b/0x1bc0<br /> sock_write_iter+0x281/0x4d0<br /> new_sync_write+0x3c5/0x6f0<br /> vfs_write+0x65e/0xbb0<br /> ksys_write+0x17e/0x200<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fa5627cbc5e<br /> Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa<br /> RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e<br /> RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005<br /> RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920<br /> R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c<br /> <br /> El planificador de paquetes podría intentar una reinyección después de recibir un MP_FAIL y antes de que se haya transmitido el mapa infinito, causando un interbloqueo ya que MPTCP necesita realizar la reinyección atómicamente con respecto al fallback.<br /> <br /> Abordar el problema evitando explícitamente la reinyección en el escenario crítico. Tenga en cuenta que esta es la única sección crítica de fallback que podría potencialmente enviar paquetes y alcanzar el doble bloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211: Descartar tramas Beacon a direcciones que no son de difusión<br /> <br /> Las tramas Beacon deben ser enviadas a la dirección de difusión, véase IEEE Std 802.11-2020, 11.1.3.1 (&amp;#39;El campo Dirección 1 de la trama Beacon .. debe establecerse a la dirección de difusión&amp;#39;). Una trama Beacon unicast podría ser utilizada como un ataque dirigido para que una de las STA asociadas haga algo (por ejemplo, usando CSA para moverla a otro canal). Por lo tanto, es mejor tener un filtrado estricto para esto en el lado de recepción y descartar todas las tramas Beacon que se envían a una dirección inesperada.<br /> <br /> Esto es aún más importante para los casos en que se utiliza la protección de balizas. La implementación actual en mac80211 está descartando correctamente las tramas Beacon unicast si el bit de Trama Protegida en el campo de Control de Trama se establece en 0. Sin embargo, si ese bit se establece en 1, la lógica utilizada para verificar los BIGTK(s) configurados no funciona realmente. Si el controlador no tiene lógica para descartar tramas Beacon unicast con el bit de Trama Protegida en 1, estas tramas serían aceptadas en el procesamiento de mac80211 como tramas Beacon válidas aunque no estén protegidas. Esto permitiría que la protección de balizas fuera eludida. Aunque la lógica para verificar la protección de balizas podría extenderse para cubrir este caso particular, una verificación más genérica para descartar todas las tramas Beacon basada en A1=dirección unicast cubre esto sin necesidad de cambios adicionales.<br /> <br /> Abordar todos estos problemas descartando las tramas Beacon recibidas si se envían a una dirección que no es de difusión.