CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50274 – idpf: avoid vport access in idpf_get_link_ksettings
https://notcve.org/view.php?id=CVE-2024-50274
In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps. • https://git.kernel.org/stable/c/02cbfba1add5bd9088c7d14c6b93b77a6ea8f3bb https://git.kernel.org/stable/c/fa4d906ad0fb63a980a1d586a061c78ea1a345ba https://git.kernel.org/stable/c/81d2fb4c7c18a3b36ba3e00b9d5b753107472d75 •
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 •