From: Greg Kroah-Hartman Date: Mon, 10 Feb 2025 13:23:07 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v6.6.77~29 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5a4ced0344a7c3fc906c38bef623ada27b104aaa;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch cpufreq-s3c64xx-fix-compilation-warning.patch drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch drm-modeset-handle-tiled-displays-in-pan_display_atomic.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 leds-lp8860-write-full-eeprom-not-only-half-of-it.patch m68k-vga-fix-i-o-defines.patch s390-futex-fix-futex_op_andn-implementation.patch --- diff --git a/queue-5.10/arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch b/queue-5.10/arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch new file mode 100644 index 0000000000..858274ee13 --- /dev/null +++ b/queue-5.10/arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch @@ -0,0 +1,60 @@ +From 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 Mon Sep 17 00:00:00 2001 +From: Jakob Unterwurzacher +Date: Fri, 13 Dec 2024 10:54:58 +0100 +Subject: arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma + +From: Jakob Unterwurzacher + +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 +Tested-by: Quentin Schulz # Puma v2.1 and v2.3 with KSZ9031 +Signed-off-by: Jakob Unterwurzacher +Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -176,7 +176,7 @@ + snps,reset-active-low; + snps,reset-delays-us = <0 10000 50000>; + tx_delay = <0x10>; +- rx_delay = <0x10>; ++ rx_delay = <0x23>; + status = "okay"; + }; + diff --git a/queue-5.10/binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch b/queue-5.10/binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch new file mode 100644 index 0000000000..36327d83ee --- /dev/null +++ b/queue-5.10/binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch @@ -0,0 +1,38 @@ +From 55cf2f4b945f6a6416cc2524ba740b83cc9af25a Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Wed, 4 Dec 2024 15:07:15 +0300 +Subject: binfmt_flat: Fix integer overflow bug on 32 bit systems + +From: Dan Carpenter + +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 +Acked-by: Nicolas Pitre +Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.mountain +Signed-off-by: Kees Cook +Signed-off-by: Greg Kroah-Hartman +--- + fs/binfmt_flat.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/binfmt_flat.c ++++ b/fs/binfmt_flat.c +@@ -534,7 +534,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; diff --git a/queue-5.10/bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch b/queue-5.10/bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch new file mode 100644 index 0000000000..e6b190a61b --- /dev/null +++ b/queue-5.10/bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch @@ -0,0 +1,48 @@ +From 5c61419e02033eaf01733d66e2fcd4044808f482 Mon Sep 17 00:00:00 2001 +From: Fedor Pchelkin +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 + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.10/bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch b/queue-5.10/bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch new file mode 100644 index 0000000000..1f34ab712f --- /dev/null +++ b/queue-5.10/bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch @@ -0,0 +1,46 @@ +From 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 Mon Sep 17 00:00:00 2001 +From: Fedor Pchelkin +Date: Wed, 18 Dec 2024 00:19:59 +0300 +Subject: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc + +From: Fedor Pchelkin + +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 +Reviewed-by: Kuniyuki Iwashima +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1864,7 +1864,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; + } + diff --git a/queue-5.10/cpufreq-s3c64xx-fix-compilation-warning.patch b/queue-5.10/cpufreq-s3c64xx-fix-compilation-warning.patch new file mode 100644 index 0000000000..08f8b3f8ec --- /dev/null +++ b/queue-5.10/cpufreq-s3c64xx-fix-compilation-warning.patch @@ -0,0 +1,70 @@ +From 43855ac61483cb914f060851535ea753c094b3e0 Mon Sep 17 00:00:00 2001 +From: Viresh Kumar +Date: Wed, 22 Jan 2025 11:36:16 +0530 +Subject: cpufreq: s3c64xx: Fix compilation warning + +From: Viresh Kumar + +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 +Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/ +Cc: 5.4+ # v5.4+ +Signed-off-by: Viresh Kumar +Link: https://patch.msgid.link/236b227e929e5adc04d1e9e7af6845a46c8e9432.1737525916.git.viresh.kumar@linaro.org +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch b/queue-5.10/drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch new file mode 100644 index 0000000000..871fa082a6 --- /dev/null +++ b/queue-5.10/drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch @@ -0,0 +1,36 @@ +From 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 Mon Sep 17 00:00:00 2001 +From: Haoxiang Li +Date: Thu, 19 Dec 2024 17:02:56 +0800 +Subject: drm/komeda: Add check for komeda_get_layer_fourcc_list() + +From: Haoxiang Li + +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 +Acked-by: Liviu Dudau +Link: https://lore.kernel.org/r/20241219090256.146424-1-haoxiang_li2024@163.com +Signed-off-by: Liviu Dudau +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/drm-modeset-handle-tiled-displays-in-pan_display_atomic.patch b/queue-5.10/drm-modeset-handle-tiled-displays-in-pan_display_atomic.patch new file mode 100644 index 0000000000..460ff1ba03 --- /dev/null +++ b/queue-5.10/drm-modeset-handle-tiled-displays-in-pan_display_atomic.patch @@ -0,0 +1,66 @@ +From f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 Mon Sep 17 00:00:00 2001 +From: Maarten Lankhorst +Date: Thu, 16 Jan 2025 15:28:24 +0100 +Subject: drm/modeset: Handle tiled displays in pan_display_atomic. + +From: Maarten Lankhorst + +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 +Link: https://patchwork.freedesktop.org/patch/msgid/20250116142825.3933-1-dev@lankhorst.se +Signed-off-by: Maarten Lankhorst +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1380,14 +1380,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); + } +@@ -1396,16 +1396,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; + } diff --git a/queue-5.10/kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch b/queue-5.10/kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch new file mode 100644 index 0000000000..04cd2bf1b5 --- /dev/null +++ b/queue-5.10/kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch @@ -0,0 +1,62 @@ +From 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 9 Oct 2024 08:04:50 -0700 +Subject: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() + +From: Sean Christopherson + +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 +Cc: Michal Luczaj +Reviewed-by: Pankaj Gupta +Acked-by: Will Deacon +Link: https://lore.kernel.org/r/20241009150455.1057573-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/kvm_host.h | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/include/linux/kvm_host.h ++++ b/include/linux/kvm_host.h +@@ -575,6 +575,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. */ diff --git a/queue-5.10/kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch b/queue-5.10/kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch new file mode 100644 index 0000000000..1c9b6d28ac --- /dev/null +++ b/queue-5.10/kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch @@ -0,0 +1,106 @@ +From 5f230f41fdd9e799f43a699348dc572bca7159aa Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +Date: Tue, 7 Jan 2025 16:43:41 +0100 +Subject: KVM: s390: vsie: fix some corner-cases when grabbing vsie pages + +From: David Hildenbrand + +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 +Reviewed-by: Claudio Imbrenda +Reviewed-by: Christoph Schlameuss +Tested-by: Christoph Schlameuss +Message-ID: <20250107154344.1003072-2-david@redhat.com> +Signed-off-by: Claudio Imbrenda +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1316,8 +1316,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); + } + +@@ -1347,15 +1353,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); +@@ -1448,7 +1459,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; diff --git a/queue-5.10/leds-lp8860-write-full-eeprom-not-only-half-of-it.patch b/queue-5.10/leds-lp8860-write-full-eeprom-not-only-half-of-it.patch new file mode 100644 index 0000000000..1ac4ce9c9f --- /dev/null +++ b/queue-5.10/leds-lp8860-write-full-eeprom-not-only-half-of-it.patch @@ -0,0 +1,34 @@ +From 0d2e820a86793595e2a776855d04701109e46663 Mon Sep 17 00:00:00 2001 +From: Alexander Sverdlin +Date: Thu, 14 Nov 2024 11:13:59 +0100 +Subject: leds: lp8860: Write full EEPROM, not only half of it + +From: Alexander Sverdlin + +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 +Link: https://lore.kernel.org/r/20241114101402.2562878-1-alexander.sverdlin@siemens.com +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/m68k-vga-fix-i-o-defines.patch b/queue-5.10/m68k-vga-fix-i-o-defines.patch new file mode 100644 index 0000000000..8180d27fe2 --- /dev/null +++ b/queue-5.10/m68k-vga-fix-i-o-defines.patch @@ -0,0 +1,83 @@ +From 53036937a101b5faeaf98e7438555fa854a1a844 Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 7 Jan 2025 10:58:56 +0100 +Subject: m68k: vga: Fix I/O defines + +From: Thomas Zimmermann + +commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream. + +Including m68k's 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 , 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 +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202501071629.DNEswlm8-lkp@intel.com/ +Fixes: 5c3f968712ce ("m68k/video: Create ") +Cc: Geert Uytterhoeven +Cc: linux-fbdev@vger.kernel.org +Cc: dri-devel@lists.freedesktop.org +Cc: Helge Deller +Cc: stable@vger.kernel.org # v3.5+ +Reviewed-by: Geert Uytterhoeven +Link: https://lore.kernel.org/20250107095912.130530-1-tzimmermann@suse.de +Signed-off-by: Geert Uytterhoeven +Signed-off-by: Greg Kroah-Hartman +--- + 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 ++#include + #include + + /* +@@ -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 */ diff --git a/queue-5.10/s390-futex-fix-futex_op_andn-implementation.patch b/queue-5.10/s390-futex-fix-futex_op_andn-implementation.patch new file mode 100644 index 0000000000..3220068f6a --- /dev/null +++ b/queue-5.10/s390-futex-fix-futex_op_andn-implementation.patch @@ -0,0 +1,40 @@ +From 26701574cee6777f867f89b4a5c667817e1ee0dd Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Tue, 7 Jan 2025 11:28:58 +0100 +Subject: s390/futex: Fix FUTEX_OP_ANDN implementation + +From: Heiko Carstens + +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 +Acked-by: Alexander Gordeev +Signed-off-by: Alexander Gordeev +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -45,7 +45,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", diff --git a/queue-5.10/series b/queue-5.10/series index 579816cd05..e483660200 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -176,3 +176,15 @@ x86-xen-fix-xen_hypercall_hvm-to-not-clobber-rbx.patch 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-komeda-add-check-for-komeda_get_layer_fourcc_list.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