--- /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
+@@ -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.
--- /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
+@@ -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,
--- /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 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
+@@ -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;
--- /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
+@@ -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;
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
--- /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
