From: Greg Kroah-Hartman Date: Mon, 13 Mar 2023 10:53:09 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.14.310~102 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4b552e42e2ea04c528c747bb99e8c63779388c18;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch ext4-fix-rename_whiteout-handling-for-inline-directories.patch ext4-fix-warning-in-ext4_update_inline_data.patch ext4-move-where-set-the-may_inline_data-flag-is-set.patch ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch series x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch --- diff --git a/queue-4.14/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch b/queue-4.14/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch new file mode 100644 index 00000000000..041f1564d86 --- /dev/null +++ b/queue-4.14/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch @@ -0,0 +1,121 @@ +From c993799baf9c5861f8df91beb80e1611b12efcbd Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Thu, 16 Feb 2023 10:55:48 -0800 +Subject: ext4: fix another off-by-one fsmap error on 1k block filesystems + +From: Darrick J. Wong + +commit c993799baf9c5861f8df91beb80e1611b12efcbd upstream. + +Apparently syzbot figured out that issuing this FSMAP call: + +struct fsmap_head cmd = { + .fmh_count = ...; + .fmh_keys = { + { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, + { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, + }, +... +}; +ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd); + +Produces this crash if the underlying filesystem is a 1k-block ext4 +filesystem: + +kernel BUG at fs/ext4/ext4.h:3331! +invalid opcode: 0000 [#1] PREEMPT SMP +CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 +RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] +RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 +RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 +RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 +RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 +R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001 +R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 +FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 +Call Trace: + + ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] + ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] + ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] + ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] + __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] + __x64_sys_ioctl+0x82/0xa0 + do_syscall_64+0x2b/0x80 + entry_SYSCALL_64_after_hwframe+0x46/0xb0 +RIP: 0033:0x7fdf20558aff +RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 +RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff +RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 +RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 +R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000 + +For GETFSMAP calls, the caller selects a physical block device by +writing its block number into fsmap_head.fmh_keys[01].fmr_device. +To query mappings for a subrange of the device, the starting byte of the +range is written to fsmap_head.fmh_keys[0].fmr_physical and the last +byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical. + +IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd +set the inputs as follows: + + fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, + fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, + +Which would return you whatever is mapped in the 12 bytes starting at +physical offset 3. + +The crash is due to insufficient range validation of keys[1] in +ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of +the filesystem, which means that s_first_data_block is nonzero. +ext4_get_group_no_and_offset subtracts this quantity from the blocknr +argument before cracking it into a group number and a block number +within a group. IOWs, block group 0 spans blocks 1-8192 (1-based) +instead of 0-8191 (0-based) like what happens with larger blocksizes. + +The net result of this encoding is that blocknr < s_first_data_block is +not a valid input to this function. The end_fsb variable is set from +the keys that are copied from userspace, which means that in the above +example, its value is zero. That leads to an underflow here: + + blocknr = blocknr - le32_to_cpu(es->s_first_data_block); + +The division then operates on -1: + + offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> + EXT4_SB(sb)->s_cluster_bits; + +Leaving an impossibly large group number (2^32-1) in blocknr. +ext4_getfsmap_check_keys checked that keys[0].fmr_physical and +keys[1].fmr_physical are in increasing order, but +ext4_getfsmap_datadev adjusts keys[0].fmr_physical to be at least +s_first_data_block. This implies that we have to check it again after +the adjustment, which is the piece that I forgot. + +Reported-by: syzbot+6be2b977c89f79b6b153@syzkaller.appspotmail.com +Fixes: 4a4956249dac ("ext4: fix off-by-one fsmap error on 1k block filesystems") +Link: https://syzkaller.appspot.com/bug?id=79d5768e9bfe362911ac1a5057a36fc6b5c30002 +Cc: stable@vger.kernel.org +Signed-off-by: Darrick J. Wong +Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnolia +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/fsmap.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/ext4/fsmap.c ++++ b/fs/ext4/fsmap.c +@@ -499,6 +499,8 @@ static int ext4_getfsmap_datadev(struct + keys[0].fmr_physical = bofs; + if (keys[1].fmr_physical >= eofs) + keys[1].fmr_physical = eofs - 1; ++ if (keys[1].fmr_physical < keys[0].fmr_physical) ++ return 0; + start_fsb = keys[0].fmr_physical; + end_fsb = keys[1].fmr_physical; + diff --git a/queue-4.14/ext4-fix-rename_whiteout-handling-for-inline-directories.patch b/queue-4.14/ext4-fix-rename_whiteout-handling-for-inline-directories.patch new file mode 100644 index 00000000000..770e38c5e45 --- /dev/null +++ b/queue-4.14/ext4-fix-rename_whiteout-handling-for-inline-directories.patch @@ -0,0 +1,88 @@ +From c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e Mon Sep 17 00:00:00 2001 +From: Eric Whitney +Date: Fri, 10 Feb 2023 12:32:44 -0500 +Subject: ext4: fix RENAME_WHITEOUT handling for inline directories + +From: Eric Whitney + +commit c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e upstream. + +A significant number of xfstests can cause ext4 to log one or more +warning messages when they are run on a test file system where the +inline_data feature has been enabled. An example: + +"EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode + #16385: comm fsstress: No space for directory leaf checksum. Please +run e2fsck -D." + +The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068, +070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585, +589, 626, 631, and 650. + +In this situation, the warning message indicates a bug in the code that +performs the RENAME_WHITEOUT operation on a directory entry that has +been stored inline. It doesn't detect that the directory is stored +inline, and incorrectly attempts to compute a dirent block checksum on +the whiteout inode when creating it. This attempt fails as a result +of the integrity checking in get_dirent_tail (usually due to a failure +to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message +is then emitted. + +Fix this by simply collecting the inlined data state at the time the +search for the source directory entry is performed. Existing code +handles the rest, and this is sufficient to eliminate all spurious +warning messages produced by the tests above. Go one step further +and do the same in the code that resets the source directory entry in +the event of failure. The inlined state should be present in the +"old" struct, but given the possibility of a race there's no harm +in taking a conservative approach and getting that information again +since the directory entry is being reread anyway. + +Fixes: b7ff91fd030d ("ext4: find old entry again if failed to rename whiteout") +Cc: stable@kernel.org +Signed-off-by: Eric Whitney +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/namei.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -1425,11 +1425,10 @@ static struct buffer_head * ext4_find_en + int has_inline_data = 1; + ret = ext4_find_inline_entry(dir, &fname, res_dir, + &has_inline_data); +- if (has_inline_data) { +- if (inlined) +- *inlined = 1; ++ if (inlined) ++ *inlined = has_inline_data; ++ if (has_inline_data) + goto cleanup_and_exit; +- } + } + + if ((namelen <= 2) && (name[0] == '.') && +@@ -3520,7 +3519,8 @@ static void ext4_resetent(handle_t *hand + * so the old->de may no longer valid and need to find it again + * before reset old inode info. + */ +- old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL); ++ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, ++ &old.inlined); + if (IS_ERR(old.bh)) + retval = PTR_ERR(old.bh); + if (!old.bh) +@@ -3688,7 +3688,8 @@ static int ext4_rename(struct inode *old + return retval; + } + +- old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL); ++ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, ++ &old.inlined); + if (IS_ERR(old.bh)) + return PTR_ERR(old.bh); + /* diff --git a/queue-4.14/ext4-fix-warning-in-ext4_update_inline_data.patch b/queue-4.14/ext4-fix-warning-in-ext4_update_inline_data.patch new file mode 100644 index 00000000000..079a1744537 --- /dev/null +++ b/queue-4.14/ext4-fix-warning-in-ext4_update_inline_data.patch @@ -0,0 +1,108 @@ +From 2b96b4a5d9443ca4cad58b0040be455803c05a42 Mon Sep 17 00:00:00 2001 +From: Ye Bin +Date: Tue, 7 Mar 2023 09:52:53 +0800 +Subject: ext4: fix WARNING in ext4_update_inline_data + +From: Ye Bin + +commit 2b96b4a5d9443ca4cad58b0040be455803c05a42 upstream. + +Syzbot found the following issue: +EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. +fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" +fscrypt: AES-256-XTS using implementation "xts-aes-aesni" +------------[ cut here ]------------ +WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 +Modules linked in: +CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 +RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 +RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 +RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 +RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 +RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 +R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 +R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c +FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + + __alloc_pages_node include/linux/gfp.h:237 [inline] + alloc_pages_node include/linux/gfp.h:260 [inline] + __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 + __do_kmalloc_node mm/slab_common.c:956 [inline] + __kmalloc+0xfe/0x190 mm/slab_common.c:981 + kmalloc include/linux/slab.h:584 [inline] + kzalloc include/linux/slab.h:720 [inline] + ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 + ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] + ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 + ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 + ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 + ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 + lookup_open fs/namei.c:3413 [inline] + open_last_lookups fs/namei.c:3481 [inline] + path_openat+0x12ac/0x2dd0 fs/namei.c:3711 + do_filp_open+0x264/0x4f0 fs/namei.c:3741 + do_sys_openat2+0x124/0x4e0 fs/open.c:1310 + do_sys_open fs/open.c:1326 [inline] + __do_sys_openat fs/open.c:1342 [inline] + __se_sys_openat fs/open.c:1337 [inline] + __x64_sys_openat+0x243/0x290 fs/open.c:1337 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Above issue happens as follows: +ext4_iget + ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60 +ext4_try_add_inline_entry + __ext4_mark_inode_dirty + ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 + ext4_xattr_shift_entries + ->after shift i_inline_off is incorrect, actually is change to 176 +ext4_try_add_inline_entry + ext4_update_inline_dir + get_max_inline_xattr_value_size + if (EXT4_I(inode)->i_inline_off) + entry = (struct ext4_xattr_entry *)((void *)raw_inode + + EXT4_I(inode)->i_inline_off); + free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); + ->As entry is incorrect, then 'free' may be negative + ext4_update_inline_data + value = kzalloc(len, GFP_NOFS); + -> len is unsigned int, maybe very large, then trigger warning when + 'kzalloc()' + +To resolve the above issue we need to update 'i_inline_off' after +'ext4_xattr_shift_entries()'. We do not need to set +EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty() +already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA +when it is needed may trigger a BUG_ON in ext4_writepages(). + +Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com +Cc: stable@kernel.org +Signed-off-by: Ye Bin +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/xattr.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/ext4/xattr.c ++++ b/fs/ext4/xattr.c +@@ -2809,6 +2809,9 @@ shift: + (void *)header, total_ino); + EXT4_I(inode)->i_extra_isize = new_extra_isize; + ++ if (ext4_has_inline_data(inode)) ++ error = ext4_find_inline_data_nolock(inode); ++ + cleanup: + if (error && (mnt_count != le16_to_cpu(sbi->s_es->s_mnt_count))) { + ext4_warning(inode->i_sb, "Unable to expand inode %lu. Delete some EAs or run e2fsck.", diff --git a/queue-4.14/ext4-move-where-set-the-may_inline_data-flag-is-set.patch b/queue-4.14/ext4-move-where-set-the-may_inline_data-flag-is-set.patch new file mode 100644 index 00000000000..a50fb041814 --- /dev/null +++ b/queue-4.14/ext4-move-where-set-the-may_inline_data-flag-is-set.patch @@ -0,0 +1,54 @@ +From 1dcdce5919115a471bf4921a57f20050c545a236 Mon Sep 17 00:00:00 2001 +From: Ye Bin +Date: Tue, 7 Mar 2023 09:52:52 +0800 +Subject: ext4: move where set the MAY_INLINE_DATA flag is set + +From: Ye Bin + +commit 1dcdce5919115a471bf4921a57f20050c545a236 upstream. + +The only caller of ext4_find_inline_data_nolock() that needs setting of +EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode(). In +ext4_write_inline_data_end() we just need to update inode->i_inline_off. +Since we are going to add one more caller that does not need to set +EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA +out to ext4_iget_extra_inode(). + +Signed-off-by: Ye Bin +Cc: stable@kernel.org +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inline.c | 1 - + fs/ext4/inode.c | 7 ++++++- + 2 files changed, 6 insertions(+), 2 deletions(-) + +--- a/fs/ext4/inline.c ++++ b/fs/ext4/inline.c +@@ -163,7 +163,6 @@ int ext4_find_inline_data_nolock(struct + (void *)ext4_raw_inode(&is.iloc)); + EXT4_I(inode)->i_inline_size = EXT4_MIN_INLINE_DATA_SIZE + + le32_to_cpu(is.s.here->e_value_size); +- ext4_set_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); + } + out: + brelse(is.iloc.bh); +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -4752,8 +4752,13 @@ static inline int ext4_iget_extra_inode( + + if (EXT4_INODE_HAS_XATTR_SPACE(inode) && + *magic == cpu_to_le32(EXT4_XATTR_MAGIC)) { ++ int err; ++ + ext4_set_inode_state(inode, EXT4_STATE_XATTR); +- return ext4_find_inline_data_nolock(inode); ++ err = ext4_find_inline_data_nolock(inode); ++ if (!err && ext4_has_inline_data(inode)) ++ ext4_set_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); ++ return err; + } else + EXT4_I(inode)->i_inline_off = 0; + return 0; diff --git a/queue-4.14/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch b/queue-4.14/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch new file mode 100644 index 00000000000..193b9f33ef3 --- /dev/null +++ b/queue-4.14/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch @@ -0,0 +1,61 @@ +From f5361da1e60d54ec81346aee8e3d8baf1be0b762 Mon Sep 17 00:00:00 2001 +From: Zhihao Cheng +Date: Wed, 8 Mar 2023 11:26:43 +0800 +Subject: ext4: zero i_disksize when initializing the bootloader inode + +From: Zhihao Cheng + +commit f5361da1e60d54ec81346aee8e3d8baf1be0b762 upstream. + +If the boot loader inode has never been used before, the +EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the +i_size to 0. However, if the "never before used" boot loader has a +non-zero i_size, then i_disksize will be non-zero, and the +inconsistency between i_size and i_disksize can trigger a kernel +warning: + + WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 + CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa + RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 + Call Trace: + vfs_write+0x3b1/0x5c0 + ksys_write+0x77/0x160 + __x64_sys_write+0x22/0x30 + do_syscall_64+0x39/0x80 + +Reproducer: + 1. create corrupted image and mount it: + mke2fs -t ext4 /tmp/foo.img 200 + debugfs -wR "sif <5> size 25700" /tmp/foo.img + mount -t ext4 /tmp/foo.img /mnt + cd /mnt + echo 123 > file + 2. Run the reproducer program: + posix_memalign(&buf, 1024, 1024) + fd = open("file", O_RDWR | O_DIRECT); + ioctl(fd, EXT4_IOC_SWAP_BOOT); + write(fd, buf, 1024); + +Fix this by setting i_disksize as well as i_size to zero when +initiaizing the boot loader inode. + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159 +Cc: stable@kernel.org +Signed-off-by: Zhihao Cheng +Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/ioctl.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ext4/ioctl.c ++++ b/fs/ext4/ioctl.c +@@ -150,6 +150,7 @@ static long swap_inode_boot_loader(struc + ei_bl->i_flags = 0; + inode_bl->i_version = 1; + i_size_write(inode_bl, 0); ++ EXT4_I(inode_bl)->i_disksize = inode_bl->i_size; + inode_bl->i_mode = S_IFREG; + if (ext4_has_feature_extents(sb)) { + ext4_set_inode_flag(inode_bl, EXT4_INODE_EXTENTS); diff --git a/queue-4.14/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch b/queue-4.14/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch new file mode 100644 index 00000000000..2efc291758f --- /dev/null +++ b/queue-4.14/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch @@ -0,0 +1,27 @@ +From 609d54441493c99f21c1823dfd66fa7f4c512ff4 Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Mon, 6 Mar 2023 13:54:50 -0500 +Subject: fs: prevent out-of-bounds array speculation when closing a file descriptor + +From: Theodore Ts'o + +commit 609d54441493c99f21c1823dfd66fa7f4c512ff4 upstream. + +Google-Bug-Id: 114199369 +Signed-off-by: Theodore Ts'o +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman +--- + fs/file.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/file.c ++++ b/fs/file.c +@@ -629,6 +629,7 @@ int __close_fd(struct files_struct *file + fdt = files_fdtable(files); + if (fd >= fdt->max_fds) + goto out_unlock; ++ fd = array_index_nospec(fd, fdt->max_fds); + file = fdt->fd[fd]; + if (!file) + goto out_unlock; diff --git a/queue-4.14/series b/queue-4.14/series new file mode 100644 index 00000000000..9602537eede --- /dev/null +++ b/queue-4.14/series @@ -0,0 +1,7 @@ +fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch +x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch +ext4-fix-rename_whiteout-handling-for-inline-directories.patch +ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch +ext4-move-where-set-the-may_inline_data-flag-is-set.patch +ext4-fix-warning-in-ext4_update_inline_data.patch +ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch diff --git a/queue-4.14/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch b/queue-4.14/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch new file mode 100644 index 00000000000..02e5dd6889a --- /dev/null +++ b/queue-4.14/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch @@ -0,0 +1,50 @@ +From b0563468eeac88ebc70559d52a0b66efc37e4e9d Mon Sep 17 00:00:00 2001 +From: Andrew Cooper +Date: Tue, 7 Mar 2023 17:46:43 +0000 +Subject: x86/CPU/AMD: Disable XSAVES on AMD family 0x17 + +From: Andrew Cooper + +commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream. + +AMD Erratum 1386 is summarised as: + + XSAVES Instruction May Fail to Save XMM Registers to the Provided + State Save Area + +This piece of accidental chronomancy causes the %xmm registers to +occasionally reset back to an older value. + +Ignore the XSAVES feature on all AMD Zen1/2 hardware. The XSAVEC +instruction (which works fine) is equivalent on affected parts. + + [ bp: Typos, move it into the F17h-specific function. ] + +Reported-by: Tavis Ormandy +Signed-off-by: Andrew Cooper +Signed-off-by: Borislav Petkov (AMD) +Cc: +Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/amd.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -197,6 +197,15 @@ static void init_amd_k6(struct cpuinfo_x + return; + } + #endif ++ /* ++ * Work around Erratum 1386. The XSAVES instruction malfunctions in ++ * certain circumstances on Zen1/2 uarch, and not all parts have had ++ * updated microcode at the time of writing (March 2023). ++ * ++ * Affected parts all have no supervisor XSAVE states, meaning that ++ * the XSAVEC instruction (which works fine) is equivalent. ++ */ ++ clear_cpu_cap(c, X86_FEATURE_XSAVES); + } + + static void init_amd_k7(struct cpuinfo_x86 *c)