CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50273 – btrfs: reinitialize delayed ref list after deleting it from the list
https://notcve.org/view.php?id=CVE-2024-50273
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead. • https://git.kernel.org/stable/c/1d57ee941692d0cc928526e21a1557b2ae3e11db https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d https://git.kernel.org/stable/c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb https://git.kernel.org/stable/c/bf0b0c6d159767c0d1c21f793950d78486690ee0 https://git.kernel.org/stable/c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851 https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6 https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e99931 https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50272 – filemap: Fix bounds checking in filemap_read()
https://notcve.org/view.php?id=CVE-2024-50272
In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. • https://git.kernel.org/stable/c/c2a9737f45e27d8263ff9643f994bda9bac0b944 https://git.kernel.org/stable/c/272830350bb1bb5bb39395966ea63b9864b135d1 https://git.kernel.org/stable/c/fbc7b803831e5c8a42c1f3427a17e55a814d6b3c https://git.kernel.org/stable/c/3d549dcfbbb0ecdaa571431a27ee5da9f2466716 https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235 https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826 https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50271 – signal: restore the override_rlimit logic
https://notcve.org/view.php?id=CVE-2024-50271
In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. • https://git.kernel.org/stable/c/d64696905554e919321e31afc210606653b8f6a4 https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1 https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7 https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40 https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50270 – mm/damon/core: avoid overflow in damon_feed_loop_next_input()
https://notcve.org/view.php?id=CVE-2024-50270
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. • https://git.kernel.org/stable/c/9294a037c01564786abb15436529fae3863268a2 https://git.kernel.org/stable/c/2d339a1f0f16ff5dea58e612ff336f0be0d041e9 https://git.kernel.org/stable/c/4401e9d10ab0281a520b9f8c220f30f60b5c248f •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-50269 – usb: musb: sunxi: Fix accessing an released usb phy
https://notcve.org/view.php?id=CVE-2024-50269
In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). • https://git.kernel.org/stable/c/6ed05c68cbcae42cd52b8e53b66952bfa9c002ce https://git.kernel.org/stable/c/583a4219841d00e96b5de55be160aa7eb7721a4d https://git.kernel.org/stable/c/b4ecc15d6f5a13c0bbe2777438e87e321f83faaa https://git.kernel.org/stable/c/a2259ebaa933331c53904caf792b619ec42f0da5 https://git.kernel.org/stable/c/721ddad945596220c123eb6f7126729fe277ee4f https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1 https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8 https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522b •