From: Greg Kroah-Hartman Date: Mon, 13 Mar 2023 10:54:57 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.14.310~98 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8fbe854e670d2efc528e7ffad6b9f203f088a269;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: btrfs-fix-percent-calculation-for-bg-reclaim-message.patch drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch drm-connector-print-max_requested_bpc-in-state-debugfs.patch ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.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 fork-allow-clone_newtime-in-clone3-flags.patch fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch series staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch --- diff --git a/queue-5.15/btrfs-fix-percent-calculation-for-bg-reclaim-message.patch b/queue-5.15/btrfs-fix-percent-calculation-for-bg-reclaim-message.patch new file mode 100644 index 00000000000..3987f5708c9 --- /dev/null +++ b/queue-5.15/btrfs-fix-percent-calculation-for-bg-reclaim-message.patch @@ -0,0 +1,56 @@ +From 95cd356ca23c3807b5f3503687161e216b1c520d Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Tue, 21 Feb 2023 10:11:24 -0800 +Subject: btrfs: fix percent calculation for bg reclaim message + +From: Johannes Thumshirn + +commit 95cd356ca23c3807b5f3503687161e216b1c520d upstream. + +We have a report, that the info message for block-group reclaim is +crossing the 100% used mark. + +This is happening as we were truncating the divisor for the division +(the block_group->length) to a 32bit value. + +Fix this by using div64_u64() to not truncate the divisor. + +In the worst case, it can lead to a div by zero error and should be +possible to trigger on 4 disks RAID0, and each device is large enough: + + $ mkfs.btrfs -f /dev/test/scratch[1234] -m raid1 -d raid0 + btrfs-progs v6.1 + [...] + Filesystem size: 40.00GiB + Block group profiles: + Data: RAID0 4.00GiB <<< + Metadata: RAID1 256.00MiB + System: RAID1 8.00MiB + +Reported-by: Forza +Link: https://lore.kernel.org/linux-btrfs/e99483.c11a58d.1863591ca52@tnonline.net/ +Fixes: 5f93e776c673 ("btrfs: zoned: print unusable percentage when reclaiming block groups") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Anand Jain +Reviewed-by: Qu Wenruo +Signed-off-by: Johannes Thumshirn +Reviewed-by: David Sterba +[ add Qu's note ] +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/block-group.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -1554,7 +1554,8 @@ void btrfs_reclaim_bgs_work(struct work_ + + btrfs_info(fs_info, + "reclaiming chunk %llu with %llu%% used %llu%% unusable", +- bg->start, div_u64(bg->used * 100, bg->length), ++ bg->start, ++ div64_u64(bg->used * 100, bg->length), + div64_u64(zone_unusable * 100, bg->length)); + trace_btrfs_reclaim_block_group(bg); + ret = btrfs_relocate_chunk(fs_info, bg->start); diff --git a/queue-5.15/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch b/queue-5.15/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch new file mode 100644 index 00000000000..0eff22ac00a --- /dev/null +++ b/queue-5.15/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch @@ -0,0 +1,35 @@ +From 0dcdf8498eae2727bb33cef3576991dc841d4343 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 6 Mar 2023 10:34:20 -0500 +Subject: drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 + +From: Alex Deucher + +commit 0dcdf8498eae2727bb33cef3576991dc841d4343 upstream. + +Properly skip non-existent registers as well. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442 +Reviewed-by: Hawking Zhang +Reviewed-by: Evan Quan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/soc15.c ++++ b/drivers/gpu/drm/amd/amdgpu/soc15.c +@@ -461,8 +461,9 @@ static int soc15_read_register(struct am + *value = 0; + for (i = 0; i < ARRAY_SIZE(soc15_allowed_read_registers); i++) { + en = &soc15_allowed_read_registers[i]; +- if (adev->reg_offset[en->hwip][en->inst] && +- reg_offset != (adev->reg_offset[en->hwip][en->inst][en->seg] ++ if (!adev->reg_offset[en->hwip][en->inst]) ++ continue; ++ else if (reg_offset != (adev->reg_offset[en->hwip][en->inst][en->seg] + + en->reg_offset)) + continue; + diff --git a/queue-5.15/drm-connector-print-max_requested_bpc-in-state-debugfs.patch b/queue-5.15/drm-connector-print-max_requested_bpc-in-state-debugfs.patch new file mode 100644 index 00000000000..484dcbd7349 --- /dev/null +++ b/queue-5.15/drm-connector-print-max_requested_bpc-in-state-debugfs.patch @@ -0,0 +1,44 @@ +From 7d386975f6a495902e679a3a250a7456d7e54765 Mon Sep 17 00:00:00 2001 +From: Harry Wentland +Date: Fri, 13 Jan 2023 11:24:09 -0500 +Subject: drm/connector: print max_requested_bpc in state debugfs +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Harry Wentland + +commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. + +This is useful to understand the bpc defaults and +support of a driver. + +Signed-off-by: Harry Wentland +Cc: Pekka Paalanen +Cc: Sebastian Wick +Cc: Vitaly.Prosyak@amd.com +Cc: Uma Shankar +Cc: Ville Syrjälä +Cc: Joshua Ashton +Cc: Jani Nikula +Cc: dri-devel@lists.freedesktop.org +Cc: amd-gfx@lists.freedesktop.org +Reviewed-By: Joshua Ashton +Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentland@amd.com +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_atomic.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/drm_atomic.c ++++ b/drivers/gpu/drm/drm_atomic.c +@@ -1052,6 +1052,7 @@ static void drm_atomic_connector_print_s + drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); + drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); + drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); ++ drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); + + if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) + if (state->writeback_job && state->writeback_job->fb) diff --git a/queue-5.15/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch b/queue-5.15/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch new file mode 100644 index 00000000000..7349e2b664e --- /dev/null +++ b/queue-5.15/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 +@@ -486,6 +486,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-5.15/ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.patch b/queue-5.15/ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.patch new file mode 100644 index 00000000000..e810b6aea00 --- /dev/null +++ b/queue-5.15/ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.patch @@ -0,0 +1,70 @@ +From ffec85d53d0f39ee4680a2cf0795255e000e1feb Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 2 Feb 2023 16:55:03 -0800 +Subject: ext4: fix cgroup writeback accounting with fs-layer encryption + +From: Eric Biggers + +commit ffec85d53d0f39ee4680a2cf0795255e000e1feb upstream. + +When writing a page from an encrypted file that is using +filesystem-layer encryption (not inline encryption), ext4 encrypts the +pagecache page into a bounce page, then writes the bounce page. + +It also passes the bounce page to wbc_account_cgroup_owner(). That's +incorrect, because the bounce page is a newly allocated temporary page +that doesn't have the memory cgroup of the original pagecache page. +This makes wbc_account_cgroup_owner() not account the I/O to the owner +of the pagecache page as it should. + +Fix this by always passing the pagecache page to +wbc_account_cgroup_owner(). + +Fixes: 001e4a8775f6 ("ext4: implement cgroup writeback support") +Cc: stable@vger.kernel.org +Reported-by: Matthew Wilcox (Oracle) +Signed-off-by: Eric Biggers +Acked-by: Tejun Heo +Link: https://lore.kernel.org/r/20230203005503.141557-1-ebiggers@kernel.org +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/page-io.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/fs/ext4/page-io.c ++++ b/fs/ext4/page-io.c +@@ -413,7 +413,8 @@ static void io_submit_init_bio(struct ex + + static void io_submit_add_bh(struct ext4_io_submit *io, + struct inode *inode, +- struct page *page, ++ struct page *pagecache_page, ++ struct page *bounce_page, + struct buffer_head *bh) + { + int ret; +@@ -427,10 +428,11 @@ submit_and_retry: + io_submit_init_bio(io, bh); + io->io_bio->bi_write_hint = inode->i_write_hint; + } +- ret = bio_add_page(io->io_bio, page, bh->b_size, bh_offset(bh)); ++ ret = bio_add_page(io->io_bio, bounce_page ?: pagecache_page, ++ bh->b_size, bh_offset(bh)); + if (ret != bh->b_size) + goto submit_and_retry; +- wbc_account_cgroup_owner(io->io_wbc, page, bh->b_size); ++ wbc_account_cgroup_owner(io->io_wbc, pagecache_page, bh->b_size); + io->io_next_block++; + } + +@@ -548,8 +550,7 @@ int ext4_bio_write_page(struct ext4_io_s + do { + if (!buffer_async_write(bh)) + continue; +- io_submit_add_bh(io, inode, +- bounce_page ? bounce_page : page, bh); ++ io_submit_add_bh(io, inode, page, bounce_page, bh); + nr_submitted++; + clear_buffer_dirty(bh); + } while ((bh = bh->b_this_page) != head); diff --git a/queue-5.15/ext4-fix-rename_whiteout-handling-for-inline-directories.patch b/queue-5.15/ext4-fix-rename_whiteout-handling-for-inline-directories.patch new file mode 100644 index 00000000000..45d116914fa --- /dev/null +++ b/queue-5.15/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 +@@ -1595,11 +1595,10 @@ static struct buffer_head *__ext4_find_e + 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] == '.') && +@@ -3660,7 +3659,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) +@@ -3827,7 +3827,8 @@ static int ext4_rename(struct user_names + 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-5.15/ext4-fix-warning-in-ext4_update_inline_data.patch b/queue-5.15/ext4-fix-warning-in-ext4_update_inline_data.patch new file mode 100644 index 00000000000..4e7200e8f36 --- /dev/null +++ b/queue-5.15/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 +@@ -2789,6 +2789,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-5.15/ext4-move-where-set-the-may_inline_data-flag-is-set.patch b/queue-5.15/ext4-move-where-set-the-may_inline_data-flag-is-set.patch new file mode 100644 index 00000000000..f8c8113de30 --- /dev/null +++ b/queue-5.15/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 +@@ -158,7 +158,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 +@@ -4549,8 +4549,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-5.15/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch b/queue-5.15/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch new file mode 100644 index 00000000000..65e0d6a6066 --- /dev/null +++ b/queue-5.15/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 +@@ -184,6 +184,7 @@ static long swap_inode_boot_loader(struc + ei_bl->i_flags = 0; + inode_set_iversion(inode_bl, 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-5.15/fork-allow-clone_newtime-in-clone3-flags.patch b/queue-5.15/fork-allow-clone_newtime-in-clone3-flags.patch new file mode 100644 index 00000000000..a0fea3b3168 --- /dev/null +++ b/queue-5.15/fork-allow-clone_newtime-in-clone3-flags.patch @@ -0,0 +1,42 @@ +From a402f1e35313fc7ce2ca60f543c4402c2c7c3544 Mon Sep 17 00:00:00 2001 +From: Tobias Klauser +Date: Wed, 8 Mar 2023 11:51:26 +0100 +Subject: fork: allow CLONE_NEWTIME in clone3 flags + +From: Tobias Klauser + +commit a402f1e35313fc7ce2ca60f543c4402c2c7c3544 upstream. + +Currently, calling clone3() with CLONE_NEWTIME in clone_args->flags +fails with -EINVAL. This is because CLONE_NEWTIME intersects with +CSIGNAL. However, CSIGNAL was deprecated when clone3 was introduced in +commit 7f192e3cd316 ("fork: add clone3"), allowing re-use of that part +of clone flags. + +Fix this by explicitly allowing CLONE_NEWTIME in clone3_args_valid. This +is also in line with the respective check in check_unshare_flags which +allow CLONE_NEWTIME for unshare(). + +Fixes: 769071ac9f20 ("ns: Introduce Time Namespace") +Cc: Andrey Vagin +Cc: Christian Brauner +Cc: stable@vger.kernel.org +Signed-off-by: Tobias Klauser +Reviewed-by: Christian Brauner +Signed-off-by: Christian Brauner (Microsoft) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/fork.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -2829,7 +2829,7 @@ static bool clone3_args_valid(struct ker + * - make the CLONE_DETACHED bit reusable for clone3 + * - make the CSIGNAL bits reusable for clone3 + */ +- if (kargs->flags & (CLONE_DETACHED | CSIGNAL)) ++ if (kargs->flags & (CLONE_DETACHED | (CSIGNAL & (~CLONE_NEWTIME)))) + return false; + + if ((kargs->flags & (CLONE_SIGHAND | CLONE_CLEAR_SIGHAND)) == diff --git a/queue-5.15/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch b/queue-5.15/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch new file mode 100644 index 00000000000..7d3551f8816 --- /dev/null +++ b/queue-5.15/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 +@@ -646,6 +646,7 @@ static struct file *pick_file(struct fil + file = ERR_PTR(-EINVAL); + goto out_unlock; + } ++ fd = array_index_nospec(fd, fdt->max_fds); + file = fdt->fd[fd]; + if (!file) { + file = ERR_PTR(-EBADF); diff --git a/queue-5.15/perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch b/queue-5.15/perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch new file mode 100644 index 00000000000..095ecf006e9 --- /dev/null +++ b/queue-5.15/perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch @@ -0,0 +1,88 @@ +From ce9f1c05d2edfa6cdf2c1a510495d333e11810a8 Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Wed, 22 Feb 2023 23:01:55 -0800 +Subject: perf inject: Fix --buildid-all not to eat up MMAP2 + +From: Namhyung Kim + +commit ce9f1c05d2edfa6cdf2c1a510495d333e11810a8 upstream. + +When MMAP2 has the PERF_RECORD_MISC_MMAP_BUILD_ID flag, it means the +record already has the build-id info. So it marks the DSO as hit, to +skip if the same DSO is not processed if it happens to miss the build-id +later. + +But it missed to copy the MMAP2 record itself so it'd fail to symbolize +samples for those regions. + +For example, the following generates 249 MMAP2 events. + + $ perf record --buildid-mmap -o- true | perf report --stat -i- | grep MMAP2 + MMAP2 events: 249 (86.8%) + +Adding perf inject should not change the number of events like this + + $ perf record --buildid-mmap -o- true | perf inject -b | \ + > perf report --stat -i- | grep MMAP2 + MMAP2 events: 249 (86.5%) + +But when --buildid-all is used, it eats most of the MMAP2 events. + + $ perf record --buildid-mmap -o- true | perf inject -b --buildid-all | \ + > perf report --stat -i- | grep MMAP2 + MMAP2 events: 1 ( 2.5%) + +With this patch, it shows the original number now. + + $ perf record --buildid-mmap -o- true | perf inject -b --buildid-all | \ + > perf report --stat -i- | grep MMAP2 + MMAP2 events: 249 (86.5%) + +Committer testing: + +Before: + + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b | perf report --stat -i- | grep MMAP2 + MMAP2 events: 58 (36.2%) + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf report --stat -i- | grep MMAP2 + MMAP2 events: 58 (36.2%) + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b --buildid-all | perf report --stat -i- | grep MMAP2 + MMAP2 events: 2 ( 1.9%) + $ + +After: + + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b | perf report --stat -i- | grep MMAP2 + MMAP2 events: 58 (29.3%) + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf report --stat -i- | grep MMAP2 + MMAP2 events: 58 (34.3%) + $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b --buildid-all | perf report --stat -i- | grep MMAP2 + MMAP2 events: 58 (38.4%) + $ + +Fixes: f7fc0d1c915a74ff ("perf inject: Do not inject BUILD_ID record if MMAP2 has it") +Signed-off-by: Namhyung Kim +Tested-by: Arnaldo Carvalho de Melo +Cc: Adrian Hunter +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230223070155.54251-1-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/builtin-inject.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/perf/builtin-inject.c ++++ b/tools/perf/builtin-inject.c +@@ -463,6 +463,7 @@ static int perf_event__repipe_buildid_mm + dso->hit = 1; + } + dso__put(dso); ++ perf_event__repipe(tool, event, sample, machine); + return 0; + } + diff --git a/queue-5.15/series b/queue-5.15/series new file mode 100644 index 00000000000..4b5dd7e3917 --- /dev/null +++ b/queue-5.15/series @@ -0,0 +1,14 @@ +fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch +btrfs-fix-percent-calculation-for-bg-reclaim-message.patch +perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch +fork-allow-clone_newtime-in-clone3-flags.patch +x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch +drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch +drm-connector-print-max_requested_bpc-in-state-debugfs.patch +staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch +ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.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-5.15/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch b/queue-5.15/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch new file mode 100644 index 00000000000..278f269ae8e --- /dev/null +++ b/queue-5.15/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch @@ -0,0 +1,51 @@ +From d17789edd6a8270c38459e592ee536a84c6202db Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Mon, 6 Mar 2023 16:35:12 +0100 +Subject: staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss() + +From: Hans de Goede + +commit d17789edd6a8270c38459e592ee536a84c6202db upstream. + +To last 2 parameters to cfg80211_get_bss() should be of +the enum ieee80211_bss_type resp. enum ieee80211_privacy types, +which WLAN_CAPABILITY_ESS very much is not. + +Fix both cfg80211_get_bss() calls in ioctl_cfg80211.c to pass +the right parameters. + +Note that the second call was already somewhat fixed by commenting +out WLAN_CAPABILITY_ESS and passing in 0 instead. This was still +not entirely correct though since that would limit returned +BSS-es to ESS type BSS-es with privacy on. + +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20230306153512.162104-2-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c ++++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +@@ -358,7 +358,7 @@ int rtw_cfg80211_check_bss(struct adapte + bss = cfg80211_get_bss(padapter->rtw_wdev->wiphy, notify_channel, + pnetwork->mac_address, pnetwork->ssid.ssid, + pnetwork->ssid.ssid_length, +- WLAN_CAPABILITY_ESS, WLAN_CAPABILITY_ESS); ++ IEEE80211_BSS_TYPE_ANY, IEEE80211_PRIVACY_ANY); + + cfg80211_put_bss(padapter->rtw_wdev->wiphy, bss); + +@@ -1239,8 +1239,8 @@ void rtw_cfg80211_unlink_bss(struct adap + + bss = cfg80211_get_bss(wiphy, NULL/*notify_channel*/, + select_network->mac_address, select_network->ssid.ssid, +- select_network->ssid.ssid_length, 0/*WLAN_CAPABILITY_ESS*/, +- 0/*WLAN_CAPABILITY_ESS*/); ++ select_network->ssid.ssid_length, IEEE80211_BSS_TYPE_ANY, ++ IEEE80211_PRIVACY_ANY); + + if (bss) { + cfg80211_unlink_bss(wiphy, bss); diff --git a/queue-5.15/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch b/queue-5.15/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch new file mode 100644 index 00000000000..86cb474bc2b --- /dev/null +++ b/queue-5.15/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 +@@ -904,6 +904,15 @@ void init_spectral_chicken(struct cpuinf + } + } + #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_zn(struct cpuinfo_x86 *c)