Total
3990 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-4640 | 1 Moxa | 8 Oncell G3470a-lte-eu, Oncell G3470a-lte-eu-t, Oncell G3470a-lte-eu-t Firmware and 5 more | 2026-06-17 | N/A | 7.1 HIGH |
| OnCell G3470A-LTE Series firmware versions v1.7.7 and prior have been identified as vulnerable due to missing bounds checking on buffer operations. An attacker could write past the boundaries of allocated buffer regions in memory, causing a program crash. | |||||
| CVE-2024-4511 | 2026-06-17 | 5.8 MEDIUM | 6.3 MEDIUM | ||
| A vulnerability classified as critical has been found in Shanghai Sunfull Automation BACnet Server HMI1002-ARM 2.0.4. This affects an unknown part of the component Message Handler. The manipulation leads to buffer overflow. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-263115. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2024-4143 | 2026-06-17 | N/A | 9.8 CRITICAL | ||
| A potential security vulnerability has been identified in certain HP PC products using AMI BIOS, which might allow arbitrary code execution. AMI has released firmware updates to mitigate this vulnerability. | |||||
| CVE-2024-4020 | 1 Tenda | 2 Fh1206, Fh1206 Firmware | 2026-06-17 | 9.0 HIGH | 8.8 HIGH |
| A vulnerability was found in Tenda FH1206 1.2.0.8(8155) and classified as critical. This issue affects the function fromAddressNat of the file /goform/addressNat. The manipulation of the argument entrys leads to buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-261671. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2024-49996 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev(). | |||||
| CVE-2024-49869 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 ("btrfs: send: annotate struct name_cache_entry with __counted_by()") we annotated the variable length array "name" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the "name_len" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: <TASK> ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 </TASK> Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way "name_len" corresponds to the actual size of the "name" array. This requires marking the "name" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90 | |||||
| CVE-2024-49830 | 1 Qualcomm | 24 Qca6574au, Qca6574au Firmware, Qca6595au and 21 more | 2026-06-17 | N/A | 6.6 MEDIUM |
| Memory corruption while processing an IOCTL call to set mixer controls. | |||||
| CVE-2024-49829 | 1 Qualcomm | 20 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 17 more | 2026-06-17 | N/A | 6.7 MEDIUM |
| Memory corruption can occur during context user dumps due to inadequate checks on buffer length. | |||||
| CVE-2024-49778 | 1 Justdan96 | 1 Tsmuxer | 2026-06-17 | N/A | 8.8 HIGH |
| A heap-based buffer overflow in tsMuxer version nightly-2024-05-12-02-01-18 allows attackers to cause Denial of Service (DoS) and Code Execution via a crafted MOV video file. | |||||
| CVE-2024-49777 | 1 Justdan96 | 1 Tsmuxer | 2026-06-17 | N/A | 8.8 HIGH |
| A heap-based buffer overflow in tsMuxer version nightly-2024-03-14-01-51-12 allows attackers to cause Denial of Service (DoS), Information Disclosure and Code Execution via a crafted MKV video file. | |||||
| CVE-2024-48986 | 1 Arm | 1 Mbed | 2026-06-17 | N/A | 7.5 HIGH |
| An issue was discovered in MBed OS 6.16.0. Its hci parsing software dynamically determines the length of certain hci packets by reading a byte from its header. Certain events cause a callback, the logic for which allocates a buffer (the length of which is determined by looking up the event type in a table). The subsequent write operation, however, copies the amount of data specified in the packet header, which may lead to a buffer overflow. This bug is trivial to exploit for a denial of service but is not certain to suffice to bring the system down and can generally not be exploited further because the exploitable buffer is dynamically allocated. | |||||
| CVE-2024-48985 | 1 Arm | 1 Mbed | 2026-06-17 | N/A | 7.5 HIGH |
| An issue was discovered in MBed OS 6.16.0. During processing of HCI packets, the software dynamically determines the length of the packet data by reading 2 bytes from the packet data. A buffer is then allocated to contain the entire packet, the size of which is calculated as the length of the packet body determined earlier and the header length. If the allocate fails because the specified packet is too large, no exception handling occurs and hciTrSerialRxIncoming continues to write bytes into the 4-byte large temporary header buffer, leading to a buffer overflow. This can be leveraged into an arbitrary write by an attacker. It is possible to overwrite the pointer to the buffer that is supposed to receive the contents of the packet body but which couldn't be allocated. One can then overwrite the state variable used by the function to determine which step of the parsing process is currently being executed. This advances the function to the next state, where it proceeds to copy data to that arbitrary location. The packet body is then written wherever the corrupted data pointer is pointing. | |||||
| CVE-2024-48984 | 1 Arm | 1 Mbed Os | 2026-06-17 | N/A | 9.8 CRITICAL |
| An issue was discovered in MBed OS 6.16.0. When parsing hci reports, the hci parsing software dynamically determines the length of a list of reports by reading a byte from an input stream. It then fetches the length of the first report, uses it to calculate the beginning of the second report, etc. In doing this, it tracks the largest report so it can later allocate a buffer that fits every individual report (but only one at a time). It does not, however, validate that these addresses are all contained within the buffer passed to hciEvtProcessLeExtAdvReport. It is then possible, though unlikely, that the buffer designated to hold the reports is allocated in such a way that one of these out-of-bounds length fields is contained within the new buffer. When the (n-1)th report is copied, it overwrites the length field of the nth report. This now corrupted length field is then used for a memcpy into the new buffer, which may lead to a buffer overflow. | |||||
| CVE-2024-48982 | 1 Arm | 1 Mbed | 2026-06-17 | N/A | 7.5 HIGH |
| An issue was discovered in MBed OS 6.16.0. Its hci parsing software dynamically determines the length of certain hci packets by reading a byte from its header. This value is assumed to be greater than or equal to 3, but the software doesn't ensure that this is the case. Supplying a length less than 3 leads to a buffer overflow in a buffer that is allocated later. It is simultaneously possible to cause another integer overflow by supplying large length values because the provided length value is increased by a few bytes to account for additional information that is supposed to be stored there. This bug is trivial to exploit for a denial of service but is not certain to suffice to bring the system down and can generally not be exploited further because the exploitable buffer is dynamically allocated. | |||||
| CVE-2024-48981 | 1 Arm | 1 Mbed | 2026-06-17 | N/A | 7.5 HIGH |
| An issue was discovered in MBed OS 6.16.0. During processing of HCI packets, the software dynamically determines the length of the packet header by looking up the identifying first byte and matching it against a table of possible lengths. The initial parsing function, hciTrSerialRxIncoming does not drop packets with invalid identifiers but also does not set a safe default for the length of unknown packets' headers, leading to a buffer overflow. This can be leveraged into an arbitrary write by an attacker. It is possible to overwrite the pointer to a not-yet-allocated buffer that is supposed to receive the contents of the packet body. One can then overwrite the state variable used by the function to determine which state of packet parsing is currently occurring. Because the buffer is allocated when the last byte of the header has been copied, the combination of having a bad header length variable that will never match the counter variable and being able to overwrite the state variable with the resulting buffer overflow can be used to advance the function to the next step while skipping the buffer allocation and resulting pointer write. The next 16 bytes from the packet body are then written wherever the corrupted data pointer is pointing. | |||||
| CVE-2024-48806 | 2026-06-17 | N/A | 6.8 MEDIUM | ||
| Buffer Overflow vulnerability in Neat Board NFC v.1.20240620.0015 allows a physically proximate attackers to escalate privileges via a crafted payload to the password field | |||||
| CVE-2024-48714 | 1 Tp-link | 2 Tl-wdr7660, Tl-wdr7660 Firmware | 2026-06-17 | N/A | 6.5 MEDIUM |
| In TP-Link TL-WDR7660 v1.0, the guestRuleJsonToBin function handles the parameter string name without checking it, which can lead to stack overflow vulnerabilities. | |||||
| CVE-2024-48713 | 1 Tp-link | 2 Tl-wdr7660, Tl-wdr7660 Firmware | 2026-06-17 | N/A | 6.5 MEDIUM |
| In TP-Link TL-WDR7660 1.0, the wacWhitelistJsonToBin function handles the parameter string name without checking it, which can lead to stack overflow vulnerabilities. | |||||
| CVE-2024-48712 | 1 Tp-link | 2 Tl-wdr7660, Tl-wdr7660 Firmware | 2026-06-17 | N/A | 6.5 MEDIUM |
| In TP-Link TL-WDR7660 1.0, the rtRuleJsonToBin function handles the parameter string name without checking it, which can lead to stack overflow vulnerabilities. | |||||
| CVE-2024-48710 | 1 Tp-link | 2 Tl-wdr7660, Tl-wdr7660 Firmware | 2026-06-17 | N/A | 6.5 MEDIUM |
| In TP-Link TL-WDR7660 1.0, the wlanTimerRuleJsonToBin function handles the parameter string name without checking it, which can lead to stack overflow vulnerabilities. | |||||