CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50030 – drm/xe/ct: prevent UAF in send_recv()
https://notcve.org/view.php?id=CVE-2024-50030
In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/8ed7dd4c55e4fb21531a9645aeb66a30eaf43a46 https://git.kernel.org/stable/c/db7f92af626178ba59dbbcdd5dee9ec24a987a88 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50029 – Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync
https://notcve.org/view.php?id=CVE-2024-50029
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? • https://git.kernel.org/stable/c/e07a06b4eb417f5271d33ce2240e93c62d98b7b4 https://git.kernel.org/stable/c/867639300759e3e1c5b1e1a5ff89231f263a32a7 https://git.kernel.org/stable/c/98ccd44002d88cbf4edfc4480df532a3da5a013e https://git.kernel.org/stable/c/18fd04ad856df07733f5bb07e7f7168e7443d393 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50028 – thermal: core: Reference count the zone in thermal_zone_get_by_id()
https://notcve.org/view.php?id=CVE-2024-50028
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. • https://git.kernel.org/stable/c/1ce50e7d408ef2bdc8ca021363fd46d1b8bfad00 https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802 https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50027 – thermal: core: Free tzp copy along with the thermal zone
https://notcve.org/view.php?id=CVE-2024-50027
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more. • https://git.kernel.org/stable/c/3d439b1a2ad36c8b4ea151c8de25309d60d17407 https://git.kernel.org/stable/c/eabe285e1c629a719d6e68fc319939c63b83bf22 https://git.kernel.org/stable/c/bdb0d40507c85bee33c2a71fde7b2e857346f112 https://git.kernel.org/stable/c/827a07525c099f54d3b15110408824541ec66b3c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50026 – scsi: wd33c93: Don't use stale scsi_pointer value
https://notcve.org/view.php?id=CVE-2024-50026
In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting. • https://git.kernel.org/stable/c/dbb2da557a6a87c88bbb4b1fef037091b57f701b https://git.kernel.org/stable/c/3afeceda855dea9b85cddd96307d4d17c8742005 https://git.kernel.org/stable/c/e04642a207f1d2ae28a08624c04c67f5681f3451 https://git.kernel.org/stable/c/b60ff1a95c7c386cdd6153de3d7d85edaeabd800 https://git.kernel.org/stable/c/9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec •