We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
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.
Reserved 2024-10-21 | Published 2024-11-19 | Updated 2024-11-19 | Assigner Linuxgit.kernel.org/...c/2fd0948a483e9cb2d669c7199bc620a21c97673d
git.kernel.org/...c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb
git.kernel.org/...c/bf0b0c6d159767c0d1c21f793950d78486690ee0
git.kernel.org/...c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851
git.kernel.org/...c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6
git.kernel.org/...c/f04be6d68f715c1473a8422fc0460f57b5e99931
git.kernel.org/...c/50a3933760b427759afdd23156a7280a19357a92
git.kernel.org/...c/c9a75ec45f1111ef530ab186c2a7684d0a0c9245
Support options