Total
7727 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-30176 | 1 Siemens | 5 Simatic Pcs Neo, Sinec Nms, Sinema Remote Connect and 2 more | 2025-10-03 | N/A | 7.5 HIGH |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SINEC NMS (All versions < V4.0), SINEMA Remote Connect (All versions), Totally Integrated Automation Portal (TIA Portal) V17 (All versions), Totally Integrated Automation Portal (TIA Portal) V18 (All versions), Totally Integrated Automation Portal (TIA Portal) V19 (All versions), Totally Integrated Automation Portal (TIA Portal) V20 (All versions), User Management Component (UMC) (All versions < V2.15.1.1). Affected products contain a out of bound read buffer overflow vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to cause a denial of service condition. | |||||
| CVE-2025-30174 | 1 Siemens | 4 Sinec Nms, Sinema Remote Connect, Totally Integrated Automation Portal and 1 more | 2025-10-03 | N/A | 7.5 HIGH |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SINEC NMS (All versions < V4.0), SINEMA Remote Connect (All versions), Totally Integrated Automation Portal (TIA Portal) V17 (All versions), Totally Integrated Automation Portal (TIA Portal) V18 (All versions), Totally Integrated Automation Portal (TIA Portal) V19 (All versions), Totally Integrated Automation Portal (TIA Portal) V20 (All versions), User Management Component (UMC) (All versions < V2.15.1.1). Affected products contain a out of bound read buffer overflow vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to cause a denial of service condition. | |||||
| CVE-2025-21438 | 1 Qualcomm | 86 Fastconnect 6200, Fastconnect 6200 Firmware, Fastconnect 6700 and 83 more | 2025-10-03 | N/A | 7.8 HIGH |
| Memory corruption while IOCTL call is invoked from user-space to read board data. | |||||
| CVE-2025-11081 | 1 Gnu | 1 Binutils | 2025-10-03 | 1.7 LOW | 3.3 LOW |
| A vulnerability was detected in GNU Binutils 2.45. This issue affects the function dump_dwarf_section of the file binutils/objdump.c. Performing manipulation results in out-of-bounds read. The attack is only possible with local access. The exploit is now public and may be used. The patch is named f87a66db645caf8cc0e6fc87b0c28c78a38af59b. It is suggested to install a patch to address this issue. | |||||
| CVE-2025-2509 | 1 Google | 1 Chrome Os | 2025-10-03 | N/A | 7.8 HIGH |
| Out-of-Bounds Read in Virglrenderer in ChromeOS 16093.57.0 allows a malicious guest VM to achieve arbitrary address access within the crosvm sandboxed process, potentially leading to VM escape via crafted vertex elements data triggering an out-of-bounds read in util_format_description. | |||||
| CVE-2025-9230 | 2025-10-02 | N/A | 7.5 HIGH | ||
| Issue summary: An application trying to decrypt CMS messages encrypted using password based encryption can trigger an out-of-bounds read and write. Impact summary: This out-of-bounds read may trigger a crash which leads to Denial of Service for an application. The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service or Execution of attacker-supplied code. Although the consequences of a successful exploit of this vulnerability could be severe, the probability that the attacker would be able to perform it is low. Besides, password based (PWRI) encryption support in CMS messages is very rarely used. For that reason the issue was assessed as Moderate severity according to our Security Policy. The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary. | |||||
| CVE-2025-9232 | 2025-10-02 | N/A | 5.9 MEDIUM | ||
| Issue summary: An application using the OpenSSL HTTP client API functions may trigger an out-of-bounds read if the 'no_proxy' environment variable is set and the host portion of the authority component of the HTTP URL is an IPv6 address. Impact summary: An out-of-bounds read can trigger a crash which leads to Denial of Service for an application. The OpenSSL HTTP client API functions can be used directly by applications but they are also used by the OCSP client functions and CMP (Certificate Management Protocol) client implementation in OpenSSL. However the URLs used by these implementations are unlikely to be controlled by an attacker. In this vulnerable code the out of bounds read can only trigger a crash. Furthermore the vulnerability requires an attacker-controlled URL to be passed from an application to the OpenSSL function and the user has to have a 'no_proxy' environment variable set. For the aforementioned reasons the issue was assessed as Low severity. The vulnerable code was introduced in the following patch releases: 3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0. The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the HTTP client implementation is outside the OpenSSL FIPS module boundary. | |||||
| CVE-2025-53806 | 1 Microsoft | 7 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 4 more | 2025-10-02 | N/A | 6.5 MEDIUM |
| Buffer over-read in Windows Routing and Remote Access Service (RRAS) allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2025-53805 | 1 Microsoft | 6 Windows 11 22h2, Windows 11 23h2, Windows 11 24h2 and 3 more | 2025-10-02 | N/A | 7.5 HIGH |
| Out-of-bounds read in Windows Internet Information Services allows an unauthorized attacker to deny service over a network. | |||||
| CVE-2025-54097 | 1 Microsoft | 7 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 4 more | 2025-10-02 | N/A | 6.5 MEDIUM |
| Out-of-bounds read in Windows Routing and Remote Access Service (RRAS) allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2025-54096 | 1 Microsoft | 7 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 4 more | 2025-10-02 | N/A | 6.5 MEDIUM |
| Out-of-bounds read in Windows Routing and Remote Access Service (RRAS) allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2025-54095 | 1 Microsoft | 7 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 4 more | 2025-10-02 | N/A | 6.5 MEDIUM |
| Out-of-bounds read in Windows Routing and Remote Access Service (RRAS) allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2025-24196 | 1 Apple | 1 Macos | 2025-10-02 | N/A | 8.8 HIGH |
| A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5. An attacker with user privileges may be able to read kernel memory. | |||||
| CVE-2025-21920 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization. | |||||
| CVE-2024-53162 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: qat/qat_4xxx - fix off by one in uof_get_name() The fw_objs[] array has "num_objs" elements so the > needs to be >= to prevent an out of bounds read. | |||||
| CVE-2024-53147 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: exfat: fix out-of-bounds access of directory entries In the case of the directory size is greater than or equal to the cluster size, if start_clu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei->hint_femp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption. This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty. | |||||
| CVE-2024-53108 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8) | |||||
| CVE-2024-53082 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key. | |||||
| CVE-2024-50301 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] | |||||
| CVE-2024-50279 | 1 Linux | 1 Linux Kernel | 2025-10-01 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. | |||||