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 últimas 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 últimas 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 últimas vulnerabilidades incorporadas al repositorio.

CVE-2023-53194

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add length check in indx_get_root<br /> <br /> This adds a length check to guarantee the retrieved index root is legit.<br /> <br /> [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243<br /> [ 162.460851]<br /> [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42<br /> [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 162.462609] Call Trace:<br /> [ 162.462954] <br /> [ 162.463276] dump_stack_lvl+0x49/0x63<br /> [ 162.463822] print_report.cold+0xf5/0x689<br /> [ 162.464608] ? unwind_get_return_address+0x3a/0x60<br /> [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.466975] kasan_report+0xa7/0x130<br /> [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0<br /> [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.468536] __asan_load2+0x68/0x90<br /> [ 162.468923] hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.469282] ? cmp_uints+0xe0/0xe0<br /> [ 162.469557] ? cmp_sdh+0x90/0x90<br /> [ 162.469864] ? ni_find_attr+0x214/0x300<br /> [ 162.470217] ? ni_load_mi+0x80/0x80<br /> [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.470931] ? ntfs_bread_run+0x190/0x190<br /> [ 162.471307] ? indx_get_root+0xe4/0x190<br /> [ 162.471556] ? indx_get_root+0x140/0x190<br /> [ 162.471833] ? indx_init+0x1e0/0x1e0<br /> [ 162.472069] ? fnd_clear+0x115/0x140<br /> [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 162.472731] indx_find+0x184/0x470<br /> [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 162.474704] ? do_syscall_64+0x3b/0x90<br /> [ 162.474962] dir_search_u+0x196/0x2f0<br /> [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 162.475661] ? ntfs_security_init+0x3d6/0x440<br /> [ 162.475906] ? is_sd_valid+0x180/0x180<br /> [ 162.476191] ntfs_extend_init+0x13f/0x2c0<br /> [ 162.476496] ? ntfs_fix_post_read+0x130/0x130<br /> [ 162.476861] ? iput.part.0+0x286/0x320<br /> [ 162.477325] ntfs_fill_super+0x11e0/0x1b50<br /> [ 162.477709] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.477970] ? vsprintf+0x20/0x20<br /> [ 162.478258] ? set_blocksize+0x95/0x150<br /> [ 162.478538] get_tree_bdev+0x232/0x370<br /> [ 162.478789] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.479038] ntfs_fs_get_tree+0x15/0x20<br /> [ 162.479374] vfs_get_tree+0x4c/0x130<br /> [ 162.479729] path_mount+0x654/0xfe0<br /> [ 162.480124] ? putname+0x80/0xa0<br /> [ 162.480484] ? finish_automount+0x2e0/0x2e0<br /> [ 162.480894] ? putname+0x80/0xa0<br /> [ 162.481467] ? kmem_cache_free+0x1c4/0x440<br /> [ 162.482280] ? putname+0x80/0xa0<br /> [ 162.482714] do_mount+0xd6/0xf0<br /> [ 162.483264] ? path_mount+0xfe0/0xfe0<br /> [ 162.484782] ? __kasan_check_write+0x14/0x20<br /> [ 162.485593] __x64_sys_mount+0xca/0x110<br /> [ 162.486024] do_syscall_64+0x3b/0x90<br /> [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.487141] RIP: 0033:0x7f9d374e948a<br /> [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a<br /> [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0<br /> [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020<br /> [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0<br /> [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 162.493644] <br /> [ 162.493908]<br /> [ 162.494214] The buggy address belongs to the physical page:<br /> [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc<br /> [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000<br /> [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000<br /> [ 162.500542] page dumped becau<br /> ---truncated---
Gravedad CVSS v3.1: ALTA
Última modificación:
02/12/2025

CVE-2023-53193

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini<br /> <br /> The gmc.ecc_irq is enabled by firmware per IFWI setting,<br /> and the host driver is not privileged to enable/disable<br /> the interrupt. So, it is meaningless to use the amdgpu_irq_put<br /> function in gmc_v10_0_hw_fini, which also leads to the call<br /> trace.<br /> <br /> [ 82.340264] Call Trace:<br /> [ 82.340265] <br /> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]<br /> [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]<br /> [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]<br /> [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]<br /> [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]<br /> [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 82.341529] process_one_work+0x21d/0x3f0<br /> [ 82.341535] worker_thread+0x1fa/0x3c0<br /> [ 82.341538] ? process_one_work+0x3f0/0x3f0<br /> [ 82.341540] kthread+0xff/0x130<br /> [ 82.341544] ? kthread_complete_and_exit+0x20/0x20<br /> [ 82.341547] ret_from_fork+0x22/0x30
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53192

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix nexthop hash size<br /> <br /> The nexthop code expects a 31 bit hash, such as what is returned by<br /> fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash<br /> returned by skb_get_hash() can lead to problems related to the fact that<br /> &amp;#39;int hash&amp;#39; is a negative number when the MSB is set.<br /> <br /> In the case of hash threshold nexthop groups, nexthop_select_path_hthr()<br /> will disproportionately select the first nexthop group entry. In the case<br /> of resilient nexthop groups, nexthop_select_path_res() may do an out of<br /> bounds access in nh_buckets[], for example:<br /> hash = -912054133<br /> num_nh_buckets = 2<br /> bucket_index = 65535<br /> <br /> which leads to the following panic:<br /> <br /> BUG: unable to handle page fault for address: ffffc900025910c8<br /> PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:nexthop_select_path+0x197/0xbf0<br /> Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85<br /> RSP: 0018:ffff88810c36f260 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8<br /> RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219<br /> R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0<br /> R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900<br /> FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x1ee/0x5c0<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? search_bpf_extables+0xfe/0x1c0<br /> ? fixup_exception+0x3b/0x470<br /> ? exc_page_fault+0xf6/0x110<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? lock_is_held_type+0xe7/0x140<br /> vxlan_xmit+0x5b2/0x2340<br /> ? __lock_acquire+0x92b/0x3370<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_register_lock_class+0x10/0x10<br /> ? skb_network_protocol+0xce/0x2d0<br /> ? dev_hard_start_xmit+0xca/0x350<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> dev_hard_start_xmit+0xca/0x350<br /> __dev_queue_xmit+0x513/0x1e20<br /> ? __pfx___dev_queue_xmit+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? mark_held_locks+0x44/0x90<br /> ? skb_push+0x4c/0x80<br /> ? eth_header+0x81/0xe0<br /> ? __pfx_eth_header+0x10/0x10<br /> ? neigh_resolve_output+0x215/0x310<br /> ? ip6_finish_output2+0x2ba/0xc90<br /> ip6_finish_output2+0x2ba/0xc90<br /> ? lock_release+0x236/0x3e0<br /> ? ip6_mtu+0xbb/0x240<br /> ? __pfx_ip6_finish_output2+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? lock_is_held_type+0xe7/0x140<br /> ip6_finish_output+0x1ee/0x780<br /> ip6_output+0x138/0x460<br /> ? __pfx_ip6_output+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_ip6_finish_output+0x10/0x10<br /> NF_HOOK.constprop.0+0xc0/0x420<br /> ? __pfx_NF_HOOK.constprop.0+0x10/0x10<br /> ? ndisc_send_skb+0x2c0/0x960<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __local_bh_enable_ip+0x93/0x110<br /> ? lock_is_held_type+0xe7/0x140<br /> ndisc_send_skb+0x4be/0x960<br /> ? __pfx_ndisc_send_skb+0x10/0x10<br /> ? mark_held_locks+0x65/0x90<br /> ? find_held_lock+0x83/0xa0<br /> ndisc_send_ns+0xb0/0x110<br /> ? __pfx_ndisc_send_ns+0x10/0x10<br /> addrconf_dad_work+0x631/0x8e0<br /> ? lock_acquire+0x180/0x3f0<br /> ? __pfx_addrconf_dad_work+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> process_one_work+0x582/0x9c0<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> worker_thread+0x93/0x630<br /> ? __kthread_parkme+0xdc/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1a5/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x60<br /> <br /> ---truncated---
Gravedad CVSS v3.1: ALTA
Última modificación:
02/12/2025

CVE-2023-53191

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53190

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix memory leaks in error path<br /> <br /> The memory allocated by vxlan_vnigroup_init() is not freed in the error<br /> path, leading to memory leaks [1]. Fix by calling<br /> vxlan_vnigroup_uninit() in the error path.<br /> <br /> The leaks can be reproduced by annotating gro_cells_init() with<br /> ALLOW_ERROR_INJECTION() and then running:<br /> <br /> # echo "100" &gt; /sys/kernel/debug/fail_function/probability<br /> # echo "1" &gt; /sys/kernel/debug/fail_function/times<br /> # echo "gro_cells_init" &gt; /sys/kernel/debug/fail_function/inject<br /> # printf %#x -12 &gt; /sys/kernel/debug/fail_function/gro_cells_init/retval<br /> # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter<br /> RTNETLINK answers: Cannot allocate memory<br /> <br /> [1]<br /> unreferenced object 0xffff88810db84a00 (size 512):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............<br /> 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0x60<br /> [] vxlan_vnigroup_init+0x4c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90<br /> [] ___sys_sendmsg+0x13a/0x1e0<br /> [] __sys_sendmsg+0x11c/0x1f0<br /> [] do_syscall_64+0x38/0x80<br /> unreferenced object 0xffff88810e76d5f8 (size 192):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....<br /> 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x90<br /> [] kvmalloc_node+0xa6/0x1f0<br /> [] bucket_table_alloc.isra.0+0x83/0x460<br /> [] rhashtable_init+0x43b/0x7c0<br /> [] vxlan_vnigroup_init+0x6c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53189

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/addrconf: fix a potential refcount underflow for idev<br /> <br /> Now in addrconf_mod_rs_timer(), reference idev depends on whether<br /> rs_timer is not pending. Then modify rs_timer timeout.<br /> <br /> There is a time gap in [1], during which if the pending rs_timer<br /> becomes not pending. It will miss to hold idev, but the rs_timer<br /> is activated. Thus rs_timer callback function addrconf_rs_timer()<br /> will be executed and put idev later without holding idev. A refcount<br /> underflow issue for idev can be caused by this.<br /> <br /> if (!timer_pending(&amp;idev-&gt;rs_timer))<br /> in6_dev_hold(idev);<br /> rs_timer, jiffies + when);<br /> <br /> To fix the issue, hold idev if mod_timer() return 0.
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53188

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix race on port output<br /> <br /> assume the following setup on a single machine:<br /> 1. An openvswitch instance with one bridge and default flows<br /> 2. two network namespaces "server" and "client"<br /> 3. two ovs interfaces "server" and "client" on the bridge<br /> 4. for each ovs interface a veth pair with a matching name and 32 rx and<br /> tx queues<br /> 5. move the ends of the veth pairs to the respective network namespaces<br /> 6. assign ip addresses to each of the veth ends in the namespaces (needs<br /> to be the same subnet)<br /> 7. start some http server on the server network namespace<br /> 8. test if a client in the client namespace can reach the http server<br /> <br /> when following the actions below the host has a chance of getting a cpu<br /> stuck in a infinite loop:<br /> 1. send a large amount of parallel requests to the http server (around<br /> 3000 curls should work)<br /> 2. in parallel delete the network namespace (do not delete interfaces or<br /> stop the server, just kill the namespace)<br /> <br /> there is a low chance that this will cause the below kernel cpu stuck<br /> message. If this does not happen just retry.<br /> Below there is also the output of bpftrace for the functions mentioned<br /> in the output.<br /> <br /> The series of events happening here is:<br /> 1. the network namespace is deleted calling<br /> `unregister_netdevice_many_notify` somewhere in the process<br /> 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and<br /> then runs `synchronize_net`<br /> 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`<br /> 4. this is then handled by `dp_device_event` which calls<br /> `ovs_netdev_detach_dev` (if a vport is found, which is the case for<br /> the veth interface attached to ovs)<br /> 5. this removes the rx_handlers of the device but does not prevent<br /> packages to be sent to the device<br /> 6. `dp_device_event` then queues the vport deletion to work in<br /> background as a ovs_lock is needed that we do not hold in the<br /> unregistration path<br /> 7. `unregister_netdevice_many_notify` continues to call<br /> `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0<br /> 8. port deletion continues (but details are not relevant for this issue)<br /> 9. at some future point the background task deletes the vport<br /> <br /> If after 7. but before 9. a packet is send to the ovs vport (which is<br /> not deleted at this point in time) which forwards it to the<br /> `dev_queue_xmit` flow even though the device is unregistering.<br /> In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is<br /> a while loop (if the packet has a rx_queue recorded) that is infinite if<br /> `dev-&gt;real_num_tx_queues` is zero.<br /> <br /> To prevent this from happening we update `do_output` to handle devices<br /> without carrier the same as if the device is not found (which would<br /> be the code path after 9. is done).<br /> <br /> Additionally we now produce a warning in `skb_tx_hash` if we will hit<br /> the infinite loop.<br /> <br /> bpftrace (first word is function name):<br /> <br /> __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2<br /> ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2<br /> netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> dp_<br /> ---truncated---
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53196

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix potential memory leak<br /> <br /> Function dwc3_qcom_probe() allocates memory for resource structure<br /> which is pointed by parent_res pointer. This memory is not<br /> freed. This leads to memory leak. Use stack memory to prevent<br /> memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53183

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Gravedad CVSS v3.1: MEDIA
Última modificación:
05/01/2026

CVE-2023-53187

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free of new block group that became unused<br /> <br /> If a task creates a new block group and that block group becomes unused<br /> before we finish its creation, at btrfs_create_pending_block_groups(),<br /> then when btrfs_mark_bg_unused() is called against the block group, we<br /> assume that the block group is currently in the list of block groups to<br /> reclaim, and we move it out of the list of new block groups and into the<br /> list of unused block groups. This has two consequences:<br /> <br /> 1) We move it out of the list of new block groups associated to the<br /> current transaction. So the block group creation is not finished and<br /> if we attempt to delete the bg because it&amp;#39;s unused, we will not find<br /> the block group item in the extent tree (or the new block group tree),<br /> its device extent items in the device tree etc, resulting in the<br /> deletion to fail due to the missing items;<br /> <br /> 2) We don&amp;#39;t increment the reference count on the block group when we<br /> move it to the list of unused block groups, because we assumed the<br /> block group was on the list of block groups to reclaim, and in that<br /> case it already has the correct reference count. However the block<br /> group was on the list of new block groups, in which case no extra<br /> reference was taken because it&amp;#39;s local to the current task. This<br /> later results in doing an extra reference count decrement when<br /> removing the block group from the unused list, eventually leading the<br /> reference count to 0.<br /> <br /> This second case was caught when running generic/297 from fstests, which<br /> produced the following assertion failure and stack trace:<br /> <br /> [589.559] assertion failed: refcount_read(&amp;block_group-&gt;refs) == 1, in fs/btrfs/block-group.c:4299<br /> [589.559] ------------[ cut here ]------------<br /> [589.559] kernel BUG at fs/btrfs/block-group.c:4299!<br /> [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.561] Code: 68 62 da c0 (...)<br /> [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246<br /> [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000<br /> [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff<br /> [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50<br /> [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00<br /> [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100<br /> [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000<br /> [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0<br /> [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [589.564] Call Trace:<br /> [589.564] <br /> [589.565] ? __die_body+0x1b/0x60<br /> [589.565] ? die+0x39/0x60<br /> [589.565] ? do_trap+0xeb/0x110<br /> [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? do_error_trap+0x6a/0x90<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? exc_invalid_op+0x4e/0x70<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? asm_exc_invalid_op+0x16/0x20<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] close_ctree+0x35d/0x560 [btrfs]<br /> [589.568] ? fsnotify_sb_delete+0x13e/0x1d0<br /> [589.568] ? dispose_list+0x3a/0x50<br /> [589.568] ? evict_inodes+0x151/0x1a0<br /> [589.568] generic_shutdown_super+0x73/0x1a0<br /> [589.569] kill_anon_super+0x14/0x30<br /> [589.569] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [589.569] deactivate_locked<br /> ---truncated---
Gravedad CVSS v3.1: ALTA
Última modificación:
02/12/2025

CVE-2023-53186

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: Fix a race between coalescing and releasing SKBs<br /> <br /> Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment<br /> recycling") allowed coalescing to proceed with non page pool page and page<br /> pool page when @from is cloned, i.e.<br /> <br /> to-&gt;pp_recycle --&gt; false<br /> from-&gt;pp_recycle --&gt; true<br /> skb_cloned(from) --&gt; true<br /> <br /> However, it actually requires skb_cloned(@from) to hold true until<br /> coalescing finishes in this situation. If the other cloned SKB is<br /> released while the merging is in process, from_shinfo-&gt;nr_frags will be<br /> set to 0 toward the end of the function, causing the increment of frag<br /> page _refcount to be unexpectedly skipped resulting in inconsistent<br /> reference counts. Later when SKB(@to) is released, it frees the page<br /> directly even though the page pool page is still in use, leading to<br /> use-after-free or double-free errors. So it should be prohibited.<br /> <br /> The double-free error message below prompted us to investigate:<br /> BUG: Bad page state in process swapper/1 pfn:0e0d1<br /> page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000<br /> index:0x2 pfn:0xe0d1<br /> flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000<br /> raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000<br /> page dumped because: nonzero _refcount<br /> <br /> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> bad_page+0x69/0xf0<br /> free_pcp_prepare+0x260/0x2f0<br /> free_unref_page+0x20/0x1c0<br /> skb_release_data+0x10b/0x1a0<br /> napi_consume_skb+0x56/0x150<br /> net_rx_action+0xf0/0x350<br /> ? __napi_schedule+0x79/0x90<br /> __do_softirq+0xc8/0x2b1<br /> __irq_exit_rcu+0xb9/0xf0<br /> common_interrupt+0x82/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:default_idle+0xb/0x20
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025

CVE-2023-53185

Fecha de publicación:
15/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: don&amp;#39;t allow to overwrite ENDPOINT0 attributes<br /> <br /> A bad USB device is able to construct a service connection response<br /> message with target endpoint being ENDPOINT0 which is reserved for<br /> HTC_CTRL_RSVD_SVC and should not be modified to be used for any other<br /> services.<br /> <br /> Reject such service connection responses.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/12/2025