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

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: fix crash due to removal of uninitialised entry<br /> <br /> A crash in conntrack was reported while trying to unlink the conntrack<br /> entry from the hash bucket list:<br /> [exception RIP: __nf_ct_delete_from_lists+172]<br /> [..]<br /> #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]<br /> #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]<br /> #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]<br /> [..]<br /> <br /> The nf_conn struct is marked as allocated from slab but appears to be in<br /> a partially initialised state:<br /> <br /> ct hlist pointer is garbage; looks like the ct hash value<br /> (hence crash).<br /> ct-&gt;status is equal to IPS_CONFIRMED|IPS_DYING, which is expected<br /> ct-&gt;timeout is 30000 (=30s), which is unexpected.<br /> <br /> Everything else looks like normal udp conntrack entry. If we ignore<br /> ct-&gt;status and pretend its 0, the entry matches those that are newly<br /> allocated but not yet inserted into the hash:<br /> - ct hlist pointers are overloaded and store/cache the raw tuple hash<br /> - ct-&gt;timeout matches the relative time expected for a new udp flow<br /> rather than the absolute &amp;#39;jiffies&amp;#39; value.<br /> <br /> If it were not for the presence of IPS_CONFIRMED,<br /> __nf_conntrack_find_get() would have skipped the entry.<br /> <br /> Theory is that we did hit following race:<br /> <br /> cpu x cpu y cpu z<br /> found entry E found entry E<br /> E is expired <br /> nf_ct_delete()<br /> return E to rcu slab<br /> init_conntrack<br /> E is re-inited,<br /> ct-&gt;status set to 0<br /> reply tuplehash hnnode.pprev<br /> stores hash value.<br /> <br /> cpu y found E right before it was deleted on cpu x.<br /> E is now re-inited on cpu z. cpu y was preempted before<br /> checking for expiry and/or confirm bit.<br /> <br /> -&gt;refcnt set to 1<br /> E now owned by skb<br /> -&gt;timeout set to 30000<br /> <br /> If cpu y were to resume now, it would observe E as<br /> expired but would skip E due to missing CONFIRMED bit.<br /> <br /> nf_conntrack_confirm gets called<br /> sets: ct-&gt;status |= CONFIRMED<br /> This is wrong: E is not yet added<br /> to hashtable.<br /> <br /> cpu y resumes, it observes E as expired but CONFIRMED:<br /> <br /> nf_ct_expired()<br /> -&gt; yes (ct-&gt;timeout is 30s)<br /> confirmed bit set.<br /> <br /> cpu y will try to delete E from the hashtable:<br /> nf_ct_delete() -&gt; set DYING bit<br /> __nf_ct_delete_from_lists<br /> <br /> Even this scenario doesn&amp;#39;t guarantee a crash:<br /> cpu z still holds the table bucket lock(s) so y blocks:<br /> <br /> wait for spinlock held by z<br /> <br /> CONFIRMED is set but there is no<br /> guarantee ct will be added to hash:<br /> "chaintoolong" or "clash resolution"<br /> logic both skip the insert step.<br /> reply hnnode.pprev still stores the<br /> hash value.<br /> <br /> unlocks spinlock<br /> return NF_DROP<br /> <br /> <br /> In case CPU z does insert the entry into the hashtable, cpu y will unlink<br /> E again right away but no crash occurs.<br /> <br /> Without &amp;#39;cpu y&amp;#39; race, &amp;#39;garbage&amp;#39; hlist is of no consequence:<br /> ct refcnt remains at 1, eventually skb will be free&amp;#39;d and E gets<br /> destroyed via: nf_conntrack_put -&gt; nf_conntrack_destroy -&gt; nf_ct_destroy.<br /> <br /> To resolve this, move the IPS_CONFIRMED assignment after the table<br /> insertion but before the unlock.<br /> <br /> Pablo points out that the confirm-bit-store could be reordered to happen<br /> before hlist add resp. the timeout fixup, so switch to set_bit and<br /> before_atomic memory barrier to prevent this.<br /> <br /> It doesn&amp;#39;t matter if other CPUs can observe a newly inserted entry right<br /> before the CONFIRMED bit was set:<br /> <br /> Such event cannot be distinguished from above "E is the old incarnation"<br /> case: the entry will be skipped.<br /> <br /> Also change nf_ct_should_gc() to first check the confirmed bit.<br /> <br /> The gc sequence is:<br /> 1. Check if entry has expired, if not skip to next entry<br /> 2. Obtain a reference to the expired entry.<br /> 3. Call nf_ct_should_gc() to double-check step 1.<br /> <br /> nf_ct_should_gc() is thus called only for entries that already failed an<br /> expiry check. After this patch, once the confirmed bit check pas<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38473

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()<br /> <br /> syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]<br /> <br /> l2cap_sock_resume_cb() has a similar problem that was fixed by commit<br /> 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").<br /> <br /> Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed<br /> under l2cap_sock_resume_cb(), we can avoid the issue simply by checking<br /> if chan-&gt;data is NULL.<br /> <br /> Let&amp;#39;s not access to the killed socket in l2cap_sock_resume_cb().<br /> <br /> [0]:<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52<br /> <br /> CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Workqueue: hci0 hci_rx_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)<br /> __dump_stack+0x30/0x40 lib/dump_stack.c:94<br /> dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120<br /> print_report+0x58/0x84 mm/kasan/report.c:524<br /> kasan_report+0xb0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189<br /> __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37<br /> instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357<br /> hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]<br /> hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514<br /> hci_event_func net/bluetooth/hci_event.c:7511 [inline]<br /> hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565<br /> hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070<br /> process_one_work+0x7e8/0x155c kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3321 [inline]<br /> worker_thread+0x958/0xed8 kernel/workqueue.c:3402<br /> kthread+0x5fc/0x75c kernel/kthread.c:464<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38474

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: net: sierra: check for no status endpoint<br /> <br /> The driver checks for having three endpoints and<br /> having bulk in and out endpoints, but not that<br /> the third endpoint is interrupt input.<br /> Rectify the omission.
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38475

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix various oops due to inet_sock type confusion.<br /> <br /> syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while<br /> freeing inet_sk(sk)-&gt;inet_opt.<br /> <br /> The address was freed multiple times even though it was read-only memory.<br /> <br /> cipso_v4_sock_setattr() did nothing wrong, and the root cause was type<br /> confusion.<br /> <br /> The cited commit made it possible to create smc_sock as an INET socket.<br /> <br /> The issue is that struct smc_sock does not have struct inet_sock as the<br /> first member but hijacks AF_INET and AF_INET6 sk_family, which confuses<br /> various places.<br /> <br /> In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(),<br /> which is an address of a function in the text segment.<br /> <br /> $ pahole -C inet_sock vmlinux<br /> struct inet_sock {<br /> ...<br /> struct ip_options_rcu * inet_opt; /* 784 8 */<br /> <br /> $ pahole -C smc_sock vmlinux<br /> struct smc_sock {<br /> ...<br /> void (*clcsk_data_ready)(struct sock *); /* 784 8 */<br /> <br /> The same issue for another field was reported before. [2][3]<br /> <br /> At that time, an ugly hack was suggested [4], but it makes both INET<br /> and SMC code error-prone and hard to change.<br /> <br /> Also, yet another variant was fixed by a hacky commit 98d4435efcbf3<br /> ("net/smc: prevent NULL pointer dereference in txopt_get").<br /> <br /> Instead of papering over the root cause by such hacks, we should not<br /> allow non-INET socket to reuse the INET infra.<br /> <br /> Let&amp;#39;s add inet_sock as the first member of smc_sock.<br /> <br /> [0]:<br /> kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73<br /> WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT<br /> Tainted: [W]=WARN<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> sp : ffff8000a03a7730<br /> x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3<br /> x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00<br /> x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0<br /> x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff<br /> x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c<br /> x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff<br /> x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000<br /> x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360<br /> x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000<br /> Call trace:<br /> kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P)<br /> cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914<br /> netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000<br /> smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581<br /> smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912<br /> security_inode_setsecurity+0x118/0x3c0 security/security.c:2706<br /> __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251<br /> __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295<br /> vfs_setxattr+0x158/0x2ac fs/xattr.c:321<br /> do_setxattr fs/xattr.c:636 [inline]<br /> file_setxattr+0x1b8/0x294 fs/xattr.c:646<br /> path_setxattrat+0x2ac/0x320 fs/xattr.c:711<br /> __do_sys_fsetxattr fs/xattr.c:761 [inline]<br /> __se_sys_fsetxattr fs/xattr.c:758 [inline]<br /> __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879<br /> el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> [<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38476

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpl: Fix use-after-free in rpl_do_srh_inline().<br /> <br /> Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers<br /> the splat below [0].<br /> <br /> rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after<br /> skb_cow_head(), which is illegal as the header could be freed then.<br /> <br /> Let&amp;#39;s fix it by making oldhdr to a local struct instead of a pointer.<br /> <br /> [0]:<br /> [root@fedora net]# ./lwt_dst_cache_ref_loop.sh<br /> ...<br /> TEST: rpl (input)<br /> [ 57.631529] ==================================================================<br /> BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> Read of size 40 at addr ffff888122bf96d8 by task ping6/1543<br /> <br /> CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)<br /> kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)<br /> kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))<br /> __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))<br /> rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)<br /> lwtunnel_input (net/core/lwtunnel.c:459)<br /> ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))<br /> __netif_receive_skb_one_core (net/core/dev.c:5967)<br /> process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)<br /> __napi_poll.constprop.0 (net/core/dev.c:7452)<br /> net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)<br /> handle_softirqs (kernel/softirq.c:579)<br /> do_softirq (kernel/softirq.c:480 (discriminator 20))<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:407)<br /> __dev_queue_xmit (net/core/dev.c:4740)<br /> ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)<br /> ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)<br /> ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)<br /> ip6_send_skb (net/ipv6/ip6_output.c:1983)<br /> rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)<br /> __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))<br /> __x64_sys_sendto (net/socket.c:2231)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f68cffb2a06<br /> Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08<br /> RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06<br /> RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003<br /> RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4<br /> R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0<br /> <br /> <br /> Allocated by task 1543:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))<br /> __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)<br /> kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)<br /> kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))<br /> __alloc_skb (net/core/skbuff.c:669)<br /> __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))<br /> ip6_<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38477

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: Fix race condition on qfq_aggregate<br /> <br /> A race condition can occur when &amp;#39;agg&amp;#39; is modified in qfq_change_agg<br /> (called during qfq_enqueue) while other threads access it<br /> concurrently. For example, qfq_dump_class may trigger a NULL<br /> dereference, and qfq_delete_class may cause a use-after-free.<br /> <br /> This patch addresses the issue by:<br /> <br /> 1. Moved qfq_destroy_class into the critical section.<br /> <br /> 2. Added sch_tree_lock protection to qfq_dump_class and<br /> qfq_dump_class_stats.
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38478

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix initialization of data for instructions that write to subdevice<br /> <br /> Some Comedi subdevice instruction handlers are known to access<br /> instruction data elements beyond the first `insn-&gt;n` elements in some<br /> cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions<br /> allocate at least `MIN_SAMPLES` (16) data elements to deal with this,<br /> but they do not initialize all of that. For Comedi instruction codes<br /> that write to the subdevice, the first `insn-&gt;n` data elements are<br /> copied from user-space, but the remaining elements are left<br /> uninitialized. That could be a problem if the subdevice instruction<br /> handler reads the uninitialized data. Ensure that the first<br /> `MIN_SAMPLES` elements are initialized before calling these instruction<br /> handlers, filling the uncopied elements with 0. For<br /> `do_insnlist_ioctl()`, the same data buffer elements are used for<br /> handling a list of instructions, so ensure the first `MIN_SAMPLES`<br /> elements are initialized for each instruction that writes to the<br /> subdevice.
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38480

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix use of uninitialized data in insn_rw_emulate_bits()<br /> <br /> For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"<br /> subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and<br /> `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have<br /> `insn_read` and `insn_write` handler functions, but to have an<br /> `insn_bits` handler function for handling Comedi `INSN_BITS`<br /> instructions. In that case, the subdevice&amp;#39;s `insn_read` and/or<br /> `insn_write` function handler pointers are set to point to the<br /> `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.<br /> <br /> For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the<br /> supplied `data[0]` value is a valid copy from user memory. It will at<br /> least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in<br /> "comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are<br /> allocated. However, if `insn-&gt;n` is 0 (which is allowable for<br /> `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain<br /> uninitialized data, and certainly contains invalid data, possibly from a<br /> different instruction in the array of instructions handled by<br /> `do_insnlist_ioctl()`. This will result in an incorrect value being<br /> written to the digital output channel (or to the digital input/output<br /> channel if configured as an output), and may be reflected in the<br /> internal saved state of the channel.<br /> <br /> Fix it by returning 0 early if `insn-&gt;n` is 0, before reaching the code<br /> that accesses `data[0]`. Previously, the function always returned 1 on<br /> success, but it is supposed to be the number of data samples actually<br /> read or written up to `insn-&gt;n`, which is 0 in this case.
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38481

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large<br /> <br /> The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to<br /> hold the array of `struct comedi_insn`, getting the length from the<br /> `n_insns` member of the `struct comedi_insnlist` supplied by the user.<br /> The allocation will fail with a WARNING and a stack dump if it is too<br /> large.<br /> <br /> Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`<br /> value is unreasonable.<br /> <br /> Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set<br /> this to the same value as `MAX_SAMPLES` (65536), which is the maximum<br /> allowed sum of the values of the member `n` in the array of `struct<br /> comedi_insn`, and sensible comedi instructions will have an `n` of at<br /> least 1.
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38468

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree<br /> <br /> htb_lookup_leaf has a BUG_ON that can trigger with the following:<br /> <br /> tc qdisc del dev lo root<br /> tc qdisc add dev lo root handle 1: htb default 1<br /> tc class add dev lo parent 1: classid 1:1 htb rate 64bit<br /> tc qdisc add dev lo parent 1:1 handle 2: netem<br /> tc qdisc add dev lo parent 2:1 handle 3: blackhole<br /> ping -I lo -c1 -W0.001 127.0.0.1<br /> <br /> The root cause is the following:<br /> <br /> 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on<br /> the selected leaf qdisc<br /> 2. netem_dequeue calls enqueue on the child qdisc<br /> 3. blackhole_enqueue drops the packet and returns a value that is not<br /> just NET_XMIT_SUCCESS<br /> 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and<br /> since qlen is now 0, it calls htb_qlen_notify -&gt; htb_deactivate -&gt;<br /> htb_deactiviate_prios -&gt; htb_remove_class_from_row -&gt; htb_safe_rb_erase<br /> 5. As this is the only class in the selected hprio rbtree,<br /> __rb_change_child in __rb_erase_augmented sets the rb_root pointer to<br /> NULL<br /> 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,<br /> which causes htb_dequeue_tree to call htb_lookup_leaf with the same<br /> hprio rbtree, and fail the BUG_ON<br /> <br /> The function graph for this scenario is shown here:<br /> 0) | htb_enqueue() {<br /> 0) + 13.635 us | netem_enqueue();<br /> 0) 4.719 us | htb_activate_prios();<br /> 0) # 2249.199 us | }<br /> 0) | htb_dequeue() {<br /> 0) 2.355 us | htb_lookup_leaf();<br /> 0) | netem_dequeue() {<br /> 0) + 11.061 us | blackhole_enqueue();<br /> 0) | qdisc_tree_reduce_backlog() {<br /> 0) | qdisc_lookup_rcu() {<br /> 0) 1.873 us | qdisc_match_from_root();<br /> 0) 6.292 us | }<br /> 0) 1.894 us | htb_search();<br /> 0) | htb_qlen_notify() {<br /> 0) 2.655 us | htb_deactivate_prios();<br /> 0) 6.933 us | }<br /> 0) + 25.227 us | }<br /> 0) 1.983 us | blackhole_dequeue();<br /> 0) + 86.553 us | }<br /> 0) # 2932.761 us | qdisc_warn_nonwc();<br /> 0) | htb_lookup_leaf() {<br /> 0) | BUG_ON();<br /> ------------------------------------------<br /> <br /> The full original bug report can be seen here [1].<br /> <br /> We can fix this just by returning NULL instead of the BUG_ON,<br /> as htb_dequeue_tree returns NULL when htb_lookup_leaf returns<br /> NULL.<br /> <br /> [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38469

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls<br /> <br /> kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host<br /> for more than one event channel potr (nr_ports &gt; 1).<br /> <br /> After the kmalloc_array(), the error paths need to go through the<br /> "out" label, but the call to kvm_read_guest_virt() does not.<br /> <br /> [Adjusted commit message. - Paolo]
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025

CVE-2025-38470

Fecha de publicación:
28/07/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime<br /> <br /> Assuming the "rx-vlan-filter" feature is enabled on a net device, the<br /> 8021q module will automatically add or remove VLAN 0 when the net device<br /> is put administratively up or down, respectively. There are a couple of<br /> problems with the above scheme.<br /> <br /> The first problem is a memory leak that can happen if the "rx-vlan-filter"<br /> feature is disabled while the device is running:<br /> <br /> # ip link add bond1 up type bond mode 0<br /> # ethtool -K bond1 rx-vlan-filter off<br /> # ip link del dev bond1<br /> <br /> When the device is put administratively down the "rx-vlan-filter"<br /> feature is disabled, so the 8021q module will not remove VLAN 0 and the<br /> memory will be leaked [1].<br /> <br /> Another problem that can happen is that the kernel can automatically<br /> delete VLAN 0 when the device is put administratively down despite not<br /> adding it when the device was put administratively up since during that<br /> time the "rx-vlan-filter" feature was disabled. null-ptr-unref or<br /> bug_on[2] will be triggered by unregister_vlan_dev() for refcount<br /> imbalance if toggling filtering during runtime:<br /> <br /> $ ip link add bond0 type bond mode 0<br /> $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q<br /> $ ethtool -K bond0 rx-vlan-filter off<br /> $ ifconfig bond0 up<br /> $ ethtool -K bond0 rx-vlan-filter on<br /> $ ifconfig bond0 down<br /> $ ip link del vlan0<br /> <br /> Root cause is as below:<br /> step1: add vlan0 for real_dev, such as bond, team.<br /> register_vlan_dev<br /> vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1<br /> step2: disable vlan filter feature and enable real_dev<br /> step3: change filter from 0 to 1<br /> vlan_device_event<br /> vlan_filter_push_vids<br /> ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0<br /> step4: real_dev down<br /> vlan_device_event<br /> vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0<br /> vlan_info_rcu_free //free vlan0<br /> step5: delete vlan0<br /> unregister_vlan_dev<br /> BUG_ON(!vlan_info); //vlan_info is null<br /> <br /> Fix both problems by noting in the VLAN info whether VLAN 0 was<br /> automatically added upon NETDEV_UP and based on that decide whether it<br /> should be deleted upon NETDEV_DOWN, regardless of the state of the<br /> "rx-vlan-filter" feature.<br /> <br /> [1]<br /> unreferenced object 0xffff8880068e3100 (size 256):<br /> comm "ip", pid 384, jiffies 4296130254<br /> hex dump (first 32 bytes):<br /> 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 81ce31fa):<br /> __kmalloc_cache_noprof+0x2b5/0x340<br /> vlan_vid_add+0x434/0x940<br /> vlan_device_event.cold+0x75/0xa8<br /> notifier_call_chain+0xca/0x150<br /> __dev_notify_flags+0xe3/0x250<br /> rtnl_configure_link+0x193/0x260<br /> rtnl_newlink_create+0x383/0x8e0<br /> __rtnl_newlink+0x22c/0xa40<br /> rtnl_newlink+0x627/0xb00<br /> rtnetlink_rcv_msg+0x6fb/0xb70<br /> netlink_rcv_skb+0x11f/0x350<br /> netlink_unicast+0x426/0x710<br /> netlink_sendmsg+0x75a/0xc20<br /> __sock_sendmsg+0xc1/0x150<br /> ____sys_sendmsg+0x5aa/0x7b0<br /> ___sys_sendmsg+0xfc/0x180<br /> <br /> [2]<br /> kernel BUG at net/8021q/vlan.c:99!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))<br /> RSP: 0018:ffff88810badf310 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80<br /> R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000<br /> R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e<br /> FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0<br /> Call Trace:<br />
Gravedad: Pendiente de análisis
Última modificación:
28/07/2025