--- /dev/null
+From 5497ffe305b2ea31ae62d4a311d7cabfb671f54a Mon Sep 17 00:00:00 2001
+From: Ondrej Jirman <megi@xff.cz>
+Date: Mon, 24 Nov 2025 19:47:03 -0800
+Subject: arm64: dts: rockchip: Fix voltage threshold for volume keys for Pinephone Pro
+
+From: Ondrej Jirman <megi@xff.cz>
+
+commit 5497ffe305b2ea31ae62d4a311d7cabfb671f54a upstream.
+
+Previously sometimes pressing the volume-down button would register as
+a volume-up button. Match the thresholds as shown in the Pinephone Pro
+schematic.
+
+Tests:
+
+~ $ evtest
+ // Mashed the volume down ~100 times with varying intensity
+ Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
+ Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
+ // Mashed the volume up ~100 times with varying intensity
+ Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
+ Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
+
+Fixes: d3150ed53580 ("arm64: dts: rockchip: Add support for volume keys to rk3399-pinephone-pro")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ondrej Jirman <megi@xff.cz>
+Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
+Reviewed-by: Pavel Machek <pavel@ucw.cz>
+Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-4-f9a10a0a50eb@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+@@ -40,13 +40,13 @@
+ button-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+- press-threshold-microvolt = <100000>;
++ press-threshold-microvolt = <2000>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+- press-threshold-microvolt = <600000>;
++ press-threshold-microvolt = <300000>;
+ };
+ };
+
--- /dev/null
+From 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 Mon Sep 17 00:00:00 2001
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+Date: Mon, 17 Nov 2025 18:47:43 -0300
+Subject: arm64: dts: rockchip: remove dangerous max-link-speed from helios64
+
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+
+commit 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 upstream.
+
+Shawn Lin from Rockchip strongly discourages attempts to use their
+RK3399 PCIe core at 5.0 GT/s speed, citing concerns about catastrophic
+failures that may happen. Even if the odds are low, drop from last user
+of this non-default property for the RK3399 platform, helios64 board
+dts.
+
+Fixes: 755fff528b1b ("arm64: dts: rockchip: add variables for pcie completion to helios64")
+Link: https://lore.kernel.org/all/e8524bf8-a90c-423f-8a58-9ef05a3db1dd@rock-chips.com/
+Cc: stable@vger.kernel.org
+Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
+Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
+Link: https://patch.msgid.link/43bb639c120f599106fca2deee6c6599b2692c5c.1763415706.git.geraldogabriel@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
+@@ -427,7 +427,6 @@
+
+ &pcie0 {
+ ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
+- max-link-speed = <2>;
+ num-lanes = <2>;
+ pinctrl-names = "default";
+ status = "okay";
--- /dev/null
+From 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Wed, 3 Dec 2025 16:24:38 +0000
+Subject: comedi: Fix getting range information for subdevices 16 to 255
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 upstream.
+
+The `COMEDI_RANGEINFO` ioctl does not work properly for subdevice
+indices above 15. Currently, the only in-tree COMEDI drivers that
+support more than 16 subdevices are the "8255" driver and the
+"comedi_bond" driver. Making the ioctl work for subdevice indices up to
+255 is achievable. It needs minor changes to the handling of the
+`COMEDI_RANGEINFO` and `COMEDI_CHANINFO` ioctls that should be mostly
+harmless to user-space, apart from making them less broken. Details
+follow...
+
+The `COMEDI_RANGEINFO` ioctl command gets the list of supported ranges
+(usually with units of volts or milliamps) for a COMEDI subdevice or
+channel. (Only some subdevices have per-channel range tables, indicated
+by the `SDF_RANGETYPE` flag in the subdevice information.) It uses a
+`range_type` value and a user-space pointer, both supplied by
+user-space, but the `range_type` value should match what was obtained
+using the `COMEDI_CHANINFO` ioctl (if the subdevice has per-channel
+range tables) or `COMEDI_SUBDINFO` ioctl (if the subdevice uses a
+single range table for all channels). Bits 15 to 0 of the `range_type`
+value contain the length of the range table, which is the only part that
+user-space should care about (so it can use a suitably sized buffer to
+fetch the range table). Bits 23 to 16 store the channel index, which is
+assumed to be no more than 255 if the subdevice has per-channel range
+tables, and is set to 0 if the subdevice has a single range table. For
+`range_type` values produced by the `COMEDI_SUBDINFO` ioctl, bits 31 to
+24 contain the subdevice index, which is assumed to be no more than 255.
+But for `range_type` values produced by the `COMEDI_CHANINFO` ioctl,
+bits 27 to 24 contain the subdevice index, which is assumed to be no
+more than 15, and bits 31 to 28 contain the COMEDI device's minor device
+number for some unknown reason lost in the mists of time. The
+`COMEDI_RANGEINFO` ioctl extract the length from bits 15 to 0 of the
+user-supplied `range_type` value, extracts the channel index from bits
+23 to 16 (only used if the subdevice has per-channel range tables),
+extracts the subdevice index from bits 27 to 24, and ignores bits 31 to
+28. So for subdevice indices 16 to 255, the `COMEDI_SUBDINFO` or
+`COMEDI_CHANINFO` ioctl will report a `range_type` value that doesn't
+work with the `COMEDI_RANGEINFO` ioctl. It will either get the range
+table for the subdevice index modulo 16, or will fail with `-EINVAL`.
+
+To fix this, always use bits 31 to 24 of the `range_type` value to hold
+the subdevice index (assumed to be no more than 255). This affects the
+`COMEDI_CHANINFO` and `COMEDI_RANGEINFO` ioctls. There should not be
+anything in user-space that depends on the old, broken usage, although
+it may now see different values in bits 31 to 28 of the `range_type`
+values reported by the `COMEDI_CHANINFO` ioctl for subdevices that have
+per-channel subdevices. User-space should not be trying to decode bits
+31 to 16 of the `range_type` values anyway.
+
+Fixes: ed9eccbe8970 ("Staging: add comedi core")
+Cc: stable@vger.kernel.org #5.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/comedi/comedi_fops.c | 2 +-
+ drivers/comedi/range.c | 2 +-
+ include/uapi/linux/comedi.h | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/comedi/comedi_fops.c
++++ b/drivers/comedi/comedi_fops.c
+@@ -1099,7 +1099,7 @@ static int do_chaninfo_ioctl(struct come
+ for (i = 0; i < s->n_chan; i++) {
+ int x;
+
+- x = (dev->minor << 28) | (it->subdev << 24) | (i << 16) |
++ x = (it->subdev << 24) | (i << 16) |
+ (s->range_table_list[i]->length);
+ if (put_user(x, it->rangelist + i))
+ return -EFAULT;
+--- a/drivers/comedi/range.c
++++ b/drivers/comedi/range.c
+@@ -52,7 +52,7 @@ int do_rangeinfo_ioctl(struct comedi_dev
+ const struct comedi_lrange *lr;
+ struct comedi_subdevice *s;
+
+- subd = (it->range_type >> 24) & 0xf;
++ subd = (it->range_type >> 24) & 0xff;
+ chan = (it->range_type >> 16) & 0xff;
+
+ if (!dev->attached)
+--- a/include/uapi/linux/comedi.h
++++ b/include/uapi/linux/comedi.h
+@@ -640,7 +640,7 @@ struct comedi_chaninfo {
+
+ /**
+ * struct comedi_rangeinfo - used to retrieve the range table for a channel
+- * @range_type: Encodes subdevice index (bits 27:24), channel index
++ * @range_type: Encodes subdevice index (bits 31:24), channel index
+ * (bits 23:16) and range table length (bits 15:0).
+ * @range_ptr: Pointer to array of @struct comedi_krange to be filled
+ * in with the range table for the channel or subdevice.
--- /dev/null
+From c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 Mon Sep 17 00:00:00 2001
+From: Francesco Lavra <flavra@baylibre.com>
+Date: Mon, 1 Dec 2025 11:00:10 +0100
+Subject: iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection
+
+From: Francesco Lavra <flavra@baylibre.com>
+
+commit c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 upstream.
+
+The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL
+event_spec field, indicating support for IIO events. However, event
+detection is not supported for all sensors, and if userspace tries to
+configure accelerometer wakeup events on a sensor device that does not
+support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL
+pointer when trying to write to the wakeup register.
+Define an additional struct iio_chan_spec array whose members have a NULL
+event_spec field, and use this array instead of st_lsm6dsx_acc_channels for
+sensors without event detection capability.
+
+Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events")
+Signed-off-by: Francesco Lavra <flavra@baylibre.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
+Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+@@ -84,6 +84,13 @@ static const struct iio_chan_spec st_lsm
+ IIO_CHAN_SOFT_TIMESTAMP(3),
+ };
+
++static const struct iio_chan_spec st_lsm6ds0_acc_channels[] = {
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x28, IIO_MOD_X, 0),
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2a, IIO_MOD_Y, 1),
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2c, IIO_MOD_Z, 2),
++ IIO_CHAN_SOFT_TIMESTAMP(3),
++};
++
+ static const struct iio_chan_spec st_lsm6dsx_gyro_channels[] = {
+ ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x22, IIO_MOD_X, 0),
+ ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x24, IIO_MOD_Y, 1),
+@@ -125,8 +132,8 @@ static const struct st_lsm6dsx_settings
+ },
+ .channels = {
+ [ST_LSM6DSX_ID_ACC] = {
+- .chan = st_lsm6dsx_acc_channels,
+- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels),
++ .chan = st_lsm6ds0_acc_channels,
++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels),
+ },
+ [ST_LSM6DSX_ID_GYRO] = {
+ .chan = st_lsm6ds0_gyro_channels,
+@@ -1428,8 +1435,8 @@ static const struct st_lsm6dsx_settings
+ },
+ .channels = {
+ [ST_LSM6DSX_ID_ACC] = {
+- .chan = st_lsm6dsx_acc_channels,
+- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels),
++ .chan = st_lsm6ds0_acc_channels,
++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels),
+ },
+ [ST_LSM6DSX_ID_GYRO] = {
+ .chan = st_lsm6dsx_gyro_channels,
--- /dev/null
+From 2934325f56150ad8dab8ab92cbe2997242831396 Mon Sep 17 00:00:00 2001
+From: feng <alec.jiang@gmail.com>
+Date: Sat, 24 Jan 2026 21:44:12 -0800
+Subject: Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA
+
+From: feng <alec.jiang@gmail.com>
+
+commit 2934325f56150ad8dab8ab92cbe2997242831396 upstream.
+
+The ASUS Zenbook UX425QA_UM425QA fails to initialize the keyboard after
+a cold boot.
+
+A quirk already exists for "ZenBook UX425", but some Zenbooks report
+"Zenbook" with a lowercase 'b'. Since DMI matching is case-sensitive,
+the existing quirk is not applied to these "extra special" Zenbooks.
+
+Testing confirms that this model needs the same quirks as the ZenBook
+UX425 variants.
+
+Signed-off-by: feng <alec.jiang@gmail.com>
+Link: https://patch.msgid.link/20260122013957.11184-1-alec.jiang@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -116,6 +116,17 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_NEVER)
+ },
+ {
++ /*
++ * ASUS Zenbook UX425QA_UM425QA
++ * Some Zenbooks report "Zenbook" with a lowercase b.
++ */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Zenbook UX425QA_UM425QA"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_PROBE_DEFER | SERIO_QUIRK_RESET_NEVER)
++ },
++ {
+ /* ASUS ZenBook UX425UA/QA */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--- /dev/null
+From 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab Mon Sep 17 00:00:00 2001
+From: gongqi <550230171hxy@gmail.com>
+Date: Thu, 22 Jan 2026 23:54:59 +0800
+Subject: Input: i8042 - add quirks for MECHREVO Wujie 15X Pro
+
+From: gongqi <550230171hxy@gmail.com>
+
+commit 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab upstream.
+
+The MECHREVO Wujie 15X Pro requires several i8042 quirks to function
+correctly. Specifically, NOMUX, RESET_ALWAYS, NOLOOP, and NOPNP are
+needed to ensure the keyboard and touchpad work reliably.
+
+Signed-off-by: gongqi <550230171hxy@gmail.com>
+Link: https://patch.msgid.link/20260122155501.376199-3-550230171hxy@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -1176,6 +1176,13 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "WUJIE Series-X5SP4NAG"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
+ /*
+ * A lot of modern Clevo barebones have touchpad and/or keyboard issues
+ * after suspend fixable with the forcenorestore quirk.
--- /dev/null
+From 10dc959398175736e495f71c771f8641e1ca1907 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 20 Jan 2026 07:42:50 -0700
+Subject: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 10dc959398175736e495f71c771f8641e1ca1907 upstream.
+
+Currently this is checked before running the pending work. Normally this
+is quite fine, as work items either end up blocking (which will create a
+new worker for other items), or they complete fairly quickly. But syzbot
+reports an issue where io-wq takes seemingly forever to exit, and with a
+bit of debugging, this turns out to be because it queues a bunch of big
+(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't
+support ->read_iter(), loop_rw_iter() ends up handling them. Each read
+returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
+these pending, processing the whole chain can take a long time. Easily
+longer than the syzbot uninterruptible sleep timeout of 140 seconds.
+This then triggers a complaint off the io-wq exit path:
+
+INFO: task syz.4.135:6326 blocked for more than 143 seconds.
+ Not tainted syzkaller #0
+ Blocked by coredump.
+"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000
+Call Trace:
+ <TASK>
+ context_switch kernel/sched/core.c:5256 [inline]
+ __schedule+0x1139/0x6150 kernel/sched/core.c:6863
+ __schedule_loop kernel/sched/core.c:6945 [inline]
+ schedule+0xe7/0x3a0 kernel/sched/core.c:6960
+ schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
+ do_wait_for_common kernel/sched/completion.c:100 [inline]
+ __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121
+ io_wq_exit_workers io_uring/io-wq.c:1328 [inline]
+ io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356
+ io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203
+ io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651
+ io_uring_files_cancel include/linux/io_uring.h:19 [inline]
+ do_exit+0x2ce/0x2bd0 kernel/exit.c:911
+ do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
+ get_signal+0x2671/0x26d0 kernel/signal.c:3034
+ arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337
+ __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
+ exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75
+ __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
+ syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
+ syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
+ syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
+ do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7fa02738f749
+RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
+RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749
+RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098
+RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
+
+There's really nothing wrong here, outside of processing these reads
+will take a LONG time. However, we can speed up the exit by checking the
+IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will
+exit the ring after queueing up all of these reads. Then once the first
+item is processed, io-wq will simply cancel the rest. That should avoid
+syzbot running into this complaint again.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/68a2decc.050a0220.e29e5.0099.GAE@google.com/
+Reported-by: syzbot+4eb282331cab6d5b6588@syzkaller.appspotmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io-wq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/io_uring/io-wq.c
++++ b/io_uring/io-wq.c
+@@ -554,9 +554,9 @@ static void io_worker_handle_work(struct
+ __releases(&acct->lock)
+ {
+ struct io_wq *wq = worker->wq;
+- bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state);
+
+ do {
++ bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state);
+ struct io_wq_work *work;
+
+ /*
--- /dev/null
+From 25150715e0b049b99df664daf05dab12f41c3e13 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 15 Jan 2026 14:31:11 -0600
+Subject: platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 25150715e0b049b99df664daf05dab12f41c3e13 upstream.
+
+The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs
+attributes:
+
+1. Off-by-one error: The loop condition used '<=' instead of '<',
+ causing access beyond array bounds. Since array indices are 0-based
+ and go from 0 to instances_count-1, the loop should use '<'.
+
+2. Missing NULL check: The code dereferenced attr_name_kobj->name
+ without checking if attr_name_kobj was NULL, causing a null pointer
+ dereference in min_length_show() and other attribute show functions.
+
+The panic occurred when fwupd tried to read BIOS configuration attributes:
+
+ Oops: general protection fault [#1] SMP KASAN NOPTI
+ KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
+ RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]
+
+Add a NULL check for attr_name_kobj before dereferencing and corrects
+the loop boundary to match the pattern used elsewhere in the driver.
+
+Cc: stable@vger.kernel.org
+Fixes: 5f94f181ca25 ("platform/x86: hp-bioscfg: bioscfg-h")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://patch.msgid.link/20260115203725.828434-3-mario.limonciello@amd.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp/hp-bioscfg/bioscfg.h | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h
+index 3166ef328eba..6b6748e4be21 100644
+--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h
++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h
+@@ -10,6 +10,7 @@
+
+ #include <linux/wmi.h>
+ #include <linux/types.h>
++#include <linux/string.h>
+ #include <linux/device.h>
+ #include <linux/module.h>
+ #include <linux/kernel.h>
+@@ -285,8 +286,9 @@ enum hp_wmi_data_elements {
+ { \
+ int i; \
+ \
+- for (i = 0; i <= bioscfg_drv.type##_instances_count; i++) { \
+- if (!strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \
++ for (i = 0; i < bioscfg_drv.type##_instances_count; i++) { \
++ if (bioscfg_drv.type##_data[i].attr_name_kobj && \
++ !strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \
+ return i; \
+ } \
+ return -EIO; \
+--
+2.52.0
+
--- /dev/null
+From fdee1b09721605f532352628d0a24623e7062efb Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 15 Jan 2026 14:31:10 -0600
+Subject: platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit fdee1b09721605f532352628d0a24623e7062efb upstream.
+
+The hp-bioscfg driver attempts to register kobjects with empty names when
+the HP BIOS returns attributes with empty name strings. This causes
+multiple kernel warnings:
+
+ kobject: (00000000135fb5e6): attempted to be registered with empty name!
+ WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310
+
+Add validation in hp_init_bios_buffer_attribute() to check if the
+attribute name is empty after parsing it from the WMI buffer. If empty,
+log a debug message and skip registration of that attribute, allowing the
+module to continue processing other valid attributes.
+
+Cc: stable@vger.kernel.org
+Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://patch.msgid.link/20260115203725.828434-2-mario.limonciello@amd.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp/hp-bioscfg/bioscfg.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c
++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c
+@@ -10,6 +10,8 @@
+ #include <linux/fs.h>
+ #include <linux/module.h>
+ #include <linux/kernel.h>
++#include <linux/printk.h>
++#include <linux/string.h>
+ #include <linux/wmi.h>
+ #include "bioscfg.h"
+ #include "../../firmware_attributes_class.h"
+@@ -786,6 +788,12 @@ static int hp_init_bios_buffer_attribute
+ if (ret < 0)
+ goto buff_attr_exit;
+
++ if (strlen(str) == 0) {
++ pr_debug("Ignoring attribute with empty name\n");
++ ret = 0;
++ goto buff_attr_exit;
++ }
++
+ if (attr_type == HPWMI_PASSWORD_TYPE ||
+ attr_type == HPWMI_SECURE_PLATFORM_TYPE)
+ temp_kset = bioscfg_drv.authentication_dir_kset;
--- /dev/null
+From f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Date: Tue, 13 Jan 2026 17:24:58 -0300
+Subject: Revert "nfc/nci: Add the inconsistency check between the input data length and count"
+
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+
+commit f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf upstream.
+
+This reverts commit 068648aab72c9ba7b0597354ef4d81ffaac7b979.
+
+NFC packets may have NUL-bytes. Checking for string length is not a correct
+assumption here. As long as there is a check for the length copied from
+copy_from_user, all should be fine.
+
+The fix only prevented the syzbot reproducer from triggering the bug
+because the packet is not enqueued anymore and the code that triggers the
+bug is not exercised.
+
+The fix even broke
+testing/selftests/nci/nci_dev, making all tests there fail. After the
+revert, 6 out of 8 tests pass.
+
+Fixes: 068648aab72c ("nfc/nci: Add the inconsistency check between the input data length and count")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Link: https://patch.msgid.link/20260113202458.449455-1-cascardo@igalia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nfc/virtual_ncidev.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/nfc/virtual_ncidev.c
++++ b/drivers/nfc/virtual_ncidev.c
+@@ -125,10 +125,6 @@ static ssize_t virtual_ncidev_write(stru
+ kfree_skb(skb);
+ return -EFAULT;
+ }
+- if (strnlen(skb->data, count) != count) {
+- kfree_skb(skb);
+- return -EINVAL;
+- }
+
+ nci_recv_frame(vdev->ndev, skb);
+ return count;
--- /dev/null
+From 9eacec5d18f98f89be520eeeef4b377acee3e4b8 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Fri, 16 Jan 2026 17:03:02 -0800
+Subject: scsi: storvsc: Process unsupported MODE_SENSE_10
+
+From: Long Li <longli@microsoft.com>
+
+commit 9eacec5d18f98f89be520eeeef4b377acee3e4b8 upstream.
+
+The Hyper-V host does not support MODE_SENSE_10 and MODE_SENSE. The
+driver handles MODE_SENSE as unsupported command, but not for
+MODE_SENSE_10. Add MODE_SENSE_10 to the same handling logic and return
+correct code to SCSI layer.
+
+Fixes: 89ae7d709357 ("Staging: hv: storvsc: Move the storage driver out of the staging area")
+Cc: stable@kernel.org
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/20260117010302.294068-1-longli@linux.microsoft.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/storvsc_drv.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1145,7 +1145,7 @@ static void storvsc_on_io_completion(str
+ * The current SCSI handling on the host side does
+ * not correctly handle:
+ * INQUIRY command with page code parameter set to 0x80
+- * MODE_SENSE command with cmd[2] == 0x1c
++ * MODE_SENSE and MODE_SENSE_10 command with cmd[2] == 0x1c
+ * MAINTENANCE_IN is not supported by HyperV FC passthrough
+ *
+ * Setup srb and scsi status so this won't be fatal.
+@@ -1155,6 +1155,7 @@ static void storvsc_on_io_completion(str
+
+ if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
+ (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
++ (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
+ (stor_pkt->vm_srb.cdb[0] == MAINTENANCE_IN &&
+ hv_dev_is_fc(device))) {
+ vstor_packet->vm_srb.scsi_status = 0;
--- /dev/null
+From 901a5f309daba412e2a30364d7ec1492fa11c32c Mon Sep 17 00:00:00 2001
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Date: Tue, 23 Dec 2025 12:00:11 +0530
+Subject: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()
+
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+
+commit 901a5f309daba412e2a30364d7ec1492fa11c32c upstream.
+
+Memory allocated for struct vscsiblk_info in scsiback_probe() is not
+freed in scsiback_remove() leading to potential memory leaks on remove,
+as well as in the scsiback_probe() error paths. Fix that by freeing it
+in scsiback_remove().
+
+Cc: stable@vger.kernel.org
+Fixes: d9d660f6e562 ("xen-scsiback: Add Xen PV SCSI backend driver")
+Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Link: https://patch.msgid.link/20251223063012.119035-1-nihaal@cse.iitm.ac.in
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/xen-scsiback.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/xen/xen-scsiback.c
++++ b/drivers/xen/xen-scsiback.c
+@@ -1262,6 +1262,7 @@ static void scsiback_remove(struct xenbu
+ gnttab_page_cache_shrink(&info->free_pages, 0);
+
+ dev_set_drvdata(&dev->dev, NULL);
++ kfree(info);
+ }
+
+ static int scsiback_probe(struct xenbus_device *dev,
comedi-dmm32at-serialize-use-of-paged-registers.patch
w1-therm-fix-off-by-one-buffer-overflow-in-alarms_store.patch
w1-fix-redundant-counter-decrement-in-w1_attach_slave_device.patch
+revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch
+input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch
+input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch
+scsi-storvsc-process-unsupported-mode_sense_10.patch
+scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch
+arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch
+arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch
+x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch
+comedi-fix-getting-range-information-for-subdevices-16-to-255.patch
+platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch
+platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch
+io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch
+iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch
--- /dev/null
+From b505f1944535f83d369ae68813e7634d11b990d3 Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Date: Tue, 6 Jan 2026 18:04:26 +0000
+Subject: x86/kfence: avoid writing L1TF-vulnerable PTEs
+
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+
+commit b505f1944535f83d369ae68813e7634d11b990d3 upstream.
+
+For native, the choice of PTE is fine. There's real memory backing the
+non-present PTE. However, for XenPV, Xen complains:
+
+ (XEN) d1 L1TF-vulnerable L1e 8010000018200066 - Shadowing
+
+To explain, some background on XenPV pagetables:
+
+ Xen PV guests are control their own pagetables; they choose the new
+ PTE value, and use hypercalls to make changes so Xen can audit for
+ safety.
+
+ In addition to a regular reference count, Xen also maintains a type
+ reference count. e.g. SegDesc (referenced by vGDT/vLDT), Writable
+ (referenced with _PAGE_RW) or L{1..4} (referenced by vCR3 or a lower
+ pagetable level). This is in order to prevent e.g. a page being
+ inserted into the pagetables for which the guest has a writable mapping.
+
+ For non-present mappings, all other bits become software accessible,
+ and typically contain metadata rather a real frame address. There is
+ nothing that a reference count could sensibly be tied to. As such, even
+ if Xen could recognise the address as currently safe, nothing would
+ prevent that frame from changing owner to another VM in the future.
+
+ When Xen detects a PV guest writing a L1TF-PTE, it responds by
+ activating shadow paging. This is normally only used for the live phase
+ of migration, and comes with a reasonable overhead.
+
+KFENCE only cares about getting #PF to catch wild accesses; it doesn't
+care about the value for non-present mappings. Use a fully inverted PTE,
+to avoid hitting the slow path when running under Xen.
+
+While adjusting the logic, take the opportunity to skip all actions if the
+PTE is already in the right state, half the number PVOps callouts, and
+skip TLB maintenance on a !P -> P transition which benefits non-Xen cases
+too.
+
+Link: https://lkml.kernel.org/r/20260106180426.710013-1-andrew.cooper3@citrix.com
+Fixes: 1dc0da6e9ec0 ("x86, kfence: enable KFENCE for x86")
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Tested-by: Marco Elver <elver@google.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Marco Elver <elver@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Jann Horn <jannh@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/kfence.h | 29 ++++++++++++++++++++++++-----
+ 1 file changed, 24 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/include/asm/kfence.h
++++ b/arch/x86/include/asm/kfence.h
+@@ -42,10 +42,34 @@ static inline bool kfence_protect_page(u
+ {
+ unsigned int level;
+ pte_t *pte = lookup_address(addr, &level);
++ pteval_t val;
+
+ if (WARN_ON(!pte || level != PG_LEVEL_4K))
+ return false;
+
++ val = pte_val(*pte);
++
++ /*
++ * protect requires making the page not-present. If the PTE is
++ * already in the right state, there's nothing to do.
++ */
++ if (protect != !!(val & _PAGE_PRESENT))
++ return true;
++
++ /*
++ * Otherwise, invert the entire PTE. This avoids writing out an
++ * L1TF-vulnerable PTE (not present, without the high address bits
++ * set).
++ */
++ set_pte(pte, __pte(~val));
++
++ /*
++ * If the page was protected (non-present) and we're making it
++ * present, there is no need to flush the TLB at all.
++ */
++ if (!protect)
++ return true;
++
+ /*
+ * We need to avoid IPIs, as we may get KFENCE allocations or faults
+ * with interrupts disabled. Therefore, the below is best-effort, and
+@@ -53,11 +77,6 @@ static inline bool kfence_protect_page(u
+ * lazy fault handling takes care of faults after the page is PRESENT.
+ */
+
+- if (protect)
+- set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
+- else
+- set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
+-
+ /*
+ * Flush this CPU's TLB, assuming whoever did the allocation/free is
+ * likely to continue running on this CPU.
projects / thirdparty / kernel / stable-queue.git / commitdiff
