Total
31581 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-46399 | 1 Microchip | 28 Bm64, Bm64 Firmware, Bm70 and 25 more | 2025-04-17 | 7.5 High |
| The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) is unresponsive with ConReqTimeoutZero. | ||||
| CVE-2022-46400 | 1 Microchip | 18 Bm70, Bm70 Firmware, Bm71 and 15 more | 2025-04-17 | 5.4 Medium |
| The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing. | ||||
| CVE-2022-46401 | 1 Microchip | 24 Bm64, Bm64 Firmware, Bm70 and 21 more | 2025-04-17 | 5.4 Medium |
| The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) accepts PauseEncReqPlainText before pairing is complete. | ||||
| CVE-2022-46423 | 1 Netgear | 2 Wnr2000, Wnr2000 Firmware | 2025-04-17 | 8.1 High |
| An exploitable firmware modification vulnerability was discovered on the Netgear WNR2000v1 router. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v1.2.3.7 and earlier. | ||||
| CVE-2022-46422 | 1 Netgear | 2 Wnr2000, Wnr2000 Firmware | 2025-04-17 | 4.8 Medium |
| An issue in Netgear WNR2000 v1 1.2.3.7 and earlier allows authenticated attackers to cause a Denial of Service (DoS) via uploading a crafted firmware image during the firmware update process. | ||||
| CVE-2022-46327 | 1 Huawei | 2 Emui, Harmonyos | 2025-04-17 | 9.8 Critical |
| Some smartphones have configuration issues. Successful exploitation of this vulnerability may cause privilege escalation, which results in system service exceptions. | ||||
| CVE-2022-46315 | 1 Huawei | 1 Harmonyos | 2025-04-17 | 7.5 High |
| The ProfileSDK has defects introduced in the design process. Successful exploitation of this vulnerability may affect system availability. | ||||
| CVE-2022-46314 | 1 Huawei | 1 Harmonyos | 2025-04-17 | 7.5 High |
| The IPC module has defects introduced in the design process. Successful exploitation of this vulnerability may affect system availability. | ||||
| CVE-2022-46310 | 1 Huawei | 1 Harmonyos | 2025-04-17 | 7.5 High |
| The TelephonyProvider module has a vulnerability in obtaining values.Successful exploitation of this vulnerability may affect data confidentiality. | ||||
| CVE-2022-46139 | 1 Tp-link | 2 Tl-wr940n V4, Tl-wr940n V4 Firmware | 2025-04-17 | 6.5 Medium |
| TP-Link TL-WR940N V4 3.16.9 and earlier allows authenticated attackers to cause a Denial of Service (DoS) via uploading a crafted firmware image during the firmware update process. | ||||
| CVE-2022-38873 | 1 Dlink | 18 Dap-2310, Dap-2310 Firmware, Dap-2330 and 15 more | 2025-04-17 | 7.5 High |
| D-Link devices DAP-2310 v2.10rc036 and earlier, DAP-2330 v1.06rc020 and earlier, DAP-2360 v2.10rc050 and earlier, DAP-2553 v3.10rc031 and earlier, DAP-2660 v1.15rc093 and earlier, DAP-2690 v3.20rc106 and earlier, DAP-2695 v1.20rc119_beta31 and earlier, DAP-3320 v1.05rc027 beta and earlier, DAP-3662 v1.05rc047 and earlier allows attackers to cause a Denial of Service (DoS) via uploading a crafted firmware after modifying the firmware header. | ||||
| CVE-2022-46403 | 1 Microchip | 18 Bm70, Bm70 Firmware, Bm71 and 15 more | 2025-04-17 | 8.6 High |
| The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) mishandles reject messages. | ||||
| CVE-2025-24427 | 1 Adobe | 3 Commerce, Commerce B2b, Magento | 2025-04-16 | 6.5 Medium |
| Adobe Commerce versions 2.4.8-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Improper Access Control vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. | ||||
| CVE-2022-35751 | 1 Microsoft | 15 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 12 more | 2025-04-16 | 7.8 High |
| Windows Hyper-V Elevation of Privilege Vulnerability | ||||
| CVE-2025-21176 | 4 Apple, Linux, Microsoft and 1 more | 22 Macos, Linux Kernel, .net and 19 more | 2025-04-16 | 8.8 High |
| .NET, .NET Framework, and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2025-21860 | 1 Linux | 1 Linux Kernel | 2025-04-16 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: mm/zswap: fix inconsistency when zswap_store_page() fails Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()") skips charging any zswap entries when it failed to zswap the entire folio. However, when some base pages are zswapped but it failed to zswap the entire folio, the zswap operation is rolled back. When freeing zswap entries for those pages, zswap_entry_free() uncharges the zswap entries that were not previously charged, causing zswap charging to become inconsistent. This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages also becomes inconsistent in the same way. As suggested by Kanchana, increment zswap_stored_pages and charge zswap entries within zswap_store_page() when it succeeds. This way, zswap_entry_free() will decrement the counter and uncharge the entries when it failed to zswap the entire folio. While this could potentially be optimized by batching objcg charging and incrementing the counter, let's focus on fixing the bug this time and leave the optimization for later after some evaluation. After resolving the inconsistency, the warnings disappear. [42.hyeyoo@gmail.com: refactor zswap_store_page()] | ||||
| CVE-2024-44943 | 1 Linux | 1 Linux Kernel | 2025-04-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm: gup: stop abusing try_grab_folio A kernel warning was reported when pinning folio in CMA memory when launching SEV virtual machine. The splat looks like: [ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520 [ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6 [ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520 [ 464.325515] Call Trace: [ 464.325520] <TASK> [ 464.325523] ? __get_user_pages+0x423/0x520 [ 464.325528] ? __warn+0x81/0x130 [ 464.325536] ? __get_user_pages+0x423/0x520 [ 464.325541] ? report_bug+0x171/0x1a0 [ 464.325549] ? handle_bug+0x3c/0x70 [ 464.325554] ? exc_invalid_op+0x17/0x70 [ 464.325558] ? asm_exc_invalid_op+0x1a/0x20 [ 464.325567] ? __get_user_pages+0x423/0x520 [ 464.325575] __gup_longterm_locked+0x212/0x7a0 [ 464.325583] internal_get_user_pages_fast+0xfb/0x190 [ 464.325590] pin_user_pages_fast+0x47/0x60 [ 464.325598] sev_pin_memory+0xca/0x170 [kvm_amd] [ 464.325616] sev_mem_enc_register_region+0x81/0x130 [kvm_amd] Per the analysis done by yangge, when starting the SEV virtual machine, it will call pin_user_pages_fast(..., FOLL_LONGTERM, ...) to pin the memory. But the page is in CMA area, so fast GUP will fail then fallback to the slow path due to the longterm pinnalbe check in try_grab_folio(). The slow path will try to pin the pages then migrate them out of CMA area. But the slow path also uses try_grab_folio() to pin the page, it will also fail due to the same check then the above warning is triggered. In addition, the try_grab_folio() is supposed to be used in fast path and it elevates folio refcount by using add ref unless zero. We are guaranteed to have at least one stable reference in slow path, so the simple atomic add could be used. The performance difference should be trivial, but the misuse may be confusing and misleading. Redefined try_grab_folio() to try_grab_folio_fast(), and try_grab_page() to try_grab_folio(), and use them in the proper paths. This solves both the abuse and the kernel warning. The proper naming makes their usecase more clear and should prevent from abusing in the future. peterx said: : The user will see the pin fails, for gpu-slow it further triggers the WARN : right below that failure (as in the original report): : : folio = try_grab_folio(page, page_increm - 1, : foll_flags); : if (WARN_ON_ONCE(!folio)) { <------------------------ here : /* : * Release the 1st page ref if the : * folio is problematic, fail hard. : */ : gup_put_folio(page_folio(page), 1, : foll_flags); : ret = -EFAULT; : goto out; : } [1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/ [shy828301@gmail.com: fix implicit declaration of function try_grab_folio_fast] | ||||
| CVE-2022-46424 | 1 Netgear | 2 Xwn5001, Xwn5001 Firmware | 2025-04-16 | 8.1 High |
| An exploitable firmware modification vulnerability was discovered on the Netgear XWN5001 Powerline 500 WiFi Access Point. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v0.4.1.1 and earlier. | ||||
| CVE-2022-46321 | 1 Huawei | 2 Emui, Harmonyos | 2025-04-16 | 7.5 High |
| The Wi-Fi module has a vulnerability in permission verification. Successful exploitation of this vulnerability may affect data confidentiality. | ||||
| CVE-2022-46318 | 1 Huawei | 2 Emui, Harmonyos | 2025-04-16 | 5.3 Medium |
| The HAware module has a function logic error. Successful exploitation of this vulnerability will affect the account removal function in Settings. | ||||