Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2025-38318

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm-ni: Fix missing platform_set_drvdata()<br /> <br /> Add missing platform_set_drvdata in arm_ni_probe(), otherwise<br /> calling platform_get_drvdata() in remove returns NULL.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38319

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table<br /> <br /> The function atomctrl_initialize_mc_reg_table() and<br /> atomctrl_initialize_mc_reg_table_v2_2() does not check the return<br /> value of smu_atom_get_data_table(). If smu_atom_get_data_table()<br /> fails to retrieve vram_info, it returns NULL which is later<br /> dereferenced.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38303

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: eir: Fix possible crashes on eir_create_adv_data<br /> <br /> eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER<br /> without checking if that would fit.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38304

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix NULL pointer deference on eir_get_service_data<br /> <br /> The len parameter is considered optional so it can be NULL so it cannot<br /> be used for skipping to next entry of EIR_SERVICE_DATA.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38305

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: remove ptp-&gt;n_vclocks check logic in ptp_vclock_in_use()<br /> <br /> There is no disagreement that we should check both ptp-&gt;is_virtual_clock<br /> and ptp-&gt;n_vclocks to check if the ptp virtual clock is in use.<br /> <br /> However, when we acquire ptp-&gt;n_vclocks_mux to read ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use(), we observe a recursive lock in the call trace<br /> starting from n_vclocks_store().<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.15.0-rc6 #1 Not tainted<br /> --------------------------------------------<br /> syz.0.1540/13807 is trying to acquire lock:<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415<br /> <br /> but task is already holding lock:<br /> ffff888030704868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> <br /> *** DEADLOCK ***<br /> ....<br /> ============================================<br /> <br /> The best way to solve this is to remove the logic that checks<br /> ptp-&gt;n_vclocks in ptp_vclock_in_use().<br /> <br /> The reason why this is appropriate is that any path that uses<br /> ptp-&gt;n_vclocks must unconditionally check if ptp-&gt;n_vclocks is greater<br /> than 0 before unregistering vclocks, and all functions are already<br /> written this way. And in the function that uses ptp-&gt;n_vclocks, we<br /> already get ptp-&gt;n_vclocks_mux before unregistering vclocks.<br /> <br /> Therefore, we need to remove the redundant check for ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use() to prevent recursive locking.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38306

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/fhandle.c: fix a race in call of has_locked_children()<br /> <br /> may_decode_fh() is calling has_locked_children() while holding no locks.<br /> That&amp;#39;s an oopsable race...<br /> <br /> The rest of the callers are safe since they are holding namespace_sem and<br /> are guaranteed a positive refcount on the mount in question.<br /> <br /> Rename the current has_locked_children() to __has_locked_children(), make<br /> it static and switch the fs/namespace.c users to it.<br /> <br /> Make has_locked_children() a wrapper for __has_locked_children(), calling<br /> the latter under read_seqlock_excl(&amp;mount_lock).
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38307

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Verify content returned by parse_int_array()<br /> <br /> The first element of the returned array stores its length. If it is 0,<br /> any manipulation beyond the element at index 0 ends with null-ptr-deref.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38308

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw<br /> <br /> Search result of avs_dai_find_path_template() shall be verified before<br /> being used. As &amp;#39;template&amp;#39; is already known when<br /> avs_hw_constraints_init() is fired, drop the search entirely.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38309

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: move xe_svm_init() earlier<br /> <br /> In xe_vm_close_and_put() we need to be able to call xe_svm_fini(),<br /> however during vm creation we can call this on the error path, before<br /> having actually initialised the svm state, leading to various splats<br /> followed by a fatal NPD.<br /> <br /> (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38310

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> seg6: Fix validation of nexthop addresses<br /> <br /> The kernel currently validates that the length of the provided nexthop<br /> address does not exceed the specified length. This can lead to the<br /> kernel reading uninitialized memory if user space provided a shorter<br /> length than the specified one.<br /> <br /> Fix by validating that the provided length exactly matches the specified<br /> one.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38294

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix NULL access in assign channel context handler<br /> <br /> Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle<br /> (ar) gets accessed from the link VIF handle (arvif) for debug logging, This<br /> is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL<br /> access, avoid radio handle access by moving to the hardware debug logging<br /> helper function (ath12k_hw_warn).<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025

CVE-2025-38295

Publication date:
10/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create()<br /> <br /> The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses<br /> smp_processor_id(), which assumes disabled preemption. This leads to kernel<br /> warnings during module loading because meson_ddr_pmu_create() can be called<br /> in a preemptible context.<br /> <br /> Following kernel warning and stack trace:<br /> [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289<br /> [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38<br /> [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0<br /> [ 31.745181] [ T2289] Tainted: [W]=WARN<br /> [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT)<br /> [ 31.745188] [ T2289] Call trace:<br /> [ 31.745191] [ T2289] show_stack+0x28/0x40 (C)<br /> [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198<br /> [ 31.745205] [ T2289] dump_stack+0x20/0x50<br /> [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0<br /> [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38<br /> [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745246] [ T2289] platform_probe+0x98/0xe0<br /> [ 31.745254] [ T2289] really_probe+0x144/0x3f8<br /> [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180<br /> [ 31.745261] [ T2289] driver_probe_device+0x54/0x268<br /> [ 31.745264] [ T2289] __driver_attach+0x11c/0x288<br /> [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160<br /> [ 31.745274] [ T2289] driver_attach+0x34/0x50<br /> [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0<br /> [ 31.745281] [ T2289] driver_register+0x78/0x120<br /> [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48<br /> [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438<br /> [ 31.745303] [ T2289] do_init_module+0x68/0x228<br /> [ 31.745311] [ T2289] load_module+0x118c/0x13a8<br /> [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390<br /> [ 31.745320] [ T2289] invoke_syscall+0x74/0x108<br /> [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8<br /> [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48<br /> [ 31.745333] [ T2289] el0_svc+0x60/0x150<br /> [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118<br /> [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0<br /> <br /> Changes replaces smp_processor_id() with raw_smp_processor_id() to<br /> ensure safe CPU ID retrieval in preemptible contexts.
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025