Total
488 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-22181 | 1 Libigl | 1 Libigl | 2025-02-12 | N/A | 7.8 HIGH |
| An out-of-bounds write vulnerability exists in the readNODE functionality of libigl v2.5.0. A specially crafted .node file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability. | |||||
| CVE-2023-26066 | 1 Lexmark | 217 6500e, B2236, B2338 and 214 more | 2025-02-11 | N/A | 9.8 CRITICAL |
| Certain Lexmark devices through 2023-02-19 have Improper Validation of an Array Index. | |||||
| CVE-2024-49837 | 1 Qualcomm | 52 Qam8255p, Qam8255p Firmware, Qam8295p and 49 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while reading CPU state data during guest VM suspend. | |||||
| CVE-2024-49843 | 1 Qualcomm | 104 Fastconnect 6200, Fastconnect 6200 Firmware, Fastconnect 7800 and 101 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while processing IOCTL from user space to handle GPU AHB bus error. | |||||
| CVE-2024-49834 | 1 Qualcomm | 254 Csra6620, Csra6620 Firmware, Csra6640 and 251 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while power-up or power-down sequence of the camera sensor. | |||||
| CVE-2024-45582 | 1 Qualcomm | 68 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 65 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while validating number of devices in Camera kernel . | |||||
| CVE-2024-49832 | 1 Qualcomm | 50 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 47 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption in Camera due to unusually high number of nodes passed to AXI port. | |||||
| CVE-2024-49833 | 1 Qualcomm | 160 Fastconnect 6700, Fastconnect 6700 Firmware, Fastconnect 6900 and 157 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption can occur in the camera when an invalid CID is used. | |||||
| 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-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-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-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-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. | |||||
| CVE-2023-52604 | 1 Linux | 1 Linux Kernel | 2024-12-12 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ Kernel panic - not syncing: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> Kernel Offset: disabled Rebooting in 86400 seconds.. The issue is caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a simple check solves this issue. Dave: As the function returns a void, good error handling would require a more intrusive code reorganization, so I modified Osama's patch at use WARN_ON_ONCE for lack of a cleaner option. The patch is tested via syzbot. | |||||