Andrew Lukoshko
b9d46fff46
Add the RHEL 211.17.1..211.18.1 backports (1162-1244) from centos-stream-10 and upstream, on top of 211.16.1. Includes the lpfc 14.4.0.x revert batch and the RHEL-only lpfc_nlp_get UAF guard. Bump to 211.18.1.
79 lines
3.4 KiB
Diff
79 lines
3.4 KiB
Diff
From 21df79956b1623ded470e38baa1058d1c641d896 Mon Sep 17 00:00:00 2001
|
|
From: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
|
|
Date: Fri, 8 May 2026 14:00:52 +0000
|
|
Subject: [PATCH] xfs: delete attr leaf freemap entries when empty
|
|
|
|
JIRA: https://redhat.atlassian.net/browse/RHEL-174054
|
|
CVE: CVE-2026-43158
|
|
|
|
commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34
|
|
Author: Darrick J. Wong <djwong@kernel.org>
|
|
Date: Fri Jan 23 09:27:30 2026 -0800
|
|
|
|
xfs: delete attr leaf freemap entries when empty
|
|
|
|
Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size
|
|
underflow"), Brian Foster observed that it's possible for a small
|
|
freemap at the end of the end of the xattr entries array to experience
|
|
a size underflow when subtracting the space consumed by an expansion of
|
|
the entries array. There are only three freemap entries, which means
|
|
that it is not a complete index of all free space in the leaf block.
|
|
|
|
This code can leave behind a zero-length freemap entry with a nonzero
|
|
base. Subsequent setxattr operations can increase the base up to the
|
|
point that it overlaps with another freemap entry. This isn't in and of
|
|
itself a problem because the code in _leaf_add that finds free space
|
|
ignores any freemap entry with zero size.
|
|
|
|
However, there's another bug in the freemap update code in _leaf_add,
|
|
which is that it fails to update a freemap entry that begins midway
|
|
through the xattr entry that was just appended to the array. That can
|
|
result in the freemap containing two entries with the same base but
|
|
different sizes (0 for the "pushed-up" entry, nonzero for the entry
|
|
that's actually tracking free space). A subsequent _leaf_add can then
|
|
allocate xattr namevalue entries on top of the entries array, leading to
|
|
data loss. But fixing that is for later.
|
|
|
|
For now, eliminate the possibility of confusion by zeroing out the base
|
|
of any freemap entry that has zero size. Because the freemap is not
|
|
intended to be a complete index of free space, a subsequent failure to
|
|
find any free space for a new xattr will trigger block compaction, which
|
|
regenerates the freemap.
|
|
|
|
It looks like this bug has been in the codebase for quite a long time.
|
|
|
|
Cc: <stable@vger.kernel.org> # v2.6.12
|
|
Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2")
|
|
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
|
|
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
|
|
Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
|
|
|
|
diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c
|
|
index fddb55605e0c..8577c01c83bd 100644
|
|
--- a/fs/xfs/libxfs/xfs_attr_leaf.c
|
|
+++ b/fs/xfs/libxfs/xfs_attr_leaf.c
|
|
@@ -1593,6 +1593,19 @@ xfs_attr3_leaf_add_work(
|
|
min_t(uint16_t, ichdr->freemap[i].size,
|
|
sizeof(xfs_attr_leaf_entry_t));
|
|
}
|
|
+
|
|
+ /*
|
|
+ * Don't leave zero-length freemaps with nonzero base lying
|
|
+ * around, because we don't want the code in _remove that
|
|
+ * matches on base address to get confused and create
|
|
+ * overlapping freemaps. If we end up with no freemap entries
|
|
+ * then the next _add will compact the leaf block and
|
|
+ * regenerate the freemaps.
|
|
+ */
|
|
+ if (ichdr->freemap[i].size == 0 && ichdr->freemap[i].base > 0) {
|
|
+ ichdr->freemap[i].base = 0;
|
|
+ ichdr->holes = 1;
|
|
+ }
|
|
}
|
|
ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index);
|
|
}
|
|
--
|
|
2.50.1 (Apple Git-155)
|
|
|