From: Greg Kroah-Hartman Date: Mon, 26 Jan 2026 13:28:01 +0000 (+0100) Subject: 6.12-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f7d3d2251054d0b01f39b1ad4fae521f6afc2c6f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch 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 io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch scsi-storvsc-process-unsupported-mode_sense_10.patch scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch --- diff --git a/queue-6.12/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch b/queue-6.12/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch new file mode 100644 index 0000000000..9bbb00bc5f --- /dev/null +++ b/queue-6.12/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch @@ -0,0 +1,53 @@ +From 5497ffe305b2ea31ae62d4a311d7cabfb671f54a Mon Sep 17 00:00:00 2001 +From: Ondrej Jirman +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 + +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 +Signed-off-by: Rudraksha Gupta +Reviewed-by: Pavel Machek +Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-4-f9a10a0a50eb@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; +- press-threshold-microvolt = <100000>; ++ press-threshold-microvolt = <2000>; + }; + + button-down { + label = "Volume Down"; + linux,code = ; +- press-threshold-microvolt = <600000>; ++ press-threshold-microvolt = <300000>; + }; + }; + diff --git a/queue-6.12/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch b/queue-6.12/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch new file mode 100644 index 0000000000..2e00a81647 --- /dev/null +++ b/queue-6.12/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 +@@ -424,7 +424,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.12/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch b/queue-6.12/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch new file mode 100644 index 0000000000..0741eebc19 --- /dev/null +++ b/queue-6.12/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 +@@ -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. diff --git a/queue-6.12/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch b/queue-6.12/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch new file mode 100644 index 0000000000..f21ea18261 --- /dev/null +++ b/queue-6.12/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 +@@ -101,6 +101,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), +@@ -142,8 +149,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, +@@ -1449,8 +1456,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.12/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch b/queue-6.12/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch new file mode 100644 index 0000000000..e189baf5e4 --- /dev/null +++ b/queue-6.12/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.12/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch b/queue-6.12/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch new file mode 100644 index 0000000000..6895b9e624 --- /dev/null +++ b/queue-6.12/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.12/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch b/queue-6.12/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch new file mode 100644 index 0000000000..a0e7f9df4c --- /dev/null +++ b/queue-6.12/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch @@ -0,0 +1,89 @@ +From 10dc959398175736e495f71c771f8641e1ca1907 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +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 + +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: + + 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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -552,9 +552,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; + + /* diff --git a/queue-6.12/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch b/queue-6.12/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch new file mode 100644 index 0000000000..c49a73d8ae --- /dev/null +++ b/queue-6.12/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch @@ -0,0 +1,72 @@ +From a8682d500f691b6dfaa16ae1502d990aeb86e8be Mon Sep 17 00:00:00 2001 +From: "David Hildenbrand (Red Hat)" +Date: Tue, 23 Dec 2025 22:40:36 +0100 +Subject: mm/rmap: fix two comments related to huge_pmd_unshare() + +From: David Hildenbrand (Red Hat) + +commit a8682d500f691b6dfaa16ae1502d990aeb86e8be upstream. + +PMD page table unsharing no longer touches the refcount of a PMD page +table. Also, it is not about dropping the refcount of a "PMD page" but +the "PMD page table". + +Let's just simplify by saying that the PMD page table was unmapped, +consequently also unmapping the folio that was mapped into this page. + +This code should be deduplicated in the future. + +Link: https://lkml.kernel.org/r/20251223214037.580860-4-david@kernel.org +Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") +Signed-off-by: David Hildenbrand (Red Hat) +Reviewed-by: Rik van Riel +Tested-by: Laurence Oberman +Reviewed-by: Lorenzo Stoakes +Acked-by: Oscar Salvador +Cc: Liu Shixin +Cc: Harry Yoo +Cc: Lance Yang +Cc: "Uschakow, Stanislav" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/rmap.c | 20 ++++---------------- + 1 file changed, 4 insertions(+), 16 deletions(-) + +--- a/mm/rmap.c ++++ b/mm/rmap.c +@@ -1753,14 +1753,8 @@ static bool try_to_unmap_one(struct foli + flush_tlb_range(vma, + range.start, range.end); + /* +- * The ref count of the PMD page was +- * dropped which is part of the way map +- * counting is done for shared PMDs. +- * Return 'true' here. When there is +- * no other sharing, huge_pmd_unshare +- * returns false and we will unmap the +- * actual page and drop map count +- * to zero. ++ * The PMD table was unmapped, ++ * consequently unmapping the folio. + */ + goto walk_done; + } +@@ -2128,14 +2122,8 @@ static bool try_to_migrate_one(struct fo + range.start, range.end); + + /* +- * The ref count of the PMD page was +- * dropped which is part of the way map +- * counting is done for shared PMDs. +- * Return 'true' here. When there is +- * no other sharing, huge_pmd_unshare +- * returns false and we will unmap the +- * actual page and drop map count +- * to zero. ++ * The PMD table was unmapped, ++ * consequently unmapping the folio. + */ + page_vma_mapped_walk_done(&pvmw); + break; diff --git a/queue-6.12/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch b/queue-6.12/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch new file mode 100644 index 0000000000..c0c971feda --- /dev/null +++ b/queue-6.12/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch @@ -0,0 +1,65 @@ +From 25150715e0b049b99df664daf05dab12f41c3e13 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +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 + +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 +Link: https://patch.msgid.link/20260115203725.828434-3-mario.limonciello@amd.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/hp/hp-bioscfg/bioscfg.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h ++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h +@@ -10,6 +10,7 @@ + + #include + #include ++#include + #include + #include + #include +@@ -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; \ diff --git a/queue-6.12/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch b/queue-6.12/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch new file mode 100644 index 0000000000..38c2755ad5 --- /dev/null +++ b/queue-6.12/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch @@ -0,0 +1,59 @@ +From fdee1b09721605f532352628d0a24623e7062efb Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +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 + +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 +Link: https://patch.msgid.link/20260115203725.828434-2-mario.limonciello@amd.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include ++#include + #include + #include "bioscfg.h" + #include "../../firmware_attributes_class.h" +@@ -784,6 +786,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; diff --git a/queue-6.12/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch b/queue-6.12/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch new file mode 100644 index 0000000000..5dd3223569 --- /dev/null +++ b/queue-6.12/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 +@@ -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; diff --git a/queue-6.12/scsi-storvsc-process-unsupported-mode_sense_10.patch b/queue-6.12/scsi-storvsc-process-unsupported-mode_sense_10.patch new file mode 100644 index 0000000000..63729991b2 --- /dev/null +++ b/queue-6.12/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 +@@ -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; diff --git a/queue-6.12/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch b/queue-6.12/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch new file mode 100644 index 0000000000..52340264e8 --- /dev/null +++ b/queue-6.12/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch @@ -0,0 +1,35 @@ +From 901a5f309daba412e2a30364d7ec1492fa11c32c Mon Sep 17 00:00:00 2001 +From: Abdun Nihaal +Date: Tue, 23 Dec 2025 12:00:11 +0530 +Subject: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() + +From: Abdun Nihaal + +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 +Reviewed-by: Juergen Gross +Link: https://patch.msgid.link/20251223063012.119035-1-nihaal@cse.iitm.ac.in +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.12/series b/queue-6.12/series index de1659a497..3088f306a9 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -44,3 +44,17 @@ 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 +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 +mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.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 diff --git a/queue-6.12/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch b/queue-6.12/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch new file mode 100644 index 0000000000..d44739e530 --- /dev/null +++ b/queue-6.12/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.