CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-53088 – i40e: fix race condition by adding filter's intermediate sync state
https://notcve.org/view.php?id=CVE-2024-53088
In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. • https://git.kernel.org/stable/c/278e7d0b9d6864a9749b9473a273892aa1528621 https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791 https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1 https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6 https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-53087 – drm/xe: Fix possible exec queue leak in exec IOCTL
https://notcve.org/view.php?id=CVE-2024-53087
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/2f92b77a8ce043fbda2664d9be4b66bdc57f67b7 https://git.kernel.org/stable/c/af797b831d8975cb4610f396dcb7f03f4b9908e7 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53086 – drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL
https://notcve.org/view.php?id=CVE-2024-53086
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095) • https://git.kernel.org/stable/c/58480c1c912ff8146d067301a0d04cca318b4a66 https://git.kernel.org/stable/c/43c8a525cbc5c8ff9d12bd8917bfaa376a29279d https://git.kernel.org/stable/c/96397b1e25dda8389dea63ec914038a170bf953d https://git.kernel.org/stable/c/64a2b6ed4bfd890a0e91955dd8ef8422a3944ed9 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53085 – tpm: Lock TPM chip in tpm_pm_suspend() first
https://notcve.org/view.php?id=CVE-2024-53085
In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved. • https://git.kernel.org/stable/c/99d46450625590d410f86fe4660a5eff7d3b8343 https://git.kernel.org/stable/c/7cd46930b8bf37b84777410ac21bfdf1179021d5 https://git.kernel.org/stable/c/eeda114c92c7b2db69878cdf27163750fd57cfe2 https://git.kernel.org/stable/c/bc203fe416abdd1c29da594565a7c3c4e979488e https://git.kernel.org/stable/c/9265fed6db601ee2ec47577815387458ef4f047a •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-53084 – drm/imagination: Break an object reference loop
https://notcve.org/view.php?id=CVE-2024-53084
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. • https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1 •