From: Greg Kroah-Hartman Date: Mon, 13 Mar 2023 10:55:08 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v4.14.310~97 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=76242ef06c2cc6c20d44251fb468f91aa74888ca;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: btrfs-fix-percent-calculation-for-bg-reclaim-message.patch btrfs-fix-unnecessary-increment-of-read-error-stat-on-write-error.patch drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-nv.patch drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc21.patch drm-connector-print-max_requested_bpc-in-state-debugfs.patch drm-display-don-t-block-hdr_output_metadata-on-unknown-eotf.patch erofs-fix-wrong-kunmap-when-using-lzma-on-highmem-platforms.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 hid-core-provide-new-max_buffer_size-attribute-to-over-ride-the-default.patch hid-uhid-over-ride-the-default-maximum-data-buffer-value-with-our-own.patch io_uring-uring_cmd-ensure-that-device-supports-iopoll.patch perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch risc-v-stop-emitting-attributes.patch series staging-rtl8723bs-fix-key-store-index-handling.patch staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch --- diff --git a/queue-6.1/btrfs-fix-percent-calculation-for-bg-reclaim-message.patch b/queue-6.1/btrfs-fix-percent-calculation-for-bg-reclaim-message.patch new file mode 100644 index 00000000000..67a571e3ae3 --- /dev/null +++ b/queue-6.1/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 +@@ -1616,7 +1616,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-6.1/btrfs-fix-unnecessary-increment-of-read-error-stat-on-write-error.patch b/queue-6.1/btrfs-fix-unnecessary-increment-of-read-error-stat-on-write-error.patch new file mode 100644 index 00000000000..f9a731ee33c --- /dev/null +++ b/queue-6.1/btrfs-fix-unnecessary-increment-of-read-error-stat-on-write-error.patch @@ -0,0 +1,37 @@ +From 98e8d36a26c2ed22f78316df7d4bf33e554b9f9f Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Mon, 13 Feb 2023 14:10:38 +0900 +Subject: btrfs: fix unnecessary increment of read error stat on write error + +From: Naohiro Aota + +commit 98e8d36a26c2ed22f78316df7d4bf33e554b9f9f upstream. + +Current btrfs_log_dev_io_error() increases the read error count even if the +erroneous IO is a WRITE request. This is because it forget to use "else +if", and all the error WRITE requests counts as READ error as there is (of +course) no REQ_RAHEAD bit set. + +Fixes: c3a62baf21ad ("btrfs: use chained bios when cloning") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Christoph Hellwig +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/volumes.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -6739,7 +6739,7 @@ static void btrfs_log_dev_io_error(struc + + if (btrfs_op(bio) == BTRFS_MAP_WRITE) + btrfs_dev_stat_inc_and_print(dev, BTRFS_DEV_STAT_WRITE_ERRS); +- if (!(bio->bi_opf & REQ_RAHEAD)) ++ else if (!(bio->bi_opf & REQ_RAHEAD)) + btrfs_dev_stat_inc_and_print(dev, BTRFS_DEV_STAT_READ_ERRS); + if (bio->bi_opf & REQ_PREFLUSH) + btrfs_dev_stat_inc_and_print(dev, BTRFS_DEV_STAT_FLUSH_ERRS); diff --git a/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-nv.patch b/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-nv.patch new file mode 100644 index 00000000000..80a93e0f0a5 --- /dev/null +++ b/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-nv.patch @@ -0,0 +1,36 @@ +From b42fee5e0b44344cfe4c38e61341ee250362c83f Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 7 Mar 2023 08:59:13 -0500 +Subject: drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv + +From: Alex Deucher + +commit b42fee5e0b44344cfe4c38e61341ee250362c83f upstream. + +Properly skip non-existent registers as well. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442 +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/nv.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/nv.c ++++ b/drivers/gpu/drm/amd/amdgpu/nv.c +@@ -393,9 +393,10 @@ static int nv_read_register(struct amdgp + *value = 0; + for (i = 0; i < ARRAY_SIZE(nv_allowed_read_registers); i++) { + en = &nv_allowed_read_registers[i]; +- if (adev->reg_offset[en->hwip][en->inst] && +- reg_offset != (adev->reg_offset[en->hwip][en->inst][en->seg] +- + en->reg_offset)) ++ 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; + + *value = nv_get_register_value(adev, diff --git a/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch b/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc15.patch new file mode 100644 index 00000000000..3edfc76eb6c --- /dev/null +++ b/queue-6.1/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 +@@ -439,8 +439,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-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc21.patch b/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc21.patch new file mode 100644 index 00000000000..a959edc6e79 --- /dev/null +++ b/queue-6.1/drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc21.patch @@ -0,0 +1,36 @@ +From 2915e43a033a778816fa4bc621f033576796521e Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 6 Mar 2023 10:35:34 -0500 +Subject: drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 + +From: Alex Deucher + +commit 2915e43a033a778816fa4bc621f033576796521e upstream. + +Properly skip non-existent registers as well. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442 +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/soc21.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/soc21.c ++++ b/drivers/gpu/drm/amd/amdgpu/soc21.c +@@ -254,9 +254,10 @@ static int soc21_read_register(struct am + *value = 0; + for (i = 0; i < ARRAY_SIZE(soc21_allowed_read_registers); i++) { + en = &soc21_allowed_read_registers[i]; +- if (adev->reg_offset[en->hwip][en->inst] && +- reg_offset != (adev->reg_offset[en->hwip][en->inst][en->seg] +- + en->reg_offset)) ++ 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; + + *value = soc21_get_register_value(adev, diff --git a/queue-6.1/drm-connector-print-max_requested_bpc-in-state-debugfs.patch b/queue-6.1/drm-connector-print-max_requested_bpc-in-state-debugfs.patch new file mode 100644 index 00000000000..ce56552515a --- /dev/null +++ b/queue-6.1/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 +@@ -1070,6 +1070,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-6.1/drm-display-don-t-block-hdr_output_metadata-on-unknown-eotf.patch b/queue-6.1/drm-display-don-t-block-hdr_output_metadata-on-unknown-eotf.patch new file mode 100644 index 00000000000..cfe44135312 --- /dev/null +++ b/queue-6.1/drm-display-don-t-block-hdr_output_metadata-on-unknown-eotf.patch @@ -0,0 +1,78 @@ +From e5eef23e267c72521d81f23f7f82d1f523d4a253 Mon Sep 17 00:00:00 2001 +From: Harry Wentland +Date: Fri, 13 Jan 2023 11:24:08 -0500 +Subject: drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Harry Wentland + +commit e5eef23e267c72521d81f23f7f82d1f523d4a253 upstream. + +The EDID of an HDR display defines EOTFs that are supported +by the display and can be set in the HDR metadata infoframe. +Userspace is expected to read the EDID and set an appropriate +HDR_OUTPUT_METADATA. + +In drm_parse_hdr_metadata_block the kernel reads the supported +EOTFs from the EDID and stores them in the +drm_connector->hdr_sink_metadata. While doing so it also +filters the EOTFs to the EOTFs the kernel knows about. +When an HDR_OUTPUT_METADATA is set it then checks to +make sure the EOTF is a supported EOTF. In cases where +the kernel doesn't know about a new EOTF this check will +fail, even if the EDID advertises support. + +Since it is expected that userspace reads the EDID to understand +what the display supports it doesn't make sense for DRM to block +an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't +understand. + +This comes with the added benefit of future-proofing metadata +support. If the spec defines a new EOTF there is no need to +update DRM and an compositor can immediately make use of it. + +Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609 + +v2: Distinguish EOTFs defind in kernel and ones defined + in EDID in the commit description (Pekka) + +v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved + to drm_hdmi_helper.c + +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 +Acked-by: Pekka Paalanen +Reviewed-By: Joshua Ashton +Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentland@amd.com +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/display/drm_hdmi_helper.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/display/drm_hdmi_helper.c ++++ b/drivers/gpu/drm/display/drm_hdmi_helper.c +@@ -44,10 +44,8 @@ int drm_hdmi_infoframe_set_hdr_metadata( + + /* Sink EOTF is Bit map while infoframe is absolute values */ + if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf, +- connector->hdr_sink_metadata.hdmi_type1.eotf)) { +- DRM_DEBUG_KMS("EOTF Not Supported\n"); +- return -EINVAL; +- } ++ connector->hdr_sink_metadata.hdmi_type1.eotf)) ++ DRM_DEBUG_KMS("Unknown EOTF %d\n", hdr_metadata->hdmi_metadata_type1.eotf); + + err = hdmi_drm_infoframe_init(frame); + if (err < 0) diff --git a/queue-6.1/erofs-fix-wrong-kunmap-when-using-lzma-on-highmem-platforms.patch b/queue-6.1/erofs-fix-wrong-kunmap-when-using-lzma-on-highmem-platforms.patch new file mode 100644 index 00000000000..222a4748f2b --- /dev/null +++ b/queue-6.1/erofs-fix-wrong-kunmap-when-using-lzma-on-highmem-platforms.patch @@ -0,0 +1,52 @@ +From 8f121dfb15f7b4ab345992ce96003eb63fd608f4 Mon Sep 17 00:00:00 2001 +From: Gao Xiang +Date: Sun, 5 Mar 2023 21:44:55 +0800 +Subject: erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms + +From: Gao Xiang + +commit 8f121dfb15f7b4ab345992ce96003eb63fd608f4 upstream. + +As the call trace shown, the root cause is kunmap incorrect pages: + + BUG: kernel NULL pointer dereference, address: 00000000 + CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4 + Workqueue: erofs_worker z_erofs_decompressqueue_work + EIP: z_erofs_lzma_decompress+0x34b/0x8ac + z_erofs_decompress+0x12/0x14 + z_erofs_decompress_queue+0x7e7/0xb1c + z_erofs_decompressqueue_work+0x32/0x60 + process_one_work+0x24b/0x4d8 + ? process_one_work+0x1a4/0x4d8 + worker_thread+0x14c/0x3fc + kthread+0xe6/0x10c + ? rescuer_thread+0x358/0x358 + ? kthread_complete_and_exit+0x18/0x18 + ret_from_fork+0x1c/0x28 + ---[ end trace 0000000000000000 ]--- + +The bug is trivial and should be fixed now. It has no impact on +!HIGHMEM platforms. + +Fixes: 622ceaddb764 ("erofs: lzma compression support") +Cc: # 5.16+ +Reviewed-by: Yue Hu +Reviewed-by: Chao Yu +Signed-off-by: Gao Xiang +Link: https://lore.kernel.org/r/20230305134455.88236-1-hsiangkao@linux.alibaba.com +Signed-off-by: Greg Kroah-Hartman +--- + fs/erofs/decompressor_lzma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/erofs/decompressor_lzma.c ++++ b/fs/erofs/decompressor_lzma.c +@@ -278,7 +278,7 @@ again: + } + } + if (no < nrpages_out && strm->buf.out) +- kunmap(rq->in[no]); ++ kunmap(rq->out[no]); + if (ni < nrpages_in) + kunmap(rq->in[ni]); + /* 4. push back LZMA stream context to the global list */ diff --git a/queue-6.1/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch b/queue-6.1/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-filesystems.patch new file mode 100644 index 00000000000..7349e2b664e --- /dev/null +++ b/queue-6.1/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-6.1/ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.patch b/queue-6.1/ext4-fix-cgroup-writeback-accounting-with-fs-layer-encryption.patch new file mode 100644 index 00000000000..5957803a044 --- /dev/null +++ b/queue-6.1/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 +@@ -409,7 +409,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; +@@ -421,10 +422,11 @@ submit_and_retry: + } + if (io->io_bio == NULL) + io_submit_init_bio(io, bh); +- 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++; + } + +@@ -543,8 +545,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-6.1/ext4-fix-rename_whiteout-handling-for-inline-directories.patch b/queue-6.1/ext4-fix-rename_whiteout-handling-for-inline-directories.patch new file mode 100644 index 00000000000..fe7d2d91fcf --- /dev/null +++ b/queue-6.1/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] == '.') && +@@ -3646,7 +3645,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) +@@ -3813,7 +3813,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-6.1/ext4-fix-warning-in-ext4_update_inline_data.patch b/queue-6.1/ext4-fix-warning-in-ext4_update_inline_data.patch new file mode 100644 index 00000000000..f2df2562958 --- /dev/null +++ b/queue-6.1/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 +@@ -2790,6 +2790,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-6.1/ext4-move-where-set-the-may_inline_data-flag-is-set.patch b/queue-6.1/ext4-move-where-set-the-may_inline_data-flag-is-set.patch new file mode 100644 index 00000000000..15253554d39 --- /dev/null +++ b/queue-6.1/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 +@@ -159,7 +159,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 +@@ -4727,8 +4727,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-6.1/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch b/queue-6.1/ext4-zero-i_disksize-when-initializing-the-bootloader-inode.patch new file mode 100644 index 00000000000..017f411858e --- /dev/null +++ b/queue-6.1/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 +@@ -434,6 +434,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-6.1/fork-allow-clone_newtime-in-clone3-flags.patch b/queue-6.1/fork-allow-clone_newtime-in-clone3-flags.patch new file mode 100644 index 00000000000..6bb692b3a82 --- /dev/null +++ b/queue-6.1/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 +@@ -2928,7 +2928,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-6.1/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch b/queue-6.1/fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch new file mode 100644 index 00000000000..03bf3d94030 --- /dev/null +++ b/queue-6.1/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 +@@ -642,6 +642,7 @@ static struct file *pick_file(struct fil + if (fd >= fdt->max_fds) + return NULL; + ++ fd = array_index_nospec(fd, fdt->max_fds); + file = fdt->fd[fd]; + if (file) { + rcu_assign_pointer(fdt->fd[fd], NULL); diff --git a/queue-6.1/hid-core-provide-new-max_buffer_size-attribute-to-over-ride-the-default.patch b/queue-6.1/hid-core-provide-new-max_buffer_size-attribute-to-over-ride-the-default.patch new file mode 100644 index 00000000000..de3c002a312 --- /dev/null +++ b/queue-6.1/hid-core-provide-new-max_buffer_size-attribute-to-over-ride-the-default.patch @@ -0,0 +1,133 @@ +From b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc Mon Sep 17 00:00:00 2001 +From: Lee Jones +Date: Mon, 23 Jan 2023 12:39:11 +0000 +Subject: HID: core: Provide new max_buffer_size attribute to over-ride the default + +From: Lee Jones + +commit b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc upstream. + +Presently, when a report is processed, its proposed size, provided by +the user of the API (as Report Size * Report Count) is compared against +the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some +low-level HID drivers allocate a reduced amount of memory to their +buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending +this check inadequate in some cases. + +In these circumstances, if the received report ends up being smaller +than the proposed report size, the remainder of the buffer is zeroed. +That is, the space between sizeof(csize) (size of the current report) +and the rsize (size proposed i.e. Report Size * Report Count), which can +be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset() +shoots straight past the end of the buffer boundary and starts zeroing +out in-use values, often resulting in calamity. + +This patch introduces a new variable into 'struct hid_ll_driver' where +individual low-level drivers can over-ride the default maximum value of +HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the +interface. + +Signed-off-by: Lee Jones +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-core.c | 32 +++++++++++++++++++++++++------- + include/linux/hid.h | 3 +++ + 2 files changed, 28 insertions(+), 7 deletions(-) + +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -261,6 +261,7 @@ static int hid_add_field(struct hid_pars + { + struct hid_report *report; + struct hid_field *field; ++ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE; + unsigned int usages; + unsigned int offset; + unsigned int i; +@@ -291,8 +292,11 @@ static int hid_add_field(struct hid_pars + offset = report->size; + report->size += parser->global.report_size * parser->global.report_count; + ++ if (parser->device->ll_driver->max_buffer_size) ++ max_buffer_size = parser->device->ll_driver->max_buffer_size; ++ + /* Total size check: Allow for possible report index byte */ +- if (report->size > (HID_MAX_BUFFER_SIZE - 1) << 3) { ++ if (report->size > (max_buffer_size - 1) << 3) { + hid_err(parser->device, "report is too long\n"); + return -1; + } +@@ -1966,6 +1970,7 @@ int hid_report_raw_event(struct hid_devi + struct hid_report_enum *report_enum = hid->report_enum + type; + struct hid_report *report; + struct hid_driver *hdrv; ++ int max_buffer_size = HID_MAX_BUFFER_SIZE; + u32 rsize, csize = size; + u8 *cdata = data; + int ret = 0; +@@ -1981,10 +1986,13 @@ int hid_report_raw_event(struct hid_devi + + rsize = hid_compute_report_size(report); + +- if (report_enum->numbered && rsize >= HID_MAX_BUFFER_SIZE) +- rsize = HID_MAX_BUFFER_SIZE - 1; +- else if (rsize > HID_MAX_BUFFER_SIZE) +- rsize = HID_MAX_BUFFER_SIZE; ++ if (hid->ll_driver->max_buffer_size) ++ max_buffer_size = hid->ll_driver->max_buffer_size; ++ ++ if (report_enum->numbered && rsize >= max_buffer_size) ++ rsize = max_buffer_size - 1; ++ else if (rsize > max_buffer_size) ++ rsize = max_buffer_size; + + if (csize < rsize) { + dbg_hid("report %d is too short, (%d < %d)\n", report->id, +@@ -2387,7 +2395,12 @@ int hid_hw_raw_request(struct hid_device + unsigned char reportnum, __u8 *buf, + size_t len, enum hid_report_type rtype, enum hid_class_request reqtype) + { +- if (len < 1 || len > HID_MAX_BUFFER_SIZE || !buf) ++ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE; ++ ++ if (hdev->ll_driver->max_buffer_size) ++ max_buffer_size = hdev->ll_driver->max_buffer_size; ++ ++ if (len < 1 || len > max_buffer_size || !buf) + return -EINVAL; + + return hdev->ll_driver->raw_request(hdev, reportnum, buf, len, +@@ -2406,7 +2419,12 @@ EXPORT_SYMBOL_GPL(hid_hw_raw_request); + */ + int hid_hw_output_report(struct hid_device *hdev, __u8 *buf, size_t len) + { +- if (len < 1 || len > HID_MAX_BUFFER_SIZE || !buf) ++ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE; ++ ++ if (hdev->ll_driver->max_buffer_size) ++ max_buffer_size = hdev->ll_driver->max_buffer_size; ++ ++ if (len < 1 || len > max_buffer_size || !buf) + return -EINVAL; + + if (hdev->ll_driver->output_report) +--- a/include/linux/hid.h ++++ b/include/linux/hid.h +@@ -827,6 +827,7 @@ struct hid_driver { + * @output_report: send output report to device + * @idle: send idle request to device + * @may_wakeup: return if device may act as a wakeup source during system-suspend ++ * @max_buffer_size: over-ride maximum data buffer size (default: HID_MAX_BUFFER_SIZE) + */ + struct hid_ll_driver { + int (*start)(struct hid_device *hdev); +@@ -852,6 +853,8 @@ struct hid_ll_driver { + + int (*idle)(struct hid_device *hdev, int report, int idle, int reqtype); + bool (*may_wakeup)(struct hid_device *hdev); ++ ++ unsigned int max_buffer_size; + }; + + extern struct hid_ll_driver i2c_hid_ll_driver; diff --git a/queue-6.1/hid-uhid-over-ride-the-default-maximum-data-buffer-value-with-our-own.patch b/queue-6.1/hid-uhid-over-ride-the-default-maximum-data-buffer-value-with-our-own.patch new file mode 100644 index 00000000000..fc54715297b --- /dev/null +++ b/queue-6.1/hid-uhid-over-ride-the-default-maximum-data-buffer-value-with-our-own.patch @@ -0,0 +1,31 @@ +From 1c5d4221240a233df2440fe75c881465cdf8da07 Mon Sep 17 00:00:00 2001 +From: Lee Jones +Date: Mon, 23 Jan 2023 12:39:12 +0000 +Subject: HID: uhid: Over-ride the default maximum data buffer value with our own + +From: Lee Jones + +commit 1c5d4221240a233df2440fe75c881465cdf8da07 upstream. + +The default maximum data buffer size for this interface is UHID_DATA_MAX +(4k). When data buffers are being processed, ensure this value is used +when ensuring the sanity, rather than a value between the user provided +value and HID_MAX_BUFFER_SIZE (16k). + +Signed-off-by: Lee Jones +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/uhid.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/hid/uhid.c ++++ b/drivers/hid/uhid.c +@@ -395,6 +395,7 @@ struct hid_ll_driver uhid_hid_driver = { + .parse = uhid_hid_parse, + .raw_request = uhid_hid_raw_request, + .output_report = uhid_hid_output_report, ++ .max_buffer_size = UHID_DATA_MAX, + }; + EXPORT_SYMBOL_GPL(uhid_hid_driver); + diff --git a/queue-6.1/io_uring-uring_cmd-ensure-that-device-supports-iopoll.patch b/queue-6.1/io_uring-uring_cmd-ensure-that-device-supports-iopoll.patch new file mode 100644 index 00000000000..2dc04cc5e07 --- /dev/null +++ b/queue-6.1/io_uring-uring_cmd-ensure-that-device-supports-iopoll.patch @@ -0,0 +1,48 @@ +From 03b3d6be73e81ddb7c2930d942cdd17f4cfd5ba5 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Wed, 8 Mar 2023 09:26:13 -0700 +Subject: io_uring/uring_cmd: ensure that device supports IOPOLL + +From: Jens Axboe + +commit 03b3d6be73e81ddb7c2930d942cdd17f4cfd5ba5 upstream. + +It's possible for a file type to support uring commands, but not +pollable ones. Hence before issuing one of those, we should check +that it is supported and error out upfront if it isn't. + +Cc: stable@vger.kernel.org +Fixes: 5756a3a7e713 ("io_uring: add iopoll infrastructure for io_uring_cmd") +Link: https://github.com/axboe/liburing/issues/816 +Reviewed-by: Kanchan Joshi +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/uring_cmd.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c +index 446a189b78b0..2e4c483075d3 100644 +--- a/io_uring/uring_cmd.c ++++ b/io_uring/uring_cmd.c +@@ -108,7 +108,7 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags) + struct file *file = req->file; + int ret; + +- if (!req->file->f_op->uring_cmd) ++ if (!file->f_op->uring_cmd) + return -EOPNOTSUPP; + + ret = security_uring_cmd(ioucmd); +@@ -120,6 +120,8 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags) + if (ctx->flags & IORING_SETUP_CQE32) + issue_flags |= IO_URING_F_CQE32; + if (ctx->flags & IORING_SETUP_IOPOLL) { ++ if (!file->f_op->uring_cmd_iopoll) ++ return -EOPNOTSUPP; + issue_flags |= IO_URING_F_IOPOLL; + req->iopoll_completed = 0; + WRITE_ONCE(ioucmd->cookie, NULL); +-- +2.39.2 + diff --git a/queue-6.1/perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch b/queue-6.1/perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch new file mode 100644 index 00000000000..f975e41475b --- /dev/null +++ b/queue-6.1/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 +@@ -538,6 +538,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-6.1/risc-v-stop-emitting-attributes.patch b/queue-6.1/risc-v-stop-emitting-attributes.patch new file mode 100644 index 00000000000..6eb17adb76e --- /dev/null +++ b/queue-6.1/risc-v-stop-emitting-attributes.patch @@ -0,0 +1,52 @@ +From e18048da9bc3f87acef4eb67a11b4fc55fe15424 Mon Sep 17 00:00:00 2001 +From: Palmer Dabbelt +Date: Thu, 23 Feb 2023 14:46:05 -0800 +Subject: RISC-V: Stop emitting attributes + +From: Palmer Dabbelt + +commit e18048da9bc3f87acef4eb67a11b4fc55fe15424 upstream. + +The RISC-V ELF attributes don't contain any useful information. New +toolchains ignore them, but they frequently trip up various older/mixed +toolchains. So just turn them off. + +Tested-by: Conor Dooley +Link: https://lore.kernel.org/r/20230223224605.6995-1-palmer@rivosinc.com +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/Makefile | 7 +++++++ + arch/riscv/kernel/compat_vdso/Makefile | 4 ++++ + 2 files changed, 11 insertions(+) + +--- a/arch/riscv/Makefile ++++ b/arch/riscv/Makefile +@@ -87,6 +87,13 @@ endif + # Avoid generating .eh_frame sections. + KBUILD_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables + ++# The RISC-V attributes frequently cause compatibility issues and provide no ++# information, so just turn them off. ++KBUILD_CFLAGS += $(call cc-option,-mno-riscv-attribute) ++KBUILD_AFLAGS += $(call cc-option,-mno-riscv-attribute) ++KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mno-arch-attr) ++KBUILD_AFLAGS += $(call as-option,-Wa$(comma)-mno-arch-attr) ++ + KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax) + KBUILD_AFLAGS_MODULE += $(call as-option,-Wa$(comma)-mno-relax) + +--- a/arch/riscv/kernel/compat_vdso/Makefile ++++ b/arch/riscv/kernel/compat_vdso/Makefile +@@ -14,6 +14,10 @@ COMPAT_LD := $(LD) + COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 + COMPAT_LD_FLAGS := -melf32lriscv + ++# Disable attributes, as they're useless and break the build. ++COMPAT_CC_FLAGS += $(call cc-option,-mno-riscv-attribute) ++COMPAT_CC_FLAGS += $(call as-option,-Wa$(comma)-mno-arch-attr) ++ + # Files to link into the compat_vdso + obj-compat_vdso = $(patsubst %, %.o, $(compat_vdso-syms)) note.o + diff --git a/queue-6.1/series b/queue-6.1/series new file mode 100644 index 00000000000..211e17d9d79 --- /dev/null +++ b/queue-6.1/series @@ -0,0 +1,24 @@ +fs-prevent-out-of-bounds-array-speculation-when-closing-a-file-descriptor.patch +btrfs-fix-unnecessary-increment-of-read-error-stat-on-write-error.patch +btrfs-fix-percent-calculation-for-bg-reclaim-message.patch +io_uring-uring_cmd-ensure-that-device-supports-iopoll.patch +erofs-fix-wrong-kunmap-when-using-lzma-on-highmem-platforms.patch +perf-inject-fix-buildid-all-not-to-eat-up-mmap2.patch +fork-allow-clone_newtime-in-clone3-flags.patch +risc-v-stop-emitting-attributes.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-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-soc21.patch +drm-amdgpu-fix-error-checking-in-amdgpu_read_mm_registers-for-nv.patch +drm-display-don-t-block-hdr_output_metadata-on-unknown-eotf.patch +drm-connector-print-max_requested_bpc-in-state-debugfs.patch +staging-rtl8723bs-fix-key-store-index-handling.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 +hid-core-provide-new-max_buffer_size-attribute-to-over-ride-the-default.patch +hid-uhid-over-ride-the-default-maximum-data-buffer-value-with-our-own.patch diff --git a/queue-6.1/staging-rtl8723bs-fix-key-store-index-handling.patch b/queue-6.1/staging-rtl8723bs-fix-key-store-index-handling.patch new file mode 100644 index 00000000000..f8fbed3705c --- /dev/null +++ b/queue-6.1/staging-rtl8723bs-fix-key-store-index-handling.patch @@ -0,0 +1,173 @@ +From 05cbcc415c9b8c8bc4f9a09f8e03610a89042f03 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Mon, 6 Mar 2023 16:35:11 +0100 +Subject: staging: rtl8723bs: Fix key-store index handling + +From: Hans de Goede + +commit 05cbcc415c9b8c8bc4f9a09f8e03610a89042f03 upstream. + +There are 2 issues with the key-store index handling + +1. The non WEP key stores can store keys with indexes 0 - BIP_MAX_KEYID, + this means that they should be an array with BIP_MAX_KEYID + 1 + entries. But some of the arrays where just BIP_MAX_KEYID entries + big. While one other array was hardcoded to a size of 6 entries, + instead of using the BIP_MAX_KEYID define. + +2. The rtw_cfg80211_set_encryption() and wpa_set_encryption() functions + index check where checking that the passed in key-index would fit + inside both the WEP key store (which only has 4 entries) as well as + in the non WEP key stores. This breaks any attempts to set non WEP + keys with index 4 or 5. + +Issue 2. specifically breaks wifi connection with some access points +which advertise PMF support. Without this fix connecting to these +access points fails with the following wpa_supplicant messages: + + nl80211: kernel reports: key addition failed + wlan0: WPA: Failed to configure IGTK to the driver + wlan0: RSN: Failed to configure IGTK + wlan0: CTRL-EVENT-DISCONNECTED bssid=... reason=1 locally_generated=1 + +Fix 1. by using the right size for the key-stores. After this 2. can +safely be fixed by checking the right max-index value depending on the +used algorithm, fixing wifi not working with some PMF capable APs. + +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20230306153512.162104-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/staging/rtl8723bs/include/rtw_security.h | 8 ++--- + drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 26 ++++++++++------- + drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 33 +++++++++++----------- + 3 files changed, 36 insertions(+), 31 deletions(-) + +--- a/drivers/staging/rtl8723bs/include/rtw_security.h ++++ b/drivers/staging/rtl8723bs/include/rtw_security.h +@@ -107,13 +107,13 @@ struct security_priv { + + u32 dot118021XGrpPrivacy; /* This specify the privacy algthm. used for Grp key */ + u32 dot118021XGrpKeyid; /* key id used for Grp Key (tx key index) */ +- union Keytype dot118021XGrpKey[BIP_MAX_KEYID]; /* 802.1x Group Key, for inx0 and inx1 */ +- union Keytype dot118021XGrptxmickey[BIP_MAX_KEYID]; +- union Keytype dot118021XGrprxmickey[BIP_MAX_KEYID]; ++ union Keytype dot118021XGrpKey[BIP_MAX_KEYID + 1]; /* 802.1x Group Key, for inx0 and inx1 */ ++ union Keytype dot118021XGrptxmickey[BIP_MAX_KEYID + 1]; ++ union Keytype dot118021XGrprxmickey[BIP_MAX_KEYID + 1]; + union pn48 dot11Grptxpn; /* PN48 used for Grp Key xmit. */ + union pn48 dot11Grprxpn; /* PN48 used for Grp Key recv. */ + u32 dot11wBIPKeyid; /* key id used for BIP Key (tx key index) */ +- union Keytype dot11wBIPKey[6]; /* BIP Key, for index4 and index5 */ ++ union Keytype dot11wBIPKey[BIP_MAX_KEYID + 1]; /* BIP Key, for index4 and index5 */ + union pn48 dot11wBIPtxpn; /* PN48 used for Grp Key xmit. */ + union pn48 dot11wBIPrxpn; /* PN48 used for Grp Key recv. */ + +--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c ++++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +@@ -711,6 +711,7 @@ exit: + static int rtw_cfg80211_set_encryption(struct net_device *dev, struct ieee_param *param, u32 param_len) + { + int ret = 0; ++ u8 max_idx; + u32 wep_key_idx, wep_key_len; + struct adapter *padapter = rtw_netdev_priv(dev); + struct mlme_priv *pmlmepriv = &padapter->mlmepriv; +@@ -724,26 +725,29 @@ static int rtw_cfg80211_set_encryption(s + goto exit; + } + +- if (param->sta_addr[0] == 0xff && param->sta_addr[1] == 0xff && +- param->sta_addr[2] == 0xff && param->sta_addr[3] == 0xff && +- param->sta_addr[4] == 0xff && param->sta_addr[5] == 0xff) { +- if (param->u.crypt.idx >= WEP_KEYS +- || param->u.crypt.idx >= BIP_MAX_KEYID) { +- ret = -EINVAL; +- goto exit; +- } +- } else { +- { ++ if (param->sta_addr[0] != 0xff || param->sta_addr[1] != 0xff || ++ param->sta_addr[2] != 0xff || param->sta_addr[3] != 0xff || ++ param->sta_addr[4] != 0xff || param->sta_addr[5] != 0xff) { + ret = -EINVAL; + goto exit; + } ++ ++ if (strcmp(param->u.crypt.alg, "WEP") == 0) ++ max_idx = WEP_KEYS - 1; ++ else ++ max_idx = BIP_MAX_KEYID; ++ ++ if (param->u.crypt.idx > max_idx) { ++ netdev_err(dev, "Error crypt.idx %d > %d\n", param->u.crypt.idx, max_idx); ++ ret = -EINVAL; ++ goto exit; + } + + if (strcmp(param->u.crypt.alg, "WEP") == 0) { + wep_key_idx = param->u.crypt.idx; + wep_key_len = param->u.crypt.key_len; + +- if ((wep_key_idx >= WEP_KEYS) || (wep_key_len <= 0)) { ++ if (wep_key_len <= 0) { + ret = -EINVAL; + goto exit; + } +--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c ++++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c +@@ -46,6 +46,7 @@ static int wpa_set_auth_algs(struct net_ + static int wpa_set_encryption(struct net_device *dev, struct ieee_param *param, u32 param_len) + { + int ret = 0; ++ u8 max_idx; + u32 wep_key_idx, wep_key_len, wep_total_len; + struct ndis_802_11_wep *pwep = NULL; + struct adapter *padapter = rtw_netdev_priv(dev); +@@ -60,19 +61,22 @@ static int wpa_set_encryption(struct net + goto exit; + } + +- if (param->sta_addr[0] == 0xff && param->sta_addr[1] == 0xff && +- param->sta_addr[2] == 0xff && param->sta_addr[3] == 0xff && +- param->sta_addr[4] == 0xff && param->sta_addr[5] == 0xff) { +- if (param->u.crypt.idx >= WEP_KEYS || +- param->u.crypt.idx >= BIP_MAX_KEYID) { +- ret = -EINVAL; +- goto exit; +- } +- } else { +- { +- ret = -EINVAL; +- goto exit; +- } ++ if (param->sta_addr[0] != 0xff || param->sta_addr[1] != 0xff || ++ param->sta_addr[2] != 0xff || param->sta_addr[3] != 0xff || ++ param->sta_addr[4] != 0xff || param->sta_addr[5] != 0xff) { ++ ret = -EINVAL; ++ goto exit; ++ } ++ ++ if (strcmp(param->u.crypt.alg, "WEP") == 0) ++ max_idx = WEP_KEYS - 1; ++ else ++ max_idx = BIP_MAX_KEYID; ++ ++ if (param->u.crypt.idx > max_idx) { ++ netdev_err(dev, "Error crypt.idx %d > %d\n", param->u.crypt.idx, max_idx); ++ ret = -EINVAL; ++ goto exit; + } + + if (strcmp(param->u.crypt.alg, "WEP") == 0) { +@@ -84,9 +88,6 @@ static int wpa_set_encryption(struct net + wep_key_idx = param->u.crypt.idx; + wep_key_len = param->u.crypt.key_len; + +- if (wep_key_idx > WEP_KEYS) +- return -EINVAL; +- + if (wep_key_len > 0) { + wep_key_len = wep_key_len <= 5 ? 5 : 13; + wep_total_len = wep_key_len + FIELD_OFFSET(struct ndis_802_11_wep, key_material); diff --git a/queue-6.1/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch b/queue-6.1/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch new file mode 100644 index 00000000000..03839ffbe9e --- /dev/null +++ b/queue-6.1/staging-rtl8723bs-pass-correct-parameters-to-cfg80211_get_bss.patch @@ -0,0 +1,56 @@ +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(-) + +diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +index 3aba4e6eec8a..84a9f4dd8f95 100644 +--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c ++++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +@@ -350,7 +350,7 @@ int rtw_cfg80211_check_bss(struct adapter *padapter) + 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); + +@@ -1139,8 +1139,8 @@ void rtw_cfg80211_unlink_bss(struct adapter *padapter, struct wlan_network *pnet + + 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); +-- +2.39.2 + diff --git a/queue-6.1/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch b/queue-6.1/x86-cpu-amd-disable-xsaves-on-amd-family-0x17.patch new file mode 100644 index 00000000000..aebfd53817f --- /dev/null +++ b/queue-6.1/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 +@@ -880,6 +880,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)