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-2022-50829

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()<br /> <br /> It is possible that skb is freed in ath9k_htc_rx_msg(), then<br /> usb_submit_urb() fails and we try to free skb again. It causes<br /> use-after-free bug. Moreover, if alloc_skb() fails, urb-&gt;context becomes<br /> NULL but rx_buf is not freed and there can be a memory leak.<br /> <br /> The patch removes unnecessary nskb and makes skb processing more clear: it<br /> is supposed that ath9k_htc_rx_msg() either frees old skb or passes its<br /> managing to another callback function.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50830

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()<br /> <br /> hd44780_probe() allocates a memory chunk for hd with kzalloc() and<br /> makes "lcd-&gt;drvdata-&gt;hd44780" point to it. When we call hd44780_remove(),<br /> we should release all relevant memory and resource. But "lcd-&gt;drvdata<br /> -&gt;hd44780" is not released, which will lead to a memory leak.<br /> <br /> We should release the "lcd-&gt;drvdata-&gt;hd44780" in hd44780_remove() to fix<br /> the memory leak bug.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50832

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()<br /> <br /> The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, add<br /> dev_kfree_skb() to fix it. Compile tested only.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50833

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: use hdev-&gt;workqueue when queuing hdev-&gt;{cmd,ncmd}_timer works<br /> <br /> syzbot is reporting attempt to schedule hdev-&gt;cmd_work work from system_wq<br /> WQ into hdev-&gt;workqueue WQ which is under draining operation [1], for<br /> commit c8efcc2589464ac7 ("workqueue: allow chained queueing during<br /> destruction") does not allow such operation.<br /> <br /> The check introduced by commit 877afadad2dce8aa ("Bluetooth: When HCI work<br /> queue is drained, only queue chained work") was incomplete.<br /> <br /> Use hdev-&gt;workqueue WQ when queuing hdev-&gt;{cmd,ncmd}_timer works because<br /> hci_{cmd,ncmd}_timeout() calls queue_work(hdev-&gt;workqueue). Also, protect<br /> the queuing operation with RCU read lock in order to avoid calling<br /> queue_delayed_work() after cancel_delayed_work() completed.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50834

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: Fix potential resource leaks<br /> <br /> nfc_get_device() take reference for the device, add missing<br /> nfc_put_device() to release it when not need anymore.<br /> Also fix the style warnning by use error EOPNOTSUPP instead of<br /> ENOTSUPP.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50817

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: avoid possible NULL deref in skb_clone()<br /> <br /> syzbot got a crash [1] in skb_clone(), caused by a bug<br /> in hsr_get_untagged_frame().<br /> <br /> When/if create_stripped_skb_hsr() returns NULL, we must<br /> not attempt to call skb_clone().<br /> <br /> While we are at it, replace a WARN_ONCE() by netdev_warn_once().<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641<br /> Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00<br /> RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207<br /> <br /> RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000<br /> RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140<br /> R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640<br /> R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620<br /> FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164<br /> hsr_forward_do net/hsr/hsr_forward.c:461 [inline]<br /> hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623<br /> hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69<br /> __netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379<br /> __netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483<br /> __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599<br /> netif_receive_skb_internal net/core/dev.c:5685 [inline]<br /> netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744<br /> tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544<br /> tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995<br /> tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025<br /> call_write_iter include/linux/fs.h:2187 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x9e9/0xdd0 fs/read_write.c:584<br /> ksys_write+0x127/0x250 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50818

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix running_req for internal abort commands<br /> <br /> Disabling the remote phy for a SATA disk causes a hang:<br /> <br /> root@(none)$ more /sys/class/sas_phy/phy-0:0:8/target_port_protocols<br /> sata<br /> root@(none)$ echo 0 &gt; sys/class/sas_phy/phy-0:0:8/enable<br /> root@(none)$ [ 67.855950] sas: ex 500e004aaaaaaa1f phy08 change count has changed<br /> [ 67.920585] sd 0:0:2:0: [sdc] Synchronizing SCSI cache<br /> [ 67.925780] sd 0:0:2:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK<br /> [ 67.935094] sd 0:0:2:0: [sdc] Stopping disk<br /> [ 67.939305] sd 0:0:2:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK<br /> ...<br /> [ 123.998998] INFO: task kworker/u192:1:642 blocked for more than 30 seconds.<br /> [ 124.005960] Not tainted 6.0.0-rc1-205202-gf26f8f761e83 #218<br /> [ 124.012049] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 124.019872] task:kworker/u192:1 state:D stack:0 pid: 642 ppid: 2 flags:0x00000008<br /> [ 124.028223] Workqueue: 0000:04:00.0_event_q sas_port_event_worker<br /> [ 124.034319] Call trace:<br /> [ 124.036758] __switch_to+0x128/0x278<br /> [ 124.040333] __schedule+0x434/0xa58<br /> [ 124.043820] schedule+0x94/0x138<br /> [ 124.047045] schedule_timeout+0x2fc/0x368<br /> [ 124.051052] wait_for_completion+0xdc/0x200<br /> [ 124.055234] __flush_workqueue+0x1a8/0x708<br /> [ 124.059328] sas_porte_broadcast_rcvd+0xa8/0xc0<br /> [ 124.063858] sas_port_event_worker+0x60/0x98<br /> [ 124.068126] process_one_work+0x3f8/0x660<br /> [ 124.072134] worker_thread+0x70/0x700<br /> [ 124.075793] kthread+0x1a4/0x1b8<br /> [ 124.079014] ret_from_fork+0x10/0x20<br /> <br /> The issue is that the per-device running_req read in<br /> pm8001_dev_gone_notify() never goes to zero and we never make progress.<br /> This is caused by missing accounting for running_req for when an internal<br /> abort command completes.<br /> <br /> In commit 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support")<br /> we started to send internal abort commands as a proper sas_task. In this<br /> when we deliver a sas_task to HW the per-device running_req is incremented<br /> in pm8001_queue_command(). However it is never decremented for internal<br /> abort commnds, so decrement in pm8001_mpi_task_abort_resp().
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50819

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: Set ubuf-&gt;sg = NULL if the creation of sg table fails<br /> <br /> When userspace tries to map the dmabuf and if for some reason<br /> (e.g. OOM) the creation of the sg table fails, ubuf-&gt;sg needs to be<br /> set to NULL. Otherwise, when the userspace subsequently closes the<br /> dmabuf fd, we&amp;#39;d try to erroneously free the invalid sg table from<br /> release_udmabuf resulting in the following crash reported by syzbot:<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 3609 Comm: syz-executor487 Not tainted<br /> 5.19.0-syzkaller-13930-g7ebfc85e2cd7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 07/22/2022<br /> RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]<br /> RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]<br /> RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114<br /> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c<br /> 8b 63 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 14<br /> 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2<br /> RSP: 0018:ffffc900037efd30 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffffffff8cb67800 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff84ad27e0 RDI: 0000000000000000<br /> RBP: fffffffffffffff4 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 000000000008c07c R12: ffff88801fa05000<br /> R13: ffff888073db07e8 R14: ffff888025c25440 R15: 0000000000000000<br /> FS: 0000555555fc4300(0000) GS:ffff8880b9a00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc1c0ce06e4 CR3: 00000000715e6000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dma_buf_release+0x157/0x2d0 drivers/dma-buf/dma-buf.c:78<br /> __dentry_kill+0x42b/0x640 fs/dcache.c:612<br /> dentry_kill fs/dcache.c:733 [inline]<br /> dput+0x806/0xdb0 fs/dcache.c:913<br /> __fput+0x39c/0x9d0 fs/file_table.c:333<br /> task_work_run+0xdd/0x1a0 kernel/task_work.c:177<br /> ptrace_notify+0x114/0x140 kernel/signal.c:2353<br /> ptrace_report_syscall include/linux/ptrace.h:420 [inline]<br /> ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]<br /> syscall_exit_work kernel/entry/common.c:249 [inline]<br /> syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]<br /> syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294<br /> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fc1c0c35b6b<br /> Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24<br /> 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44<br /> RSP: 002b:00007ffd78a06090 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1c0c35b6b<br /> RDX: 0000000020000280 RSI: 0000000040086200 RDI: 0000000000000006<br /> RBP: 0000000000000007 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000000c<br /> R13: 0000000000000003 R14: 00007fc1c0cfe4a0 R15: 00007ffd78a06140<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]<br /> RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]<br /> RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50820

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()<br /> <br /> dmc620_pmu_init() won&amp;#39;t remove the callback added by<br /> cpuhp_setup_state_multi() when platform_driver_register() failed. Remove<br /> the callback by cpuhp_remove_multi_state() in fail path.<br /> <br /> Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:<br /> arm-ccn: Prevent hotplug callback leak")
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50821

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Don&amp;#39;t leak netobj memory when gss_read_proxy_verf() fails
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50822

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/restrack: Release MR restrack when delete<br /> <br /> The MR restrack also needs to be released when delete it, otherwise it<br /> cause memory leak as the task struct won&amp;#39;t be released.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025

CVE-2022-50823

Publication date:
30/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: tegra: Fix refcount leak in tegra114_clock_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
31/12/2025