CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2024-44960 – usb: gadget: core: Check for unset descriptor
https://notcve.org/view.php?id=CVE-2024-44960
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: Check for unset descriptor Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. • https://git.kernel.org/stable/c/d1c188d330ca33cc35d1590441ba276f31144299 https://git.kernel.org/stable/c/54f83b8c8ea9b22082a496deadf90447a326954e https://git.kernel.org/stable/c/d7e3f2fe01372eb914d0e451f0e7a46cbcb98f9e https://git.kernel.org/stable/c/85c9ece11264499890d0e9f0dee431ac1bda981c https://git.kernel.org/stable/c/fc71e39a6c07440e6968227f3db1988f45d7a7b7 https://git.kernel.org/stable/c/94f5de2eefae22c449e367c2dacafe869af73e3f https://git.kernel.org/stable/c/8212b44b7109bd30dbf7eb7f5ecbbc413757a7d7 https://git.kernel.org/stable/c/ba15815dd24cc5ec0d23e2170dc58c7db •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44957 – xen: privcmd: Switch from mutex to spinlock for irqfds
https://notcve.org/view.php?id=CVE-2024-44957
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock. • https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3 •
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 •