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-63984
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()<br /> <br /> ipv6_rpl_srh_decompress() computes:<br /> <br /> outhdr-&gt;hdrlen = (((n + 1) * sizeof(struct in6_addr)) &gt;&gt; 3);<br /> <br /> hdrlen is __u8. For n &gt;= 127 the result exceeds 255 and silently<br /> truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):<br /> <br /> (128 * 16) &gt;&gt; 3 = 256, truncated to 0 as __u8<br /> <br /> The caller in ipv6_rpl_srh_rcv() then places the compressed header<br /> at buf + ((ohdr-&gt;hdrlen + 1) &gt; 3 = 254, which fits in __u8. The compressed<br /> header then lands at buf + ((254 + 1)
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63985
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: eeprom: add more safeties to EEPROM Netlink fallback<br /> <br /> The Netlink fallback path for reading module EEPROM<br /> (fallback_set_params()) validates that offset total_len)<br /> return -EINVAL;<br /> <br /> This could lead to surprises in both drivers and device FW.<br /> Add the missing offset + length validation to fallback_set_params(),<br /> mirroring the ioctl.<br /> <br /> Similarly - ethtool core in general, and ethtool_get_any_eeprom()<br /> in particular tries to zero-init all buffers passed to the drivers<br /> to avoid any extra work of zeroing things out. eeprom_fallback()<br /> uses a plain kmalloc(), change it to zalloc.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63986
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: tsinfo: don&amp;#39;t pass ERR_PTR to genlmsg_cancel on prepare failure<br /> <br /> The goto err label leads to:<br /> <br /> genlmsg_cancel(skb, ehdr);<br /> return ret;<br /> <br /> If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg.<br /> There&amp;#39;s nothing to cancel, and passing an error pointer to<br /> genlmsg_cancel() would cause a crash.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63987
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES<br /> <br /> ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION<br /> nest list with an index &amp;#39;i&amp;#39; and writes new_profile[i++] without<br /> bounding i. The destination is kmemdup()&amp;#39;d at NET_DIM_PARAMS_NUM_PROFILES<br /> entries (5), but the Netlink nest count is entirely user-controlled.<br /> Netlink policies do not have support for constraining the number<br /> of nested entries (or number of multi-attr entries).
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63970
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: bind uarg before filling zerocopy skb<br /> <br /> virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg<br /> before entering the send loop, but virtio_transport_alloc_skb() still<br /> fills the skb before it inherits that uarg. When fixed-buffer vectored<br /> zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach<br /> managed frags and return -EMSGSIZE. The rollback path call kfree_skb()<br /> to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so<br /> skb_release_data() falls through to ordinary frag unref.<br /> <br /> Pass the uarg into virtio_transport_alloc_skb() and bind it immediately<br /> before virtio_transport_fill_skb(). This keeps control or no-payload skbs<br /> untouched while ensuring success and rollback share one lifetime rule.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63971
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix race between sctp_wait_for_connect and peeloff<br /> <br /> sctp_wait_for_connect() drops and re-acquires the socket lock while<br /> waiting for the association to reach ESTABLISHED state. During this<br /> window, another thread can peeloff the association to a new socket via<br /> getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc-&gt;base.sk. After<br /> re-acquiring the old socket lock, sctp_wait_for_connect() returns<br /> success without noticing the migration — the caller then accesses<br /> the association under the wrong lock in sctp_datamsg_from_user().<br /> <br /> Add the same sk != asoc-&gt;base.sk check that sctp_wait_for_sndbuf()<br /> already has, returning an error if the association was migrated while<br /> we slept.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63972
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Skip redundant detach on already-detached port<br /> <br /> When mana_per_port_queue_reset_work_handler() runs after a previous<br /> detach succeeded but attach failed, the port is left in a detached<br /> state with apc-&gt;tx_qp and apc-&gt;rxqs already freed. Calling<br /> mana_detach() again unconditionally leads to NULL pointer dereferences<br /> during queue teardown.<br /> <br /> Add an early exit in mana_detach() when the port is already in<br /> detached state (!netif_device_present) for non-close callers, making<br /> it safe to call idempotently. This allows the queue reset handler and<br /> other recovery paths to simply retry mana_attach() without redundant<br /> teardown.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63973
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Add NULL guards in teardown path to prevent panic on attach failure<br /> <br /> When queue allocation fails partway through, the error cleanup frees<br /> and NULLs apc-&gt;tx_qp and apc-&gt;rxqs. Multiple teardown paths such as<br /> mana_remove(), mana_change_mtu() recovery, and internal error handling<br /> in mana_alloc_queues() can subsequently call into functions that<br /> dereference these pointers without NULL checks:<br /> <br /> - mana_chn_setxdp() dereferences apc-&gt;rxqs[0], causing a NULL pointer<br /> dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26).<br /> - mana_destroy_vport() iterates apc-&gt;rxqs without a NULL check.<br /> - mana_fence_rqs() iterates apc-&gt;rxqs without a NULL check.<br /> - mana_dealloc_queues() iterates apc-&gt;tx_qp without a NULL check.<br /> <br /> Add NULL guards for apc-&gt;rxqs in mana_fence_rqs(),<br /> mana_destroy_vport(), and before the mana_chn_setxdp() call. Add a<br /> NULL guard for apc-&gt;tx_qp in mana_dealloc_queues() to skip TX queue<br /> draining when TX queues were never allocated or already freed.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63974
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close<br /> <br /> Since hci_dev_close_sync() can now be called during the reset path, we<br /> should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts<br /> while the hdev workqueue is being drained.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63975
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp<br /> <br /> If dcid is received for an already-assigned destination CID the spec<br /> requires that both channels to be discarded, but calling l2cap_chan_del<br /> may invalidate the tmp cursor created by list_for_each_entry_safe and<br /> in fact it is the wrong procedure as the chan-&gt;dcid may be assigned<br /> previously it really needs to be disconnected.<br /> <br /> Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so<br /> instead schedule l2cap_chan_timeout with delay 0 to close the channel<br /> asynchronously.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63976
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: clear chan-&gt;ident on ECRED reconfiguration success<br /> <br /> l2cap_ecred_reconf_rsp() returns early on success without clearing<br /> chan-&gt;ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp,<br /> l2cap_le_connect_rsp, l2cap_config_rsp) clears chan-&gt;ident after a<br /> successful transaction to prevent the channel from matching subsequent<br /> responses with the recycled ident value.<br /> <br /> A remote attacker that completed a reconfiguration as the peer can<br /> replay a failure response with the stale ident, causing the kernel to<br /> match and destroy the already-established channel via<br /> l2cap_chan_del(chan, ECONNRESET).<br /> <br /> Clear chan-&gt;ident for all matching channels on success, and harden the<br /> failure path by using l2cap_chan_hold_unless_zero() consistent with<br /> other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026

CVE-2026-63977
Publication date:
19/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: zl3073x: use __dpll_device_change_ntf() and remove change_work<br /> <br /> The change_work was introduced to send device change notifications<br /> from DPLL device callbacks without deadlocking on dpll_lock, since<br /> the callbacks are already invoked under that lock. Now that<br /> __dpll_device_change_ntf() is exported for callers that already<br /> hold dpll_lock, use it directly and remove the change_work<br /> infrastructure entirely.<br /> <br /> This eliminates a race condition where change_work could be<br /> re-scheduled after cancel_work_sync() during device teardown,<br /> potentially causing the handler to dereference a freed or NULL<br /> dpll_dev pointer.
Severity CVSS v4.0: Pending analysis
Last modification:
19/07/2026
Subscribe to Vulnerabilities