Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2025-39859

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog<br /> <br /> The ptp_ocp_detach() only shuts down the watchdog timer if it is<br /> pending. However, if the timer handler is already running, the<br /> timer_delete_sync() is not called. This leads to race conditions<br /> where the devlink that contains the ptp_ocp is deallocated while<br /> the timer handler is still accessing it, resulting in use-after-free<br /> bugs. The following details one of the race scenarios.<br /> <br /> (thread 1) | (thread 2)<br /> ptp_ocp_remove() |<br /> ptp_ocp_detach() | ptp_ocp_watchdog()<br /> if (timer_pending(&amp;bp-&gt;watchdog))| bp = timer_container_of()<br /> timer_delete_sync() |<br /> |<br /> devlink_free(devlink) //free |<br /> | bp-&gt; //use<br /> <br /> Resolve this by unconditionally calling timer_delete_sync() to ensure<br /> the timer is reliably deactivated, preventing any access after free.
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39860

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()<br /> <br /> syzbot reported the splat below without a repro.<br /> <br /> In the splat, a single thread calling bt_accept_dequeue() freed sk<br /> and touched it after that.<br /> <br /> The root cause would be the racy l2cap_sock_cleanup_listen() call<br /> added by the cited commit.<br /> <br /> bt_accept_dequeue() is called under lock_sock() except for<br /> l2cap_sock_release().<br /> <br /> Two threads could see the same socket during the list iteration<br /> in bt_accept_dequeue():<br /> <br /> CPU1 CPU2 (close())<br /> ---- ----<br /> sock_hold(sk) sock_hold(sk);<br /> lock_sock(sk)
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39843

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: slub: avoid wake up kswapd in set_track_prepare<br /> <br /> set_track_prepare() can incur lock recursion.<br /> The issue is that it is called from hrtimer_start_range_ns<br /> holding the per_cpu(hrtimer_bases)[n].lock, but when enabled<br /> CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,<br /> and try to hold the per_cpu(hrtimer_bases)[n].lock.<br /> <br /> Avoid deadlock caused by implicitly waking up kswapd by passing in<br /> allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the<br /> debug_objects_fill_pool() case. Inside stack depot they are processed by<br /> gfp_nested_mask().<br /> Since ___slab_alloc() has preemption disabled, we mask out<br /> __GFP_DIRECT_RECLAIM from the flags there.<br /> <br /> The oops looks something like:<br /> <br /> BUG: spinlock recursion on CPU#3, swapper/3/0<br /> lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3<br /> Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)<br /> Call trace:<br /> spin_bug+0x0<br /> _raw_spin_lock_irqsave+0x80<br /> hrtimer_try_to_cancel+0x94<br /> task_contending+0x10c<br /> enqueue_dl_entity+0x2a4<br /> dl_server_start+0x74<br /> enqueue_task_fair+0x568<br /> enqueue_task+0xac<br /> do_activate_task+0x14c<br /> ttwu_do_activate+0xcc<br /> try_to_wake_up+0x6c8<br /> default_wake_function+0x20<br /> autoremove_wake_function+0x1c<br /> __wake_up+0xac<br /> wakeup_kswapd+0x19c<br /> wake_all_kswapds+0x78<br /> __alloc_pages_slowpath+0x1ac<br /> __alloc_pages_noprof+0x298<br /> stack_depot_save_flags+0x6b0<br /> stack_depot_save+0x14<br /> set_track_prepare+0x5c<br /> ___slab_alloc+0xccc<br /> __kmalloc_cache_noprof+0x470<br /> __set_page_owner+0x2bc<br /> post_alloc_hook[jt]+0x1b8<br /> prep_new_page+0x28<br /> get_page_from_freelist+0x1edc<br /> __alloc_pages_noprof+0x13c<br /> alloc_slab_page+0x244<br /> allocate_slab+0x7c<br /> ___slab_alloc+0x8e8<br /> kmem_cache_alloc_noprof+0x450<br /> debug_objects_fill_pool+0x22c<br /> debug_object_activate+0x40<br /> enqueue_hrtimer[jt]+0xdc<br /> hrtimer_start_range_ns+0x5f8<br /> ...
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39844

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: move page table sync declarations to linux/pgtable.h<br /> <br /> During our internal testing, we started observing intermittent boot<br /> failures when the machine uses 4-level paging and has a large amount of<br /> persistent memory:<br /> <br /> BUG: unable to handle page fault for address: ffffe70000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0 <br /> Oops: 0002 [#1] SMP NOPTI<br /> RIP: 0010:__init_single_page+0x9/0x6d<br /> Call Trace:<br /> <br /> __init_zone_device_page+0x17/0x5d<br /> memmap_init_zone_device+0x154/0x1bb<br /> pagemap_range+0x2e0/0x40f<br /> memremap_pages+0x10b/0x2f0<br /> devm_memremap_pages+0x1e/0x60<br /> dev_dax_probe+0xce/0x2ec [device_dax]<br /> dax_bus_probe+0x6d/0xc9<br /> [... snip ...]<br /> <br /> <br /> It turns out that the kernel panics while initializing vmemmap (struct<br /> page array) when the vmemmap region spans two PGD entries, because the new<br /> PGD entry is only installed in init_mm.pgd, but not in the page tables of<br /> other tasks.<br /> <br /> And looking at __populate_section_memmap():<br /> if (vmemmap_can_optimize(altmap, pgmap)) <br /> // does not sync top level page tables<br /> r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);<br /> else <br /> // sync top level page tables in x86<br /> r = vmemmap_populate(start, end, nid, altmap);<br /> <br /> In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c<br /> synchronizes the top level page table (See commit 9b861528a801 ("x86-64,<br /> mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so<br /> that all tasks in the system can see the new vmemmap area.<br /> <br /> However, when vmemmap_can_optimize() returns true, the optimized path<br /> skips synchronization of top-level page tables. This is because<br /> vmemmap_populate_compound_pages() is implemented in core MM code, which<br /> does not handle synchronization of the top-level page tables. Instead,<br /> the core MM has historically relied on each architecture to perform this<br /> synchronization manually.<br /> <br /> We&amp;#39;re not the first party to encounter a crash caused by not-sync&amp;#39;d top<br /> level page tables: earlier this year, Gwan-gyeong Mun attempted to address<br /> the issue [1] [2] after hitting a kernel panic when x86 code accessed the<br /> vmemmap area before the corresponding top-level entries were synced. At<br /> that time, the issue was believed to be triggered only when struct page<br /> was enlarged for debugging purposes, and the patch did not get further<br /> updates.<br /> <br /> It turns out that current approach of relying on each arch to handle the<br /> page table sync manually is fragile because 1) it&amp;#39;s easy to forget to sync<br /> the top level page table, and 2) it&amp;#39;s also easy to overlook that the<br /> kernel should not access the vmemmap and direct mapping areas before the<br /> sync.<br /> <br /> # The solution: Make page table sync more code robust and harder to miss<br /> <br /> To address this, Dave Hansen suggested [3] [4] introducing<br /> {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables<br /> and allow each architecture to explicitly perform synchronization when<br /> installing top-level entries. With this approach, we no longer need to<br /> worry about missing the sync step, reducing the risk of future<br /> regressions.<br /> <br /> The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,<br /> PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by<br /> vmalloc and ioremap to synchronize page tables.<br /> <br /> pgd_populate_kernel() looks like this:<br /> static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,<br /> p4d_t *p4d)<br /> {<br /> pgd_populate(&amp;init_mm, pgd, p4d);<br /> if (ARCH_PAGE_TABLE_SYNC_MASK &amp; PGTBL_PGD_MODIFIED)<br /> arch_sync_kernel_mappings(addr, addr);<br /> }<br /> <br /> It is worth noting that vmalloc() and apply_to_range() carefully<br /> synchronizes page tables by calling p*d_alloc_track() and<br /> arch_sync_kernel_mappings(), and thus they are not affected by<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39845

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()<br /> <br /> Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure<br /> page tables are properly synchronized when calling p*d_populate_kernel().<br /> <br /> For 5-level paging, synchronization is performed via<br /> pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so<br /> synchronization is instead performed at the P4D level via<br /> p4d_populate_kernel().<br /> <br /> This fixes intermittent boot failures on systems using 4-level paging and<br /> a large amount of persistent memory:<br /> <br /> BUG: unable to handle page fault for address: ffffe70000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP NOPTI<br /> RIP: 0010:__init_single_page+0x9/0x6d<br /> Call Trace:<br /> <br /> __init_zone_device_page+0x17/0x5d<br /> memmap_init_zone_device+0x154/0x1bb<br /> pagemap_range+0x2e0/0x40f<br /> memremap_pages+0x10b/0x2f0<br /> devm_memremap_pages+0x1e/0x60<br /> dev_dax_probe+0xce/0x2ec [device_dax]<br /> dax_bus_probe+0x6d/0xc9<br /> [... snip ...]<br /> <br /> <br /> It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap<br /> before sync_global_pgds() [1]:<br /> <br /> BUG: unable to handle page fault for address: ffffeb3ff1200000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> Tainted: [W]=WARN<br /> RIP: 0010:vmemmap_set_pmd+0xff/0x230<br /> <br /> vmemmap_populate_hugepages+0x176/0x180<br /> vmemmap_populate+0x34/0x80<br /> __populate_section_memmap+0x41/0x90<br /> sparse_add_section+0x121/0x3e0<br /> __add_pages+0xba/0x150<br /> add_pages+0x1d/0x70<br /> memremap_pages+0x3dc/0x810<br /> devm_memremap_pages+0x1c/0x60<br /> xe_devm_add+0x8b/0x100 [xe]<br /> xe_tile_init_noalloc+0x6a/0x70 [xe]<br /> xe_device_probe+0x48c/0x740 [xe]<br /> [... snip ...]
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39846

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()<br /> <br /> In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to<br /> res and used in pci_bus_alloc_resource(). There is a dereference of res<br /> in pci_bus_alloc_resource(), which could lead to a NULL pointer<br /> dereference on failure of pcmcia_make_resource().<br /> <br /> Fix this bug by adding a check of res.
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39847

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: fix memory leak in pad_compress_skb<br /> <br /> If alloc_skb() fails in pad_compress_skb(), it returns NULL without<br /> releasing the old skb. The caller does:<br /> <br /> skb = pad_compress_skb(ppp, skb);<br /> if (!skb)<br /> goto drop;<br /> <br /> drop:<br /> kfree_skb(skb);<br /> <br /> When pad_compress_skb() returns NULL, the reference to the old skb is<br /> lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.<br /> <br /> Align pad_compress_skb() semantics with realloc(): only free the old<br /> skb if allocation and compression succeed. At the call site, use the<br /> new_skb variable so the original skb is not lost when pad_compress_skb()<br /> fails.
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39848

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: properly unshare skbs in ax25_kiss_rcv()<br /> <br /> Bernard Pidoux reported a regression apparently caused by commit<br /> c353e8983e0d ("net: introduce per netns packet chains").<br /> <br /> skb-&gt;dev becomes NULL and we crash in __netif_receive_skb_core().<br /> <br /> Before above commit, different kind of bugs or corruptions could happen<br /> without a major crash.<br /> <br /> But the root cause is that ax25_kiss_rcv() can queue/mangle input skb<br /> without checking if this skb is shared or not.<br /> <br /> Many thanks to Bernard Pidoux for his help, diagnosis and tests.<br /> <br /> We had a similar issue years ago fixed with commit 7aaed57c5c28<br /> ("phonet: properly unshare skbs in phonet_rcv()").
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39849

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()<br /> <br /> If the ssid-&gt;datalen is more than IEEE80211_MAX_SSID_LEN (32) it would<br /> lead to memory corruption so add some bounds checking.
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39850

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects<br /> <br /> When the "proxy" option is enabled on a VXLAN device, the device will<br /> suppress ARP requests and IPv6 Neighbor Solicitation messages if it is<br /> able to reply on behalf of the remote host. That is, if a matching and<br /> valid neighbor entry is configured on the VXLAN device whose MAC address<br /> is not behind the "any" remote (0.0.0.0 / ::).<br /> <br /> The code currently assumes that the FDB entry for the neighbor&amp;#39;s MAC<br /> address points to a valid remote destination, but this is incorrect if<br /> the entry is associated with an FDB nexthop group. This can result in a<br /> NPD [1][3] which can be reproduced using [2][4].<br /> <br /> Fix by checking that the remote destination exists before dereferencing<br /> it.<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014<br /> RIP: 0010:vxlan_xmit+0xb58/0x15f0<br /> [...]<br /> Call Trace:<br /> <br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> packet_sendmsg+0x113a/0x1850<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> ip address add 192.0.2.1/32 dev lo<br /> <br /> ip nexthop add id 1 via 192.0.2.2 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy<br /> <br /> ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10<br /> <br /> arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3<br /> <br /> [3]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014<br /> RIP: 0010:vxlan_xmit+0x803/0x1600<br /> [...]<br /> Call Trace:<br /> <br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> ip6_finish_output2+0x210/0x6c0<br /> ip6_finish_output+0x1af/0x2b0<br /> ip6_mr_output+0x92/0x3e0<br /> ip6_send_skb+0x30/0x90<br /> rawv6_sendmsg+0xe6e/0x12e0<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f383422ec77<br /> <br /> [4]<br /> #!/bin/bash<br /> <br /> ip address add 2001:db8:1::1/128 dev lo<br /> <br /> ip nexthop add id 1 via 2001:db8:1::1 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy<br /> <br /> ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10<br /> <br /> ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-39851

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix NPD when refreshing an FDB entry with a nexthop object<br /> <br /> VXLAN FDB entries can point to either a remote destination or an FDB<br /> nexthop group. The latter is usually used in EVPN deployments where<br /> learning is disabled.<br /> <br /> However, when learning is enabled, an incoming packet might try to<br /> refresh an FDB entry that points to an FDB nexthop group and therefore<br /> does not have a remote. Such packets should be dropped, but they are<br /> only dropped after dereferencing the non-existent remote, resulting in a<br /> NPD [1] which can be reproduced using [2].<br /> <br /> Fix by dropping such packets earlier. Remove the misleading comment from<br /> first_remote_rcu().<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014<br /> RIP: 0010:vxlan_snoop+0x98/0x1e0<br /> [...]<br /> Call Trace:<br /> <br /> vxlan_encap_bypass+0x209/0x240<br /> encap_bypass_if_local+0xb1/0x100<br /> vxlan_xmit_one+0x1375/0x17e0<br /> vxlan_xmit+0x6b4/0x15f0<br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> packet_sendmsg+0x113a/0x1850<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> ip address add 192.0.2.1/32 dev lo<br /> ip address add 192.0.2.2/32 dev lo<br /> <br /> ip nexthop add id 1 via 192.0.2.3 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass<br /> ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020<br /> bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10<br /> <br /> mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q
Gravedad: Pendiente de análisis
Última modificación:
19/09/2025

CVE-2025-10718

Fecha de publicación:
19/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** A vulnerability was found in Ooma Office Business Phone App up to 7.2.2 on Android. This affects an unknown part of the component com.ooma.office2. The manipulation results in improper export of android application components. The attack needs to be approached locally. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.
Gravedad CVSS v4.0: MEDIA
Última modificación:
19/09/2025