CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47658 – crypto: stm32/cryp - call finalize with bh disabled
https://notcve.org/view.php?id=CVE-2024-47658
In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. • https://git.kernel.org/stable/c/d93a2f86b0a998aa1f0870c85a2a60a0771ef89a https://git.kernel.org/stable/c/5d734665cd5d93270731e0ff1dd673fec677f447 https://git.kernel.org/stable/c/56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46871 – drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
https://notcve.org/view.php?id=CVE-2024-46871
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. • https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7 https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37 https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98 https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46870 – drm/amd/display: Disable DMCUB timeout for DCN35
https://notcve.org/view.php?id=CVE-2024-46870
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state. [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal. • https://git.kernel.org/stable/c/31c254c9cd4b122a10db297124f867107a696d83 https://git.kernel.org/stable/c/7c70e60fbf4bff1123f0e8d5cb1ae71df6164d7f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46869 – Bluetooth: btintel_pcie: Allocate memory for driver private data
https://notcve.org/view.php?id=CVE-2024-46869
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data. • https://git.kernel.org/stable/c/6e65a09f927566f257322358d429b267548473eb https://git.kernel.org/stable/c/fa9e1c1b1f389a8e6d987ac6cb3e2ba04f8ec875 https://git.kernel.org/stable/c/2b4545f08cc68d2fc835f5c490b36e0264750030 https://git.kernel.org/stable/c/7ffaa200251871980af12e57649ad57c70bf0f43 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46868 – firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
https://notcve.org/view.php?id=CVE-2024-46868
In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire() If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting. • https://git.kernel.org/stable/c/759e7a2b62eb3ef3c93ffeb5cca788a09627d7d9 https://git.kernel.org/stable/c/8c6a5a1fc02ad1d62d06897ab330693d4d27cd03 https://git.kernel.org/stable/c/db213b0cfe3268d8b1d382b3bcc999c687a2567f •