Total
448 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2017-8251 | 1 Google | 1 Android | 2025-04-20 | 6.8 MEDIUM | 7.8 HIGH |
| In all Qualcomm products with Android releases from CAF using the Linux kernel, in functions msm_isp_check_stream_cfg_cmd & msm_isp_stats_update_cgc_override, 'stream_cfg_cmd->num_streams' is not checked, and could overflow the array stream_cfg_cmd->stream_handle. | |||||
| CVE-2022-31745 | 1 Mozilla | 1 Firefox | 2025-04-15 | N/A | 4.3 MEDIUM |
| If array shift operations are not used, the Garbage Collector may have become confused about valid objects. This vulnerability affects Firefox < 101. | |||||
| CVE-2023-52988 | 1 Linux | 1 Linux Kernel | 2025-04-15 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE. | |||||
| CVE-2016-7170 | 3 Debian, Opensuse, Qemu | 3 Debian Linux, Leap, Qemu | 2025-04-12 | 2.1 LOW | 4.4 MEDIUM |
| The vmsvga_fifo_run function in hw/display/vmware_vga.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (out-of-bounds write and QEMU process crash) via vectors related to cursor.mask[] and cursor.image[] array sizes when processing a DEFINE_CURSOR svga command. | |||||
| CVE-2016-8815 | 2 Microsoft, Nvidia | 2 Windows, Gpu Driver | 2025-04-12 | 7.2 HIGH | 7.8 HIGH |
| All versions of NVIDIA Windows GPU Display Driver contain a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgDdiEscape where a value passed from a user to the driver is used without validation as the index to an array, leading to denial of service or potential escalation of privileges. | |||||
| CVE-2016-8816 | 2 Microsoft, Nvidia | 2 Windows, Gpu Driver | 2025-04-12 | 7.2 HIGH | 7.8 HIGH |
| All versions of NVIDIA Windows GPU Display Driver contain a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgDdiEscape where a value passed from a user to the driver is used without validation as the index to an array, leading to denial of service or potential escalation of privileges. | |||||
| CVE-2014-6317 | 1 Microsoft | 9 Windows 7, Windows 8, Windows 8.1 and 6 more | 2025-04-12 | 7.1 HIGH | N/A |
| Array index error in win32k.sys in the kernel-mode drivers in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to cause a denial of service (reboot) via a crafted TrueType font, aka "Denial of Service in Windows Kernel Mode Driver Vulnerability." | |||||
| CVE-2010-2806 | 3 Apple, Canonical, Freetype | 5 Iphone Os, Mac Os X, Tvos and 2 more | 2025-04-11 | 6.8 MEDIUM | N/A |
| Array index error in the t42_parse_sfnts function in type42/t42parse.c in FreeType before 2.4.2 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via negative size values for certain strings in FontType42 font files, leading to a heap-based buffer overflow. | |||||
| CVE-2011-1169 | 1 Linux | 1 Linux Kernel | 2025-04-11 | 7.2 HIGH | N/A |
| Array index error in the asihpi_hpi_ioctl function in sound/pci/asihpi/hpioctl.c in the AudioScience HPI driver in the Linux kernel before 2.6.38.1 might allow local users to cause a denial of service (memory corruption) or possibly gain privileges via a crafted adapter index value that triggers access to an invalid kernel pointer. | |||||
| CVE-2025-21991 | 1 Linux | 1 Linux Kernel | 2025-04-10 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their CPU masks and unconditionally accesses per-CPU data for the first CPU of each mask. According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes." Therefore, some node CPU masks may be empty and wouldn't have a "first CPU". On a machine with far memory (and therefore CPU-less NUMA nodes): - cpumask_of_node(nid) is 0 - cpumask_first(0) is CONFIG_NR_CPUS - cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of bounds This does not have any security implications since flashing microcode is a privileged operation but I believe this has reliability implications by potentially corrupting memory while flashing a microcode update. When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes a microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Change the loop to go over only NUMA nodes which have CPUs before determining whether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ] | |||||
| CVE-2024-46821 | 1 Linux | 1 Linux Kernel | 2025-04-10 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix negative array index read Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor. V2: fix clk_index return check (Tim Huang) | |||||
| CVE-2024-46813 | 1 Linux | 1 Linux Kernel | 2025-04-10 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_index before accessing dc->links[] [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index. This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity. | |||||
| CVE-2022-33274 | 1 Qualcomm | 22 Qam8295p, Qam8295p Firmware, Qca6574au and 19 more | 2025-04-09 | N/A | 8.4 HIGH |
| Memory corruption in android core due to improper validation of array index while returning feature ids after license authentication. | |||||
| CVE-2007-5756 | 1 Winpcap | 1 Winpcap | 2025-04-09 | 6.9 MEDIUM | N/A |
| Multiple array index errors in the bpf_filter_init function in NPF.SYS in WinPcap before 4.0.2, when run in monitor mode (aka Table Management Extensions or TME), and as used in Wireshark and possibly other products, allow local users to gain privileges via crafted IOCTL requests. | |||||
| CVE-2009-3080 | 7 Canonical, Debian, Linux and 4 more | 13 Ubuntu Linux, Debian Linux, Linux Kernel and 10 more | 2025-04-09 | 7.2 HIGH | N/A |
| Array index error in the gdth_read_event function in drivers/scsi/gdth.c in the Linux kernel before 2.6.32-rc8 allows local users to cause a denial of service or possibly gain privileges via a negative event index in an IOCTL request. | |||||
| CVE-2025-21423 | 2025-04-07 | N/A | 7.8 HIGH | ||
| Memory corruption occurs when handling client calls to EnableTestMode through an Escape call. | |||||
| CVE-2025-21447 | 2025-04-07 | N/A | 7.8 HIGH | ||
| Memory corruption may occur while processing device IO control call for session control. | |||||
| CVE-2024-38587 | 1 Linux | 1 Linux Kernel | 2025-04-04 | N/A | 5.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: speakup: Fix sizeof() vs ARRAY_SIZE() bug The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds. | |||||
| CVE-2024-26755 | 1 Linux | 1 Linux Kernel | 2025-04-04 | N/A | 5.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done. | |||||
| CVE-2024-26758 | 1 Linux | 1 Linux Kernel | 2025-04-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend. | |||||