Filtered by CWE-122
Total 2411 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2024-38051 1 Microsoft 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more 2025-05-05 7.8 High
Windows Graphics Component Remote Code Execution Vulnerability
CVE-2024-38025 1 Microsoft 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more 2025-05-05 7.2 High
Microsoft Windows Performance Data Helper Library Remote Code Execution Vulnerability
CVE-2024-37987 1 Microsoft 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more 2025-05-05 8 High
Secure Boot Security Feature Bypass Vulnerability
CVE-2024-37331 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-37332 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-37318 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21415 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21414 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21398 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21373 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21335 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-21333 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2024-38088 1 Microsoft 4 Sql Server 2016, Sql Server 2017, Sql Server 2019 and 1 more 2025-05-05 8.8 High
SQL Server Native Client OLE DB Provider Remote Code Execution Vulnerability
CVE-2022-24942 1 Silabs 1 Micrium Uc-http 2025-05-05 9.1 Critical
Heap based buffer overflow in HTTP Server functionality in Micrium uC-HTTP 3.01.01 allows remote code execution via HTTP request.
CVE-2024-53681 1 Redhat 1 Enterprise Linux 2025-05-04 6.7 Medium
In the Linux kernel, the following vulnerability has been resolved: nvmet: Don't overflow subsysnqn nvmet_root_discovery_nqn_store treats the subsysnqn string like a fixed size buffer, even though it is dynamically allocated to the size of the string. Create a new string with kstrndup instead of using the old buffer.
CVE-2024-45030 1 Linux 1 Linux Kernel 2025-05-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: igb: cope with large MAX_SKB_FRAGS Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX. An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320 The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head. Address the issue by checking if 2K buffers are insufficient.
CVE-2024-41039 2 Linux, Redhat 3 Linux Kernel, Enterprise Linux, Rhel Eus 2025-05-04 7.8 High
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix overflow checking of wmfw header Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used.
CVE-2024-41038 2 Linux, Redhat 3 Linux Kernel, Enterprise Linux, Rhel Eus 2025-05-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs.
CVE-2024-26733 4 Debian, Linux, Netapp and 1 more 60 Debian Linux, Linux Kernel, 8200 and 57 more 2025-05-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK>
CVE-2022-48632 1 Redhat 1 Enterprise Linux 2025-05-04 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments.