Total
409206 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-52547 | 1 Huawei | 2 Curiem-wfg9b, Curiem-wfg9b Firmware | 2026-06-17 | N/A | 7.8 HIGH |
| Huawei Matebook D16(Model: CREM-WXX9, BIOS: v2.26. Memory Corruption in SMI Handler of HddPassword SMM Module. This can be leveraged by a malicious OS attacker to corrupt data structures stored at the beginning of SMRAM and can potentially lead to code execution in SMM. | |||||
| CVE-2023-52546 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Vulnerability of package name verification being bypassed in the Calendar app. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2023-52545 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Vulnerability of undefined permissions in the Calendar app. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52544 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 4.3 MEDIUM |
| Vulnerability of file path verification being bypassed in the email module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2023-52543 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.2 MEDIUM |
| Permission verification vulnerability in the system module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52542 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.5 MEDIUM |
| Permission verification vulnerability in the system module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52541 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Authentication vulnerability in the API for app pre-loading. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2023-52540 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Vulnerability of improper authentication in the Iaware module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52539 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Permission verification vulnerability in the Settings module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2023-52538 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 9.1 CRITICAL |
| Vulnerability of package name verification being bypassed in the HwIms module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52537 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Vulnerability of package name verification being bypassed in the HwIms module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2023-52536 | 2 Google, Unisoc | 14 Android, S8000, Sc7731e and 11 more | 2026-06-17 | N/A | 4.4 MEDIUM |
| In faceid service, there is a possible out of bounds read due to a missing bounds check. This could lead to local denial of service with System execution privileges needed | |||||
| CVE-2023-52535 | 2 Google, Unisoc | 7 Android, Sc7731e, Sc9832e and 4 more | 2026-06-17 | N/A | 4.4 MEDIUM |
| In vsp driver, there is a possible missing verification incorrect input. This could lead to local denial of service with no additional execution privileges needed | |||||
| CVE-2023-52534 | 2 Google, Unisoc | 5 Android, S8000, T760 and 2 more | 2026-06-17 | N/A | 5.9 MEDIUM |
| In ngmm, there is a possible undefined behavior due to incorrect error handling. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2023-52533 | 2 Google, Unisoc | 5 Android, S8000, T760 and 2 more | 2026-06-17 | N/A | 5.3 MEDIUM |
| In modem-ps-nas-ngmm, there is a possible undefined behavior due to incorrect error handling. This could lead to remote information disclosure no additional execution privileges needed | |||||
| CVE-2023-52532 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging. | |||||
| CVE-2023-52531 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the "(u8 *)" cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected. | |||||
| CVE-2023-52529 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 6.0 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called. | |||||
| CVE-2023-52528 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. | |||||
| CVE-2023-52527 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when 'copy' is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn't. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds the UDP packet itself. | |||||