--- /dev/null
+From 95cd356ca23c3807b5f3503687161e216b1c520d Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Date: Tue, 21 Feb 2023 10:11:24 -0800
+Subject: btrfs: fix percent calculation for bg reclaim message
+
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+
+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 <forza@tnonline.net>
+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 <anand.jain@oracle.com>
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+[ add Qu's note ]
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 98e8d36a26c2ed22f78316df7d4bf33e554b9f9f Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Mon, 13 Feb 2023 14:10:38 +0900
+Subject: btrfs: fix unnecessary increment of read error stat on write error
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+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 <hch@lst.de>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From b42fee5e0b44344cfe4c38e61341ee250362c83f Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+commit b42fee5e0b44344cfe4c38e61341ee250362c83f upstream.
+
+Properly skip non-existent registers as well.
+
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 0dcdf8498eae2727bb33cef3576991dc841d4343 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+commit 0dcdf8498eae2727bb33cef3576991dc841d4343 upstream.
+
+Properly skip non-existent registers as well.
+
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From 2915e43a033a778816fa4bc621f033576796521e Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+commit 2915e43a033a778816fa4bc621f033576796521e upstream.
+
+Properly skip non-existent registers as well.
+
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 7d386975f6a495902e679a3a250a7456d7e54765 Mon Sep 17 00:00:00 2001
+From: Harry Wentland <harry.wentland@amd.com>
+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 <harry.wentland@amd.com>
+
+commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream.
+
+This is useful to understand the bpc defaults and
+support of a driver.
+
+Signed-off-by: Harry Wentland <harry.wentland@amd.com>
+Cc: Pekka Paalanen <ppaalanen@gmail.com>
+Cc: Sebastian Wick <sebastian.wick@redhat.com>
+Cc: Vitaly.Prosyak@amd.com
+Cc: Uma Shankar <uma.shankar@intel.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Joshua Ashton <joshua@froggi.es>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: amd-gfx@lists.freedesktop.org
+Reviewed-By: Joshua Ashton <joshua@froggi.es>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentland@amd.com
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From e5eef23e267c72521d81f23f7f82d1f523d4a253 Mon Sep 17 00:00:00 2001
+From: Harry Wentland <harry.wentland@amd.com>
+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 <harry.wentland@amd.com>
+
+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 <harry.wentland@amd.com>
+Cc: Pekka Paalanen <ppaalanen@gmail.com>
+Cc: Sebastian Wick <sebastian.wick@redhat.com>
+Cc: Vitaly.Prosyak@amd.com
+Cc: Uma Shankar <uma.shankar@intel.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Joshua Ashton <joshua@froggi.es>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: amd-gfx@lists.freedesktop.org
+Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
+Reviewed-By: Joshua Ashton <joshua@froggi.es>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentland@amd.com
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 8f121dfb15f7b4ab345992ce96003eb63fd608f4 Mon Sep 17 00:00:00 2001
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+Date: Sun, 5 Mar 2023 21:44:55 +0800
+Subject: erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms
+
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+
+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: <stable@vger.kernel.org> # 5.16+
+Reviewed-by: Yue Hu <huyue2@coolpad.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20230305134455.88236-1-hsiangkao@linux.alibaba.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From c993799baf9c5861f8df91beb80e1611b12efcbd Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <djwong@kernel.org>
+Date: Thu, 16 Feb 2023 10:55:48 -0800
+Subject: ext4: fix another off-by-one fsmap error on 1k block filesystems
+
+From: Darrick J. Wong <djwong@kernel.org>
+
+commit c993799baf9c5861f8df91beb80e1611b12efcbd upstream.
+
+Apparently syzbot figured out that issuing this FSMAP call:
+
+struct fsmap_head cmd = {
+ .fmh_count = ...;
+ .fmh_keys = {
+ { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
+ { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
+ },
+...
+};
+ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
+
+Produces this crash if the underlying filesystem is a 1k-block ext4
+filesystem:
+
+kernel BUG at fs/ext4/ext4.h:3331!
+invalid opcode: 0000 [#1] PREEMPT SMP
+CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
+RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
+RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
+RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
+RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
+RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
+R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
+R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
+FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
+Call Trace:
+ <TASK>
+ ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
+ ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
+ ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
+ ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
+ __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
+ __x64_sys_ioctl+0x82/0xa0
+ do_syscall_64+0x2b/0x80
+ entry_SYSCALL_64_after_hwframe+0x46/0xb0
+RIP: 0033:0x7fdf20558aff
+RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff
+RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003
+RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010
+R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000
+
+For GETFSMAP calls, the caller selects a physical block device by
+writing its block number into fsmap_head.fmh_keys[01].fmr_device.
+To query mappings for a subrange of the device, the starting byte of the
+range is written to fsmap_head.fmh_keys[0].fmr_physical and the last
+byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.
+
+IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd
+set the inputs as follows:
+
+ fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},
+ fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},
+
+Which would return you whatever is mapped in the 12 bytes starting at
+physical offset 3.
+
+The crash is due to insufficient range validation of keys[1] in
+ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of
+the filesystem, which means that s_first_data_block is nonzero.
+ext4_get_group_no_and_offset subtracts this quantity from the blocknr
+argument before cracking it into a group number and a block number
+within a group. IOWs, block group 0 spans blocks 1-8192 (1-based)
+instead of 0-8191 (0-based) like what happens with larger blocksizes.
+
+The net result of this encoding is that blocknr < s_first_data_block is
+not a valid input to this function. The end_fsb variable is set from
+the keys that are copied from userspace, which means that in the above
+example, its value is zero. That leads to an underflow here:
+
+ blocknr = blocknr - le32_to_cpu(es->s_first_data_block);
+
+The division then operates on -1:
+
+ offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >>
+ EXT4_SB(sb)->s_cluster_bits;
+
+Leaving an impossibly large group number (2^32-1) in blocknr.
+ext4_getfsmap_check_keys checked that keys[0].fmr_physical and
+keys[1].fmr_physical are in increasing order, but
+ext4_getfsmap_datadev adjusts keys[0].fmr_physical to be at least
+s_first_data_block. This implies that we have to check it again after
+the adjustment, which is the piece that I forgot.
+
+Reported-by: syzbot+6be2b977c89f79b6b153@syzkaller.appspotmail.com
+Fixes: 4a4956249dac ("ext4: fix off-by-one fsmap error on 1k block filesystems")
+Link: https://syzkaller.appspot.com/bug?id=79d5768e9bfe362911ac1a5057a36fc6b5c30002
+Cc: stable@vger.kernel.org
+Signed-off-by: Darrick J. Wong <djwong@kernel.org>
+Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnolia
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/fsmap.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/ext4/fsmap.c
++++ b/fs/ext4/fsmap.c
+@@ -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;
+
--- /dev/null
+From ffec85d53d0f39ee4680a2cf0795255e000e1feb Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 2 Feb 2023 16:55:03 -0800
+Subject: ext4: fix cgroup writeback accounting with fs-layer encryption
+
+From: Eric Biggers <ebiggers@google.com>
+
+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) <willy@infradead.org>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Link: https://lore.kernel.org/r/20230203005503.141557-1-ebiggers@kernel.org
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e Mon Sep 17 00:00:00 2001
+From: Eric Whitney <enwlinux@gmail.com>
+Date: Fri, 10 Feb 2023 12:32:44 -0500
+Subject: ext4: fix RENAME_WHITEOUT handling for inline directories
+
+From: Eric Whitney <enwlinux@gmail.com>
+
+commit c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e upstream.
+
+A significant number of xfstests can cause ext4 to log one or more
+warning messages when they are run on a test file system where the
+inline_data feature has been enabled. An example:
+
+"EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode
+ #16385: comm fsstress: No space for directory leaf checksum. Please
+run e2fsck -D."
+
+The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068,
+070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585,
+589, 626, 631, and 650.
+
+In this situation, the warning message indicates a bug in the code that
+performs the RENAME_WHITEOUT operation on a directory entry that has
+been stored inline. It doesn't detect that the directory is stored
+inline, and incorrectly attempts to compute a dirent block checksum on
+the whiteout inode when creating it. This attempt fails as a result
+of the integrity checking in get_dirent_tail (usually due to a failure
+to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message
+is then emitted.
+
+Fix this by simply collecting the inlined data state at the time the
+search for the source directory entry is performed. Existing code
+handles the rest, and this is sufficient to eliminate all spurious
+warning messages produced by the tests above. Go one step further
+and do the same in the code that resets the source directory entry in
+the event of failure. The inlined state should be present in the
+"old" struct, but given the possibility of a race there's no harm
+in taking a conservative approach and getting that information again
+since the directory entry is being reread anyway.
+
+Fixes: b7ff91fd030d ("ext4: find old entry again if failed to rename whiteout")
+Cc: stable@kernel.org
+Signed-off-by: Eric Whitney <enwlinux@gmail.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/namei.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/fs/ext4/namei.c
++++ b/fs/ext4/namei.c
+@@ -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);
+ /*
--- /dev/null
+From 2b96b4a5d9443ca4cad58b0040be455803c05a42 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Tue, 7 Mar 2023 09:52:53 +0800
+Subject: ext4: fix WARNING in ext4_update_inline_data
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit 2b96b4a5d9443ca4cad58b0040be455803c05a42 upstream.
+
+Syzbot found the following issue:
+EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
+fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
+fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
+------------[ cut here ]------------
+WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
+Modules linked in:
+CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
+RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
+RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
+RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
+RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
+RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
+R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
+R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
+FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ __alloc_pages_node include/linux/gfp.h:237 [inline]
+ alloc_pages_node include/linux/gfp.h:260 [inline]
+ __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
+ __do_kmalloc_node mm/slab_common.c:956 [inline]
+ __kmalloc+0xfe/0x190 mm/slab_common.c:981
+ kmalloc include/linux/slab.h:584 [inline]
+ kzalloc include/linux/slab.h:720 [inline]
+ ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
+ ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
+ ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
+ ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
+ ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
+ ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
+ lookup_open fs/namei.c:3413 [inline]
+ open_last_lookups fs/namei.c:3481 [inline]
+ path_openat+0x12ac/0x2dd0 fs/namei.c:3711
+ do_filp_open+0x264/0x4f0 fs/namei.c:3741
+ do_sys_openat2+0x124/0x4e0 fs/open.c:1310
+ do_sys_open fs/open.c:1326 [inline]
+ __do_sys_openat fs/open.c:1342 [inline]
+ __se_sys_openat fs/open.c:1337 [inline]
+ __x64_sys_openat+0x243/0x290 fs/open.c:1337
+ do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+Above issue happens as follows:
+ext4_iget
+ ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
+ext4_try_add_inline_entry
+ __ext4_mark_inode_dirty
+ ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
+ ext4_xattr_shift_entries
+ ->after shift i_inline_off is incorrect, actually is change to 176
+ext4_try_add_inline_entry
+ ext4_update_inline_dir
+ get_max_inline_xattr_value_size
+ if (EXT4_I(inode)->i_inline_off)
+ entry = (struct ext4_xattr_entry *)((void *)raw_inode +
+ EXT4_I(inode)->i_inline_off);
+ free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
+ ->As entry is incorrect, then 'free' may be negative
+ ext4_update_inline_data
+ value = kzalloc(len, GFP_NOFS);
+ -> len is unsigned int, maybe very large, then trigger warning when
+ 'kzalloc()'
+
+To resolve the above issue we need to update 'i_inline_off' after
+'ext4_xattr_shift_entries()'. We do not need to set
+EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
+already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA
+when it is needed may trigger a BUG_ON in ext4_writepages().
+
+Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com
+Cc: stable@kernel.org
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/xattr.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/ext4/xattr.c
++++ b/fs/ext4/xattr.c
+@@ -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.",
--- /dev/null
+From 1dcdce5919115a471bf4921a57f20050c545a236 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Tue, 7 Mar 2023 09:52:52 +0800
+Subject: ext4: move where set the MAY_INLINE_DATA flag is set
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit 1dcdce5919115a471bf4921a57f20050c545a236 upstream.
+
+The only caller of ext4_find_inline_data_nolock() that needs setting of
+EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode(). In
+ext4_write_inline_data_end() we just need to update inode->i_inline_off.
+Since we are going to add one more caller that does not need to set
+EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA
+out to ext4_iget_extra_inode().
+
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Cc: stable@kernel.org
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inline.c | 1 -
+ fs/ext4/inode.c | 7 ++++++-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/inline.c
++++ b/fs/ext4/inline.c
+@@ -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;
--- /dev/null
+From f5361da1e60d54ec81346aee8e3d8baf1be0b762 Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+Date: Wed, 8 Mar 2023 11:26:43 +0800
+Subject: ext4: zero i_disksize when initializing the bootloader inode
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+commit f5361da1e60d54ec81346aee8e3d8baf1be0b762 upstream.
+
+If the boot loader inode has never been used before, the
+EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
+i_size to 0. However, if the "never before used" boot loader has a
+non-zero i_size, then i_disksize will be non-zero, and the
+inconsistency between i_size and i_disksize can trigger a kernel
+warning:
+
+ WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
+ CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
+ RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
+ Call Trace:
+ vfs_write+0x3b1/0x5c0
+ ksys_write+0x77/0x160
+ __x64_sys_write+0x22/0x30
+ do_syscall_64+0x39/0x80
+
+Reproducer:
+ 1. create corrupted image and mount it:
+ mke2fs -t ext4 /tmp/foo.img 200
+ debugfs -wR "sif <5> size 25700" /tmp/foo.img
+ mount -t ext4 /tmp/foo.img /mnt
+ cd /mnt
+ echo 123 > file
+ 2. Run the reproducer program:
+ posix_memalign(&buf, 1024, 1024)
+ fd = open("file", O_RDWR | O_DIRECT);
+ ioctl(fd, EXT4_IOC_SWAP_BOOT);
+ write(fd, buf, 1024);
+
+Fix this by setting i_disksize as well as i_size to zero when
+initiaizing the boot loader inode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
+Cc: stable@kernel.org
+Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/ioctl.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ext4/ioctl.c
++++ b/fs/ext4/ioctl.c
+@@ -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);
--- /dev/null
+From a402f1e35313fc7ce2ca60f543c4402c2c7c3544 Mon Sep 17 00:00:00 2001
+From: Tobias Klauser <tklauser@distanz.ch>
+Date: Wed, 8 Mar 2023 11:51:26 +0100
+Subject: fork: allow CLONE_NEWTIME in clone3 flags
+
+From: Tobias Klauser <tklauser@distanz.ch>
+
+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 <avagin@openvz.org>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
+Reviewed-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)) ==
--- /dev/null
+From 609d54441493c99f21c1823dfd66fa7f4c512ff4 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 6 Mar 2023 13:54:50 -0500
+Subject: fs: prevent out-of-bounds array speculation when closing a file descriptor
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 609d54441493c99f21c1823dfd66fa7f4c512ff4 upstream.
+
+Google-Bug-Id: 114199369
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/file.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/file.c
++++ b/fs/file.c
+@@ -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);
--- /dev/null
+From b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc Mon Sep 17 00:00:00 2001
+From: Lee Jones <lee@kernel.org>
+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 <lee@kernel.org>
+
+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 <lee@kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 1c5d4221240a233df2440fe75c881465cdf8da07 Mon Sep 17 00:00:00 2001
+From: Lee Jones <lee@kernel.org>
+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 <lee@kernel.org>
+
+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 <lee@kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 03b3d6be73e81ddb7c2930d942cdd17f4cfd5ba5 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 8 Mar 2023 09:26:13 -0700
+Subject: io_uring/uring_cmd: ensure that device supports IOPOLL
+
+From: Jens Axboe <axboe@kernel.dk>
+
+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 <joshi.k@samsung.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From ce9f1c05d2edfa6cdf2c1a510495d333e11810a8 Mon Sep 17 00:00:00 2001
+From: Namhyung Kim <namhyung@kernel.org>
+Date: Wed, 22 Feb 2023 23:01:55 -0800
+Subject: perf inject: Fix --buildid-all not to eat up MMAP2
+
+From: Namhyung Kim <namhyung@kernel.org>
+
+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 <namhyung@kernel.org>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230223070155.54251-1-namhyung@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From e18048da9bc3f87acef4eb67a11b4fc55fe15424 Mon Sep 17 00:00:00 2001
+From: Palmer Dabbelt <palmer@rivosinc.com>
+Date: Thu, 23 Feb 2023 14:46:05 -0800
+Subject: RISC-V: Stop emitting attributes
+
+From: Palmer Dabbelt <palmer@rivosinc.com>
+
+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 <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/r/20230223224605.6995-1-palmer@rivosinc.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+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
--- /dev/null
+From 05cbcc415c9b8c8bc4f9a09f8e03610a89042f03 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 6 Mar 2023 16:35:11 +0100
+Subject: staging: rtl8723bs: Fix key-store index handling
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+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 <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20230306153512.162104-1-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From d17789edd6a8270c38459e592ee536a84c6202db Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 6 Mar 2023 16:35:12 +0100
+Subject: staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss()
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+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 <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20230306153512.162104-2-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From b0563468eeac88ebc70559d52a0b66efc37e4e9d Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Date: Tue, 7 Mar 2023 17:46:43 +0000
+Subject: x86/CPU/AMD: Disable XSAVES on AMD family 0x17
+
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+
+commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream.
+
+AMD Erratum 1386 is summarised as:
+
+ XSAVES Instruction May Fail to Save XMM Registers to the Provided
+ State Save Area
+
+This piece of accidental chronomancy causes the %xmm registers to
+occasionally reset back to an older value.
+
+Ignore the XSAVES feature on all AMD Zen1/2 hardware. The XSAVEC
+instruction (which works fine) is equivalent on affected parts.
+
+ [ bp: Typos, move it into the F17h-specific function. ]
+
+Reported-by: Tavis Ormandy <taviso@gmail.com>
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/amd.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
