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-11399

Publication date:
07/10/2025
A security vulnerability has been detected in SourceCodester Hotel and Lodge Management System 1.0. This affects an unknown function of the file /pages/save_room.php. The manipulation of the argument floorno leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used.
Severity CVSS v4.0: MEDIUM
Last modification:
09/10/2025

CVE-2023-53687

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk<br /> <br /> When the best clk is searched, we iterate over all possible clk.<br /> <br /> If we find a better match, the previous one, if any, needs to be freed.<br /> If a better match has already been found, we still need to free the new<br /> one, otherwise it leaks.
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53686

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: fix null-ptr-deref in handshake_nl_done_doit()<br /> <br /> We should not call trace_handshake_cmd_done_err() if socket lookup has failed.<br /> <br /> Also we should call trace_handshake_cmd_done_err() before releasing the file,<br /> otherwise dereferencing sock-&gt;sk can return garbage.<br /> <br /> This also reverts 7afc6d0a107f ("net/handshake: Fix uninitialized local variable")<br /> <br /> Unable to handle kernel paging request at virtual address dfff800000000003<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> Mem abort info:<br /> ESR = 0x0000000096000005<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [dfff800000000003] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193<br /> lr : handshake_nl_done_doit+0x180/0x9c8<br /> sp : ffff800096e37180<br /> x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000<br /> x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8<br /> x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000<br /> x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001<br /> x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003<br /> x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078<br /> x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000<br /> Call trace:<br /> handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]<br /> genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067<br /> netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549<br /> genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914<br /> sock_sendmsg_nosec net/socket.c:725 [inline]<br /> sock_sendmsg net/socket.c:748 [inline]<br /> ____sys_sendmsg+0x56c/0x840 net/socket.c:2494<br /> ___sys_sendmsg net/socket.c:2548 [inline]<br /> __sys_sendmsg+0x26c/0x33c net/socket.c:2577<br /> __do_sys_sendmsg net/socket.c:2586 [inline]<br /> __se_sys_sendmsg net/socket.c:2584 [inline]<br /> __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584<br /> __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155<br /> el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591<br /> Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908)
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53685

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: Fix memory leak for detached NAPI queue.<br /> <br /> syzkaller reported [0] memory leaks of sk and skb related to the TUN<br /> device with no repro, but we can reproduce it easily with:<br /> <br /> struct ifreq ifr = {}<br /> int fd_tun, fd_tmp;<br /> char buf[4] = {};<br /> <br /> fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0);<br /> ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;<br /> ioctl(fd_tun, TUNSETIFF, &amp;ifr);<br /> <br /> ifr.ifr_flags = IFF_DETACH_QUEUE;<br /> ioctl(fd_tun, TUNSETQUEUE, &amp;ifr);<br /> <br /> fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);<br /> ifr.ifr_flags = IFF_UP;<br /> ioctl(fd_tmp, SIOCSIFFLAGS, &amp;ifr);<br /> <br /> write(fd_tun, buf, sizeof(buf));<br /> close(fd_tun);<br /> <br /> If we enable NAPI and multi-queue on a TUN device, we can put skb into<br /> tfile-&gt;sk.sk_write_queue after the queue is detached. We should prevent<br /> it by checking tfile-&gt;detached before queuing skb.<br /> <br /> Note this must be done under tfile-&gt;sk.sk_write_queue.lock because write()<br /> and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would<br /> be a small race window:<br /> <br /> write() ioctl(IFF_DETACH_QUEUE)<br /> `- tun_get_user `- __tun_detach<br /> |- if (tfile-&gt;detached) |- tun_disable_queue<br /> | `-&gt; false | `- tfile-&gt;detached = tun<br /> | `- tun_queue_purge<br /> |- spin_lock_bh(&amp;queue-&gt;lock)<br /> `- __skb_queue_tail(queue, skb)<br /> <br /> Another solution is to call tun_queue_purge() when closing and<br /> reattaching the detached queue, but it could paper over another<br /> problems. Also, we do the same kind of test for IFF_NAPI_FRAGS.<br /> <br /> [0]:<br /> unreferenced object 0xffff88801edbc800 (size 2048):<br /> comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............<br /> backtrace:<br /> [] __do_kmalloc_node mm/slab_common.c:965 [inline]<br /> [] __kmalloc+0x4a/0x130 mm/slab_common.c:979<br /> [] kmalloc include/linux/slab.h:563 [inline]<br /> [] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035<br /> [] sk_alloc+0x36/0x2f0 net/core/sock.c:2088<br /> [] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438<br /> [] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165<br /> [] chrdev_open+0x111/0x300 fs/char_dev.c:414<br /> [] do_dentry_open+0x2f9/0x750 fs/open.c:920<br /> [] do_open fs/namei.c:3636 [inline]<br /> [] path_openat+0x143f/0x1a30 fs/namei.c:3791<br /> [] do_filp_open+0xce/0x1c0 fs/namei.c:3818<br /> [] do_sys_openat2+0xf0/0x260 fs/open.c:1356<br /> [] do_sys_open fs/open.c:1372 [inline]<br /> [] __do_sys_openat fs/open.c:1388 [inline]<br /> [] __se_sys_openat fs/open.c:1383 [inline]<br /> [] __x64_sys_openat+0x83/0xf0 fs/open.c:1383<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> unreferenced object 0xffff88802f671700 (size 240):<br /> comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s)<br /> hex dump (first 32 bytes):<br /> 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h.......<br /> 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............<br /> backtrace:<br /> [] __alloc_skb+0x223/0x250 net/core/skbuff.c:644<br /> [] alloc_skb include/linux/skbuff.h:1288 [inline]<br /> [] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378<br /> [] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729<br /> [] tun_alloc_skb drivers/net/tun.c:1529 [inline]<br /> [
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53684

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Zero padding when dumping algos and encap<br /> <br /> When copying data to user-space we should ensure that only valid<br /> data is copied over. Padding in structures may be filled with<br /> random (possibly sensitve) data and should never be given directly<br /> to user-space.<br /> <br /> This patch fixes the copying of xfrm algorithms and the encap<br /> template in xfrm_user so that padding is zeroed.
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53683

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()<br /> <br /> syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for<br /> crafted filesystem image can contain bogus length. There conditions are<br /> not kernel bugs that can justify kernel to panic.
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53682

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (xgene) Fix ioremap and memremap leak<br /> <br /> Smatch reports:<br /> <br /> drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:<br /> &amp;#39;ctx-&gt;pcc_comm_addr&amp;#39; from ioremap() not released on line: 757.<br /> <br /> This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),<br /> ioremap and memremap is not released, which may cause a leak.<br /> <br /> To fix this, ioremap and memremap is modified to devm_ioremap and<br /> devm_memremap.<br /> <br /> [groeck: Fixed formatting and subject]
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53681

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent<br /> <br /> In some specific situations, the return value of __bch_btree_node_alloc<br /> may be NULL. This may lead to a potential NULL pointer dereference in<br /> caller function like a calling chain :<br /> btree_split-&gt;bch_btree_node_alloc-&gt;__bch_btree_node_alloc.<br /> <br /> Fix it by initializing the return value in __bch_btree_node_alloc.
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53680

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Avoid calling OPDESC() with ops-&gt;opnum == OP_ILLEGAL<br /> <br /> OPDESC() simply indexes into nfsd4_ops[] by the op&amp;#39;s operation<br /> number, without range checking that value. It assumes callers are<br /> careful to avoid calling it with an out-of-bounds opnum value.<br /> <br /> nfsd4_decode_compound() is not so careful, and can invoke OPDESC()<br /> with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end<br /> of nfsd4_ops[].
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53679

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt7601u: fix an integer underflow<br /> <br /> Fix an integer underflow that leads to a null pointer dereference in<br /> &amp;#39;mt7601u_rx_skb_from_seg()&amp;#39;. The variable &amp;#39;dma_len&amp;#39; in the URB packet<br /> could be manipulated, which could trigger an integer underflow of<br /> &amp;#39;seg_len&amp;#39; in &amp;#39;mt7601u_rx_process_seg()&amp;#39;. This underflow subsequently<br /> causes the &amp;#39;bad_frame&amp;#39; checks in &amp;#39;mt7601u_rx_skb_from_seg()&amp;#39; to be<br /> bypassed, eventually leading to a dereference of the pointer &amp;#39;p&amp;#39;, which<br /> is a null pointer.<br /> <br /> Ensure that &amp;#39;dma_len&amp;#39; is greater than &amp;#39;min_seg_len&amp;#39;.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+<br /> #139<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:skb_add_rx_frag+0x143/0x370<br /> Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44<br /> 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 3c 02<br /> 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00<br /> RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8<br /> RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010<br /> R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000<br /> R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008<br /> FS: 0000000000000000(0000) GS:ffff88811a800000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> mt7601u_rx_tasklet+0xc73/0x1270<br /> ? mt7601u_submit_rx_buf.isra.0+0x510/0x510<br /> ? tasklet_action_common.isra.0+0x79/0x2f0<br /> tasklet_action_common.isra.0+0x206/0x2f0<br /> __do_softirq+0x1b5/0x880<br /> ? tasklet_unlock+0x30/0x30<br /> run_ksoftirqd+0x26/0x50<br /> smpboot_thread_fn+0x34f/0x7d0<br /> ? smpboot_register_percpu_thread+0x370/0x370<br /> kthread+0x3a1/0x480<br /> ? set_kthread_struct+0x120/0x120<br /> ret_from_fork+0x1f/0x30<br /> Modules linked in: 88XXau(O) 88x2bu(O)<br /> ---[ end trace 57f34f93b4da0f9b ]---<br /> RIP: 0010:skb_add_rx_frag+0x143/0x370<br /> Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44<br /> 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 3c 02<br /> 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00<br /> RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8<br /> RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010<br /> R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000<br /> R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008<br /> FS: 0000000000000000(0000) GS:ffff88811a800000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53678

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix system suspend without fbdev being initialized<br /> <br /> If fbdev is not initialized for some reason - in practice on platforms<br /> without display - suspending fbdev should be skipped during system<br /> suspend, fix this up. While at it add an assert that suspending fbdev<br /> only happens with the display present.<br /> <br /> This fixes the following:<br /> <br /> [ 91.227923] PM: suspend entry (s2idle)<br /> [ 91.254598] Filesystems sync: 0.025 seconds<br /> [ 91.270518] Freezing user space processes<br /> [ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds)<br /> [ 91.272686] OOM killer disabled.<br /> [ 91.272872] Freezing remaining freezable tasks<br /> [ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)<br /> [ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8<br /> [ 91.659981] #PF: supervisor write access in kernel mode<br /> [ 91.660252] #PF: error_code(0x0002) - not-present page<br /> [ 91.660511] PGD 0 P4D 0<br /> [ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54<br /> [ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown<br /> [ 91.661680] RIP: 0010:mutex_lock+0x19/0x30<br /> [ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40<br /> [ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246<br /> [ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000<br /> [ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8<br /> [ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0<br /> [ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20<br /> [ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000<br /> [ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0<br /> [ 91.665988] PKRU: 55555554<br /> [ 91.666131] Call Trace:<br /> [ 91.666265] <br /> [ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915]<br /> [ 91.666738] i915_drm_suspend+0xb9/0x100 [i915]<br /> [ 91.667029] pci_pm_suspend+0x78/0x170<br /> [ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10<br /> [ 91.667461] dpm_run_callback+0x47/0x150<br /> [ 91.667673] __device_suspend+0x10a/0x4e0<br /> [ 91.667880] dpm_suspend+0x134/0x270<br /> [ 91.668069] dpm_suspend_start+0x79/0x80<br /> [ 91.668272] suspend_devices_and_enter+0x11b/0x890<br /> [ 91.668526] pm_suspend.cold+0x270/0x2fc<br /> [ 91.668737] state_store+0x46/0x90<br /> [ 91.668916] kernfs_fop_write_iter+0x11b/0x200<br /> [ 91.669153] vfs_write+0x1e1/0x3a0<br /> [ 91.669336] ksys_write+0x53/0xd0<br /> [ 91.669510] do_syscall_64+0x58/0xc0<br /> [ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0<br /> [ 91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0<br /> [ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40<br /> [ 91.670524] ? do_syscall_64+0x67/0xc0<br /> [ 91.670717] ? __irq_exit_rcu+0x3d/0x140<br /> [ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [ 91.671202] RIP: 0033:0x7f28ffd14284<br /> <br /> v2: CC stable. (Jani)<br /> <br /> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015<br /> (cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2)
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026

CVE-2023-53677

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix memory leaks in i915 selftests<br /> <br /> This patch fixes memory leaks on error escapes in function fake_get_pages<br /> <br /> (cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567)
Severity CVSS v4.0: Pending analysis
Last modification:
03/02/2026