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-40257

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix a race in mptcp_pm_del_add_timer()<br /> <br /> mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &amp;entry-&gt;add_timer)<br /> while another might have free entry already, as reported by syzbot.<br /> <br /> Add RCU protection to fix this issue.<br /> <br /> Also change confusing add_timer variable with stop_timer boolean.<br /> <br /> syzbot report:<br /> <br /> BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616<br /> Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44<br /> <br /> CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Workqueue: events mptcp_worker<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616<br /> sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631<br /> mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362<br /> mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174<br /> tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361<br /> tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441<br /> tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931<br /> tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374<br /> ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239<br /> NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318<br /> NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318<br /> __netif_receive_skb_one_core net/core/dev.c:6079 [inline]<br /> __netif_receive_skb+0x143/0x380 net/core/dev.c:6192<br /> process_backlog+0x31e/0x900 net/core/dev.c:6544<br /> __napi_poll+0xb6/0x540 net/core/dev.c:7594<br /> napi_poll net/core/dev.c:7657 [inline]<br /> net_rx_action+0x5f7/0xda0 net/core/dev.c:7784<br /> handle_softirqs+0x22f/0x710 kernel/softirq.c:622<br /> __do_softirq kernel/softirq.c:656 [inline]<br /> __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302<br /> mptcp_pm_send_ack net/mptcp/pm.c:210 [inline]<br /> mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1<br /> mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002<br /> mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762<br /> process_one_work kernel/workqueue.c:3263 [inline]<br /> process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 44:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:400 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417<br /> kasan_kmalloc include/linux/kasan.h:262 [inline]<br /> __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385<br /> mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355<br /> mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline]<br /> __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529<br /> mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008<br /> mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762<br /> process_one_work kernel/workqueue.c:3263 [inline]<br /> process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> Freed by task 6630:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587<br /> kasan_save_free_info mm/kasan/kasan.h:406 [inline]<br /> poison_slab_object m<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40258

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix race condition in mptcp_schedule_work()<br /> <br /> syzbot reported use-after-free in mptcp_schedule_work() [1]<br /> <br /> Issue here is that mptcp_schedule_work() schedules a work,<br /> then gets a refcount on sk-&gt;sk_refcnt if the work was scheduled.<br /> This refcount will be released by mptcp_worker().<br /> <br /> [A] if (schedule_work(...)) {<br /> [B] sock_hold(sk);<br /> return true;<br /> }<br /> <br /> Problem is that mptcp_worker() can run immediately and complete before [B]<br /> <br /> We need instead :<br /> <br /> sock_hold(sk);<br /> if (schedule_work(...))<br /> return true;<br /> sock_put(sk);<br /> <br /> [1]<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25<br /> Call Trace:<br /> <br /> __refcount_add include/linux/refcount.h:-1 [inline]<br /> __refcount_inc include/linux/refcount.h:366 [inline]<br /> refcount_inc include/linux/refcount.h:383 [inline]<br /> sock_hold include/net/sock.h:816 [inline]<br /> mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943<br /> mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316<br /> call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747<br /> expire_timers kernel/time/timer.c:1798 [inline]<br /> __run_timers kernel/time/timer.c:2372 [inline]<br /> __run_timer_base+0x648/0x970 kernel/time/timer.c:2384<br /> run_timer_base kernel/time/timer.c:2393 [inline]<br /> run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403<br /> handle_softirqs+0x22f/0x710 kernel/softirq.c:622<br /> __do_softirq kernel/softirq.c:656 [inline]<br /> run_ktimerd+0xcf/0x190 kernel/softirq.c:1138<br /> smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40259

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Do not sleep in atomic context<br /> <br /> sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may<br /> sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead<br /> of disabled.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40260

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix scx_enable() crash on helper kthread creation failure<br /> <br /> A crash was observed when the sched_ext selftests runner was<br /> terminated with Ctrl+\ while test 15 was running:<br /> <br /> NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0<br /> LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0<br /> Call Trace:<br /> scx_enable.constprop.0+0x32c/0x12b0 (unreliable)<br /> bpf_struct_ops_link_create+0x18c/0x22c<br /> __sys_bpf+0x23f8/0x3044<br /> sys_bpf+0x2c/0x6c<br /> system_call_exception+0x124/0x320<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> kthread_run_worker() returns an ERR_PTR() on failure rather than NULL,<br /> but the current code in scx_alloc_and_add_sched() only checks for a NULL<br /> helper. Incase of failure on SIGQUIT, the error is not handled in<br /> scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an<br /> error pointer.<br /> <br /> Error handling is fixed in scx_alloc_and_add_sched() to propagate<br /> PTR_ERR() into ret, so that scx_enable() jumps to the existing error<br /> path, avoiding random dereference on failure.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40248

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Ignore signal/timeout on connect() if already established<br /> <br /> During connect(), acting on a signal/timeout by disconnecting an already<br /> established socket leads to several issues:<br /> <br /> 1. connect() invoking vsock_transport_cancel_pkt() -&gt;<br /> virtio_transport_purge_skbs() may race with sendmsg() invoking<br /> virtio_transport_get_credit(). This results in a permanently elevated<br /> `vvs-&gt;bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.<br /> <br /> 2. connect() resetting a connected socket&amp;#39;s state may race with socket<br /> being placed in a sockmap. A disconnected socket remaining in a sockmap<br /> breaks sockmap&amp;#39;s assumptions. And gives rise to WARNs.<br /> <br /> 3. connect() transitioning SS_CONNECTED -&gt; SS_UNCONNECTED allows for a<br /> transport change/drop after TCP_ESTABLISHED. Which poses a problem for<br /> any simultaneous sendmsg() or connect() and may result in a<br /> use-after-free/null-ptr-deref.<br /> <br /> Do not disconnect socket on signal/timeout. Keep the logic for unconnected<br /> sockets: they don&amp;#39;t linger, can&amp;#39;t be placed in a sockmap, are rejected by<br /> sendmsg().<br /> <br /> [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/<br /> [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/<br /> [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40249

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: cdev: make sure the cdev fd is still active before emitting events<br /> <br /> With the final call to fput() on a file descriptor, the release action<br /> may be deferred and scheduled on a work queue. The reference count of<br /> that descriptor is still zero and it must not be used. It&amp;#39;s possible<br /> that a GPIO change, we want to notify the user-space about, happens<br /> AFTER the reference count on the file descriptor associated with the<br /> character device went down to zero but BEFORE the .release() callback<br /> was called from the workqueue and so BEFORE we unregistered from the<br /> notifier.<br /> <br /> Using the regular get_file() routine in this situation triggers the<br /> following warning:<br /> <br /> struct file::f_count incremented from zero; use-after-free condition present!<br /> <br /> So use the get_file_active() variant that will return NULL on file<br /> descriptors that have been or are being released.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40250

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Clean up only new IRQ glue on request_irq() failure<br /> <br /> The mlx5_irq_alloc() function can inadvertently free the entire rmap<br /> and end up in a crash[1] when the other threads tries to access this,<br /> when request_irq() fails due to exhausted IRQ vectors. This commit<br /> modifies the cleanup to remove only the specific IRQ mapping that was<br /> just added.<br /> <br /> This prevents removal of other valid mappings and ensures precise<br /> cleanup of the failed IRQ allocation&amp;#39;s associated glue object.<br /> <br /> Note: This error is observed when both fwctl and rds configs are enabled.<br /> <br /> [1]<br /> mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1<br /> mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to<br /> request irq. err = -28<br /> infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while<br /> trying to test write-combining support<br /> mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1<br /> mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1<br /> mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to<br /> request irq. err = -28<br /> infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while<br /> trying to test write-combining support<br /> mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1<br /> mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to<br /> request irq. err = -28<br /> mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to<br /> request irq. err = -28<br /> general protection fault, probably for non-canonical address<br /> 0xe277a58fde16f291: 0000 [#1] SMP NOPTI<br /> <br /> RIP: 0010:free_irq_cpu_rmap+0x23/0x7d<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]<br /> ? __die_body.cold+0x8/0xa<br /> ? die_addr+0x39/0x53<br /> ? exc_general_protection+0x1c4/0x3e9<br /> ? dev_vprintk_emit+0x5f/0x90<br /> ? asm_exc_general_protection+0x22/0x27<br /> ? free_irq_cpu_rmap+0x23/0x7d<br /> mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]<br /> irq_pool_request_vector+0x7d/0x90 [mlx5_core]<br /> mlx5_irq_request+0x2e/0xe0 [mlx5_core]<br /> mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]<br /> comp_irq_request_pci+0x64/0xf0 [mlx5_core]<br /> create_comp_eq+0x71/0x385 [mlx5_core]<br /> ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]<br /> mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]<br /> ? xas_load+0x8/0x91<br /> mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]<br /> mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]<br /> mlx5e_open_channels+0xad/0x250 [mlx5_core]<br /> mlx5e_open_locked+0x3e/0x110 [mlx5_core]<br /> mlx5e_open+0x23/0x70 [mlx5_core]<br /> __dev_open+0xf1/0x1a5<br /> __dev_change_flags+0x1e1/0x249<br /> dev_change_flags+0x21/0x5c<br /> do_setlink+0x28b/0xcc4<br /> ? __nla_parse+0x22/0x3d<br /> ? inet6_validate_link_af+0x6b/0x108<br /> ? cpumask_next+0x1f/0x35<br /> ? __snmp6_fill_stats64.constprop.0+0x66/0x107<br /> ? __nla_validate_parse+0x48/0x1e6<br /> __rtnl_newlink+0x5ff/0xa57<br /> ? kmem_cache_alloc_trace+0x164/0x2ce<br /> rtnl_newlink+0x44/0x6e<br /> rtnetlink_rcv_msg+0x2bb/0x362<br /> ? __netlink_sendskb+0x4c/0x6c<br /> ? netlink_unicast+0x28f/0x2ce<br /> ? rtnl_calcit.isra.0+0x150/0x146<br /> netlink_rcv_skb+0x5f/0x112<br /> netlink_unicast+0x213/0x2ce<br /> netlink_sendmsg+0x24f/0x4d9<br /> __sock_sendmsg+0x65/0x6a<br /> ____sys_sendmsg+0x28f/0x2c9<br /> ? import_iovec+0x17/0x2b<br /> ___sys_sendmsg+0x97/0xe0<br /> __sys_sendmsg+0x81/0xd8<br /> do_syscall_64+0x35/0x87<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x0<br /> RIP: 0033:0x7fc328603727<br /> Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed<br /> ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48<br /> RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727<br /> RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d<br /> RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000<br /> R13: 00000000000<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40251

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: rate: Unset parent pointer in devl_rate_nodes_destroy<br /> <br /> The function devl_rate_nodes_destroy is documented to "Unset parent for<br /> all rate objects". However, it was only calling the driver-specific<br /> `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing<br /> the parent&amp;#39;s refcount, without actually setting the<br /> `devlink_rate-&gt;parent` pointer to NULL.<br /> <br /> This leaves a dangling pointer in the `devlink_rate` struct, which cause<br /> refcount error in netdevsim[1] and mlx5[2]. In addition, this is<br /> inconsistent with the behavior of `devlink_nl_rate_parent_node_set`,<br /> where the parent pointer is correctly cleared.<br /> <br /> This patch fixes the issue by explicitly setting `devlink_rate-&gt;parent`<br /> to NULL after notifying the driver, thus fulfilling the function&amp;#39;s<br /> documented behavior for all rate objects.<br /> <br /> [1]<br /> repro steps:<br /> echo 1 &gt; /sys/bus/netdevsim/new_device<br /> devlink dev eswitch set netdevsim/netdevsim1 mode switchdev<br /> echo 1 &gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs<br /> devlink port function rate add netdevsim/netdevsim1/test_node<br /> devlink port function rate set netdevsim/netdevsim1/128 parent test_node<br /> echo 1 &gt; /sys/bus/netdevsim/del_device<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> __nsim_dev_port_del+0x6c/0x70 [netdevsim]<br /> nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]<br /> nsim_drv_remove+0x2b/0xb0 [netdevsim]<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> device_unregister+0x1a/0x60<br /> del_device_store+0x111/0x170 [netdevsim]<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x55/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> devlink dev eswitch set pci/0000:08:00.0 mode switchdev<br /> devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000<br /> devlink port function rate add pci/0000:08:00.0/group1<br /> devlink port function rate set pci/0000:08:00.0/32768 parent group1<br /> modprobe -r mlx5_ib mlx5_fwctl mlx5_core<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]<br /> mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]<br /> mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]<br /> mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]<br /> notifier_call_chain+0x33/0xa0<br /> blocking_notifier_call_chain+0x3b/0x50<br /> mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]<br /> mlx5_eswitch_disable+0x63/0x90 [mlx5_core]<br /> mlx5_unload+0x1d/0x170 [mlx5_core]<br /> mlx5_uninit_one+0xa2/0x130 [mlx5_core]<br /> remove_one+0x78/0xd0 [mlx5_core]<br /> pci_device_remove+0x39/0xa0<br /> device_release_driver_internal+0x194/0x1f0<br /> unbind_store+0x99/0xa0<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x53/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40252

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()<br /> <br /> The loops in &amp;#39;qede_tpa_cont()&amp;#39; and &amp;#39;qede_tpa_end()&amp;#39;, iterate<br /> over &amp;#39;cqe-&gt;len_list[]&amp;#39; using only a zero-length terminator as<br /> the stopping condition. If the terminator was missing or<br /> malformed, the loop could run past the end of the fixed-size array.<br /> <br /> Add an explicit bound check using ARRAY_SIZE() in both loops to prevent<br /> a potential out-of-bounds access.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40253

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ctcm: Fix double-kfree<br /> <br /> The function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39; is called conditionally<br /> from function &amp;#39;ctcmpc_unpack_skb&amp;#39;. It frees passed mpcginfo.<br /> After that a call to function &amp;#39;kfree&amp;#39; in function &amp;#39;ctcmpc_unpack_skb&amp;#39;<br /> frees it again.<br /> <br /> Remove &amp;#39;kfree&amp;#39; call in function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39;.<br /> <br /> Bug detected by the clang static analyzer.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40247

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix pgtable prealloc error path<br /> <br /> The following splat was reported:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000<br /> [0000000000000010] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : build_detached_freelist+0x28/0x224<br /> lr : kmem_cache_free_bulk.part.0+0x38/0x244<br /> sp : ffff000a508c7a20<br /> x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350<br /> x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000<br /> x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000<br /> x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8<br /> x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640<br /> x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30<br /> x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940<br /> x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000<br /> x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8<br /> x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00<br /> Call trace:<br /> build_detached_freelist+0x28/0x224 (P)<br /> kmem_cache_free_bulk.part.0+0x38/0x244<br /> kmem_cache_free_bulk+0x10/0x1c<br /> msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0<br /> msm_vma_job_free+0x30/0x240<br /> msm_ioctl_vm_bind+0x1d0/0x9a0<br /> drm_ioctl_kernel+0x84/0x104<br /> drm_ioctl+0x358/0x4d4<br /> __arm64_sys_ioctl+0x8c/0xe0<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x3c/0xe0<br /> do_el0_svc+0x18/0x20<br /> el0_svc+0x30/0x100<br /> el0t_64_sync_handler+0x104/0x130<br /> el0t_64_sync+0x170/0x174<br /> Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Since msm_vma_job_free() is called directly from the ioctl, this looks<br /> like an error path cleanup issue. Which I think results from<br /> prealloc_cleanup() called without a preceding successful<br /> prealloc_allocate() call. So handle that case better.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/678677/
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40240

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: avoid NULL dereference when chunk data buffer is missing<br /> <br /> chunk-&gt;skb pointer is dereferenced in the if-block where it&amp;#39;s supposed<br /> to be NULL only.<br /> <br /> chunk-&gt;skb can only be NULL if chunk-&gt;head_skb is not. Check for frag_list<br /> instead and do it just before replacing chunk-&gt;skb. We&amp;#39;re sure that<br /> otherwise chunk-&gt;skb is non-NULL because of outer if() condition.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025