Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Go to Calendar     Go to Press Room     Go to Newsletters subscription

Search

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-43103
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lapbether: handle NETDEV_PRE_TYPE_CHANGE<br /> <br /> lapbeth_data_transmit() expects the underlying device type<br /> to be ARPHRD_ETHER.<br /> <br /> Returning NOTIFY_BAD from lapbeth_device_event() makes sure<br /> bonding driver can not break this expectation.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43104
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Fix a memory leak in hang state error path<br /> <br /> When vc4_save_hang_state() encounters an early return condition, it<br /> returns without freeing the previously allocated `kernel_state`,<br /> leaking memory.<br /> <br /> Add the missing kfree() calls by consolidating the early return paths<br /> into a single place.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43096
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv: Fix infinite fault loop on permission-denied GPA intercepts<br /> <br /> Prevent infinite fault loops when guests access memory regions without<br /> proper permissions. Currently, mshv_handle_gpa_intercept() attempts to<br /> remap pages for all faults on movable memory regions, regardless of<br /> whether the access type is permitted. When a guest writes to a read-only<br /> region, the remap succeeds but the region remains read-only, causing<br /> immediate re-fault and spinning the vCPU indefinitely.<br /> <br /> Validate intercept access type against region permissions before<br /> attempting remaps. Reject writes to non-writable regions and executes to<br /> non-executable regions early, returning false to let the VMM handle the<br /> intercept appropriately.<br /> <br /> This also closes a potential DoS vector where malicious guests could<br /> intentionally trigger these fault loops to consume host resources.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43097
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: hv: Fix double ida_free in hv_pci_probe error path<br /> <br /> If hv_pci_probe() fails after storing the domain number in<br /> hbus-&gt;bridge-&gt;domain_nr, there is a call to free this domain_nr via<br /> pci_bus_release_emul_domain_nr(), however, during cleanup, the bridge<br /> release callback pci_release_host_bridge_dev() also frees the domain_nr<br /> causing ida_free to be called on same ID twice and triggering following<br /> warning:<br /> <br /> ida_free called for id=28971 which is not allocated.<br /> WARNING: lib/idr.c:594 at ida_free+0xdf/0x160, CPU#0: kworker/0:2/198<br /> Call Trace:<br /> pci_bus_release_emul_domain_nr+0x17/0x20<br /> pci_release_host_bridge_dev+0x4b/0x60<br /> device_release+0x3b/0xa0<br /> kobject_put+0x8e/0x220<br /> devm_pci_alloc_host_bridge_release+0xe/0x20<br /> devres_release_all+0x9a/0xd0<br /> device_unbind_cleanup+0x12/0xa0<br /> really_probe+0x1c5/0x3f0<br /> vmbus_add_channel_work+0x135/0x1a0<br /> <br /> Fix this by letting pci core handle the free domain_nr and remove<br /> the explicit free called in pci-hyperv driver.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43098
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: s3fwrn5: allocate rx skb before consuming bytes<br /> <br /> s3fwrn82_uart_read() reports the number of accepted bytes to the serdev<br /> core. The current code consumes bytes into recv_skb and may already<br /> deliver a complete frame before allocating a fresh receive buffer.<br /> <br /> If that alloc_skb() fails, the callback returns 0 even though it has<br /> already consumed bytes, and it leaves recv_skb as NULL for the next<br /> receive callback. That breaks the receive_buf() accounting contract and<br /> can also lead to a NULL dereference on the next skb_put_u8().<br /> <br /> Allocate the receive skb lazily before consuming the next byte instead.<br /> If allocation fails, return the number of bytes already accepted.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43091
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Wait for RCU readers during policy netns exit<br /> <br /> xfrm_policy_fini() frees the policy_bydst hash tables after flushing the<br /> policy work items and deleting all policies, but it does not wait for<br /> concurrent RCU readers to leave their read-side critical sections first.<br /> <br /> The policy_bydst tables are published via rcu_assign_pointer() and are<br /> looked up through rcu_dereference_check(), so netns teardown must also<br /> wait for an RCU grace period before freeing the table memory.<br /> <br /> Fix this by adding synchronize_rcu() before freeing the policy hash tables.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43093
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: tighten UMEM headroom validation to account for tailroom and min frame<br /> <br /> The current headroom validation in xdp_umem_reg() could leave us with<br /> insufficient space dedicated to even receive minimum-sized ethernet<br /> frame. Furthermore if multi-buffer would come to play then<br /> skb_shared_info stored at the end of XSK frame would be corrupted.<br /> <br /> HW typically works with 128-aligned sizes so let us provide this value<br /> as bare minimum.<br /> <br /> Multi-buffer setting is known later in the configuration process so<br /> besides accounting for 128 bytes, let us also take care of tailroom space<br /> upfront.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43088
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_key: zero aligned sockaddr tail in PF_KEY exports<br /> <br /> PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr<br /> payload space, so IPv6 addresses occupy 32 bytes on the wire. However,<br /> `pfkey_sockaddr_fill()` initializes only the first 28 bytes of<br /> `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.<br /> <br /> Not every PF_KEY message is affected. The state and policy dump builders<br /> already zero the whole message buffer before filling the sockaddr<br /> payloads. Keep the fix to the export paths that still append aligned<br /> sockaddr payloads with plain `skb_put()`:<br /> <br /> - `SADB_ACQUIRE`<br /> - `SADB_X_NAT_T_NEW_MAPPING`<br /> - `SADB_X_MIGRATE`<br /> <br /> Fix those paths by clearing only the aligned sockaddr tail after<br /> `pfkey_sockaddr_fill()`.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43089
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm_user: fix info leak in build_mapping()<br /> <br /> struct xfrm_usersa_id has a one-byte padding hole after the proto<br /> field, which ends up never getting set to zero before copying out to<br /> userspace. Fix that up by zeroing out the whole structure before<br /> setting individual variables.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43090
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix refcount leak in xfrm_migrate_policy_find<br /> <br /> syzkaller reported a memory leak in xfrm_policy_alloc:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888114d79000 (size 1024):<br /> comm "syz.1.17", pid 931<br /> ...<br /> xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432<br /> <br /> The root cause is a double call to xfrm_pol_hold_rcu() in<br /> xfrm_migrate_policy_find(). The lookup function already returns<br /> a policy with held reference, making the second call redundant.<br /> <br /> Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount<br /> imbalance and prevent the memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43092
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: validate MTU against usable frame size on bind<br /> <br /> AF_XDP bind currently accepts zero-copy pool configurations without<br /> verifying that the device MTU fits into the usable frame space provided<br /> by the UMEM chunk.<br /> <br /> This becomes a problem since we started to respect tailroom which is<br /> subtracted from chunk_size (among with headroom). 2k chunk size might<br /> not provide enough space for standard 1500 MTU, so let us catch such<br /> settings at bind time. Furthermore, validate whether underlying HW will<br /> be able to satisfy configured MTU wrt XSK&amp;#39;s frame size multiplied by<br /> supported Rx buffer chain length (that is exposed via<br /> net_device::xdp_zc_max_segs).
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026

CVE-2026-43094
Publication date:
06/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: add missing negotiate_features op to Hyper-V ops table<br /> <br /> Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by<br /> negotiating supported features") added the .negotiate_features callback<br /> to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot<br /> to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL<br /> on Hyper-V VMs.<br /> <br /> During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(),<br /> which unconditionally dereferences hw-&gt;mac.ops.negotiate_features().<br /> On Hyper-V this results in a NULL pointer dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...]<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:0x0<br /> [...]<br /> Call Trace:<br /> ixgbevf_negotiate_api+0x66/0x160 [ixgbevf]<br /> ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf]<br /> ixgbevf_probe+0x20f/0x4a0 [ixgbevf]<br /> local_pci_probe+0x50/0xa0<br /> work_for_cpu_fn+0x1a/0x30<br /> [...]<br /> <br /> Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and<br /> wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP<br /> gracefully.
Severity CVSS v4.0: Pending analysis
Last modification:
06/05/2026
Subscribe to Vulnerabilities