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-2026-53305

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ps883x: Fix Oops at unbind<br /> <br /> When trying to unbind a device in order to bind to it vfio-platform as:<br /> <br /> echo bc0000.geniqup &gt; /sys/bus/platform/devices/bc0000.geniqup/driver/unbind<br /> <br /> I get the following Oops:<br /> <br /> [ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> [ 436.487762] Mem abort info:<br /> [ 436.490716] ESR = 0x0000000096000004<br /> [ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 436.500071] SET = 0, FnV = 0<br /> [ 436.503250] EA = 0, S1PTW = 0<br /> [ 436.506505] FSC = 0x04: level 0 translation fault<br /> [ 436.511533] Data abort info:<br /> [ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000<br /> [ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> [ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 436.550374] Modules linked in:<br /> [ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT<br /> [ 436.564440] Tainted: [W]=WARN<br /> [ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025<br /> [ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 436.581841] pc : ps883x_retimer_remove+0x14/0x94<br /> [ 436.586605] lr : i2c_device_remove+0x28/0x84<br /> [ 436.591017] sp : ffff8000847137c0<br /> <br /> That&amp;#39;s because the ps883x_retimer_remove() retrieves the driver data<br /> from i2c_get_clientdata() which was never set at probe. So, add<br /> i2c_set_clientdata() at the end of the probe.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53306

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: hvc_iucv: fix off-by-one in number of supported devices<br /> <br /> MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.<br /> This is the number of entries in:<br /> static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];<br /> <br /> Sometimes hvc_iucv_table[] is limited by:<br /> (a) if (num &gt; hvc_iucv_devices) // for error detection<br /> or<br /> (b) for (i = 0; i MAX_HVC_IUCV_LINES)<br /> <br /> If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].<br /> Oops.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53292

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind<br /> <br /> syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via<br /> pn_socket_autobind():<br /> <br /> kernel BUG at net/phonet/socket.c:213!<br /> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]<br /> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421<br /> Call Trace:<br /> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797<br /> __sock_sendmsg net/socket.c:812 [inline]<br /> __sys_sendto+0x402/0x590 net/socket.c:2280<br /> ...<br /> <br /> pn_socket_autobind() calls pn_socket_bind() with port 0 and, on<br /> -EINVAL, assumes the socket was already bound and asserts that the<br /> port is non-zero:<br /> <br /> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));<br /> if (err != -EINVAL)<br /> return err;<br /> BUG_ON(!pn_port(pn_sk(sock-&gt;sk)-&gt;sobject));<br /> return 0; /* socket was already bound */<br /> <br /> However pn_socket_bind() also returns -EINVAL when sk-&gt;sk_state is not<br /> TCP_CLOSE, even when the socket has never been bound and pn_port() is<br /> still 0. In that case the BUG_ON() fires and panics the kernel from a<br /> user-triggerable path.<br /> <br /> Treat the "bind returned -EINVAL but pn_port() is still 0" case as a<br /> regular error and propagate -EINVAL to the caller instead of crashing.<br /> Existing callers already translate a non-zero return from<br /> pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here<br /> only changes behaviour from panic to a normal errno.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53293

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG<br /> <br /> There were multiple issues in that code.<br /> <br /> First of all the order between the reset semaphore and the mm_lock was<br /> wrong (e.g. copy_to_user) was called while holding the lock.<br /> <br /> Then we allocated memory while holding the reset semaphore which is also<br /> a pretty big bug and can deadlock.<br /> <br /> Then we used down_read_trylock() instead of waiting for the reset to<br /> finish.<br /> <br /> (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53294

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: don&amp;#39;t free the reused channel<br /> <br /> The RX channel can be aliased to the TX channel if it has a different<br /> MMIO. This special case needs to be handled when freeing the channels<br /> otherwise a double-free occurs.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53295

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: add sanity check for channel array<br /> <br /> Fail gracefully if there is no channel array attached to the mailbox<br /> controller. Otherwise the later dereference will cause an OOPS which<br /> might not be seen because mailbox controllers might instantiate very<br /> early. Remove the comment explaining the obvious while here.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53296

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: free channels on probe error<br /> <br /> On probe error, free the previously obtained channels. This not only<br /> prevents a leak, but also UAF scenarios because the client structure<br /> will be removed nonetheless because it was allocated with devm.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53297

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Guard mana_remove against double invocation<br /> <br /> If PM resume fails (e.g., mana_attach() returns an error), mana_probe()<br /> calls mana_remove(), which tears down the device and sets<br /> gd-&gt;gdma_context = NULL and gd-&gt;driver_data = NULL.<br /> <br /> However, a failed resume callback does not automatically unbind the<br /> driver. When the device is eventually unbound, mana_remove() is invoked<br /> a second time. Without a NULL check, it dereferences gc-&gt;dev with<br /> gc == NULL, causing a kernel panic.<br /> <br /> Add an early return if gdma_context or driver_data is NULL so the second<br /> invocation is harmless. Move the dev = gc-&gt;dev assignment after the<br /> guard so it cannot dereference NULL.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53285

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED<br /> <br /> [Why]<br /> dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with<br /> DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(),<br /> which disables local softirqs.<br /> <br /> The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to<br /> allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path,<br /> which calls BUG_ON(in_interrupt()) because it&amp;#39;s invoked within the<br /> FPU-enabled (softirq disabled) region, leading to a kernel crash.<br /> <br /> [How]<br /> Wrap the dc_state_create_phantom_plane() call with the<br /> DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during<br /> this memory allocation.<br /> <br /> (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53286

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix double free and use-after-free in aux device error paths<br /> <br /> When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or<br /> idpf_plug_core_aux_dev(), the err_aux_dev_add label calls<br /> auxiliary_device_uninit() and falls through to err_aux_dev_init. The<br /> uninit call will trigger put_device(), which invokes the release<br /> callback (idpf_vport_adev_release / idpf_core_adev_release) that frees<br /> iadev. The fall-through then reads adev-&gt;id from the freed iadev for<br /> ida_free() and double-frees iadev with kfree().<br /> <br /> Free the IDA slot and clear the back-pointer before uninit, while adev<br /> is still valid, then return immediately.<br /> <br /> Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization")<br /> fixed the same use-after-free in the matching unplug path in this file but<br /> missed both probe error paths.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53287

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix incorrect inheritable capability in CAPSET records<br /> <br /> __audit_log_capset() records the effective capability set into the<br /> inheritable field due to a copy-paste error. Every CAPSET audit<br /> record therefore reports cap_pi (process inheritable) with the value<br /> of cap_effective instead of cap_inheritable.<br /> <br /> This silently corrupts audit data used for compliance and forensic<br /> analysis: an attacker who modifies inheritable capabilities to<br /> prepare for a privilege-escalating exec would have the change masked<br /> in the audit trail.<br /> <br /> The bug has been present since the original introduction of CAPSET<br /> audit records in 2008.
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026

CVE-2026-53288

Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Reserve an extra page for early kernel mapping<br /> <br /> The final part of [data, end) segment may overflow into the next page of<br /> init_pg_end[1] which is the gap page before early_init_stack[2]:<br /> <br /> [1]<br /> crash_arm64_v9.0.1&gt; vtop ffffffed00601000<br /> VIRTUAL PHYSICAL<br /> ffffffed00601000 83401000<br /> <br /> PAGE DIRECTORY: ffffffecffd62000<br /> PGD: ffffffecffd62da0 =&gt; 10000000833fb003<br /> PMD: ffffff80033fb018 =&gt; 10000000833fe003<br /> PTE: ffffff80033fe008 =&gt; 68000083401f03<br /> PAGE: 83401000<br /> <br /> PTE PHYSICAL FLAGS<br /> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)<br /> <br /> PAGE PHYSICAL MAPPING INDEX CNT FLAGS<br /> fffffffec00d0040 83401000 0 0 1 4000 reserved<br /> <br /> [2]<br /> ffffffed002c8000 (r) __pi__data<br /> ffffffed0054e000 (d) __pi___bss_start<br /> ffffffed005f5000 (b) __pi_init_pg_dir<br /> ffffffed005fe000 (b) __pi_init_pg_end<br /> ffffffed005ff000 (B) early_init_stack<br /> ffffffed00608000 (b) __pi__end<br /> <br /> For 4K pages, the early kernel mapping may use 2MB block entries but the<br /> kernel segments are only 64KB aligned. Segment boundaries that fall<br /> within a 2MB block therefore require a PTE table so that different<br /> attributes can be applied on either side of the boundary.<br /> <br /> KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel<br /> VMAs registered by declare_kernel_vmas(). However, since commit<br /> 5973a62efa34 ("arm64: map [_text, _stext) virtual address range<br /> non-executable+read-only"), the early mapper also maps [_text, _stext)<br /> separately from [_stext, _etext). This adds one more early-only split<br /> and can require one more page-table page than the existing<br /> EARLY_SEGMENT_EXTRA_PAGES allowance reserves.<br /> <br /> Increase the 4K-page early mapping allowance by one page to cover that<br /> additional split.<br /> <br /> [catalin.marinas@arm.com: rewrote part of the commit log]<br /> [catalin.marinas@arm.com: expanded the code comment]
Severity CVSS v4.0: Pending analysis
Last modification:
30/06/2026