CVSS: -EPSS: %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 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-46867 – drm/xe/client: fix deadlock in show_meminfo()
https://notcve.org/view.php?id=CVE-2024-46867
In the Linux kernel, the following vulnerability has been resolved: drm/xe/client: fix deadlock in show_meminfo() There is a real deadlock as well as sleeping in atomic() bug in here, if the bo put happens to be the last ref, since bo destruction wants to grab the same spinlock and sleeping locks. Fix that by dropping the ref using xe_bo_put_deferred(), and moving the final commit outside of the lock. Dropping the lock around the put is tricky since the bo can go out of scope and delete itself from the list, making it difficult to navigate to the next list entry. (cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a) • https://git.kernel.org/stable/c/0845233388f8a26d00acf9bf230cfd4f36aa4c30 https://git.kernel.org/stable/c/9d3de463e23bfb1ff1567a32b099b1b3e5286a48 https://git.kernel.org/stable/c/9bd7ff293fc84792514aeafa06c5a17f05cb5f4b •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-46866 – drm/xe/client: add missing bo locking in show_meminfo()
https://notcve.org/view.php?id=CVE-2024-46866
In the Linux kernel, the following vulnerability has been resolved: drm/xe/client: add missing bo locking in show_meminfo() bo_meminfo() wants to inspect bo state like tt and the ttm resource, however this state can change at any point leading to stuff like NPD and UAF, if the bo lock is not held. Grab the bo lock when calling bo_meminfo(), ensuring we drop any spinlocks first. In the case of object_idr we now also need to hold a ref. v2 (MattB) - Also add xe_bo_assert_held() (cherry picked from commit 4f63d712fa104c3ebefcb289d1e733e86d8698c7) • https://git.kernel.org/stable/c/0845233388f8a26d00acf9bf230cfd4f36aa4c30 https://git.kernel.org/stable/c/abc8feacacf8fae10eecf6fea7865e8c1fee419c https://git.kernel.org/stable/c/94c4aa266111262c96c98f822d1bccc494786fee •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-46865 – fou: fix initialization of grc
https://notcve.org/view.php?id=CVE-2024-46865
In the Linux kernel, the following vulnerability has been resolved: fou: fix initialization of grc The grc must be initialize first. There can be a condition where if fou is NULL, goto out will be executed and grc would be used uninitialized. • https://git.kernel.org/stable/c/d7567f098f54cb53ee3cee1c82e3d0ed9698b6b3 https://git.kernel.org/stable/c/1df42be305fe478ded1ee0c1d775f4ece713483b https://git.kernel.org/stable/c/c46cd6aaca81040deaea3500ba75126963294bd9 https://git.kernel.org/stable/c/231c235d2f7a66f018f172e26ffd47c363f244ef https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08 https://git.kernel.org/stable/c/5d537b8d900514509622ce92330b70d2e581d409 https://git.kernel.org/stable/c/7ae890ee19479eeeb87724cca8430b5cb3660c74 https://git.kernel.org/stable/c/aca06c617c83295f0caa486ad608fbef7 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-46864 – x86/hyperv: fix kexec crash due to VP assist page corruption
https://notcve.org/view.php?id=CVE-2024-46864
In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: fix kexec crash due to VP assist page corruption commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") introduces a new cpuhp state for hyperv initialization. cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and so hv_cpu_die() won't be called on all CPUs. This means the VP assist page won't be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec panic/hang issues"). Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state(). • https://git.kernel.org/stable/c/9636be85cc5bdd8b7a7f6a53405cbcc52161c93c https://git.kernel.org/stable/c/2ae1beb3ab4f28868cc5d1541d05e1fbee3ad825 https://git.kernel.org/stable/c/d6f018a3b49d0a94ddbd0e479c2af6b19724e434 https://git.kernel.org/stable/c/b9af6418279c4cf73ca073f8ea024992b38be8ab •