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-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:
08/10/2025

CVE-2025-11400

Publication date:
07/10/2025
A vulnerability was detected in SourceCodester Hotel and Lodge Management System 1.0. This impacts an unknown function of the file /del_room.php. The manipulation of the argument ID results in sql injection. The attack can be executed remotely. The exploit is now public and may be used.
Severity CVSS v4.0: MEDIUM
Last modification:
09/10/2025

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-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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

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:
08/10/2025

CVE-2023-53671

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL<br /> <br /> Commit 994f706872e6 ("srcu: Make Tree SRCU able to operate without<br /> snp_node array") assumes that cpu 0 is always online. However, there<br /> really are situations when some other CPU is the boot CPU, for example,<br /> when booting a kdump kernel with the maxcpus=1 boot parameter.<br /> <br /> On PowerPC, the kdump kernel can hang as follows:<br /> ...<br /> [ 1.740036] systemd[1]: Hostname set to <br /> [ 243.686240] INFO: task systemd:1 blocked for more than 122 seconds.<br /> [ 243.686264] Not tainted 6.1.0-rc1 #1<br /> [ 243.686272] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000<br /> [ 243.686296] Call Trace:<br /> [ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable)<br /> [ 243.686317] [c000000016657830] [c00000001001dec0] __switch_to+0x130/0x220<br /> [ 243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580<br /> [ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140<br /> [ 243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+0x168/0x1c0<br /> [ 243.686374] [c000000016657a80] [c000000010f61de8] __wait_for_common+0x148/0x360<br /> [ 243.686387] [c000000016657b20] [c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0<br /> [ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40<br /> [ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160<br /> [ 243.686428] [c000000016657c40] [c0000000105f6500] inotify_release+0x30/0xa0<br /> [ 243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350<br /> [ 243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170<br /> [ 243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140<br /> [ 243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270<br /> [ 243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180<br /> [ 243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280<br /> [ 243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4<br /> [ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000<br /> [ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1)<br /> [ 243.686548] MSR: 800000000000d033 CR: 42044440 XER: 00000000<br /> [ 243.686572] IRQMASK: 0<br /> [ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000<br /> [ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001<br /> [ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000<br /> [ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000<br /> [ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000<br /> [ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570<br /> [ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98<br /> [ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4<br /> [ 243.686691] LR [0000000000000000] 0x0<br /> [ 243.686698] --- interrupt: 3000<br /> [ 243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.<br /> [ 243.686717] Not tainted 6.1.0-rc1 #1<br /> [ 243.686724] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800<br /> [ 243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn<br /> [ 243.686758] Call Trace:<br /> [ 243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable)<br /> [ 243.686775] [c0000000166738d0] [c00000001001dec0] __switch_to+0x130/0x220<br /> [ 243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
08/10/2025