From: Greg Kroah-Hartman Date: Mon, 26 Jan 2026 13:27:33 +0000 (+0100) Subject: 6.1-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9490a54b4576b8a61bc4c42d8e4c6ccc947f8cac;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch comedi-fix-getting-range-information-for-subdevices-16-to-255.patch iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch scsi-storvsc-process-unsupported-mode_sense_10.patch x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch --- diff --git a/queue-6.1/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch b/queue-6.1/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch new file mode 100644 index 0000000000..f84e62a021 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch @@ -0,0 +1,39 @@ +From 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 Mon Sep 17 00:00:00 2001 +From: Geraldo Nascimento +Date: Mon, 17 Nov 2025 18:47:43 -0300 +Subject: arm64: dts: rockchip: remove dangerous max-link-speed from helios64 + +From: Geraldo Nascimento + +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 +Reviewed-by: Dragan Simic +Signed-off-by: Geraldo Nascimento +Acked-by: Shawn Lin +Link: https://patch.msgid.link/43bb639c120f599106fca2deee6c6599b2692c5c.1763415706.git.geraldogabriel@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + 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"; diff --git a/queue-6.1/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch b/queue-6.1/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch new file mode 100644 index 0000000000..aa49cfc07b --- /dev/null +++ b/queue-6.1/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch @@ -0,0 +1,101 @@ +From 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 Mon Sep 17 00:00:00 2001 +From: Ian Abbott +Date: Wed, 3 Dec 2025 16:24:38 +0000 +Subject: comedi: Fix getting range information for subdevices 16 to 255 + +From: Ian Abbott + +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 +Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1095,7 +1095,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. diff --git a/queue-6.1/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch b/queue-6.1/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch new file mode 100644 index 0000000000..494ac7c696 --- /dev/null +++ b/queue-6.1/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch @@ -0,0 +1,68 @@ +From c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 Mon Sep 17 00:00:00 2001 +From: Francesco Lavra +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 + +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 +Reviewed-by: Andy Shevchenko +Acked-by: Lorenzo Bianconi +Cc: stable@vger.kernel.org +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -76,6 +76,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), +@@ -117,8 +124,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, +@@ -1009,8 +1016,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, diff --git a/queue-6.1/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch b/queue-6.1/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch new file mode 100644 index 0000000000..e189baf5e4 --- /dev/null +++ b/queue-6.1/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch @@ -0,0 +1,48 @@ +From 2934325f56150ad8dab8ab92cbe2997242831396 Mon Sep 17 00:00:00 2001 +From: feng +Date: Sat, 24 Jan 2026 21:44:12 -0800 +Subject: Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA + +From: feng + +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 +Link: https://patch.msgid.link/20260122013957.11184-1-alec.jiang@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + 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."), diff --git a/queue-6.1/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch b/queue-6.1/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch new file mode 100644 index 0000000000..6895b9e624 --- /dev/null +++ b/queue-6.1/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch @@ -0,0 +1,38 @@ +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-6.1/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch b/queue-6.1/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch new file mode 100644 index 0000000000..d167a728a6 --- /dev/null +++ b/queue-6.1/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch @@ -0,0 +1,46 @@ +From f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +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 + +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 +Link: https://patch.msgid.link/20260113202458.449455-1-cascardo@igalia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nfc/virtual_ncidev.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/drivers/nfc/virtual_ncidev.c ++++ b/drivers/nfc/virtual_ncidev.c +@@ -121,10 +121,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(ndev, skb); + return count; diff --git a/queue-6.1/scsi-storvsc-process-unsupported-mode_sense_10.patch b/queue-6.1/scsi-storvsc-process-unsupported-mode_sense_10.patch new file mode 100644 index 0000000000..f3171baff7 --- /dev/null +++ b/queue-6.1/scsi-storvsc-process-unsupported-mode_sense_10.patch @@ -0,0 +1,44 @@ +From 9eacec5d18f98f89be520eeeef4b377acee3e4b8 Mon Sep 17 00:00:00 2001 +From: Long Li +Date: Fri, 16 Jan 2026 17:03:02 -0800 +Subject: scsi: storvsc: Process unsupported MODE_SENSE_10 + +From: Long Li + +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 +Reviewed-by: Michael Kelley +Link: https://patch.msgid.link/20260117010302.294068-1-longli@linux.microsoft.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1136,7 +1136,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. +@@ -1146,6 +1146,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; diff --git a/queue-6.1/series b/queue-6.1/series index a3e5635adf..2b91498daf 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -116,3 +116,11 @@ serial-8250_pci-fix-broken-rs485-for-f81504-508-512.patch 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 +arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch +x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch +comedi-fix-getting-range-information-for-subdevices-16-to-255.patch +iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch diff --git a/queue-6.1/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch b/queue-6.1/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch new file mode 100644 index 0000000000..d44739e530 --- /dev/null +++ b/queue-6.1/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch @@ -0,0 +1,114 @@ +From b505f1944535f83d369ae68813e7634d11b990d3 Mon Sep 17 00:00:00 2001 +From: Andrew Cooper +Date: Tue, 6 Jan 2026 18:04:26 +0000 +Subject: x86/kfence: avoid writing L1TF-vulnerable PTEs + +From: Andrew Cooper + +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 +Tested-by: Marco Elver +Cc: Alexander Potapenko +Cc: Marco Elver +Cc: Dmitry Vyukov +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: Borislav Petkov +Cc: Dave Hansen +Cc: "H. Peter Anvin" +Cc: Jann Horn +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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.