--- /dev/null
+From 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 Mon Sep 17 00:00:00 2001
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+Date: Fri, 13 Dec 2024 10:54:58 +0100
+Subject: arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma
+
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+
+commit 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 upstream.
+
+During mass manufacturing, we noticed the mmc_rx_crc_error counter,
+as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
+above zero during nuttcp speedtests. Most of the time, this did not
+affect the achieved speed, but it prompted this investigation.
+
+Cycling through the rx_delay range on six boards (see table below) of
+various ages shows that there is a large good region from 0x12 to 0x35
+where we see zero crc errors on all tested boards.
+
+The old rx_delay value (0x10) seems to have always been on the edge for
+the KSZ9031RNX that is usually placed on Puma.
+
+Choose "rx_delay = 0x23" to put us smack in the middle of the good
+region. This works fine as well with the KSZ9131RNX PHY that was used
+for a small number of boards during the COVID chip shortages.
+
+ Board S/N PHY rx_delay good region
+ --------- --- --------------------
+ Puma TT0069903 KSZ9031RNX 0x11 0x35
+ Puma TT0157733 KSZ9031RNX 0x11 0x35
+ Puma TT0681551 KSZ9031RNX 0x12 0x37
+ Puma TT0681156 KSZ9031RNX 0x10 0x38
+ Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
+ Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
+
+ Intersection of good regions = 0x12 0x35
+ Middle of good region = 0x23
+
+Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
+Cc: stable@vger.kernel.org
+Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
+Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # Puma v2.1 and v2.3 with KSZ9031
+Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
+Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+@@ -136,7 +136,7 @@
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x10>;
+- rx_delay = <0x10>;
++ rx_delay = <0x23>;
+ status = "okay";
+ };
+
--- /dev/null
+From 55cf2f4b945f6a6416cc2524ba740b83cc9af25a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Wed, 4 Dec 2024 15:07:15 +0300
+Subject: binfmt_flat: Fix integer overflow bug on 32 bit systems
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream.
+
+Most of these sizes and counts are capped at 256MB so the math doesn't
+result in an integer overflow. The "relocs" count needs to be checked
+as well. Otherwise on 32bit systems the calculation of "full_data"
+could be wrong.
+
+ full_data = data_len + relocs * sizeof(unsigned long);
+
+Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Acked-by: Nicolas Pitre <npitre@baylibre.com>
+Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.mountain
+Signed-off-by: Kees Cook <kees@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_flat.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/binfmt_flat.c
++++ b/fs/binfmt_flat.c
+@@ -542,7 +542,7 @@ static int load_flat_file(struct linux_b
+ * 28 bits (256 MB) is way more than reasonable in this case.
+ * If some top bits are set we have probable binary corruption.
+ */
+- if ((text_len | data_len | bss_len | stack_len | full_data) >> 28) {
++ if ((text_len | data_len | bss_len | stack_len | relocs | full_data) >> 28) {
+ pr_err("bad header\n");
+ ret = -ENOEXEC;
+ goto err;
--- /dev/null
+From 5c61419e02033eaf01733d66e2fcd4044808f482 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 29 Jan 2025 00:08:14 +0300
+Subject: Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 5c61419e02033eaf01733d66e2fcd4044808f482 upstream.
+
+One of the possible ways to enable the input MTU auto-selection for L2CAP
+connections is supposed to be through passing a special "0" value for it
+as a socket option. Commit [1] added one of those into avdtp. However, it
+simply wouldn't work because the kernel still treats the specified value
+as invalid and denies the setting attempt. Recorded BlueZ logs include the
+following:
+
+ bluetoothd[496]: profiles/audio/avdtp.c:l2cap_connect() setsockopt(L2CAP_OPTIONS): Invalid argument (22)
+
+[1]: https://github.com/bluez/bluez/commit/ae5be371a9f53fed33d2b34748a95a5498fd4b77
+
+Found by Linux Verification Center (linuxtesting.org).
+
+Fixes: 4b6e228e297b ("Bluetooth: Auto tune if input MTU is set to 0")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/l2cap_sock.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -727,12 +727,12 @@ static bool l2cap_valid_mtu(struct l2cap
+ {
+ switch (chan->scid) {
+ case L2CAP_CID_ATT:
+- if (mtu < L2CAP_LE_MIN_MTU)
++ if (mtu && mtu < L2CAP_LE_MIN_MTU)
+ return false;
+ break;
+
+ default:
+- if (mtu < L2CAP_DEFAULT_MIN_MTU)
++ if (mtu && mtu < L2CAP_DEFAULT_MIN_MTU)
+ return false;
+ }
+
--- /dev/null
+From 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 18 Dec 2024 00:19:59 +0300
+Subject: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 upstream.
+
+A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
+from l2cap_sock_new_connection_cb() and the error handling paths should
+also be aware of it.
+
+Seemingly a more elegant solution would be to swap bt_sock_alloc() and
+l2cap_chan_create() calls since they are not interdependent to that moment
+but then l2cap_chan_create() adds the soon to be deallocated and still
+dummy-initialized channel to the global list accessible by many L2CAP
+paths. The channel would be removed from the list in short period of time
+but be a bit more straight-forward here and just check for NULL instead of
+changing the order of function calls.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE static
+analysis tool.
+
+Fixes: 7c4f78cdb8e7 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/l2cap_sock.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -1876,7 +1876,8 @@ static struct sock *l2cap_sock_alloc(str
+ chan = l2cap_chan_create();
+ if (!chan) {
+ sk_free(sk);
+- sock->sk = NULL;
++ if (sock)
++ sock->sk = NULL;
+ return NULL;
+ }
+
--- /dev/null
+From 43855ac61483cb914f060851535ea753c094b3e0 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Wed, 22 Jan 2025 11:36:16 +0530
+Subject: cpufreq: s3c64xx: Fix compilation warning
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit 43855ac61483cb914f060851535ea753c094b3e0 upstream.
+
+The driver generates following warning when regulator support isn't
+enabled in the kernel. Fix it.
+
+ drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target':
+>> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable]
+ 55 | unsigned int old_freq, new_freq;
+ | ^~~~~~~~
+>> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable]
+ 54 | struct s3c64xx_dvfs *dvfs;
+ | ^~~~
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/
+Cc: 5.4+ <stable@vger.kernel.org> # v5.4+
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Link: https://patch.msgid.link/236b227e929e5adc04d1e9e7af6845a46c8e9432.1737525916.git.viresh.kumar@linaro.org
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/s3c64xx-cpufreq.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/cpufreq/s3c64xx-cpufreq.c
++++ b/drivers/cpufreq/s3c64xx-cpufreq.c
+@@ -24,6 +24,7 @@ struct s3c64xx_dvfs {
+ unsigned int vddarm_max;
+ };
+
++#ifdef CONFIG_REGULATOR
+ static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = {
+ [0] = { 1000000, 1150000 },
+ [1] = { 1050000, 1150000 },
+@@ -31,6 +32,7 @@ static struct s3c64xx_dvfs s3c64xx_dvfs_
+ [3] = { 1200000, 1350000 },
+ [4] = { 1300000, 1350000 },
+ };
++#endif
+
+ static struct cpufreq_frequency_table s3c64xx_freq_table[] = {
+ { 0, 0, 66000 },
+@@ -51,15 +53,16 @@ static struct cpufreq_frequency_table s3
+ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
+ unsigned int index)
+ {
+- struct s3c64xx_dvfs *dvfs;
+- unsigned int old_freq, new_freq;
++ unsigned int new_freq = s3c64xx_freq_table[index].frequency;
+ int ret;
+
++#ifdef CONFIG_REGULATOR
++ struct s3c64xx_dvfs *dvfs;
++ unsigned int old_freq;
++
+ old_freq = clk_get_rate(policy->clk) / 1000;
+- new_freq = s3c64xx_freq_table[index].frequency;
+ dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data];
+
+-#ifdef CONFIG_REGULATOR
+ if (vddarm && new_freq > old_freq) {
+ ret = regulator_set_voltage(vddarm,
+ dvfs->vddarm_min,
--- /dev/null
+From 819bf6662b93a5a8b0c396d2c7e7fab6264c9808 Mon Sep 17 00:00:00 2001
+From: Lijo Lazar <lijo.lazar@amd.com>
+Date: Wed, 22 Jan 2025 09:12:41 +0530
+Subject: drm/amd/pm: Mark MM activity as unsupported
+
+From: Lijo Lazar <lijo.lazar@amd.com>
+
+commit 819bf6662b93a5a8b0c396d2c7e7fab6264c9808 upstream.
+
+Aldebaran doesn't support querying MM activity percentage. Keep the
+field as 0xFFs to mark it as unsupported.
+
+Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
+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/pm/swsmu/smu13/aldebaran_ppt.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+@@ -1711,7 +1711,6 @@ static ssize_t aldebaran_get_gpu_metrics
+
+ gpu_metrics->average_gfx_activity = metrics.AverageGfxActivity;
+ gpu_metrics->average_umc_activity = metrics.AverageUclkActivity;
+- gpu_metrics->average_mm_activity = 0;
+
+ /* Valid power data is available only from primary die */
+ if (aldebaran_is_primary(smu)) {
--- /dev/null
+From c7b49506b3ba7a62335e6f666a43f67d5cd9fd1e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 18 Dec 2024 19:36:47 +0200
+Subject: drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit c7b49506b3ba7a62335e6f666a43f67d5cd9fd1e upstream.
+
+I'm seeing underruns with these 64bpp YUV formats on TGL.
+
+The weird details:
+- only happens on pipe B/C/D SDR planes, pipe A SDR planes
+ seem fine, as do all HDR planes
+- somehow CDCLK related, higher CDCLK allows for bigger plane
+ with these formats without underruns. With 300MHz CDCLK I
+ can only go up to 1200 pixels wide or so, with 650MHz even
+ a 3840 pixel wide plane was OK
+- ICL and ADL so far appear unaffected
+
+So not really sure what's the deal with this, but bspec does
+state "64-bit formats supported only on the HDR planes" so
+let's just drop these formats from the SDR planes. We already
+disallow 64bpp RGB formats.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20241218173650.19782-2-ville.syrjala@linux.intel.com
+Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
+(cherry picked from commit 35e1aacfe536d6e8d8d440cd7155366da2541ad4)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
++++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
+@@ -98,8 +98,6 @@ static const u32 icl_sdr_y_plane_formats
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_XYUV8888,
+ DRM_FORMAT_XVYU2101010,
+- DRM_FORMAT_XVYU12_16161616,
+- DRM_FORMAT_XVYU16161616,
+ };
+
+ static const u32 icl_sdr_uv_plane_formats[] = {
+@@ -126,8 +124,6 @@ static const u32 icl_sdr_uv_plane_format
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_XYUV8888,
+ DRM_FORMAT_XVYU2101010,
+- DRM_FORMAT_XVYU12_16161616,
+- DRM_FORMAT_XVYU16161616,
+ };
+
+ static const u32 icl_hdr_plane_formats[] = {
--- /dev/null
+From 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <haoxiang_li2024@163.com>
+Date: Thu, 19 Dec 2024 17:02:56 +0800
+Subject: drm/komeda: Add check for komeda_get_layer_fourcc_list()
+
+From: Haoxiang Li <haoxiang_li2024@163.com>
+
+commit 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 upstream.
+
+Add check for the return value of komeda_get_layer_fourcc_list()
+to catch the potential exception.
+
+Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
+Acked-by: Liviu Dudau <liviu.dudau@arm.com>
+Link: https://lore.kernel.org/r/20241219090256.146424-1-haoxiang_li2024@163.com
+Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
++++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+@@ -160,6 +160,10 @@ static int komeda_wb_connector_add(struc
+ formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
+ kwb_conn->wb_layer->layer_type,
+ &n_formats);
++ if (!formats) {
++ kfree(kwb_conn);
++ return -ENOMEM;
++ }
+
+ err = drm_writeback_connector_init(&kms->base, wb_conn,
+ &komeda_wb_connector_funcs,
--- /dev/null
+From f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 Mon Sep 17 00:00:00 2001
+From: Maarten Lankhorst <dev@lankhorst.se>
+Date: Thu, 16 Jan 2025 15:28:24 +0100
+Subject: drm/modeset: Handle tiled displays in pan_display_atomic.
+
+From: Maarten Lankhorst <dev@lankhorst.se>
+
+commit f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 upstream.
+
+Tiled displays have a different x/y offset to begin with. Instead of
+attempting to remember this, just apply a delta instead.
+
+This fixes the first tile being duplicated on other tiles when vt
+switching.
+
+Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250116142825.3933-1-dev@lankhorst.se
+Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_fb_helper.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -1407,14 +1407,14 @@ int drm_fb_helper_set_par(struct fb_info
+ }
+ EXPORT_SYMBOL(drm_fb_helper_set_par);
+
+-static void pan_set(struct drm_fb_helper *fb_helper, int x, int y)
++static void pan_set(struct drm_fb_helper *fb_helper, int dx, int dy)
+ {
+ struct drm_mode_set *mode_set;
+
+ mutex_lock(&fb_helper->client.modeset_mutex);
+ drm_client_for_each_modeset(mode_set, &fb_helper->client) {
+- mode_set->x = x;
+- mode_set->y = y;
++ mode_set->x += dx;
++ mode_set->y += dy;
+ }
+ mutex_unlock(&fb_helper->client.modeset_mutex);
+ }
+@@ -1423,16 +1423,18 @@ static int pan_display_atomic(struct fb_
+ struct fb_info *info)
+ {
+ struct drm_fb_helper *fb_helper = info->par;
+- int ret;
++ int ret, dx, dy;
+
+- pan_set(fb_helper, var->xoffset, var->yoffset);
++ dx = var->xoffset - info->var.xoffset;
++ dy = var->yoffset - info->var.yoffset;
++ pan_set(fb_helper, dx, dy);
+
+ ret = drm_client_modeset_commit_locked(&fb_helper->client);
+ if (!ret) {
+ info->var.xoffset = var->xoffset;
+ info->var.yoffset = var->yoffset;
+ } else
+- pan_set(fb_helper, info->var.xoffset, info->var.yoffset);
++ pan_set(fb_helper, -dx, -dy);
+
+ return ret;
+ }
--- /dev/null
+From 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 9 Oct 2024 08:04:50 -0700
+Subject: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 upstream.
+
+Explicitly verify the target vCPU is fully online _prior_ to clamping the
+index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
+generate '0', i.e. KVM will return vCPU0 instead of NULL.
+
+In practice, the bug is unlikely to cause problems, as it will only come
+into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
+send interrupts to vCPU0 instead of dropping them on the floor.
+
+However, returning vCPU0 when it shouldn't exist per online_vcpus is
+problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
+to insert into the xarray before publishing the vCPU to userspace (see
+commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
+i.e. before vCPU creation is guaranteed to succeed.
+
+As a result, incorrectly providing access to vCPU0 will trigger a
+use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
+bails out of vCPU creation due to an error and frees vCPU0. Commit
+afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
+in doing so introduced an unsolvable teardown conundrum. Preventing
+accesses to vCPU0 before it's fully online will allow reverting commit
+afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
+
+Fixes: 1d487e9bf8ba ("KVM: fix spectrev1 gadgets")
+Cc: stable@vger.kernel.org
+Cc: Will Deacon <will@kernel.org>
+Cc: Michal Luczaj <mhal@rbox.co>
+Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241009150455.1057573-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/kvm_host.h | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/include/linux/kvm_host.h
++++ b/include/linux/kvm_host.h
+@@ -796,6 +796,15 @@ static inline struct kvm_io_bus *kvm_get
+ static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
+ {
+ int num_vcpus = atomic_read(&kvm->online_vcpus);
++
++ /*
++ * Explicitly verify the target vCPU is online, as the anti-speculation
++ * logic only limits the CPU's ability to speculate, e.g. given a "bad"
++ * index, clamping the index to 0 would return vCPU0, not NULL.
++ */
++ if (i >= num_vcpus)
++ return NULL;
++
+ i = array_index_nospec(i, num_vcpus);
+
+ /* Pairs with smp_wmb() in kvm_vm_ioctl_create_vcpu. */
--- /dev/null
+From 5f230f41fdd9e799f43a699348dc572bca7159aa Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Tue, 7 Jan 2025 16:43:41 +0100
+Subject: KVM: s390: vsie: fix some corner-cases when grabbing vsie pages
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 5f230f41fdd9e799f43a699348dc572bca7159aa upstream.
+
+We try to reuse the same vsie page when re-executing the vsie with a
+given SCB address. The result is that we use the same shadow SCB --
+residing in the vsie page -- and can avoid flushing the TLB when
+re-running the vsie on a CPU.
+
+So, when we allocate a fresh vsie page, or when we reuse a vsie page for
+a different SCB address -- reusing the shadow SCB in different context --
+we set ihcpu=0xffff to trigger the flush.
+
+However, after we looked up the SCB address in the radix tree, but before
+we grabbed the vsie page by raising the refcount to 2, someone could reuse
+the vsie page for a different SCB address, adjusting page->index and the
+radix tree. In that case, we would be reusing the vsie page with a
+wrong page->index.
+
+Another corner case is that we might set the SCB address for a vsie
+page, but fail the insertion into the radix tree. Whoever would reuse
+that page would remove the corresponding radix tree entry -- which might
+now be a valid entry pointing at another page, resulting in the wrong
+vsie page getting removed from the radix tree.
+
+Let's handle such races better, by validating that the SCB address of a
+vsie page didn't change after we grabbed it (not reuse for a different
+SCB; the alternative would be performing another tree lookup), and by
+setting the SCB address to invalid until the insertion in the tree
+succeeded (SCB addresses are aligned to 512, so ULONG_MAX is invalid).
+
+These scenarios are rare, the effects a bit unclear, and these issues were
+only found by code inspection. Let's CC stable to be safe.
+
+Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Tested-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Message-ID: <20250107154344.1003072-2-david@redhat.com>
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kvm/vsie.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/arch/s390/kvm/vsie.c
++++ b/arch/s390/kvm/vsie.c
+@@ -1321,8 +1321,14 @@ static struct vsie_page *get_vsie_page(s
+ page = radix_tree_lookup(&kvm->arch.vsie.addr_to_page, addr >> 9);
+ rcu_read_unlock();
+ if (page) {
+- if (page_ref_inc_return(page) == 2)
+- return page_to_virt(page);
++ if (page_ref_inc_return(page) == 2) {
++ if (page->index == addr)
++ return page_to_virt(page);
++ /*
++ * We raced with someone reusing + putting this vsie
++ * page before we grabbed it.
++ */
++ }
+ page_ref_dec(page);
+ }
+
+@@ -1352,15 +1358,20 @@ static struct vsie_page *get_vsie_page(s
+ kvm->arch.vsie.next++;
+ kvm->arch.vsie.next %= nr_vcpus;
+ }
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ }
+- page->index = addr;
+- /* double use of the same address */
++ /* Mark it as invalid until it resides in the tree. */
++ page->index = ULONG_MAX;
++
++ /* Double use of the same address or allocation failure. */
+ if (radix_tree_insert(&kvm->arch.vsie.addr_to_page, addr >> 9, page)) {
+ page_ref_dec(page);
+ mutex_unlock(&kvm->arch.vsie.mutex);
+ return NULL;
+ }
++ page->index = addr;
+ mutex_unlock(&kvm->arch.vsie.mutex);
+
+ vsie_page = page_to_virt(page);
+@@ -1453,7 +1464,9 @@ void kvm_s390_vsie_destroy(struct kvm *k
+ vsie_page = page_to_virt(page);
+ release_gmap_shadow(vsie_page);
+ /* free the radix tree entry */
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ __free_page(page);
+ }
+ kvm->arch.vsie.page_count = 0;
--- /dev/null
+From 0d2e820a86793595e2a776855d04701109e46663 Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Date: Thu, 14 Nov 2024 11:13:59 +0100
+Subject: leds: lp8860: Write full EEPROM, not only half of it
+
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+
+commit 0d2e820a86793595e2a776855d04701109e46663 upstream.
+
+I struggle to explain dividing an ARRAY_SIZE() by the size of an element
+once again. As the latter equals to 2, only the half of EEPROM was ever
+written. Drop the unexplainable division and write full ARRAY_SIZE().
+
+Cc: stable@vger.kernel.org
+Fixes: 7a8685accb95 ("leds: lp8860: Introduce TI lp8860 4 channel LED driver")
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Link: https://lore.kernel.org/r/20241114101402.2562878-1-alexander.sverdlin@siemens.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/leds/leds-lp8860.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/leds/leds-lp8860.c
++++ b/drivers/leds/leds-lp8860.c
+@@ -267,7 +267,7 @@ static int lp8860_init(struct lp8860_led
+ goto out;
+ }
+
+- reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs) / sizeof(lp8860_eeprom_disp_regs[0]);
++ reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs);
+ for (i = 0; i < reg_count; i++) {
+ ret = regmap_write(led->eeprom_regmap,
+ lp8860_eeprom_disp_regs[i].reg,
--- /dev/null
+From 53036937a101b5faeaf98e7438555fa854a1a844 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 7 Jan 2025 10:58:56 +0100
+Subject: m68k: vga: Fix I/O defines
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream.
+
+Including m68k's <asm/raw_io.h> in vga.h on nommu platforms results
+in conflicting defines with io_no.h for various I/O macros from the
+__raw_read and __raw_write families. An example error is
+
+ In file included from arch/m68k/include/asm/vga.h:12,
+ from include/video/vga.h:22,
+ from include/linux/vgaarb.h:34,
+ from drivers/video/aperture.c:12:
+>> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined
+ 39 | #define __raw_readb in_8
+ |
+ In file included from arch/m68k/include/asm/io.h:6,
+ from include/linux/io.h:13,
+ from include/linux/irq.h:20,
+ from include/asm-generic/hardirq.h:17,
+ from ./arch/m68k/include/generated/asm/hardirq.h:1,
+ from include/linux/hardirq.h:11,
+ from include/linux/interrupt.h:11,
+ from include/linux/trace_recursion.h:5,
+ from include/linux/ftrace.h:10,
+ from include/linux/kprobes.h:28,
+ from include/linux/kgdb.h:19,
+ from include/linux/fb.h:6,
+ from drivers/video/aperture.c:5:
+ arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous definition
+ 16 | #define __raw_readb(addr) \
+ |
+
+Include <asm/io.h>, which avoids raw_io.h on nommu platforms.
+Also change the defined values of some of the read/write symbols in
+vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not
+generally available.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501071629.DNEswlm8-lkp@intel.com/
+Fixes: 5c3f968712ce ("m68k/video: Create <asm/vga.h>")
+Cc: Geert Uytterhoeven <geert@linux-m68k.org>
+Cc: linux-fbdev@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v3.5+
+Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Link: https://lore.kernel.org/20250107095912.130530-1-tzimmermann@suse.de
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/m68k/include/asm/vga.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/m68k/include/asm/vga.h
++++ b/arch/m68k/include/asm/vga.h
+@@ -9,7 +9,7 @@
+ */
+ #ifndef CONFIG_PCI
+
+-#include <asm/raw_io.h>
++#include <asm/io.h>
+ #include <asm/kmap.h>
+
+ /*
+@@ -29,9 +29,9 @@
+ #define inw_p(port) 0
+ #define outb_p(port, val) do { } while (0)
+ #define outw(port, val) do { } while (0)
+-#define readb raw_inb
+-#define writeb raw_outb
+-#define writew raw_outw
++#define readb __raw_readb
++#define writeb __raw_writeb
++#define writew __raw_writew
+
+ #endif /* CONFIG_PCI */
+ #endif /* _ASM_M68K_VGA_H */
--- /dev/null
+From 26701574cee6777f867f89b4a5c667817e1ee0dd Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Tue, 7 Jan 2025 11:28:58 +0100
+Subject: s390/futex: Fix FUTEX_OP_ANDN implementation
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit 26701574cee6777f867f89b4a5c667817e1ee0dd upstream.
+
+The futex operation FUTEX_OP_ANDN is supposed to implement
+
+*(int *)UADDR2 &= ~OPARG;
+
+The s390 implementation just implements an AND instead of ANDN.
+Add the missing bitwise not operation to oparg to fix this.
+
+This is broken since nearly 19 years, so it looks like user space is
+not making use of this operation.
+
+Fixes: 3363fbdd6fb4 ("[PATCH] s390: futex atomic operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/include/asm/futex.h
++++ b/arch/s390/include/asm/futex.h
+@@ -43,7 +43,7 @@ static inline int arch_futex_atomic_op_i
+ break;
+ case FUTEX_OP_ANDN:
+ __futex_atomic_op("lr %2,%1\nnr %2,%5\n",
+- ret, oldval, newval, uaddr, oparg);
++ ret, oldval, newval, uaddr, ~oparg);
+ break;
+ case FUTEX_OP_XOR:
+ __futex_atomic_op("lr %2,%1\nxr %2,%5\n",
x86-xen-add-frame_end-to-xen_hypercall_hvm.patch
netem-update-sch-q.qlen-before-qdisc_tree_reduce_bac.patch
tun-revert-fix-group-permission-check.patch
+cpufreq-s3c64xx-fix-compilation-warning.patch
+leds-lp8860-write-full-eeprom-not-only-half-of-it.patch
+drm-modeset-handle-tiled-displays-in-pan_display_atomic.patch
+s390-futex-fix-futex_op_andn-implementation.patch
+m68k-vga-fix-i-o-defines.patch
+binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch
+arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch
+kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch
+kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch
+drm-amd-pm-mark-mm-activity-as-unsupported.patch
+drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch
+drm-i915-drop-64bpp-yuv-formats-from-icl-sdr-planes.patch
+bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch
+bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
