Vulnerabilities > Linux > Linux Kernel > 6.10
DATE | CVE | VULNERABILITY TITLE | RISK |
---|---|---|---|
2024-07-30 | CVE-2024-42142 | Unspecified vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-switch, Create ingress ACL when needed Currently, ingress acl is used for three features. | 5.5 |
2024-07-30 | CVE-2024-42149 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: fs: don't misleadingly warn during thaw operations The block device may have been frozen before it was claimed by a filesystem. | 5.5 |
2024-07-30 | CVE-2024-42150 | Unspecified vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net: txgbe: remove separate irq request for MSI and INTx When using MSI or INTx interrupts, request_irq() for pdev->irq will conflict with request_threaded_irq() for txgbe->misc.irq, to cause system crash. | 5.5 |
2024-07-30 | CVE-2024-42152 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). | 4.7 |
2024-07-30 | CVE-2024-42153 | Improper Locking vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. | 5.5 |
2024-07-30 | CVE-2024-42154 | Improper Check for Unusual or Exceptional Conditions vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated). | 4.4 |
2024-07-30 | CVE-2024-42230 | Unspecified vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. | 4.4 |
2024-07-30 | CVE-2024-42231 | Incorrect Calculation vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix calc_available_free_space() for zoned mode calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. | 5.5 |
2024-07-29 | CVE-2024-42089 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. | 5.5 |
2024-07-29 | CVE-2024-42070 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. | 5.5 |