CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53081 – media: ar0521: don't overflow when checking PLL values
https://notcve.org/view.php?id=CVE-2024-53081
In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64. • https://git.kernel.org/stable/c/852b50aeed153b513c0b36298559114fab0fab80 https://git.kernel.org/stable/c/5e1523076acf95b4ea68d19b6f27e6891267cc24 https://git.kernel.org/stable/c/a244b82d0ae60326901f2b50c15e3118298b7ecd https://git.kernel.org/stable/c/97ed0c0332d5525653668b31acf62ff1e6b50784 https://git.kernel.org/stable/c/438d3085ba5b8b5bfa5290faa594e577f6ac9aa7 •
CVSS: -EPSS: %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: %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 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53072 – platform/x86/amd/pmc: Detect when STB is not available
https://notcve.org/view.php?id=CVE-2024-53072
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message. • https://git.kernel.org/stable/c/3d7d407dfb05b257e15cb0c6b056428a4a8c2e5d https://git.kernel.org/stable/c/a50863dd1f92d43c975ab2ecc3476617fe98a66e https://git.kernel.org/stable/c/7a3ed3f125292bc3398e04d10108124250892e3f https://git.kernel.org/stable/c/67ff30e24a0466bdd5be1d0b84385ec3c85fdacd https://git.kernel.org/stable/c/bceec87a73804bb4c33b9a6c96e2d27cd893a801 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53070 – usb: dwc3: fix fault at system suspend if device was already runtime suspended
https://notcve.org/view.php?id=CVE-2024-53070
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: fix fault at system suspend if device was already runtime suspended If the device was already runtime suspended then during system suspend we cannot access the device registers else it will crash. Also we cannot access any registers after dwc3_core_exit() on some platforms so move the dwc3_enable_susphy() call to the top. • https://git.kernel.org/stable/c/073530898ebf44a9418434e899cfa9ca86945333 https://git.kernel.org/stable/c/85ca88f93162acb94dbcb26d0ee2b145864d14a1 https://git.kernel.org/stable/c/4fad7370086797afe6471493e3a5f36add8c48a7 https://git.kernel.org/stable/c/a690a9e38e6ba819789074388de7cff06425ef5b https://git.kernel.org/stable/c/d9e65d461a9de037e7c9d584776d025cfce6d86d https://git.kernel.org/stable/c/562804b1561cc248cc37746a1c96c83cab1d7209 https://git.kernel.org/stable/c/4abc5ee334fe4aba50461c45fdaaa4c5e5c57789 https://git.kernel.org/stable/c/06b98197b69e2f2af9cb1991ee0b1c876 •