Export limit exceeded: 331915 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (331915 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-43372 | 1 Emlog | 1 Emlog | 2025-05-05 | 4.8 Medium |
| Emlog Pro v1.7.1 was discovered to contain a reflected cross-site scripting (XSS) vulnerability at /admin/store.php. | ||||
| CVE-2022-43109 | 1 Dlink | 2 Dir-823g, Dir-823g Firmware | 2025-05-05 | 9.8 Critical |
| D-Link DIR-823G v1.0.2 was found to contain a command injection vulnerability in the function SetNetworkTomographySettings. This vulnerability allows attackers to execute arbitrary commands via a crafted packet. | ||||
| CVE-2022-43108 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-05-05 | 9.8 Critical |
| Tenda AC23 V16.03.07.45_cn was discovered to contain a stack overflow via the firewallEn parameter in the formSetFirewallCfg function. | ||||
| CVE-2022-43105 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-05-05 | 9.8 Critical |
| Tenda AC23 V16.03.07.45_cn was discovered to contain a stack overflow via the shareSpeed parameter in the fromSetWifiGusetBasic function. | ||||
| CVE-2022-43104 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-05-05 | 9.8 Critical |
| Tenda AC23 V16.03.07.45_cn was discovered to contain a stack overflow via the wpapsk_crypto parameter in the fromSetWirelessRepeat function. | ||||
| CVE-2022-43103 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-05-05 | 9.8 Critical |
| Tenda AC23 V16.03.07.45_cn was discovered to contain a stack overflow via the list parameter in the formSetQosBand function. | ||||
| CVE-2022-43102 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-05-05 | 9.8 Critical |
| Tenda AC23 V16.03.07.45_cn was discovered to contain a stack overflow via the timeZone parameter in the fromSetSysTime function. | ||||
| CVE-2022-43063 | 1 Online Diagnostic Lab Management System Project | 1 Online Diagnostic Lab Management System | 2025-05-05 | 7.2 High |
| Online Diagnostic Lab Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /classes/Users.php?f=delete_client. | ||||
| CVE-2022-43062 | 1 Online Diagnostic Lab Management System Project | 1 Online Diagnostic Lab Management System | 2025-05-05 | 7.2 High |
| Online Diagnostic Lab Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /classes/Master.php?f=delete_appointment. | ||||
| CVE-2022-43061 | 1 Online Tours \& Travels Management System Project | 1 Online Tours \& Travels Management System | 2025-05-05 | 7.2 High |
| Online Tours & Travels Management System v1.0 was discovered to contain an arbitrary file upload vulnerability in the component /operations/travellers.php. This vulnerability allows attackers to execute arbitrary code via a crafted PHP file. | ||||
| CVE-2022-42744 | 1 Auieo | 1 Candidats | 2025-05-05 | 9.8 Critical |
| CandidATS version 3.0.0 allows an external attacker to perform CRUD operations on the application databases. This is possible because the application does not correctly validate the entriesPerPage parameter against SQLi attacks. | ||||
| CVE-2022-3708 | 1 Google | 1 Web Stories | 2025-05-05 | 9.6 Critical |
| The Web Stories plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including 1.24.0 due to insufficient validation of URLs supplied via the 'url' parameter found via the /v1/hotlink/proxy REST API Endpoint. This makes it possible for authenticated users to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. | ||||
| CVE-2020-22524 | 1 Freeimage Project | 1 Freeimage | 2025-05-05 | 6.5 Medium |
| Buffer Overflow vulnerability in FreeImage_Load function in FreeImage Library 3.19.0(r1828) allows attackers to cuase a denial of service via crafted PFM file. | ||||
| CVE-2020-21427 | 1 Freeimage Project | 1 Freeimage | 2025-05-05 | 7.8 High |
| Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file. | ||||
| CVE-2025-3552 | 2025-05-05 | N/A | ||
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: The vendor was not able to verify the existence of the original vulnerability report and the researcher was not able to provide further proof. | ||||
| CVE-2025-3551 | 2025-05-05 | N/A | ||
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: The vendor was not able to verify the existence of the original vulnerability report and the researcher was not able to provide further proof. | ||||
| CVE-2025-4273 | 2025-05-05 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2025-21986 | 2025-05-04 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: net: switchdev: Convert blocking notification chain to a raw one A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event. In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1]. Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process(). Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future. Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block. [1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted -------------------------------------------- ip/52731 is trying to acquire lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 but task is already holding lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((switchdev_blocking_notif_chain).rwsem); lock((switchdev_blocking_notif_chain).rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by ip/52731: #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 stack backtrace: ... ? __pfx_down_read+0x10/0x10 ? __pfx_mark_lock+0x10/0x10 ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10 blocking_notifier_call_chain+0x58/0xa0 switchdev_port_attr_notify.constprop.0+0xb3/0x1b0 ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10 ? mark_held_locks+0x94/0xe0 ? switchdev_deferred_process+0x11a/0x340 switchdev_port_attr_set_deferred+0x27/0xd0 switchdev_deferred_process+0x164/0x340 br_switchdev_port_unoffload+0xc8/0x100 [bridge] br_switchdev_blocking_event+0x29f/0x580 [bridge] notifier_call_chain+0xa2/0x440 blocking_notifier_call_chain+0x6e/0xa0 switchdev_bridge_port_unoffload+0xde/0x1a0 ... | ||||
| CVE-2025-21916 | 2025-05-04 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix a flaw in existing endpoint checks Syzbot once again identified a flaw in usb endpoint checking, see [1]. This time the issue stems from a commit authored by me (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")). While using usb_find_common_endpoints() may usually be enough to discard devices with wrong endpoints, in this case one needs more than just finding and identifying the sufficient number of endpoints of correct types - one needs to check the endpoint's address as well. Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind, switch the endpoint verification approach to usb_check_XXX_endpoints() instead to fix incomplete ep testing. [1] Syzbot report: usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ... | ||||
| CVE-2025-21907 | 2025-05-04 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: mm: memory-failure: update ttu flag inside unmap_poisoned_folio Patch series "mm: memory_failure: unmap poisoned folio during migrate properly", v3. Fix two bugs during folio migration if the folio is poisoned. This patch (of 3): Commit 6da6b1d4a7df ("mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in order to stop send SIGBUS signal when accessing an error page after a memory error on a clean folio. However during page migration, anon folio must be set with TTU_HWPOISON during unmap_*(). For pagecache we need some policy just like the one in hwpoison_user_mappings to set this flag. So move this policy from hwpoison_user_mappings to unmap_poisoned_folio to handle this warning properly. Warning will be produced during unamp poison folio with the following log: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c Modules linked in: CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G W 6.13.0-rc1-00018-gacdb4bbda7ab #42 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0x8fc/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0x8fc/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- [mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping', per Miaohe] | ||||