Export limit exceeded: 339475 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 339475 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (339475 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-26629 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. | ||||
| CVE-2023-53820 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: loop: loop_set_status_from_info() check before assignment In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should be checked before reassignment, because if an overflow error occurs, the original correct value will be changed to the wrong value, and it will not be changed back. More, the original patch did not solve the problem, the value was set and ioctl returned an error, but the subsequent io used the value in the loop driver, which still caused an alarm: loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos | ||||
| CVE-2023-53692 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free read in ext4_find_extent for bigalloc + inline Syzbot found the following issue: loop0: detected capacity change from 0 to 2048 EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. ================================================================== BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 Read of size 4 at addr ffff888073644750 by task syz-executor420/5067 CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809 ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline] ext4_da_map_blocks fs/ext4/inode.c:1806 [inline] ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870 ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098 ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285 ext4_file_write_iter+0x1d0/0x18f0 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f4b7a9737b9 RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9 RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004 RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Above issue is happens when enable bigalloc and inline data feature. As commit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped for bigalloc + inline. But it only resolved issue when has inline data, if inline data has been converted to extent(ext4_da_convert_inline_data_to_extent) before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. However i_data is still store inline data in this scene. Then will trigger UAF when find extent. To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)" in ext4_clu_mapped(). | ||||
| CVE-2022-50286 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline When converting files with inline data to extents, delayed allocations made on a file system created with both the bigalloc and inline options can result in invalid extent status cache content, incorrect reserved cluster counts, kernel memory leaks, and potential kernel panics. With bigalloc, the code that determines whether a block must be delayed allocated searches the extent tree to see if that block maps to a previously allocated cluster. If not, the block is delayed allocated, and otherwise, it isn't. However, if the inline option is also used, and if the file containing the block is marked as able to store data inline, there isn't a valid extent tree associated with the file. The current code in ext4_clu_mapped() calls ext4_find_extent() to search the non-existent tree for a previously allocated cluster anyway, which typically finds nothing, as desired. However, a side effect of the search can be to cache invalid content from the non-existent tree (garbage) in the extent status tree, including bogus entries in the pending reservation tree. To fix this, avoid searching the extent tree when allocating blocks for bigalloc + inline files that are being converted from inline to extent mapped. | ||||
| CVE-2009-0696 | 2 Isc, Redhat | 2 Bind, Enterprise Linux | 2025-12-23 | N/A |
| The dns_db_findrdataset function in db.c in named in ISC BIND 9.4 before 9.4.3-P3, 9.5 before 9.5.1-P3, and 9.6 before 9.6.1-P1, when configured as a master server, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via an ANY record in the prerequisite section of a crafted dynamic update message. | ||||
| CVE-2025-35452 | 4 Multicam-systems, Ptzoptics, Smtav and 1 more | 121 Mcamii Ptz, Mcamii Ptz Firmware, Ndi Fixed Camera and 118 more | 2025-12-23 | 9.8 Critical |
| PTZOptics and possibly other ValueHD-based pan-tilt-zoom cameras use default, shared credentials for the administrative web interface. | ||||
| CVE-2017-20206 | 2 Wordpress, Wpmudev | 2 Wordpress, Appointments | 2025-12-23 | 9.8 Critical |
| The Appointments plugin for WordPress is vulnerable to PHP Object Injection in versions up to, and including, 2.2.1 via deserialization of untrusted input from the `wpmudev_appointments` cookie. This allows unauthenticated attackers to inject a PHP Object. Attackers were actively exploiting this vulnerability with the WP_Theme() class to create backdoors. | ||||
| CVE-2025-65000 | 1 Checkmk | 1 Checkmk | 2025-12-23 | 5.3 Medium |
| SSH private keys of the "Remote alert handlers (Linux)" rule were exposed in the rule page's HTML source in Checkmk <= 2.4.0p18 and all versions of Checkmk 2.3.0. This potentially allowed unauthorized triggering of predefined alert handlers on hosts where the handler was deployed. | ||||
| CVE-2024-10470 | 1 Vibethemes | 2 Wordpress Learning Management System, Wordpress Learning Management System | 2025-12-23 | 9.8 Critical |
| The WPLMS Learning Management System for WordPress, WordPress LMS theme for WordPress is vulnerable to arbitrary file read and deletion due to insufficient file path validation and permissions checks in the readfile and unlink functions in all versions up to, and including, 4.962. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). The theme is vulnerable even when it is not activated. | ||||
| CVE-2025-64997 | 1 Checkmk | 1 Checkmk | 2025-12-23 | 6.5 Medium |
| Insufficient permission validation in Checkmk versions prior to 2.4.0p17 and 2.3.0p42 allow low-privileged users to view agent information via the REST API, which could lead to information disclosure. | ||||
| CVE-2015-10134 | 1 Mywebsiteadvisor | 1 Simple Backup | 2025-12-23 | 7.5 High |
| The Simple Backup plugin for WordPress is vulnerable to Arbitrary File Download in versions up to, and including, 2.7.10. via the download_backup_file function. This is due to a lack of capability checks and file type validation. This makes it possible for attackers to download sensitive files such as the wp-config.php file from the affected site. | ||||
| CVE-2023-4537 | 1 Comarch | 1 Erp Xl | 2025-12-23 | 7.4 High |
| Comarch ERP XL client is vulnerable to MS SQL protocol downgrade request from a server side, what could lead to an unencrypted communication vulnerable to data interception and modification. This issue affects ERP XL: from 2020.2.2 through 2023.2. | ||||
| CVE-2024-11863 | 1 Arm | 2 Scp-firmware, Scp Firmware | 2025-12-23 | 5.3 Medium |
| Specifically crafted SCMI messages sent to an SCP running SCP-Firmware release versions up to and including 2.15.0 may lead to a Usage Fault and crash the SCP | ||||
| CVE-2024-11864 | 1 Arm | 2 Scp-firmware, Scp Firmware | 2025-12-23 | 7.5 High |
| Specifically crafted SCMI messages sent to an SCP running SCP-Firmware release versions up to and including 2.15.0 may lead to a Usage Fault and crash the SCP | ||||
| CVE-2024-9413 | 1 Arm | 2 Scp-firmware, Scp Firmware | 2025-12-23 | 8 High |
| The transport_message_handler function in SCP-Firmware release versions 2.11.0-2.15.0 does not properly handle errors, potentially allowing an Application Processor (AP) to cause a buffer overflow in System Control Processor (SCP) firmware. | ||||
| CVE-2025-14567 | 2 Haxxorsid, Stock Management System Project | 2 Stock-management-system, Stock Management System | 2025-12-23 | 5.3 Medium |
| A weakness has been identified in haxxorsid Stock-Management-System up to fbbbf213e9c93b87183a3891f77e3cc7095f22b0. This affects an unknown function of the file /api/employees. Executing manipulation can lead to missing authentication. It is possible to launch the attack remotely. The exploit has been made available to the public and could be exploited. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The vendor was contacted early about this disclosure but did not respond in any way. This vulnerability only affects products that are no longer supported by the maintainer. | ||||
| CVE-2025-48864 | 2025-12-23 | N/A | ||
| This CVE id was assigned but later discarded. | ||||
| CVE-2025-48863 | 2025-12-23 | N/A | ||
| This CVE id was assigned but later discarded. | ||||
| CVE-2024-10398 | 2025-12-23 | N/A | ||
| This CVE id was assigned but later discarded. | ||||
| CVE-2024-10396 | 1 Openafs | 1 Openafs | 2025-12-23 | 6.5 Medium |
| An authenticated user can provide a malformed ACL to the fileserver's StoreACL RPC, causing the fileserver to crash, possibly expose uninitialized memory, and possibly store garbage data in the audit log. Malformed ACLs provided in responses to client FetchACL RPCs can cause client processes to crash and possibly expose uninitialized memory into other ACLs stored on the server. | ||||