From: Greg Kroah-Hartman Date: Wed, 18 Aug 2021 07:54:08 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.13.13~58 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=cb2cacc3d103262c3ef1d6d806a38893605c2a7c;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: ext4-fix-ext4_max_logical_block-macro.patch x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch --- diff --git a/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch b/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch new file mode 100644 index 00000000000..8ad664444bd --- /dev/null +++ b/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch @@ -0,0 +1,45 @@ +From 175efa81feb8405676e0136d97b10380179c92e0 Mon Sep 17 00:00:00 2001 +From: Ritesh Harjani +Date: Tue, 5 May 2020 17:43:14 +0200 +Subject: ext4: fix EXT4_MAX_LOGICAL_BLOCK macro + +From: Ritesh Harjani + +commit 175efa81feb8405676e0136d97b10380179c92e0 upstream. + +ext4 supports max number of logical blocks in a file to be 0xffffffff. +(This is since ext4_extent's ee_block is __le32). +This means that EXT4_MAX_LOGICAL_BLOCK should be 0xfffffffe (starting +from 0 logical offset). This patch fixes this. + +The issue was seen when ext4 moved to iomap_fiemap API and when +overlayfs was mounted on top of ext4. Since overlayfs was missing +filemap_check_ranges(), so it could pass a arbitrary huge length which +lead to overflow of map.m_len logic. + +This patch fixes that. + +Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework") +Reported-by: syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com +Signed-off-by: Ritesh Harjani +Reviewed-by: Jan Kara +Signed-off-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20200505154324.3226743-2-hch@lst.de +Signed-off-by: Theodore Ts'o +Signed-off-by: George Kennedy +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/ext4.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/ext4.h ++++ b/fs/ext4/ext4.h +@@ -718,7 +718,7 @@ enum { + #define EXT4_MAX_BLOCK_FILE_PHYS 0xFFFFFFFF + + /* Max logical block we can support */ +-#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFF ++#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFE + + /* + * Structure of an inode on the disk diff --git a/queue-5.4/series b/queue-5.4/series new file mode 100644 index 00000000000..d7bf6e24a51 --- /dev/null +++ b/queue-5.4/series @@ -0,0 +1,2 @@ +ext4-fix-ext4_max_logical_block-macro.patch +x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch diff --git a/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch b/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch new file mode 100644 index 00000000000..97851049729 --- /dev/null +++ b/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch @@ -0,0 +1,163 @@ +From f9dfb5e390fab2df9f7944bb91e7705aba14cd26 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Fri, 18 Jun 2021 16:18:25 +0200 +Subject: x86/fpu: Make init_fpstate correct with optimized XSAVE + +From: Thomas Gleixner + +commit f9dfb5e390fab2df9f7944bb91e7705aba14cd26 upstream. + +The XSAVE init code initializes all enabled and supported components with +XRSTOR(S) to init state. Then it XSAVEs the state of the components back +into init_fpstate which is used in several places to fill in the init state +of components. + +This works correctly with XSAVE, but not with XSAVEOPT and XSAVES because +those use the init optimization and skip writing state of components which +are in init state. So init_fpstate.xsave still contains all zeroes after +this operation. + +There are two ways to solve that: + + 1) Use XSAVE unconditionally, but that requires to reshuffle the buffer when + XSAVES is enabled because XSAVES uses compacted format. + + 2) Save the components which are known to have a non-zero init state by other + means. + +Looking deeper, #2 is the right thing to do because all components the +kernel supports have all-zeroes init state except the legacy features (FP, +SSE). Those cannot be hard coded because the states are not identical on all +CPUs, but they can be saved with FXSAVE which avoids all conditionals. + +Use FXSAVE to save the legacy FP/SSE components in init_fpstate along with +a BUILD_BUG_ON() which reminds developers to validate that a newly added +component has all zeroes init state. As a bonus remove the now unused +copy_xregs_to_kernel_booting() crutch. + +The XSAVE and reshuffle method can still be implemented in the unlikely +case that components are added which have a non-zero init state and no +other means to save them. For now, FXSAVE is just simple and good enough. + + [ bp: Fix a typo or two in the text. ] + +Fixes: 6bad06b76892 ("x86, xsave: Use xsaveopt in context-switch path when supported") +Signed-off-by: Thomas Gleixner +Signed-off-by: Borislav Petkov +Reviewed-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20210618143444.587311343@linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/fpu/internal.h | 30 +++++++--------------------- + arch/x86/kernel/fpu/xstate.c | 38 +++++++++++++++++++++++++++++++++--- + 2 files changed, 43 insertions(+), 25 deletions(-) + +--- a/arch/x86/include/asm/fpu/internal.h ++++ b/arch/x86/include/asm/fpu/internal.h +@@ -204,6 +204,14 @@ static inline void copy_fxregs_to_kernel + asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave)); + } + ++static inline void fxsave(struct fxregs_state *fx) ++{ ++ if (IS_ENABLED(CONFIG_X86_32)) ++ asm volatile( "fxsave %[fx]" : [fx] "=m" (*fx)); ++ else ++ asm volatile("fxsaveq %[fx]" : [fx] "=m" (*fx)); ++} ++ + /* These macros all use (%edi)/(%rdi) as the single memory argument. */ + #define XSAVE ".byte " REX_PREFIX "0x0f,0xae,0x27" + #define XSAVEOPT ".byte " REX_PREFIX "0x0f,0xae,0x37" +@@ -274,28 +282,6 @@ static inline void copy_fxregs_to_kernel + + /* + * This function is called only during boot time when x86 caps are not set +- * up and alternative can not be used yet. +- */ +-static inline void copy_xregs_to_kernel_booting(struct xregs_state *xstate) +-{ +- u64 mask = -1; +- u32 lmask = mask; +- u32 hmask = mask >> 32; +- int err; +- +- WARN_ON(system_state != SYSTEM_BOOTING); +- +- if (boot_cpu_has(X86_FEATURE_XSAVES)) +- XSTATE_OP(XSAVES, xstate, lmask, hmask, err); +- else +- XSTATE_OP(XSAVE, xstate, lmask, hmask, err); +- +- /* We should never fault when copying to a kernel buffer: */ +- WARN_ON_FPU(err); +-} +- +-/* +- * This function is called only during boot time when x86 caps are not set + * up and alternative can not be used yet. + */ + static inline void copy_kernel_to_xregs_booting(struct xregs_state *xstate) +--- a/arch/x86/kernel/fpu/xstate.c ++++ b/arch/x86/kernel/fpu/xstate.c +@@ -399,12 +399,32 @@ static void __init print_xstate_offset_s + } + + /* ++ * All supported features have either init state all zeros or are ++ * handled in setup_init_fpu() individually. This is an explicit ++ * feature list and does not use XFEATURE_MASK*SUPPORTED to catch ++ * newly added supported features at build time and make people ++ * actually look at the init state for the new feature. ++ */ ++#define XFEATURES_INIT_FPSTATE_HANDLED \ ++ (XFEATURE_MASK_FP | \ ++ XFEATURE_MASK_SSE | \ ++ XFEATURE_MASK_YMM | \ ++ XFEATURE_MASK_OPMASK | \ ++ XFEATURE_MASK_ZMM_Hi256 | \ ++ XFEATURE_MASK_Hi16_ZMM | \ ++ XFEATURE_MASK_PKRU | \ ++ XFEATURE_MASK_BNDREGS | \ ++ XFEATURE_MASK_BNDCSR) ++ ++/* + * setup the xstate image representing the init state + */ + static void __init setup_init_fpu_buf(void) + { + static int on_boot_cpu __initdata = 1; + ++ BUILD_BUG_ON(XCNTXT_MASK != XFEATURES_INIT_FPSTATE_HANDLED); ++ + WARN_ON_FPU(!on_boot_cpu); + on_boot_cpu = 0; + +@@ -423,10 +443,22 @@ static void __init setup_init_fpu_buf(vo + copy_kernel_to_xregs_booting(&init_fpstate.xsave); + + /* +- * Dump the init state again. This is to identify the init state +- * of any feature which is not represented by all zero's. ++ * All components are now in init state. Read the state back so ++ * that init_fpstate contains all non-zero init state. This only ++ * works with XSAVE, but not with XSAVEOPT and XSAVES because ++ * those use the init optimization which skips writing data for ++ * components in init state. ++ * ++ * XSAVE could be used, but that would require to reshuffle the ++ * data when XSAVES is available because XSAVES uses xstate ++ * compaction. But doing so is a pointless exercise because most ++ * components have an all zeros init state except for the legacy ++ * ones (FP and SSE). Those can be saved with FXSAVE into the ++ * legacy area. Adding new features requires to ensure that init ++ * state is all zeroes or if not to add the necessary handling ++ * here. + */ +- copy_xregs_to_kernel_booting(&init_fpstate.xsave); ++ fxsave(&init_fpstate.fxsave); + } + + static int xfeature_uncompacted_offset(int xfeature_nr)