CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53080 – drm/panthor: Lock XArray when getting entries for the VM
https://notcve.org/view.php?id=CVE-2024-53080
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock. • https://git.kernel.org/stable/c/647810ec247641eb5aec8caef818919a4518a0b1 https://git.kernel.org/stable/c/3342f066a8e1020a6f7d1fbd6b23bfdeda473eb5 https://git.kernel.org/stable/c/444fa5b100e5c90550d6bccfe4476efb0391b3ca •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53079 – mm/thp: fix deferred split unqueue naming and locking
https://notcve.org/view.php?id=CVE-2024-53079
In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? • https://git.kernel.org/stable/c/87eaceb3faa59b9b4d940ec9554ce251325d83fe https://git.kernel.org/stable/c/fc4951c3e3358dd82ea508e893695b916c813f17 https://git.kernel.org/stable/c/afb1352d06b1b6b2cfd1f901c766a430c87078b3 https://git.kernel.org/stable/c/f8f931bba0f92052cf842b7e30917b1afcc77d5a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53078 – drm/tegra: Fix NULL vs IS_ERR() check in probe()
https://notcve.org/view.php?id=CVE-2024-53078
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match. • https://git.kernel.org/stable/c/45c690aea8ee5b7d012cd593bd288540a4bfdbf0 https://git.kernel.org/stable/c/6d6c005855b97b8caf6039c1774745ee74c91fa6 https://git.kernel.org/stable/c/a85df8c7b5ee2d3d4823befada42c5c41aff4cb0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53077 – rpcrdma: Always release the rpcrdma_device's xa_array
https://notcve.org/view.php?id=CVE-2024-53077
In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation. • https://git.kernel.org/stable/c/7e86845a0346efc95fddaa97ce5cd6a8bda8c71c https://git.kernel.org/stable/c/36b7f5a4f300d038270324640ff7c1399245159d https://git.kernel.org/stable/c/63a81588cd2025e75fbaf30b65930b76825c456f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53076 – iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()
https://notcve.org/view.php?id=CVE-2024-53076
In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0. • https://git.kernel.org/stable/c/38416c28e16890b52fdd5eb73479299ec3f062f3 https://git.kernel.org/stable/c/62c11896683129790b8f5ab6eb7e695818b0b723 https://git.kernel.org/stable/c/b304362ce836968b803e5d4c5f84dcb51a7bf0f2 https://git.kernel.org/stable/c/369f05688911b05216cfcd6ca74473bec87948d7 •