Export limit exceeded: 16317 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (16317 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2022-34835 1 Denx 1 U-boot 2026-05-12 9.8 Critical
In Das U-Boot through 2022.07-rc5, an integer signedness error and resultant stack-based buffer overflow in the "i2c md" command enables the corruption of the return address pointer of the do_i2c_md function.
CVE-2022-30790 1 Denx 1 U-boot 2026-05-12 7.8 High
Das U-Boot 2022.01 has a Buffer Overflow, a different issue than CVE-2022-30552.
CVE-2022-2347 1 Denx 1 U-boot 2026-05-12 7.7 High
There exists an unchecked length field in UBoot. The U-Boot DFU implementation does not bound the length field in USB DFU download setup packets, and it does not verify that the transfer direction corresponds to the specified command. Consequently, if a physical attacker crafts a USB DFU download setup packet with a `wLength` greater than 4096 bytes, they can write beyond the heap-allocated request buffer.
CVE-2019-14204 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is a stack-based buffer overflow in this nfs_handler reply helper function: nfs_umountall_reply.
CVE-2019-14203 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is a stack-based buffer overflow in this nfs_handler reply helper function: nfs_mount_reply.
CVE-2019-14202 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is a stack-based buffer overflow in this nfs_handler reply helper function: nfs_readlink_reply.
CVE-2019-14201 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is a stack-based buffer overflow in this nfs_handler reply helper function: nfs_lookup_reply.
CVE-2019-14200 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is a stack-based buffer overflow in this nfs_handler reply helper function: rpc_lookup_reply.
CVE-2019-14198 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with a failed length check at nfs_read_reply when calling store_block in the NFSv3 case.
CVE-2019-14196 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with a failed length check at nfs_lookup_reply.
CVE-2019-14195 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with unvalidated length at nfs_readlink_reply in the "else" block after calculating the new path length.
CVE-2019-14194 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with a failed length check at nfs_read_reply when calling store_block in the NFSv2 case.
CVE-2019-14193 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with an unvalidated length at nfs_readlink_reply, in the "if" block after calculating the new path length.
CVE-2019-14192 1 Denx 1 U-boot 2026-05-12 N/A
An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy when parsing a UDP packet due to a net_process_received_packet integer underflow during an nc_input_packet call.
CVE-2019-13106 2 Denx, Opensuse 2 U-boot, Leap 2026-05-12 7.8 High
Das U-Boot versions 2016.09 through 2019.07-rc4 can memset() too much data while reading a crafted ext4 filesystem, which results in a stack buffer overflow and likely code execution.
CVE-2019-13104 2 Denx, Opensuse 2 U-boot, Leap 2026-05-12 7.8 High
In Das U-Boot versions 2016.11-rc1 through 2019.07-rc4, an underflow can cause memcpy() to overwrite a very large amount of data (including the whole stack) while reading a crafted ext4 filesystem.
CVE-2026-20657 1 Apple 4 Ios And Ipados, Ipados, Iphone Os and 1 more 2026-05-11 6.5 Medium
A buffer overflow issue was addressed with improved memory handling. This issue is fixed in iOS 18.7.7 and iPadOS 18.7.7, iOS 26.4 and iPadOS 26.4, macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4, visionOS 26.4. Parsing a maliciously crafted file may lead to an unexpected app termination.
CVE-2026-31780 1 Linux 1 Linux Kernel 2026-05-11 7.8 High
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.
CVE-2026-43205 1 Linux 1 Linux Kernel 2026-05-11 7.8 High
In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...
CVE-2026-43208 1 Linux 1 Linux Kernel 2026-05-11 9.8 Critical
In the Linux kernel, the following vulnerability has been resolved: net: do not pass flow_id to set_rps_cpu() Blamed commit made the assumption that the RPS table for each receive queue would have the same size, and that it would not change. Compute flow_id in set_rps_cpu(), do not assume we can use the value computed by get_rps_cpu(). Otherwise we risk out-of-bound access and/or crashes.