Vulnerabilities > Linux > Linux Kernel > High
| DATE | CVE | VULNERABILITY TITLE | RISK |
|---|---|---|---|
| 2024-07-30 | CVE-2024-42147 | Double Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. | 7.8 |
| 2024-07-30 | CVE-2024-42148 | Improper Validation of Array Index vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). | 7.8 |
| 2024-07-30 | CVE-2024-42159 | Improper Check for Unusual or Exceptional Conditions vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. | 7.8 |
| 2024-07-30 | CVE-2024-42160 | Improper Check for Unusual or Exceptional Conditions vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code. | 7.8 |
| 2024-07-30 | CVE-2024-42162 | Improper Check for Unusual or Exceptional Conditions vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: gve: Account for stopped queues when reading NIC stats We now account for the fact that the NIC might send us stats for a subset of queues. | 7.0 |
| 2024-07-30 | CVE-2024-42225 | Use of Uninitialized Resource vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: replace skb_put with skb_put_zero Avoid potentially reusing uninitialized data | 7.5 |
| 2024-07-30 | CVE-2024-42228 | Use of Uninitialized Resource vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian) | 7.0 |
| 2024-07-29 | CVE-2024-42093 | Out-of-bounds Write vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | 7.8 |
| 2024-07-29 | CVE-2024-42094 | Out-of-bounds Write vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | 7.8 |
| 2024-07-29 | CVE-2024-41087 | Double Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix double free on error If e.g. | 7.8 |