CVSS: 5.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-43870 – perf: Fix event leak upon exit
https://notcve.org/view.php?id=CVE-2024-43870
In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exit When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); <IRQ> perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); </IRQ> =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] <IRQ WORK> perf_pending_irq() // early return: event->oncpu = -1 </IRQ WORK> [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling. A logical flaw exists in the Linux kernel. When a task is scheduled, pending sigtrap deliveries are deferred to the target task upon resuming to userspace via task_work. • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8 https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c https://git.kernel.org/stable/c/67fad724f1b568b356c1065d50df46e6b30eb2f7 https://git.kernel.org/stable/c/70882d7fa74f0731492a0d493e8515a4f7131831 https://git.kernel.org/stable/c/05d3fd599594abf79aad4484bccb2b26e1cb0b51 https://git.kernel.org/stable/c/3d7a63352a93bdb8a1cdf29606bf617d3ac1c22a https://git.kernel.org/stable/c/2fd5ad3f310de22836cdacae919dd99d7 • CWE-404: Improper Resource Shutdown or Release •
CVSS: 6.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-43869 – perf: Fix event leak upon exec and file release
https://notcve.org/view.php?id=CVE-2024-43869
In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exec and file release The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed. • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8 https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c https://git.kernel.org/stable/c/9ad46f1fef421d43cdab3a7d1744b2f43b54dae0 https://git.kernel.org/stable/c/ed2c202dac55423a52d7e2290f2888bf08b8ee99 https://git.kernel.org/stable/c/104e258a004037bc7dba9f6085c71dad6af57ad4 https://git.kernel.org/stable/c/f34d8307a73a18de5320fcc6f40403146d061891 https://git.kernel.org/stable/c/3a5465418f5fd970e86a86c7f4075be26 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43867 – drm/nouveau: prime: fix refcount underflow
https://notcve.org/view.php?id=CVE-2024-43867
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) • https://git.kernel.org/stable/c/ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6 https://git.kernel.org/stable/c/3bcb8bba72ce89667fa863054956267c450c47ef https://git.kernel.org/stable/c/906372e753c5027a1dc88743843b6aa2ad1aaecf https://git.kernel.org/stable/c/16998763c62bb465ebc409d0373b9cdcef1a61a6 https://git.kernel.org/stable/c/ebebba4d357b6c67f96776a48ddbaf0060fa4c10 https://git.kernel.org/stable/c/f23cd66933fe76b84d8e282e5606b4d99068c320 https://git.kernel.org/stable/c/2a1b327d57a8ac080977633a18999f032d7e9e3f https://git.kernel.org/stable/c/a9bf3efc33f1fbf88787a277f73494592 •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43866 – net/mlx5: Always drain health in shutdown callback
https://notcve.org/view.php?id=CVE-2024-43866
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. • https://git.kernel.org/stable/c/d2aa060d40fa060e963f9a356d43481e43ba3dac https://git.kernel.org/stable/c/63d10e93df94c93bdeac87a9401696b1edadb7ed https://git.kernel.org/stable/c/5005e2e159b300c1b8c6820a1e13a62eb0127b9b https://git.kernel.org/stable/c/6b6c2ebd83f2bf97e8f221479372aaca97a4a9b2 https://git.kernel.org/stable/c/6048dec754554a1303d632be6042d3feb3295285 https://git.kernel.org/stable/c/1b75da22ed1e6171e261bc9265370162553d5393 https://access.redhat.com/security/cve/CVE-2024-43866 https://bugzilla.redhat.com/show_bug.cgi?id=2306358 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43863 – drm/vmwgfx: Fix a deadlock in dma buf fence polling
https://notcve.org/view.php?id=CVE-2024-43863
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. • https://git.kernel.org/stable/c/2298e804e96eb3635c39519c8287befd92460303 https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237 https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3 https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f •