Latest CVEs

• CVE-2025-40221 - media: pci: mg4b: fix uninitialized iio scan data

  CVE ID :CVE-2025-40221
  Published : Dec. 4, 2025, 2:50 p.m. | 17 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40220 - fuse: fix livelock in synchronous file put from fuseblk workers

  CVE ID :CVE-2025-40220
  Published : Dec. 4, 2025, 2:50 p.m. | 17 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [] request_wait_answer+0x1fe/0x2a0 [fuse] [] __fuse_simple_request+0xd3/0x2b0 [fuse] [] fuse_do_getattr+0xfc/0x1f0 [fuse] [] fuse_file_read_iter+0xbe/0x1c0 [fuse] [] aio_read+0x130/0x1e0 [] io_submit_one+0x542/0x860 [] __x64_sys_io_submit+0x98/0x1a0 [] do_syscall_64+0x37/0xf0 [] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [] request_wait_answer+0x1fe/0x2a0 [fuse] [] __fuse_simple_request+0xd3/0x2b0 [fuse] [] fuse_file_put+0x9a/0xd0 [fuse] [] fuse_release+0x36/0x50 [fuse] [] __fput+0xec/0x2b0 [] task_work_run+0x55/0x90 [] syscall_exit_to_user_mode+0xe9/0x100 [] do_syscall_64+0x43/0xf0 [] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40219 - PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV

  CVE ID :CVE-2025-40219
  Published : Dec. 4, 2025, 2:50 p.m. | 17 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40218 - mm/damon/vaddr: do not repeat pte_offset_map_lock() until success

  CVE ID :CVE-2025-40218
  Published : Dec. 4, 2025, 2:50 p.m. | 17 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: do not repeat pte_offset_map_lock() until success DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function. This is for reading and writing page table accessed bits. If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN. pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though. Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel. Avoid the infinite loop by simply not retrying the page table walk. DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40217 - pidfs: validate extensible ioctls

  CVE ID :CVE-2025-40217
  Published : Dec. 4, 2025, 2:50 p.m. | 18 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: pidfs: validate extensible ioctls Validate extensible ioctls stricter than we do now.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-14007 - dayrui XunRuiCMS Domain Name Binding admin79f2ec220c7e.php cross site scripting

  CVE ID :CVE-2025-14007
  Published : Dec. 4, 2025, 2:32 p.m. | 36 minutes ago
  Description :A vulnerability was detected in dayrui XunRuiCMS up to 4.7.1. This affects an unknown part of the file /admin79f2ec220c7e.php?c=api&m=demo&name=mobile of the component Domain Name Binding Page. The manipulation results in cross site scripting. The attack may be performed from remote. A high complexity level is associated with this attack. It is indicated that the exploitability is difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-14006 - dayrui XunRuiCMS Add Data Validation admind45f74adbd95.php cross site scripting

  CVE ID :CVE-2025-14006
  Published : Dec. 4, 2025, 2:32 p.m. | 36 minutes ago
  Description :A security vulnerability has been detected in dayrui XunRuiCMS up to 4.7.1. Affected by this issue is some unknown functionality of the file /admind45f74adbd95.php?c=field&m=add&rname=site&rid=1&page=1 of the component Add Data Validation Page. The manipulation of the argument data[name] leads to cross site scripting. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2024-5401 - Synology DiskStation Manager (DSM) and Synology Unified Controller (DSMUC) Privilege Escalation Vulnerability

  CVE ID :CVE-2024-5401
  Published : Dec. 4, 2025, 2:20 p.m. | 48 minutes ago
  Description :Improper control of dynamically-managed code resources vulnerability in WebAPI component in Synology DiskStation Manager (DSM) before 7.1.1-42962-8 and 7.2.1-69057-2 and 7.2.2-72806 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote authenticated users to obtain privileges without consent via unspecified vectors.
  Severity: 4.3 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2024-45539 - Synology DSM/DSMUC Out-of-bounds Write Remote Denial-of-Service Vulnerability

  CVE ID :CVE-2024-45539
  Published : Dec. 4, 2025, 2:17 p.m. | 50 minutes ago
  Description :Out-of-bounds write vulnerability in cgi components in Synology DiskStation Manager (DSM) before 7.2.1-69057-2 and 7.2.2-72806 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote attackers to conduct denial-of-service attacks via unspecified vectors.
  Severity: 7.5 | HIGH
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2024-45538 - Synology DSM CSRF Vulnerability

  CVE ID :CVE-2024-45538
  Published : Dec. 4, 2025, 2:16 p.m. | 52 minutes ago
  Description :Cross-Site Request Forgery (CSRF) vulnerability in WebAPI Framework in Synology DiskStation Manager (DSM) before 7.2.1-69057-2 and 7.2.2-72806 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote attackers to execute arbitrary code via unspecified vectors.
  Severity: 9.6 | CRITICAL
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-14005 - dayrui XunRuiCMS Add Display Name Field admind45f74adbd95.php cross site scripting

  CVE ID :CVE-2025-14005
  Published : Dec. 4, 2025, 2:16 p.m. | 52 minutes ago
  Description :A weakness has been identified in dayrui XunRuiCMS up to 4.7.1. Affected by this vulnerability is an unknown functionality of the file /admind45f74adbd95.php?c=field&m=add&rname=site&rid=1&page=0 of the component Add Display Name Field. Executing manipulation of the argument data[name] can lead to cross site scripting. The attack can be executed remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
  Severity: 4.8 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-14004 - dayrui XunRuiCMS Email Setting admind45f74adbd95.php server-side request forgery

  CVE ID :CVE-2025-14004
  Published : Dec. 4, 2025, 2:16 p.m. | 52 minutes ago
  Description :A security flaw has been discovered in dayrui XunRuiCMS up to 4.7.1. Affected is an unknown function of the file /admind45f74adbd95.php?c=email&m=add of the component Email Setting Handler. Performing manipulation results in server-side request forgery. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
  Severity: 5.8 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40216 - io_uring/rsrc: don't rely on user vaddr alignment

  CVE ID :CVE-2025-40216
  Published : Dec. 4, 2025, 2:14 p.m. | 54 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: don't rely on user vaddr alignment There is no guaranteed alignment for user pointers, however the calculation of an offset of the first page into a folio after coalescing uses some weird bit mask logic, get rid of it.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40215 - xfrm: delete x->tunnel as we delete x

  CVE ID :CVE-2025-40215
  Published : Dec. 4, 2025, 1:15 p.m. | 1 hour, 52 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: xfrm: delete x->tunnel as we delete x The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete. We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state. Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped. A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-40214 - af_unix: Initialise scc_index in unix_add_edge().

  CVE ID :CVE-2025-40214
  Published : Dec. 4, 2025, 1:15 p.m. | 1 hour, 52 minutes ago
  Description :In the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.
  Severity: 0.0 | NA
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-11222 - Central Dogma Open Redirect Vulnerability

  CVE ID :CVE-2025-11222
  Published : Dec. 4, 2025, 1:15 p.m. | 1 hour, 52 minutes ago
  Description :Central Dogma versions before 0.78.0 contain an Open Redirect vulnerability that allows attackers to redirect users to untrusted sites via specially crafted URLs, potentially facilitating phishing attacks and credential theft.
  Severity: 6.1 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-41080 - Multiple vulnerabilities in Seafile

  CVE ID :CVE-2025-41080
  Published : Dec. 4, 2025, 12:16 p.m. | 2 hours, 52 minutes ago
  Description :A stored Cross-Site Scripting (XSS) vulnerability has been found in Seafile v12.0.10. This vulnerability allows an attacker to execute arbitrary code in the victim's browser by storing malicious payloads with POST parámetro 'p' in '/api/v2.1/repos/{repo_id}/file/'.
  Severity: 5.1 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-41079 - Multiple vulnerabilities in Seafile

  CVE ID :CVE-2025-41079
  Published : Dec. 4, 2025, 12:16 p.m. | 2 hours, 52 minutes ago
  Description :A stored Cross-Site Scripting (XSS) vulnerability has been found in Seafile v12.0.10. This vulnerability allows an attacker to execute arbitrary code in the victim's browser by storing malicious payloads with PUT parámetro 'name' in '/api/v2.1/user/'.
  Severity: 5.1 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-14010 - Ansible-collection-community-general: ansible-collection-community-general: keycloak user module leaks credentials in verbose output

  CVE ID :CVE-2025-14010
  Published : Dec. 4, 2025, 10:16 a.m. | 4 hours, 52 minutes ago
  Description :A flaw was found in ansible-collection-community-general. This vulnerability allows for information exposure (IE) of sensitive credentials, specifically plaintext passwords, via verbose output when running Ansible with debug modes. Attackers with access to logs could retrieve these secrets and potentially compromise Keycloak accounts or administrative access.
  Severity: 5.5 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...

• CVE-2025-12826 - Custom Post Type UI nauthenticated (Previously Administrator+) Custom Post Type Modification

  CVE ID :CVE-2025-12826
  Published : Dec. 4, 2025, 7:16 a.m. | 7 hours, 52 minutes ago
  Description :The Custom Post Type UI plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.18.0. This is due to the plugin not verifying that a user has the required capability to perform actions in the "cptui_process_post_type" function. This makes it possible for authenticated attackers, with subscriber level access and above, to add, edit, or delete custom post types in limited situations.
  Severity: 4.8 | MEDIUM
  Visit the link for more details, such as CVSS details, affected products, timeline, and more...