Total
472 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-45569 | 1 Qualcomm | 348 Ar8035, Ar8035 Firmware, Csr8811 and 345 more | 2025-02-05 | N/A | 9.8 CRITICAL |
| Memory corruption while parsing the ML IE due to invalid frame content. | |||||
| CVE-2025-21680 | 1 Linux | 1 Linux Kernel | 2025-02-04 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: pktgen: Avoid out-of-bounds access in get_imix_entries Passing a sufficient amount of imix entries leads to invalid access to the pkt_dev->imix_entries array because of the incorrect boundary check. UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130 Found by Linux Verification Center (linuxtesting.org) with SVACE. [ fp: allow to fill the array completely; minor changelog cleanup ] | |||||
| CVE-2024-56595 | 1 Linux | 1 Linux Kernel | 2025-01-16 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out. | |||||
| CVE-2024-53228 | 1 Linux | 1 Linux Kernel | 2025-01-16 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: riscv: kvm: Fix out-of-bounds array access In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an out-of-bound index. This is used as a special marker for the base extensions, that cannot be disabled. However, when traversing the extensions, that special marker is not checked prior indexing the array. Add an out-of-bounds check to the function. | |||||
| CVE-2024-56598 | 1 Linux | 1 Linux Kernel | 2025-01-16 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: jfs: array-index-out-of-bounds fix in dtReadFirst The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case. | |||||
| CVE-2024-56596 | 1 Linux | 1 Linux Kernel | 2025-01-16 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in jfs_readdir The stbl might contain some invalid values. Added a check to return error code in that case. | |||||
| CVE-2024-45550 | 1 Qualcomm | 16 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 13 more | 2025-01-13 | N/A | 7.8 HIGH |
| Memory corruption occurs when invoking any IOCTL-calling application that executes all MCDM driver IOCTL calls. | |||||
| CVE-2024-53156 | 1 Linux | 1 Linux Kernel | 2025-01-07 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. | |||||
| CVE-2023-52812 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd: check num of link levels when update pcie param In SR-IOV environment, the value of pcie_table->num_of_link_levels will be 0, and num_of_levels - 1 will cause array index out of bounds | |||||
| CVE-2023-52818 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7 For pptable structs that use flexible array sizes, use flexible arrays. | |||||
| CVE-2024-35905 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-30 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7. | |||||
| CVE-2024-26981 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | 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-2023-52649 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Avoid reading beyond LUT array When the floor LUT index (drm_fixp2int(lut_index) is the last index of the array the ceil LUT index will point to an entry beyond the array. Make sure we guard against it and use the value of the floor LUT index. v3: - Drop bits from commit description that didn't contribute anything of value | |||||
| CVE-2024-27042 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()' The issue arises when the array 'adev->vcn.vcn_config' is accessed before checking if the index 'adev->vcn.num_vcn_inst' is within the bounds of the array. The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array before it is used as an index. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use. | |||||
| CVE-2024-26969 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | |||||
| CVE-2024-26968 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq9574: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | |||||
| CVE-2024-26967 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | |||||
| CVE-2024-26966 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | |||||
| CVE-2024-46871 | 1 Linux | 1 Linux Kernel | 2024-12-14 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it. | |||||
| CVE-2023-31307 | 1 Amd | 32 Radeon Pro W6300, Radeon Pro W6400, Radeon Pro W6600 and 29 more | 2024-12-13 | N/A | 2.3 LOW |
| Improper validation of array index in Power Management Firmware (PMFW) may allow a privileged attacker to cause an out-of-bounds memory read within PMFW, potentially leading to a denial of service. | |||||