--- /dev/null
+From c993799baf9c5861f8df91beb80e1611b12efcbd Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <djwong@kernel.org>
+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 <djwong@kernel.org>
+
+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:
+ <TASK>
+ 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 <djwong@kernel.org>
+Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnolia
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e Mon Sep 17 00:00:00 2001
+From: Eric Whitney <enwlinux@gmail.com>
+Date: Fri, 10 Feb 2023 12:32:44 -0500
+Subject: ext4: fix RENAME_WHITEOUT handling for inline directories
+
+From: Eric Whitney <enwlinux@gmail.com>
+
+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 <enwlinux@gmail.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ /*
--- /dev/null
+From 2b96b4a5d9443ca4cad58b0040be455803c05a42 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Tue, 7 Mar 2023 09:52:53 +0800
+Subject: ext4: fix WARNING in ext4_update_inline_data
+
+From: Ye Bin <yebin10@huawei.com>
+
+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:
+ <TASK>
+ __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 <yebin10@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.",
--- /dev/null
+From 1dcdce5919115a471bf4921a57f20050c545a236 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Tue, 7 Mar 2023 09:52:52 +0800
+Subject: ext4: move where set the MAY_INLINE_DATA flag is set
+
+From: Ye Bin <yebin10@huawei.com>
+
+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 <yebin10@huawei.com>
+Cc: stable@kernel.org
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From f5361da1e60d54ec81346aee8e3d8baf1be0b762 Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+Date: Wed, 8 Mar 2023 11:26:43 +0800
+Subject: ext4: zero i_disksize when initializing the bootloader inode
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+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 <chengzhihao1@huawei.com>
+Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 609d54441493c99f21c1823dfd66fa7f4c512ff4 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+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 <tytso@mit.edu>
+
+commit 609d54441493c99f21c1823dfd66fa7f4c512ff4 upstream.
+
+Google-Bug-Id: 114199369
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+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
--- /dev/null
+From b0563468eeac88ebc70559d52a0b66efc37e4e9d Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Date: Tue, 7 Mar 2023 17:46:43 +0000
+Subject: x86/CPU/AMD: Disable XSAVES on AMD family 0x17
+
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+
+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 <taviso@gmail.com>
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
