Tags give the ability to mark specific points in history as being important
-
xfs-6.1-fixes-4
4eb559dd · ·Bug fixes for 6.1-rc4: - Fix a UAF bug during log recovery. - Fix memory leaks when mount fails. - Detect corrupt bestfree information in a directory block. - Fix incorrect return value type for the dax page fault handlers. - Fix fortify complaints about memcpy of xfs log item objects. - Strengthen inadequate validation of recovered log items. - Fix incorrectly declared flex array in EFI log item structs. - Log corrupt log items for debugging purposes. - Fix infinite loop problems in the refcount code if the refcount btree node block keys are corrupt. - Fix infinite loop problems in the refcount code if the refcount btree records suffer MSB bitflips. - Add more sanity checking to continued defer ops to prevent overflows from one AG to the next or off EOFS.
-
xfs-6.1-fixes-3
9f187ba0 · ·Bug fixes for 6.1-rc4: - Fix a UAF bug during log recovery. - Fix memory leaks when mount fails. - Detect corrupt bestfree information in a directory block. - Fix incorrect return value type for the dax page fault handlers. - Fix fortify complaints about memcpy of xfs log item objects. - Strengthen inadequate validation of recovered log items. - Fix incorrectly declared flex array in EFI log item structs. - Log corrupt log items for debugging purposes. Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-
xfs-6.1-fixes-2
47ba8cc7 · ·Bug fixes for 6.1-rc1: - Fix a UAF bug during log recovery. - Fix memory leaks when mount fails. - Detect corrupt bestfree information in a directory block. - Fix incorrect return value type for the dax page fault handlers. Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-
refcount-cow-domain-6.1_2022-10-31
8b972158 · ·xfs: improve runtime refcountbt corruption detection Fuzz testing of the refcount btree demonstrated a weakness in validation of refcount btree records during normal runtime. The idea of using the upper bit of the rc_startblock field to separate the refcount records into one group for shared space and another for CoW staging extents was added at the last minute. The incore struct left this bit encoded in the upper bit of the startblock field, which makes it all too easy for arithmetic operations to overflow if we don't detect the cowflag properly. When I ran a norepair fuzz tester, I was able to crash the kernel on one of these accidental overflows by fuzzing a key record in a node block, which broke lookups. To fix the problem, make the domain (shared/cow) a separate field in the incore record. Unfortunately, a customer also hit this once in production. Due to bugs in the kernel running on the VM host, writes to the disk image would occasionally be lost. Given sufficient memory pressure on the VM guest, a refcountbt xfs_buf could be reclaimed and later reloaded from the stale copy on the virtual disk. The stale disk contents were a refcount btree leaf block full of records for the wrong domain, and this caused an infinite loop in the guest VM. v2: actually include the refcount adjust loop invariant checking patch; move the deferred refcount continuation checks earlier in the series; break up the megapatch into smaller pieces; fix an uninitialized list error. v3: in the continuation check patch, verify the per-ag extent before converting it to a fsblock Signed-off-by: Darrick J. Wong <djwong@kernel.org> -
fix-log-recovery-misuse-6.1_2022-10-31
950f0d50 · ·xfs: fix various problems with log intent item recovery Starting with 6.1-rc1, CONFIG_FORTIFY_SOURCE checks became smart enough to detect memcpy() callers that copy beyond what seems to be the end of a struct. Unfortunately, gcc has a bug wherein it cannot reliably compute the size of a struct containing another struct containing a flex array at the end. This is the case with the xfs log item format structures, which means that -rc1 starts complaining all over the place. Fix these problems by memcpying the struct head and the flex arrays separately. Although it's tempting to use the FLEX_ARRAY macros, the structs involved are part of the ondisk log format. Some day we're going to want to make the ondisk log contents endian-safe, which means that we will have to stop using memcpy entirely. While we're at it, fix some deficiencies in the validation of recovered log intent items -- if the size of the recovery buffer is not even large enough to cover the flex array record count in the head, we should abort the recovery of that item immediately. The last patch of this series changes the EFI/EFD sizeof functions names and behaviors to be consistent with the similarly named sizeof helpers for other log intent items. v2: fix more inadequate log intent done recovery validation and dump corrupt recovered items Signed-off-by: Darrick J. Wong <djwong@kernel.org> -
xfs-6.1-fixes_2022-10-31
47ba8cc7 · ·xfs: bug fixes for 6.1 Bug fixes for 6.1. Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-
xfs-6.1-fixes_2022-10-27
e07ee6fe · ·xfs: new code for 5.20 New code for 5.20. Signed-off-by: Darrick J. Wong <djwong@kernel.org>