Total
635 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-41564 | 1 Emilyploszaj | 1 Emi | 2026-06-17 | N/A | 4.3 MEDIUM |
| EMI v.1.1.10 and before, fixed in v.1.1.11, contains an Improper Validation of Specified Index, Position, or Offset in Input vulnerability. The specific issue is a failure to validate slot index and decrement stack count in EMI mod for Minecraft, which allows in-game item duplication. | |||||
| CVE-2024-41061 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. | |||||
| CVE-2024-39461 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypi_discover_clocks() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning. | |||||
| CVE-2024-38631 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: iio: adc: PAC1934: fix accessing out of bounds array index Fix accessing out of bounds array index for average current and voltage measurements. The device itself has only 4 channels, but in sysfs there are "fake" channels for the average voltages and currents too. | |||||
| CVE-2024-38562 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: Avoid address calculations via out of bounds array indexing Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning. | |||||
| CVE-2024-36743 | 1 Oneflow | 1 Oneflow | 2026-06-17 | N/A | 7.5 HIGH |
| An issue in OneFlow-Inc. Oneflow v0.9.1 allows attackers to cause a Denial of Service (DoS) when an empty array is processed with oneflow.dot. | |||||
| CVE-2024-36740 | 1 Oneflow | 1 Oneflow | 2026-06-17 | N/A | 7.5 HIGH |
| An issue in OneFlow-Inc. Oneflow v0.9.1 allows attackers to cause a Denial of Service (DoS) when index as a negative number exceeds the range of size. | |||||
| CVE-2024-36015 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded. | |||||
| CVE-2024-35164 | 1 Apache | 1 Guacamole | 2026-06-17 | N/A | 6.8 MEDIUM |
| The terminal emulator of Apache Guacamole 1.5.5 and older does not properly validate console codes received from servers via text-based protocols like SSH. If a malicious user has access to a text-based connection, a specially-crafted sequence of console codes could allow arbitrary code to be executed with the privileges of the running guacd process. Users are recommended to upgrade to version 1.6.0, which fixes this issue. | |||||
| CVE-2024-34050 | 1 Onosproject | 1 Traffic Steering Xapplication | 2026-06-17 | N/A | 7.5 HIGH |
| Open Networking Foundation SD-RAN Rimedo rimedo-ts 0.1.1 has a slice bounds out-of-range panic in "return uint64(b[2])<<16 | uint64(b[1])<<8 | uint64(b[0])" in reader.go. | |||||
| CVE-2024-34048 | 1 O-ran-sc | 1 Ric-plt-e2mgr | 2026-06-17 | N/A | 9.8 CRITICAL |
| O-RAN RIC I-Release e2mgr lacks array size checks in E2nodeConfigUpdateNotificationHandler. | |||||
| CVE-2024-34047 | 1 O-ran-sc | 1 Ric-plt-e2mgr | 2026-06-17 | N/A | 4.3 MEDIUM |
| O-RAN RIC I-Release e2mgr lacks array size checks in RicServiceUpdateHandler. | |||||
| CVE-2024-33044 | 1 Qualcomm | 422 315 5g Iot Modem, 315 5g Iot Modem Firmware, Aqt1000 and 419 more | 2026-06-17 | N/A | 8.4 HIGH |
| Memory corruption while Configuring the SMR/S2CR register in Bypass mode. | |||||
| CVE-2024-33032 | 1 Qualcomm | 138 C-v2x 9150, C-v2x 9150 Firmware, Fastconnect 6200 and 135 more | 2026-06-17 | N/A | 6.7 MEDIUM |
| Memory corruption when the user application modifies the same shared memory asynchronously when kernel is accessing it. | |||||
| CVE-2024-32673 | 2026-06-17 | N/A | 5.5 MEDIUM | ||
| Improper Validation of Array Index vulnerability in Samsung Open Source Walrus Webassembly runtime engine allows a segmentation fault issue. This issue affects Walrus: before 72c7230f32a0b791355bbdfc78669701024b0956. | |||||
| CVE-2024-31581 | 2 Fedoraproject, Ffmpeg | 2 Fedora, Ffmpeg | 2026-06-17 | N/A | 9.8 CRITICAL |
| FFmpeg version n6.1 was discovered to contain an improper validation of array index vulnerability in libavcodec/cbs_h266_syntax_template.c. This vulnerability allows attackers to cause undefined behavior within the application. | |||||
| CVE-2024-2214 | 1 Eclipse | 1 Threadx | 2026-06-17 | N/A | 7.0 HIGH |
| In Eclipse ThreadX before version 6.4.0, the _Mtxinit() function in the Xtensa port was missing an array size check causing a memory overwrite. The affected file was ports/xtensa/xcc/src/tx_clib_lock.c | |||||
| CVE-2024-29231 | 1 Synology | 2 Diskstation Manager, Surveillance Station | 2026-06-17 | N/A | 5.4 MEDIUM |
| Improper validation of array index vulnerability in UserPrivilege.Enum webapi component in Synology Surveillance Station before 9.2.0-9289 and 9.2.0-11289 allows remote authenticated users to obtain non-sensitive information and conduct limited denial-of-service attacks via unspecified vectors. | |||||
| CVE-2024-26981 | 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: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. | |||||
| CVE-2024-26758 | 1 Linux | 1 Linux Kernel | 2026-06-17 | 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. | |||||