CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44956 – drm/xe/preempt_fence: enlarge the fence critical section
https://notcve.org/view.php?id=CVE-2024-44956
In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences. • https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44955 – drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute
https://notcve.org/view.php?id=CVE-2024-44955
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When commit new state which directly referring to info stored in dc_sink will cause null pointer dereference. [how] Remove redundant checking condition. Relevant condition should already be covered by checking if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. • https://git.kernel.org/stable/c/39b217193729aa45eded8de24d9245468a0c0263 https://git.kernel.org/stable/c/fcf6a49d79923a234844b8efe830a61f3f0584e4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44954 – ALSA: line6: Fix racy access to midibuf
https://notcve.org/view.php?id=CVE-2024-44954
In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5 https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29 https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747 https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44953 – scsi: ufs: core: Fix deadlock during RTC update
https://notcve.org/view.php?id=CVE-2024-44953
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix deadlock during RTC update There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume. Here is deadlock backtrace: kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff <ffffffee5e71ddb0> __switch_to+0x1a8/0x2d4 <ffffffee5e71e604> __schedule+0x684/0xa98 <ffffffee5e71ea60> schedule+0x48/0xc8 <ffffffee5e725f78> schedule_timeout+0x48/0x170 <ffffffee5e71fb74> do_wait_for_common+0x108/0x1b0 <ffffffee5e71efe0> wait_for_completion+0x44/0x60 <ffffffee5d6de968> __flush_work+0x39c/0x424 <ffffffee5d6decc0> __cancel_work_sync+0xd8/0x208 <ffffffee5d6dee2c> cancel_delayed_work_sync+0x14/0x28 <ffffffee5e2551b8> __ufshcd_wl_suspend+0x19c/0x480 <ffffffee5e255fb8> ufshcd_wl_runtime_suspend+0x3c/0x1d4 <ffffffee5dffd80c> scsi_runtime_suspend+0x78/0xc8 <ffffffee5df93580> __rpm_callback+0x94/0x3e0 <ffffffee5df90b0c> rpm_suspend+0x2d4/0x65c <ffffffee5df91448> __pm_runtime_suspend+0x80/0x114 <ffffffee5dffd95c> scsi_runtime_idle+0x38/0x6c <ffffffee5df912f4> rpm_idle+0x264/0x338 <ffffffee5df90f14> __pm_runtime_idle+0x80/0x110 <ffffffee5e24ce44> ufshcd_rtc_work+0x128/0x1e4 <ffffffee5d6e3a40> process_one_work+0x26c/0x650 <ffffffee5d6e65c8> worker_thread+0x260/0x3d8 <ffffffee5d6edec8> kthread+0x110/0x134 <ffffffee5d616b18> ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE. • https://git.kernel.org/stable/c/6bf999e0eb41850d5c857102535d5c53b2ede224 https://git.kernel.org/stable/c/f13f1858a28c68b7fc0d72c2008d5c1f80d2e8d5 https://git.kernel.org/stable/c/3911af778f208e5f49d43ce739332b91e26bc48e •
CVSS: -EPSS: 0%CPEs: 16EXPL: 0CVE-2024-44952 – driver core: Fix uevent_show() vs driver detach race
https://notcve.org/view.php?id=CVE-2024-44952
In the Linux kernel, the following vulnerability has been resolved: driver core: Fix uevent_show() vs driver detach race uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. • https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea •