Export limit exceeded: 347269 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 45652 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 21647 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (21647 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-61863 | 1 Fujielectric | 2 Monitouch V-sft, V-sft | 2025-10-27 | 7.8 High |
| An out-of-bounds read vulnerability exists in VS6ComFile!CSaveData::delete_mem of V-SFT v6.2.7.0 and earlier. Opening specially crafted V-SFT files may lead to information disclosure, affected system's abnormal end (ABEND), and arbitrary code execution. | ||||
| CVE-2025-61862 | 1 Fujielectric | 2 Monitouch V-sft, V-sft | 2025-10-27 | 7.8 High |
| An out-of-bounds read vulnerability exists in VS6ComFile!get_ovlp_element_size of V-SFT v6.2.7.0 and earlier. Opening specially crafted V-SFT files may lead to information disclosure, affected system's abnormal end (ABEND), and arbitrary code execution. | ||||
| CVE-2025-61861 | 1 Fujielectric | 2 Monitouch V-sft, V-sft | 2025-10-27 | 7.8 High |
| An out-of-bounds read vulnerability exists in VS6ComFile!load_link_inf of V-SFT v6.2.7.0 and earlier. Opening specially crafted V-SFT files may lead to information disclosure, affected system's abnormal end (ABEND), and arbitrary code execution. | ||||
| CVE-2025-61860 | 1 Fujielectric | 2 Monitouch V-sft, V-sft | 2025-10-27 | 7.8 High |
| An out-of-bounds read vulnerability exists in VS6MemInIF!set_temp_type_default of V-SFT v6.2.7.0 and earlier. Opening specially crafted V-SFT files may lead to information disclosure, affected system's abnormal end (ABEND), and arbitrary code execution. | ||||
| CVE-2025-61856 | 1 Fujielectric | 2 Monitouch V-sft, V-sft | 2025-10-27 | 7.8 High |
| A stack-based buffer overflow vulnerability exists in VS6ComFile!CV7BaseMap::WriteV7DataToRom of V-SFT v6.2.7.0 and earlier. Opening specially crafted V-SFT files may lead to information disclosure, affected system's abnormal end (ABEND), and arbitrary code execution. | ||||
| CVE-2023-23376 | 1 Microsoft | 21 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 18 more | 2025-10-27 | 7.8 High |
| Windows Common Log File System Driver Elevation of Privilege Vulnerability | ||||
| CVE-2023-33010 | 1 Zyxel | 46 Atp100, Atp100 Firmware, Atp100w and 43 more | 2025-10-27 | 9.8 Critical |
| A buffer overflow vulnerability in the ID processing function in Zyxel ATP series firmware versions 4.32 through 5.36 Patch 1, USG FLEX series firmware versions 4.50 through 5.36 Patch 1, USG FLEX 50(W) firmware versions 4.25 through 5.36 Patch 1, USG20(W)-VPN firmware versions 4.25 through 5.36 Patch 1, VPN series firmware versions 4.30 through 5.36 Patch 1, ZyWALL/USG series firmware versions 4.25 through 4.73 Patch 1, could allow an unauthenticated attacker to cause denial-of-service (DoS) conditions and even a remote code execution on an affected device. | ||||
| CVE-2025-60339 | 1 Tenda | 2 Ac6, Ac6 Firmware | 2025-10-27 | 7.5 High |
| Multiple buffer overflow vulnerabilities in the openSchedWifi function of Tenda AC6 v.15.03.06.50 allows attackers to cause a Denial of Service (DoS) via injecting a crafted payload into the schedStartTime and schedEndTime parameters. | ||||
| CVE-2025-60337 | 1 Tenda | 2 Ac6, Ac6 Firmware | 2025-10-27 | 7.5 High |
| Tenda AC6 V2.0 15.03.06.50 was discovered to contain a buffer overflow in the speed_dir parameter in the SetSpeedWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. | ||||
| CVE-2025-55083 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-27 | 5.3 Medium |
| In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check resulting it out by two out of bound read. | ||||
| CVE-2025-55085 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-27 | 7.5 High |
| In NextX Duo before 6.4.4, in the HTTP client module, the network support code for Eclipse Foundation ThreadX, the parsing of HTTP header fields was missing bounds verification. A crafted server response could cause undefined behavior. | ||||
| CVE-2022-36063 | 1 Eclipse | 1 Threadx Usbx | 2025-10-27 | 7.6 High |
| Azure RTOS USBx is a USB host, device, and on-the-go (OTG) embedded stack, fully integrated with Azure RTOS ThreadX and available for all Azure RTOS ThreadX–supported processors. Azure RTOS USBX implementation of host support for USB CDC ECM includes an integer underflow and a buffer overflow in the `_ux_host_class_cdc_ecm_mac_address_get` function which may be potentially exploited to achieve remote code execution or denial of service. Setting mac address string descriptor length to a `0` or `1` allows an attacker to introduce an integer underflow followed (string_length) by a buffer overflow of the `cdc_ecm -> ux_host_class_cdc_ecm_node_id` array. This may allow one to redirect the code execution flow or introduce a denial of service. The fix has been included in USBX release [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). Improved mac address string descriptor length validation to check for unexpectedly small values may be used as a workaround. | ||||
| CVE-2022-29246 | 1 Eclipse | 1 Threadx Usbx | 2025-10-27 | 9.8 Critical |
| Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack. Prior to version 6.1.11, he USBX DFU UPLOAD functionality may be utilized to introduce a buffer overflow resulting in overwrite of memory contents. In particular cases this may allow an attacker to bypass security features or execute arbitrary code. The implementation of `ux_device_class_dfu_control_request` function does not assure that a buffer overflow will not occur during handling of the DFU UPLOAD command. When an attacker issues the `UX_SLAVE_CLASS_DFU_COMMAND_UPLOAD` control transfer request with `wLenght` larger than the buffer size (`UX_SLAVE_REQUEST_CONTROL_MAX_LENGTH`, 256 bytes), depending on the actual implementation of `dfu -> ux_slave_class_dfu_read`, a buffer overflow may occur. In example `ux_slave_class_dfu_read` may read 4096 bytes (or more up to 65k) to a 256 byte buffer ultimately resulting in an overflow. Furthermore in case an attacker has some control over the read flash memory, this may result in execution of arbitrary code and platform compromise. A fix for this issue has been included in USBX release 6.1.11. As a workaround, align request and buffer size to assure that buffer boundaries are respected. | ||||
| CVE-2022-29223 | 1 Eclipse | 1 Threadx Usbx | 2025-10-27 | 7.5 High |
| Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack. In versions prior to 6.1.10, an attacker can cause a buffer overflow by providing the Azure RTOS USBX host stack a HUB descriptor with `bNbPorts` set to a value greater than `UX_MAX_TT` which defaults to 8. For a `bNbPorts` value of 255, the implementation of `ux_host_class_hub_descriptor_get` function will modify the contents of `hub` -> `ux_host_class_hub_device` -> `ux_device_hub_tt` array violating the end boundary by 255 - `UX_MAX_TT` items. The USB host stack needs to validate the number of ports reported by the hub, and if the value is larger than UX_MAX_TT, USB stack needs to reject the request. This fix has been included in USBX release 6.1.10. | ||||
| CVE-2020-15999 | 7 Debian, Fedoraproject, Freetype and 4 more | 10 Debian Linux, Fedora, Freetype and 7 more | 2025-10-24 | 9.6 Critical |
| Heap buffer overflow in Freetype in Google Chrome prior to 86.0.4240.111 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. | ||||
| CVE-2025-55094 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-24 | 7.5 High |
| In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_icmpv6_validate_options() when handling a packet with ICMP6 options. | ||||
| CVE-2025-55087 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-24 | 7.5 High |
| In NextX Duo's snmp addon versions before 6.4.4, a part of the Eclipse Foundation ThreadX, an attacker could cause an out-of-bound read by a crafted SNMPv3 security parameters. | ||||
| CVE-2025-55093 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-24 | 5.3 Medium |
| In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_packet_receive() when handling unicast DHCP messages that could cause corruption of 4 bytes of memory. | ||||
| CVE-2025-55092 | 1 Eclipse | 1 Threadx Netx Duo | 2025-10-24 | 5.3 Medium |
| In Eclipse Foundation NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_option_process() when processing an IPv4 packet with the timestamp option. | ||||
| CVE-2022-49706 | 1 Linux | 1 Linux Kernel | 2025-10-24 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: zonefs: fix zonefs_iomap_begin() for reads If a readahead is issued to a sequential zone file with an offset exactly equal to the current file size, the iomap type is set to IOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is calculated as 0. This causes a WARN_ON() in iomap_iter(): [17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80 [...] [17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80 [...] [17309.754560] Call Trace: [17309.757078] <TASK> [17309.759240] ? lock_is_held_type+0xd8/0x130 [17309.763531] iomap_readahead+0x1a8/0x870 [17309.767550] ? iomap_read_folio+0x4c0/0x4c0 [17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400 [17309.778848] ? lock_release+0x370/0x750 [17309.784462] ? folio_add_lru+0x217/0x3f0 [17309.790220] ? reacquire_held_locks+0x4e0/0x4e0 [17309.796543] read_pages+0x17d/0xb60 [17309.801854] ? folio_add_lru+0x238/0x3f0 [17309.807573] ? readahead_expand+0x5f0/0x5f0 [17309.813554] ? policy_node+0xb5/0x140 [17309.819018] page_cache_ra_unbounded+0x27d/0x450 [17309.825439] filemap_get_pages+0x500/0x1450 [17309.831444] ? filemap_add_folio+0x140/0x140 [17309.837519] ? lock_is_held_type+0xd8/0x130 [17309.843509] filemap_read+0x28c/0x9f0 [17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs] [17309.856162] ? trace_contention_end+0xd6/0x130 [17309.862416] ? __mutex_lock+0x221/0x1480 [17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs] [17309.875364] ? filemap_get_pages+0x1450/0x1450 [17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620 [17309.888248] ? wait_for_completion_io_timeout+0x20/0x20 [17309.895231] ? lock_is_held_type+0xd8/0x130 [17309.901115] ? lock_is_held_type+0xd8/0x130 [17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs] [17309.913750] new_sync_read+0x2d8/0x520 [17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0 Furthermore, this causes iomap_readahead() to loop forever as iomap_readahead_iter() always returns 0, making no progress. Fix this by treating reads after the file size as access to holes, setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDR and using the length argument as is for the iomap length. To simplify the code with this change, zonefs_iomap_begin() is split into the read variant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and the write variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops. | ||||