From 7226eddac9e81e28b7f0fb9fef3eaa46c3d6f6e1 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 26 Jan 2026 14:27:20 +0100 Subject: [PATCH] 5.15-stable patches added patches: 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 --- ...-for-sensors-without-event-detection.patch | 68 +++++++++++ ...irk-for-asus-zenbook-ux425qa_um425qa.patch | 48 ++++++++ ...dd-quirks-for-mechrevo-wujie-15x-pro.patch | 38 ++++++ ...ween-the-input-data-length-and-count.patch | 46 +++++++ ...sc-process-unsupported-mode_sense_10.patch | 44 +++++++ queue-5.15/series | 6 + ...e-avoid-writing-l1tf-vulnerable-ptes.patch | 114 ++++++++++++++++++ 7 files changed, 364 insertions(+) create mode 100644 queue-5.15/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch create mode 100644 queue-5.15/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch create mode 100644 queue-5.15/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch create mode 100644 queue-5.15/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch create mode 100644 queue-5.15/scsi-storvsc-process-unsupported-mode_sense_10.patch create mode 100644 queue-5.15/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch diff --git a/queue-5.15/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch b/queue-5.15/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch new file mode 100644 index 0000000000..4f398c58e9 --- /dev/null +++ b/queue-5.15/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 +@@ -74,6 +74,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), +@@ -116,8 +123,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, +@@ -1016,8 +1023,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-5.15/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch b/queue-5.15/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch new file mode 100644 index 0000000000..0f263cb2d2 --- /dev/null +++ b/queue-5.15/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 +@@ -114,6 +114,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-5.15/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch b/queue-5.15/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch new file mode 100644 index 0000000000..53094d09eb --- /dev/null +++ b/queue-5.15/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 +@@ -1168,6 +1168,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 nomux + reset + noloop + nopnp. Luckily, diff --git a/queue-5.15/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch b/queue-5.15/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-5.15/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-5.15/scsi-storvsc-process-unsupported-mode_sense_10.patch b/queue-5.15/scsi-storvsc-process-unsupported-mode_sense_10.patch new file mode 100644 index 0000000000..0c2abaaae6 --- /dev/null +++ b/queue-5.15/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 +@@ -1199,7 +1199,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. +@@ -1209,6 +1209,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-5.15/series b/queue-5.15/series index 413612c632..e36ec0357a 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -81,3 +81,9 @@ net-sched-qfq-use-cl_is_active-to-determine-whether-.patch crypto-authencesn-reject-too-short-aad-assoclen-8-to.patch comedi-dmm32at-serialize-use-of-paged-registers.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 +x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch +iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch diff --git a/queue-5.15/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch b/queue-5.15/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch new file mode 100644 index 0000000000..d44739e530 --- /dev/null +++ b/queue-5.15/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. -- 2.47.3