CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41064 – powerpc/eeh: avoid possible crash when edev->pdev changes
https://notcve.org/view.php?id=CVE-2024-41064
In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: avoid possible crash when edev->pdev changes If a PCI device is removed during eeh_pe_report_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus. • https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3 https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1 https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274 https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5 https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41063 – Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
https://notcve.org/view.php?id=CVE-2024-41063
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list. • https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9 https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92 https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39 https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678 https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41062 – bluetooth/l2cap: sync sock recv cb and release
https://notcve.org/view.php?id=CVE-2024-41062
In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. • https://git.kernel.org/stable/c/605572e64cd9cebb05ed609d96cff05b50d18cdf https://git.kernel.org/stable/c/b803f30ea23e0968b6c8285c42adf0d862ab2bf6 https://git.kernel.org/stable/c/3b732449b78183d17178db40be3a4401cf3cd629 https://git.kernel.org/stable/c/89e856e124f9ae548572c56b1b70c2255705f8fe •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41061 – drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport
https://notcve.org/view.php?id=CVE-2024-41061
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. • https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85 https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41060 – drm/radeon: check bo_va->bo is non-NULL before using it
https://notcve.org/view.php?id=CVE-2024-41060
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. • https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3 https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342 https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536 •