Total
597 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-1103 | 1 Dlink | 2 Dir-823x, Dir-823x Firmware | 2025-05-21 | 6.5 Medium |
| A vulnerability, which was classified as problematic, was found in D-Link DIR-823X 240126/240802. This affects the function set_wifi_blacklists of the file /goform/set_wifi_blacklists of the component HTTP POST Request Handler. The manipulation of the argument macList leads to null pointer dereference. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2022-40890 | 1 Open5gs | 1 Open5gs | 2025-05-21 | 7.5 High |
| A vulnerability in /src/amf/amf-context.c in Open5GS 2.4.10 and earlier leads to AMF denial of service. | ||||
| CVE-2025-4756 | 1 Dlink | 2 Di-7003g, Di-7003g Firmware | 2025-05-21 | 5.3 Medium |
| A vulnerability was found in D-Link DI-7003GV2 24.04.18D1 R(68125). It has been declared as problematic. This vulnerability affects unknown code of the file /H5/restart.asp. The manipulation leads to denial of service. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2021-47550 | 1 Linux | 1 Linux Kernel | 2025-05-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put. | ||||
| CVE-2024-1187 | 1 Munsoft | 1 Easy Outlook Express Recovery | 2025-05-15 | 3.3 Low |
| A vulnerability, which was classified as problematic, has been found in Munsoft Easy Outlook Express Recovery 2.0. This issue affects some unknown processing of the component Registration Key Handler. The manipulation leads to denial of service. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier VDB-252677 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2025-3198 | 1 Gnu | 1 Binutils | 2025-05-15 | 3.3 Low |
| A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue. | ||||
| CVE-2022-28887 | 3 Apple, F-secure, Microsoft | 8 Macos, Atlant, Elements Endpoint Detection And Response and 5 more | 2025-05-15 | 4.3 Medium |
| Multiple Denial-of-Service (DoS) vulnerability was discovered in F-Secure & WithSecure products whereby the aerdl.dll unpacker handler function crashes. This can lead to a possible scanning engine crash. | ||||
| CVE-2024-39721 | 1 Ollama | 1 Ollama | 2025-05-13 | 7.5 High |
| An issue was discovered in Ollama before 0.1.34. The CreateModelHandler function uses os.Open to read a file until completion. The req.Path parameter is user-controlled and can be set to /dev/random, which is blocking, causing the goroutine to run infinitely (even after the HTTP request is aborted by the client). | ||||
| CVE-2024-1189 | 1 Softaculous | 1 Ampps | 2025-05-09 | 5.3 Medium |
| A vulnerability has been found in AMPPS 2.7 and classified as problematic. Affected by this vulnerability is an unknown functionality of the component Encryption Passphrase Handler. The manipulation leads to denial of service. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 4.0 is able to address this issue. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-252679. NOTE: The vendor explains that AMPPS 4.0 is a complete overhaul and the code was re-written. | ||||
| CVE-2024-0732 | 1 Pcman Ftp Server Project | 1 Pcman Ftp Server | 2025-05-09 | 5.3 Medium |
| A vulnerability was found in PCMan FTP Server 2.0.7 and classified as problematic. This issue affects some unknown processing of the component STOR Command Handler. The manipulation leads to denial of service. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-251555. | ||||
| CVE-2022-22677 | 2 Apple, Redhat | 4 Ipados, Iphone Os, Macos and 1 more | 2025-05-06 | 4.3 Medium |
| A logic issue in the handling of concurrent media was addressed with improved state handling. This issue is fixed in macOS Monterey 12.4, iOS 15.5 and iPadOS 15.5. Video self-preview in a webRTC call may be interrupted if the user answers a phone call. | ||||
| CVE-2022-1473 | 3 Netapp, Openssl, Redhat | 44 A250, A250 Firmware, A700s and 41 more | 2025-05-05 | 7.5 High |
| The OPENSSL_LH_flush() function, which empties a hash table, contains a bug that breaks reuse of the memory occuppied by the removed hash table entries. This function is used when decoding certificates or keys. If a long lived process periodically decodes certificates or keys its memory usage will expand without bounds and the process might be terminated by the operating system causing a denial of service. Also traversing the empty hash table entries will take increasingly more time. Typically such long lived processes might be TLS clients or TLS servers configured to accept client certificate authentication. The function was added in the OpenSSL 3.0 version thus older releases are not affected by the issue. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). | ||||
| CVE-2024-50065 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under "rcu-walk" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT. | ||||
| CVE-2024-47736 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference. | ||||
| CVE-2024-46861 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs. | ||||
| CVE-2024-26757 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. | ||||
| CVE-2022-48661 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. | ||||
| CVE-2023-52476 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. | ||||
| CVE-2021-47585 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in __add_inode_ref() Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(), but when the function returns in line 1184 (#4) victim_name allocated by line 1169 (#3) is not freed, which will lead to a memory leak. There is a similar snippet of code in this function as allocating a memory chunk for victim_name in line 1104 (#1) as well as releasing the memory in line 1116 (#2). We should kfree() victim_name when the return value of backref_in_log() is less than zero and before the function returns in line 1184 (#4). 1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans, 1058 struct btrfs_root *root, 1059 struct btrfs_path *path, 1060 struct btrfs_root *log_root, 1061 struct btrfs_inode *dir, 1062 struct btrfs_inode *inode, 1063 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char *name, int namelen, 1065 int *search_done) 1066 { 1104 victim_name = kmalloc(victim_name_len, GFP_NOFS); // #1: kmalloc (victim_name-1) 1105 if (!victim_name) 1106 return -ENOMEM; 1112 ret = backref_in_log(log_root, &search_key, 1113 parent_objectid, victim_name, 1114 victim_name_len); 1115 if (ret < 0) { 1116 kfree(victim_name); // #2: kfree (victim_name-1) 1117 return ret; 1118 } else if (!ret) { 1169 victim_name = kmalloc(victim_name_len, GFP_NOFS); // #3: kmalloc (victim_name-2) 1170 if (!victim_name) 1171 return -ENOMEM; 1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 if (ret < 0) { 1184 return ret; // #4: missing kfree (victim_name-2) 1185 } else if (!ret) { 1241 return 0; 1242 } | ||||
| CVE-2022-44552 | 1 Huawei | 2 Emui, Harmonyos | 2025-05-01 | 7.5 High |
| The lock screen module has defects introduced in the design process. Successful exploitation of this vulnerability may affect system availability. | ||||