Total
7759 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-31209 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | N/A | 6.3 MEDIUM |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. Parsing a file may lead to disclosure of user information. | |||||
| CVE-2025-31196 | 1 Apple | 2 Ipados, Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in iPadOS 17.7.7, macOS Ventura 13.7.6, macOS Sonoma 14.7.6. Processing a maliciously crafted file may lead to a denial-of-service or potentially disclose memory contents. | |||||
| CVE-2025-2784 | 2 Gnome, Redhat | 21 Libsoup, Codeready Linux Builder, Codeready Linux Builder For Arm64 and 18 more | 2025-11-03 | N/A | 7.0 HIGH |
| A flaw was found in libsoup. The package is vulnerable to a heap buffer over-read when sniffing content via the skip_insight_whitespace() function. Libsoup clients may read one byte out-of-bounds in response to a crafted HTTP response by an HTTP server. | |||||
| CVE-2025-27931 | 1 Pdf-xchange | 1 Pdf-xchange Editor | 2025-11-03 | N/A | 6.5 MEDIUM |
| An out-of-bounds read vulnerability exists in the EMF functionality of PDF-XChange Editor version 10.5.2.395. By using a specially crafted EMF file, an attacker could exploit this vulnerability to perform an out-of-bounds read, potentially leading to the disclosure of sensitive information. | |||||
| CVE-2025-24311 | 2025-11-03 | N/A | 8.4 HIGH | ||
| An out-of-bounds read vulnerability exists in the cv_send_blockdata functionality of Dell ControlVault3 prior to 5.15.10.14 and Dell ControlVault3 Plus prior to 6.2.26.36. A specially crafted ControlVault API call can lead to an information leak. An attacker can issue an API call to trigger this vulnerability. | |||||
| CVE-2025-22079 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate l_tree_depth to avoid out-of-bounds access The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1]. | |||||
| CVE-2025-22038 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate zero num_subauth before sub_auth is accessed Access psid->sub_auth[psid->num_subauth - 1] without checking if num_subauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure num_subauth != 0 before sub_auth is accessed. | |||||
| CVE-2025-21993 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic() When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message. | |||||
| CVE-2025-21920 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 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-2025-21905 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: limit printed string from FW file There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer. Fix that by limiting the print format to the size of the buffer we have. | |||||
| CVE-2025-21719 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to "struct sk_buff_head unresolved", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708 | |||||
| CVE-2024-58014 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. | |||||
| CVE-2024-58007 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. | |||||
| CVE-2024-57998 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: OPP: add index check to assert to avoid buffer overflow in _read_freq() Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed(). Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions. | |||||
| CVE-2024-57945 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. | |||||
| CVE-2024-56378 | 1 Freedesktop | 1 Poppler | 2025-11-03 | N/A | 4.3 MEDIUM |
| libpoppler.so in Poppler through 24.12.0 has an out-of-bounds read vulnerability within the JBIG2Bitmap::combine function in JBIG2Stream.cc. | |||||
| CVE-2023-53154 | 1 Cjson Project | 1 Cjson | 2025-11-03 | N/A | 2.9 LOW |
| parse_string in cJSON before 1.7.18 has a heap-based buffer over-read via {"1":1, with no trailing newline if cJSON_ParseWithLength is called. | |||||
| CVE-2023-53034 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative. [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative Ensuring xlate_pos is a positive or zero before BIT. | |||||
| CVE-2023-42822 | 2 Fedoraproject, Neutrinolabs | 2 Fedora, Xrdp | 2025-11-03 | N/A | 4.6 MEDIUM |
| xrdp is an open source remote desktop protocol server. Access to the font glyphs in xrdp_painter.c is not bounds-checked . Since some of this data is controllable by the user, this can result in an out-of-bounds read within the xrdp executable. The vulnerability allows an out-of-bounds read within a potentially privileged process. On non-Debian platforms, xrdp tends to run as root. Potentially an out-of-bounds write can follow the out-of-bounds read. There is no denial-of-service impact, providing xrdp is running in forking mode. This issue has been addressed in release 0.9.23.1. Users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2023-29383 | 1 Shadow Project | 1 Shadow | 2025-11-03 | N/A | 3.3 LOW |
| In Shadow 4.13, it is possible to inject control characters into fields provided to the SUID program chfn (change finger). Although it is not possible to exploit this directly (e.g., adding a new user fails because \n is in the block list), it is possible to misrepresent the /etc/passwd file when viewed. Use of \r manipulations and Unicode characters to work around blocking of the : character make it possible to give the impression that a new user has been added. In other words, an adversary may be able to convince a system administrator to take the system offline (an indirect, social-engineered denial of service) by demonstrating that "cat /etc/passwd" shows a rogue user account. | |||||