--- /dev/null
+From ca57bf46e7a94f8c53d05c376df9fcfdcb482100 Mon Sep 17 00:00:00 2001
+From: Kartik Rajput <kkartik@nvidia.com>
+Date: Thu, 7 May 2026 21:15:54 +0530
+Subject: clocksource/drivers/timer-tegra186: Fix support for multiple watchdog instances
+
+From: Kartik Rajput <kkartik@nvidia.com>
+
+commit ca57bf46e7a94f8c53d05c376df9fcfdcb482100 upstream.
+
+Tegra SoCs support multiple watchdogs; currently only one (WDT0) is
+used. When multiple watchdogs are registered, tegra186_wdt_enable()
+overwrites the TKEIE(x) register, discarding any existing watchdog
+interrupt enable bits. As a result, enabling one watchdog inadvertently
+disables interrupts for the others.
+
+Fix this by preserving the existing TKEIE(x) value and updating it
+using a read-modify-write sequence.
+
+Fixes: 42cee19a9f83 ("clocksource: Add Tegra186 timers support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
+Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
+Link: https://patch.msgid.link/20260507154557.2082697-2-kkartik@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clocksource/timer-tegra186.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/clocksource/timer-tegra186.c
++++ b/drivers/clocksource/timer-tegra186.c
+@@ -144,7 +144,8 @@ static void tegra186_wdt_enable(struct t
+ u32 value;
+
+ /* unmask hardware IRQ, this may have been lost across powergate */
+- value = TKEIE_WDT_MASK(wdt->index, 1);
++ value = readl(tegra->regs + TKEIE(wdt->tmr->hwirq));
++ value |= TKEIE_WDT_MASK(wdt->index, 1);
+ writel(value, tegra->regs + TKEIE(wdt->tmr->hwirq));
+
+ /* clear interrupt */
--- /dev/null
+From a9029dd55696c651ee46912afa2a166fa456bb3e Mon Sep 17 00:00:00 2001
+From: Tianxiang Chen <nanmu@xiaomi.com>
+Date: Wed, 8 Apr 2026 22:19:14 +0800
+Subject: cpufreq: Fix hotplug-suspend race during reboot
+
+From: Tianxiang Chen <nanmu@xiaomi.com>
+
+commit a9029dd55696c651ee46912afa2a166fa456bb3e upstream.
+
+During system reboot, cpufreq_suspend() is called via the
+kernel_restart() -> device_shutdown() path. Unlike the normal system
+suspend path, the reboot path does not call freeze_processes(), so
+userspace processes and kernel threads remain active.
+
+This allows CPU hotplug operations to run concurrently with
+cpufreq_suspend(). The original code has no synchronization with CPU
+hotplug, leading to a race condition where governor_data can be freed
+by the hotplug path while cpufreq_suspend() is still accessing it,
+resulting in a null pointer dereference:
+
+ Unable to handle kernel NULL pointer dereference
+ Call Trace:
+ do_kernel_fault+0x28/0x3c
+ cpufreq_suspend+0xdc/0x160
+ device_shutdown+0x18/0x200
+ kernel_restart+0x40/0x80
+ arm64_sys_reboot+0x1b0/0x200
+
+Fix this by adding cpus_read_lock()/cpus_read_unlock() to
+cpufreq_suspend() to block CPU hotplug operations while suspend is in
+progress.
+
+Fixes: 65650b35133f ("cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown")
+Signed-off-by: Tianxiang Chen <nanmu@xiaomi.com>
+Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
+Cc: All applicable <stable@vger.kernel.org>
+[ rjw: Changelog edits ]
+Link: https://patch.msgid.link/20260408141914.35281-1-nanmu@xiaomi.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/cpufreq.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -1970,6 +1970,7 @@ void cpufreq_suspend(void)
+ if (!cpufreq_driver)
+ return;
+
++ cpus_read_lock();
+ if (!has_target() && !cpufreq_driver->suspend)
+ goto suspend;
+
+@@ -1989,6 +1990,7 @@ void cpufreq_suspend(void)
+
+ suspend:
+ cpufreq_suspended = true;
++ cpus_read_unlock();
+ }
+
+ /**
--- /dev/null
+From bcbdaa1086c25a8a5d48e04e1b82fdfb0682b681 Mon Sep 17 00:00:00 2001
+From: Fushuai Wang <wangfushuai@baidu.com>
+Date: Wed, 20 May 2026 11:21:19 +0800
+Subject: cpufreq: intel_pstate: Sync policy->cur during CPU offline
+
+From: Fushuai Wang <wangfushuai@baidu.com>
+
+commit bcbdaa1086c25a8a5d48e04e1b82fdfb0682b681 upstream.
+
+When a CPU goes offline with HWP disabled, intel_pstate_set_min_pstate()
+sets the MSR_IA32_PERF_CTL to minimum frequency to prevent SMT siblings
+from being restricted. However, the policy->cur value was not updated,
+leaving it at the previous value.
+
+When the CPU comes back online, governor->limits() checks if target_freq
+equals policy->cur and skips the frequency adjustment if they match. Since
+policy->cur still holds the previous value, the governor does not call
+cpufreq_driver->target to update MSR_IA32_PERF_CTL.
+
+Fix this by synchronizing policy->cur with the hardware state when setting
+minimum pstate during CPU offline.
+
+Fixes: bb18008f8086 ("intel_pstate: Set core to min P state during core offline")
+Cc: stable@vger.kernel.org # 3.15+
+Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
+[ rjw: Subject refinement ]
+Link: https://patch.msgid.link/20260520032119.30615-1-fushuai.wang@linux.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/intel_pstate.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -2666,10 +2666,12 @@ static int intel_cpufreq_cpu_offline(str
+ * from getting to lower performance levels, so force the minimum
+ * performance on CPU offline to prevent that from happening.
+ */
+- if (hwp_active)
++ if (hwp_active) {
+ intel_pstate_hwp_offline(cpu);
+- else
++ } else {
+ intel_pstate_set_min_pstate(cpu);
++ policy->cur = cpu->pstate.min_freq;
++ }
+
+ intel_pstate_exit_perf_limits(policy);
+
--- /dev/null
+From 266d3dd8b757b48a576e90f018b51f7b7563cc32 Mon Sep 17 00:00:00 2001
+From: Yuho Choi <dbgh9129@gmail.com>
+Date: Thu, 16 Apr 2026 10:46:21 -0400
+Subject: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
+
+From: Yuho Choi <dbgh9129@gmail.com>
+
+commit 266d3dd8b757b48a576e90f018b51f7b7563cc32 upstream.
+
+pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the
+two-phase _OSC negotiation. Between the two calls it freed
+output.pointer but left output.length unchanged. Since
+acpi_evaluate_object() treats a non-zero length with a non-NULL
+pointer as an existing buffer to write into, the second call wrote
+into freed memory (use-after-free). The subsequent kfree(output.pointer)
+at out_free then freed the same pointer a second time (double free).
+
+Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER
+after freeing the first result, so ACPICA allocates a fresh buffer for
+each phase independently.
+
+Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
+Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
+Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
+Cc: All applicable <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20260416144621.93964-1-dbgh9129@gmail.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/pcc-cpufreq.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/cpufreq/pcc-cpufreq.c
++++ b/drivers/cpufreq/pcc-cpufreq.c
+@@ -352,6 +352,8 @@ static int __init pcc_cpufreq_do_osc(acp
+ }
+
+ kfree(output.pointer);
++ output.pointer = NULL;
++ output.length = ACPI_ALLOCATE_BUFFER;
+ capabilities[0] = 0x0;
+ capabilities[1] = 0x1;
+
--- /dev/null
+From 896df22ee57648b0c505bd76ddbc6b2341834696 Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Tue, 5 May 2026 17:12:31 +0800
+Subject: firmware_loader: fix device reference leak in firmware_upload_register()
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit 896df22ee57648b0c505bd76ddbc6b2341834696 upstream.
+
+firmware_upload_register()
+ -> fw_create_instance()
+ -> device_initialize()
+
+After fw_create_instance() succeeds, the lifetime of the embedded struct
+device is expected to be managed through the device core reference
+counting, since fw_create_instance() has already called
+device_initialize().
+
+In firmware_upload_register(), if alloc_lookup_fw_priv() fails after
+fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees
+fw_sysfs directly instead of releasing the device reference with
+put_device(). This may leave the reference count of the embedded struct
+device unbalanced, resulting in a refcount leak.
+
+The issue was identified by a static analysis tool I developed and
+confirmed by manual review. Fix this by using put_device(fw_dev) in the
+failure path and letting fw_dev_release() handle the final cleanup,
+instead of freeing the instance directly from the error path.
+
+Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Link: https://patch.msgid.link/20260505091231.607089-1-lgs201920130244@gmail.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/firmware_loader/sysfs_upload.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/base/firmware_loader/sysfs_upload.c
++++ b/drivers/base/firmware_loader/sysfs_upload.c
+@@ -340,7 +340,6 @@ firmware_upload_register(struct module *
+ goto free_fw_upload_priv;
+ }
+ fw_upload->priv = fw_sysfs;
+- fw_sysfs->fw_upload_priv = fw_upload_priv;
+ fw_dev = &fw_sysfs->dev;
+
+ ret = alloc_lookup_fw_priv(name, &fw_cache, &fw_priv, NULL, 0, 0,
+@@ -348,10 +347,12 @@ firmware_upload_register(struct module *
+ if (ret != 0) {
+ if (ret > 0)
+ ret = -EINVAL;
+- goto free_fw_sysfs;
++ put_device(fw_dev);
++ goto free_fw_upload_priv;
+ }
+ fw_priv->is_paged_buf = true;
+ fw_sysfs->fw_priv = fw_priv;
++ fw_sysfs->fw_upload_priv = fw_upload_priv;
+
+ ret = device_add(fw_dev);
+ if (ret) {
+@@ -362,9 +363,6 @@ firmware_upload_register(struct module *
+
+ return fw_upload;
+
+-free_fw_sysfs:
+- kfree(fw_sysfs);
+-
+ free_fw_upload_priv:
+ kfree(fw_upload_priv);
+
--- /dev/null
+From 46c8beeccd8ab2c863827254a85ea877654a3534 Mon Sep 17 00:00:00 2001
+From: Manish Khadka <maskmemanish@gmail.com>
+Date: Fri, 15 May 2026 22:27:00 +0545
+Subject: HID: letsketch: fix UAF on inrange_timer at driver unbind
+
+From: Manish Khadka <maskmemanish@gmail.com>
+
+commit 46c8beeccd8ab2c863827254a85ea877654a3534 upstream.
+
+letsketch_driver does not provide a .remove callback, but
+letsketch_probe() arms a per-device timer:
+
+ timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0);
+
+The timer is re-armed from letsketch_raw_event() with a 100 ms
+timeout on every pen-in-range report, and its callback dereferences
+data->input_tablet to deliver a synthetic BTN_TOOL_PEN release.
+
+letsketch_data is allocated with devm_kzalloc(), and its input_dev
+fields are devm-allocated via letsketch_setup_input_tablet(). On
+device unbind (USB unplug or rmmod), the HID core runs its default
+teardown and devm cleanup frees both letsketch_data and the input
+devices. Because no .remove callback exists, nothing drains the
+timer first: if raw_event armed it within ~100 ms of the unbind,
+the pending timer fires on freed memory. This is a UAF read of
+data and of data->input_tablet, followed by input_report_key() /
+input_sync() into the freed input_dev.
+
+The same problem can occur on the probe error path: if
+hid_hw_start() enabled I/O on an always-poll-quirk device and then
+failed, raw_event may have armed the timer before devm releases
+data.
+
+Fix by adding a .remove callback that calls hid_hw_stop() first.
+hid_hw_stop() synchronously kills the URBs that deliver raw_event(),
+so once it returns no path can re-arm the timer. timer_shutdown_sync()
+then drains any in-flight callback and permanently disables further
+mod_timer() calls. Apply the same timer_shutdown_sync() in the probe
+error path so the timer is guaranteed not to outlive data.
+
+Fixes: 33a5c2793451 ("HID: Add new Letsketch tablet driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hid-letsketch.c | 36 +++++++++++++++++++++++++++++++++---
+ 1 file changed, 33 insertions(+), 3 deletions(-)
+
+--- a/drivers/hid/hid-letsketch.c
++++ b/drivers/hid/hid-letsketch.c
+@@ -295,13 +295,42 @@ static int letsketch_probe(struct hid_de
+
+ ret = letsketch_setup_input_tablet(data);
+ if (ret)
+- return ret;
++ goto err_shutdown_timer;
+
+ ret = letsketch_setup_input_tablet_pad(data);
+ if (ret)
+- return ret;
++ goto err_shutdown_timer;
+
+- return hid_hw_start(hdev, HID_CONNECT_HIDRAW);
++ ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
++ if (ret)
++ goto err_shutdown_timer;
++
++ return 0;
++
++err_shutdown_timer:
++ /*
++ * Drain any pending callback and permanently disable the timer
++ * before devm releases data: if hid_hw_start() enabled I/O on an
++ * always-poll-quirk device and then failed, raw_event may have
++ * armed the timer already.
++ */
++ timer_shutdown_sync(&data->inrange_timer);
++ return ret;
++}
++
++static void letsketch_remove(struct hid_device *hdev)
++{
++ struct letsketch_data *data = hid_get_drvdata(hdev);
++
++ /*
++ * hid_hw_stop() synchronously kills the URBs that deliver
++ * raw_event(), so once it returns no path can re-arm
++ * inrange_timer. timer_shutdown_sync() then drains any
++ * in-flight callback and permanently disables further
++ * mod_timer() calls before devm releases data.
++ */
++ hid_hw_stop(hdev);
++ timer_shutdown_sync(&data->inrange_timer);
+ }
+
+ static const struct hid_device_id letsketch_devices[] = {
+@@ -314,6 +343,7 @@ static struct hid_driver letsketch_drive
+ .name = "letsketch",
+ .id_table = letsketch_devices,
+ .probe = letsketch_probe,
++ .remove = letsketch_remove,
+ .raw_event = letsketch_raw_event,
+ };
+ module_hid_driver(letsketch_driver);
--- /dev/null
+From 7705b4140d188ce22656f6e541ae7ef834c7e11a Mon Sep 17 00:00:00 2001
+From: Maoyi Xie <maoyixie.tju@gmail.com>
+Date: Thu, 18 Jun 2026 15:06:35 +0800
+Subject: HID: lg-g15: cancel pending work on remove to fix a use-after-free
+
+From: Maoyi Xie <maoyixie.tju@gmail.com>
+
+commit 7705b4140d188ce22656f6e541ae7ef834c7e11a upstream.
+
+lg_g15_data is allocated with devm and holds a work item. The report
+handlers schedule that work straight from device input.
+lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,
+and lg_g510_leds_event() does it too. The worker dereferences the
+lg_g15_data back through container_of.
+
+The driver had no remove callback and never cancelled the work. So if a
+report scheduled the work and the keyboard was then unplugged, devres
+freed lg_g15_data while the work was still pending or running, and the
+worker touched freed memory. This is a use-after-free. It is reachable
+as a race on device unplug.
+
+Add a remove callback that cancels the work before devres frees the
+state. g15->work is only initialized for the models that schedule it
+(G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the
+cancel on g15->work.func to avoid cancelling a work that was never set
+up. The g15 NULL test mirrors the one already in lg_g15_raw_event().
+
+Fixes: 97b741aba918 ("HID: lg-g15: Add keyboard and LCD backlight control")
+Cc: stable@vger.kernel.org
+Suggested-by: Hans de Goede <hansg@kernel.org>
+Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hid-lg-g15.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/drivers/hid/hid-lg-g15.c
++++ b/drivers/hid/hid-lg-g15.c
+@@ -945,11 +945,27 @@ static const struct hid_device_id lg_g15
+ };
+ MODULE_DEVICE_TABLE(hid, lg_g15_devices);
+
++static void lg_g15_remove(struct hid_device *hdev)
++{
++ struct lg_g15_data *g15 = hid_get_drvdata(hdev);
++
++ /*
++ * g15->work is only initialized for the models that schedule it
++ * (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so only
++ * cancel it when it was set up.
++ */
++ if (g15 && g15->work.func)
++ cancel_work_sync(&g15->work);
++
++ hid_hw_stop(hdev);
++}
++
+ static struct hid_driver lg_g15_driver = {
+ .name = "lg-g15",
+ .id_table = lg_g15_devices,
+ .raw_event = lg_g15_raw_event,
+ .probe = lg_g15_probe,
++ .remove = lg_g15_remove,
+ };
+ module_hid_driver(lg_g15_driver);
+
--- /dev/null
+From f784fcea450617055d2d12eec5b2f6e0e38bf878 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Wed, 10 Jun 2026 16:29:09 +0800
+Subject: HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit f784fcea450617055d2d12eec5b2f6e0e38bf878 upstream.
+
+sensor_hub_input_attr_get_raw_value() is limited to returning a single
+32-bit value, which is insufficient for sensors that report data larger
+than 32 bits, such as a quaternion with four s16 elements.
+
+Add sensor_hub_input_attr_read_values() that accepts a caller-provided
+buffer and accumulates incoming data until the buffer is full. The two
+paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size
+being non-zero, preserving backward compatibility.
+
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Co-developed-by: Zhang Lixu <lixu.zhang@intel.com>
+Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
+Acked-by: Jiri Kosina <jkosina@suse.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hid-sensor-hub.c | 77 +++++++++++++++++++++++++++++++++++++----
+ include/linux/hid-sensor-hub.h | 25 +++++++++++++
+ 2 files changed, 96 insertions(+), 6 deletions(-)
+
+--- a/drivers/hid/hid-sensor-hub.c
++++ b/drivers/hid/hid-sensor-hub.c
+@@ -286,6 +286,54 @@ done_proc:
+ }
+ EXPORT_SYMBOL_GPL(sensor_hub_get_feature);
+
++int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
++ u32 usage_id, u32 attr_usage_id,
++ u32 report_id,
++ enum sensor_hub_read_flags flag,
++ u32 buffer_size, u8 *buffer)
++{
++ struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
++ struct hid_report *report;
++ unsigned long flags;
++ long cycles;
++ int ret;
++
++ report = sensor_hub_report(report_id, hsdev->hdev, HID_INPUT_REPORT);
++ if (!report)
++ return -EINVAL;
++
++ mutex_lock(hsdev->mutex_ptr);
++ if (flag == SENSOR_HUB_SYNC) {
++ memset(&hsdev->pending, 0, sizeof(hsdev->pending));
++ init_completion(&hsdev->pending.ready);
++ hsdev->pending.usage_id = usage_id;
++ hsdev->pending.attr_usage_id = attr_usage_id;
++ hsdev->pending.max_raw_size = buffer_size;
++ hsdev->pending.raw_data = buffer;
++
++ spin_lock_irqsave(&data->lock, flags);
++ hsdev->pending.status = true;
++ spin_unlock_irqrestore(&data->lock, flags);
++ }
++ mutex_lock(&data->mutex);
++ hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT);
++ mutex_unlock(&data->mutex);
++ ret = 0;
++ if (flag == SENSOR_HUB_SYNC) {
++ cycles = wait_for_completion_interruptible_timeout(&hsdev->pending.ready,
++ HZ * 5);
++ if (cycles == 0)
++ ret = -ETIMEDOUT;
++ else if (cycles < 0)
++ ret = cycles;
++
++ hsdev->pending.status = false;
++ }
++ mutex_unlock(hsdev->mutex_ptr);
++
++ return ret;
++}
++EXPORT_SYMBOL_GPL(sensor_hub_input_attr_read_values);
+
+ int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
+ u32 usage_id,
+@@ -480,6 +528,8 @@ static int sensor_hub_raw_event(struct h
+ struct hid_collection *collection = NULL;
+ void *priv = NULL;
+ struct hid_sensor_hub_device *hsdev = NULL;
++ u32 copy_size;
++ u32 avail;
+
+ hid_dbg(hdev, "sensor_hub_raw_event report id:0x%x size:%d type:%d\n",
+ report->id, size, report->type);
+@@ -520,12 +570,27 @@ static int sensor_hub_raw_event(struct h
+ hsdev->pending.attr_usage_id ==
+ report->field[i]->logical)) {
+ hid_dbg(hdev, "data was pending ...\n");
+- hsdev->pending.raw_data = kmemdup(ptr, sz, GFP_ATOMIC);
+- if (hsdev->pending.raw_data)
+- hsdev->pending.raw_size = sz;
+- else
+- hsdev->pending.raw_size = 0;
+- complete(&hsdev->pending.ready);
++ if (hsdev->pending.max_raw_size) {
++ if (hsdev->pending.index < hsdev->pending.max_raw_size) {
++ avail = hsdev->pending.max_raw_size - hsdev->pending.index;
++ copy_size = clamp(sz, 0U, avail);
++
++ memcpy(hsdev->pending.raw_data + hsdev->pending.index,
++ ptr, copy_size);
++ hsdev->pending.index += copy_size;
++ if (hsdev->pending.index >= hsdev->pending.max_raw_size) {
++ hsdev->pending.raw_size = hsdev->pending.index;
++ complete(&hsdev->pending.ready);
++ }
++ }
++ } else {
++ hsdev->pending.raw_data = kmemdup(ptr, sz, GFP_ATOMIC);
++ if (hsdev->pending.raw_data)
++ hsdev->pending.raw_size = sz;
++ else
++ hsdev->pending.raw_size = 0;
++ complete(&hsdev->pending.ready);
++ }
+ }
+ if (callback->capture_sample) {
+ if (report->field[i]->logical)
+--- a/include/linux/hid-sensor-hub.h
++++ b/include/linux/hid-sensor-hub.h
+@@ -43,6 +43,8 @@ struct hid_sensor_hub_attribute_info {
+ * @attr_usage_id: Usage Id of a field, E.g. X-AXIS for a gyro.
+ * @raw_size: Response size for a read request.
+ * @raw_data: Place holder for received response.
++ * @index: Current write index into raw_data for multi-byte reads.
++ * @max_raw_size: Total buffer size for multi-byte reads; 0 for single-value reads.
+ */
+ struct sensor_hub_pending {
+ bool status;
+@@ -51,6 +53,8 @@ struct sensor_hub_pending {
+ u32 attr_usage_id;
+ int raw_size;
+ u8 *raw_data;
++ u32 index;
++ u32 max_raw_size;
+ };
+
+ /**
+@@ -183,6 +187,27 @@ int sensor_hub_input_attr_get_raw_value(
+ );
+
+ /**
++ * sensor_hub_input_attr_read_values() - Synchronous multi-byte read request
++ * @hsdev: Hub device instance.
++ * @usage_id: Attribute usage id of parent physical device as per spec
++ * @attr_usage_id: Attribute usage id as per spec
++ * @report_id: Report id to look for
++ * @flag: Synchronous or asynchronous read
++ * @buffer_size: Size of the buffer in bytes
++ * @buffer: Buffer to store the read data
++ *
++ * Issues a synchronous or asynchronous read request for an input attribute,
++ * accumulating data into the provided buffer until it is full.
++ * Return: 0 on success, -ETIMEDOUT if the device did not respond, or a
++ * negative error code.
++ */
++int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
++ u32 usage_id, u32 attr_usage_id,
++ u32 report_id,
++ enum sensor_hub_read_flags flag,
++ u32 buffer_size, u8 *buffer);
++
++/**
+ * sensor_hub_set_feature() - Feature set request
+ * @hsdev: Hub device instance.
+ * @report_id: Report id to look for
--- /dev/null
+From ec2612b8ad9e642596db011dd8b6568ef1edeaa1 Mon Sep 17 00:00:00 2001
+From: Myeonghun Pak <mhun512@gmail.com>
+Date: Thu, 4 Jun 2026 13:56:58 +0900
+Subject: HID: wacom: stop hardware after post-start probe failures
+
+From: Myeonghun Pak <mhun512@gmail.com>
+
+commit ec2612b8ad9e642596db011dd8b6568ef1edeaa1 upstream.
+
+wacom_parse_and_register() starts HID hardware before registering inputs
+and initializing pad LEDs/remotes. Those later steps can fail, but their
+error paths currently release Wacom resources without stopping the HID
+hardware.
+
+Route post-hid_hw_start() failures through hid_hw_stop() before
+releasing driver resources.
+
+This issue was identified during our ongoing static-analysis research while
+reviewing kernel code.
+
+Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start")
+Cc: stable@vger.kernel.org
+Co-developed-by: Ijae Kim <ae878000@gmail.com>
+Signed-off-by: Ijae Kim <ae878000@gmail.com>
+Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
+Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/wacom_sys.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/hid/wacom_sys.c
++++ b/drivers/hid/wacom_sys.c
+@@ -2422,16 +2422,16 @@ static int wacom_parse_and_register(stru
+
+ error = wacom_register_inputs(wacom);
+ if (error)
+- goto fail;
++ goto fail_hw_stop;
+
+ if (wacom->wacom_wac.features.device_type & WACOM_DEVICETYPE_PAD) {
+ error = wacom_initialize_leds(wacom);
+ if (error)
+- goto fail;
++ goto fail_hw_stop;
+
+ error = wacom_initialize_remotes(wacom);
+ if (error)
+- goto fail;
++ goto fail_hw_stop;
+ }
+
+ if (!wireless) {
+@@ -2445,14 +2445,14 @@ static int wacom_parse_and_register(stru
+ cancel_delayed_work_sync(&wacom->init_work);
+ _wacom_query_tablet_data(wacom);
+ error = -ENODEV;
+- goto fail_quirks;
++ goto fail_hw_stop;
+ }
+
+ if (features->device_type & WACOM_DEVICETYPE_WL_MONITOR) {
+ error = hid_hw_open(hdev);
+ if (error) {
+ hid_err(hdev, "hw open failed\n");
+- goto fail_quirks;
++ goto fail_hw_stop;
+ }
+ }
+
+@@ -2461,7 +2461,7 @@ static int wacom_parse_and_register(stru
+
+ return 0;
+
+-fail_quirks:
++fail_hw_stop:
+ hid_hw_stop(hdev);
+ fail:
+ wacom_release_resources(wacom);
--- /dev/null
+From 69f888381d2ecbe18ed9f112c096f8fd3623db98 Mon Sep 17 00:00:00 2001
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Date: Mon, 11 May 2026 12:12:11 +0530
+Subject: OPP: of: Fix potential memory leak in opp_parse_supplies()
+
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+
+commit 69f888381d2ecbe18ed9f112c096f8fd3623db98 upstream.
+
+The memory allocated for microvolt, microamp and microwatt is not freed
+in one of the paths in opp_parse_supplies() which returns directly.
+Fix that by adding a goto to the error unwind ladder.
+
+Fixes: 2eedf62e66c2 ("OPP: decouple dt properties in opp_parse_supplies()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/opp/of.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/opp/of.c
++++ b/drivers/opp/of.c
+@@ -710,7 +710,7 @@ static int opp_parse_supplies(struct dev
+ */
+ if (unlikely(opp_table->regulator_count == -1)) {
+ opp_table->regulator_count = 0;
+- return 0;
++ goto free_microwatt;
+ }
+
+ for (i = 0, j = 0; i < opp_table->regulator_count; i++) {
+@@ -733,6 +733,7 @@ static int opp_parse_supplies(struct dev
+ opp->supplies[i].u_watt = microwatt[i];
+ }
+
++free_microwatt:
+ kfree(microwatt);
+ free_microamp:
+ kfree(microamp);
--- /dev/null
+From 87bd2ad568e15b90d5f7d4bcd70342d05dad649c Mon Sep 17 00:00:00 2001
+From: WenTao Liang <vulab@iscas.ac.cn>
+Date: Fri, 12 Jun 2026 00:17:38 +0800
+Subject: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path
+
+From: WenTao Liang <vulab@iscas.ac.cn>
+
+commit 87bd2ad568e15b90d5f7d4bcd70342d05dad649c upstream.
+
+In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference
+via get_pid() and stores it in timer.it.cpu.pid. If the subsequent
+posix_cpu_timer_set() call fails, the function returns immediately
+without calling posix_cpu_timer_del() to release the pid reference,
+causing a leak.
+
+Fix it by calling posix_cpu_timer_del() before the unlock-and-return
+on the error path, consistent with the other exit paths in the same
+function.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260611161738.97043-1-vulab@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/posix-cpu-timers.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/time/posix-cpu-timers.c
++++ b/kernel/time/posix-cpu-timers.c
+@@ -1535,6 +1535,7 @@ static int do_cpu_nanosleep(const clocki
+ spin_lock_irq(&timer.it_lock);
+ error = posix_cpu_timer_set(&timer, flags, &it, NULL);
+ if (error) {
++ posix_cpu_timer_del(&timer);
+ spin_unlock_irq(&timer.it_lock);
+ return error;
+ }
--- /dev/null
+From dd29c017aed628076e915fe4cdfb5392fd4c5cab Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Fri, 15 May 2026 10:37:40 -0400
+Subject: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit dd29c017aed628076e915fe4cdfb5392fd4c5cab upstream.
+
+RT migration is done aggressively. When a CPU schedules out a high
+priority RT task for a lower priority task, it will look to see if there's
+any RT tasks that are waiting to run on another CPU that is of higher
+priority than the task this CPU is about to run. If it finds one, it will
+pull that task over to the CPU and allow it to run there instead.
+
+Normally, this pulling is done by looking at the RT overloaded mask (rto)
+which contains all the CPUs in the scheduler domain with RT tasks that are
+waiting to run due to a higher priority RT task currently running on their
+CPU. The CPU that is about to schedule a lower priority task will grab the
+rq lock of the overloaded CPU and move the RT task from that CPU's runqueue
+to the local one and schedule the higher priority RT task.
+
+This caused issues when a lot of CPUs would schedule a lower priority task
+at the same time. They would all try to grab the same runqueue lock of
+the CPU with the overloaded RT tasks. Only the first CPU that got in will
+get that task. All the others would wait until they got the runqueue lock
+and see there's nothing to pull and do nothing. On systems with lots of
+CPUs, this caused a large latency (up to 500us) which is beyond what
+PREEMPT_RT is to allow.
+
+The solution to that was to create an RT_PUSH_IPI logic. When any CPU
+wanted to pull a task, instead of grabbing the runqueue lock of the
+overloaded CPU, it would start by sending an IPI to the overloaded CPU,
+and that IPI handler would have the CPU with the waiting RT task do a push
+instead. Then that handler would send an IPI to the next CPU with
+overloaded RT tasks, and so on. Note, after the first CPU starts this
+process, if another CPU wanted to do a pull, it would see that the process
+has already begun and would only increment a counter to have the IPIs
+continue again.
+
+The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause
+a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded
+context on PREEMPT_RT but they can run in an interrupt context in non-RT.
+
+If an IPI lands on a CPU that has just woken up multiple RT tasks and the
+current CPU is running a non RT or a low priority RT task, instead of
+doing a push, it would simply do a schedule on that CPU. But if a softirq
+was also executing on this CPU, the schedule would need to wait until the
+softirq finished. Until then, the CPU would still be considered overloaded
+as there are RT tasks still waiting to run on it.
+
+A live lock occurred on a workload that was doing heavy networking traffic
+on a large machine where the softirqs would run 500us out of 750us. And it
+would also be waking up RT tasks, causing the RT pull logic to be
+constantly executed.
+
+When a softirq triggered on a CPU with RT tasks queued but not running
+yet, and the other CPUs would see this CPU as being overloaded, they would
+send an IPI over to it. The CPU would notice that the waiting RT tasks are
+of higher priority than the currently running task and simply schedule
+that CPU instead. But because the softirq was executing, before it could
+schedule, it would receive another IPI to do the same. The amount of IPIs
+would slow down the currently running softirq so much that before it could
+return back to task context, it would execute another softirq never
+allowing the CPU to schedule. This live locked that CPU.
+
+As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if
+PREEMPT_RT is not enabled.
+
+Fixes: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling")
+Closes: https://lore.kernel.org/all/20260506235716.2530720-1-tj@kernel.org/
+Reported-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260515103740.25ccbed8@gandalf.local.home
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/features.h | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/kernel/sched/features.h
++++ b/kernel/sched/features.h
+@@ -68,8 +68,16 @@ SCHED_FEAT(WARN_DOUBLE_CLOCK, false)
+ * rq lock and possibly create a large contention, sending an
+ * IPI to that CPU and let that CPU push the RT task to where
+ * it should go may be a better scenario.
++ *
++ * This is best for PREEMPT_RT, but for non-RT it can cause issues
++ * when preemption is disabled for long periods of time. Have
++ * it only default enabled for PREEMPT_RT.
+ */
++# ifdef CONFIG_PREEMPT_RT
+ SCHED_FEAT(RT_PUSH_IPI, true)
++# else
++SCHED_FEAT(RT_PUSH_IPI, false)
++# endif
+ #endif
+
+ SCHED_FEAT(RT_RUNTIME_SHARE, false)
smb-client-use-unaligned-reads-in-parse_posix_ctxt.patch
smb-client-harden-posix-sid-length-parsing.patch
smb-client-mask-server-provided-mode-to-07777-in-modefromsid.patch
+opp-of-fix-potential-memory-leak-in-opp_parse_supplies.patch
+firmware_loader-fix-device-reference-leak-in-firmware_upload_register.patch
+cpufreq-intel_pstate-sync-policy-cur-during-cpu-offline.patch
+sched-rt-have-rt_push_ipi-be-default-off-for-non-preempt_rt.patch
+cpufreq-fix-hotplug-suspend-race-during-reboot.patch
+cpufreq-pcc-fix-use-after-free-and-double-free-in-_osc-evaluation.patch
+posix-cpu-timers-fix-pid-refcount-leak-in-do_cpu_nanosleep-error-path.patch
+clocksource-drivers-timer-tegra186-fix-support-for-multiple-watchdog-instances.patch
+x.509-fix-validation-of-asn.1-certificate-header.patch
+tools-mm-slabinfo-fix-trace-disable-logic-inversion.patch
+tools-mm-slabinfo-fix-total_objects-attribute-name.patch
+hid-wacom-stop-hardware-after-post-start-probe-failures.patch
+hid-letsketch-fix-uaf-on-inrange_timer-at-driver-unbind.patch
+hid-lg-g15-cancel-pending-work-on-remove-to-fix-a-use-after-free.patch
+hid-sensor-hub-add-sensor_hub_input_attr_read_values-for-multi-byte-reads.patch
--- /dev/null
+From 892a7864730775c3dbee2a39e9ead4fa8d4256e7 Mon Sep 17 00:00:00 2001
+From: Yichong Chen <chenyichong@uniontech.com>
+Date: Fri, 12 Jun 2026 15:13:59 +0800
+Subject: tools/mm/slabinfo: fix total_objects attribute name
+
+From: Yichong Chen <chenyichong@uniontech.com>
+
+commit 892a7864730775c3dbee2a39e9ead4fa8d4256e7 upstream.
+
+SLUB exports the total_objects sysfs attribute, but slabinfo tries to read
+objects_total. As a result, the lookup fails and the field remains zero.
+
+Use the correct attribute name and rename the corresponding structure
+member to match.
+
+Fixes: 205ab99dd103 ("slub: Update statistics handling for variable order slabs")
+Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
+Cc: <stable@vger.kernel.org>
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Link: https://patch.msgid.link/96556748872BB47E+20260612071359.649946-1-chenyichong@uniontech.com
+Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/mm/slabinfo.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tools/mm/slabinfo.c
++++ b/tools/mm/slabinfo.c
+@@ -33,7 +33,7 @@ struct slabinfo {
+ unsigned int hwcache_align, object_size, objs_per_slab;
+ unsigned int sanity_checks, slab_size, store_user, trace;
+ int order, poison, reclaim_account, red_zone;
+- unsigned long partial, objects, slabs, objects_partial, objects_total;
++ unsigned long partial, objects, slabs, objects_partial, total_objects;
+ unsigned long alloc_fastpath, alloc_slowpath;
+ unsigned long free_fastpath, free_slowpath;
+ unsigned long free_frozen, free_add_partial, free_remove_partial;
+@@ -1256,7 +1256,7 @@ static void read_slab_dir(void)
+ slab->object_size = get_obj("object_size");
+ slab->objects = get_obj("objects");
+ slab->objects_partial = get_obj("objects_partial");
+- slab->objects_total = get_obj("objects_total");
++ slab->total_objects = get_obj("total_objects");
+ slab->objs_per_slab = get_obj("objs_per_slab");
+ slab->order = get_obj("order");
+ slab->partial = get_obj("partial");
--- /dev/null
+From 235ab68d67eadbef1fdbfb771f21f5bacc77a2ae Mon Sep 17 00:00:00 2001
+From: Xuewen Wang <wangxuewen@kylinos.cn>
+Date: Mon, 18 May 2026 14:21:57 +0800
+Subject: tools/mm/slabinfo: Fix trace disable logic inversion
+
+From: Xuewen Wang <wangxuewen@kylinos.cn>
+
+commit 235ab68d67eadbef1fdbfb771f21f5bacc77a2ae upstream.
+
+The disable trace path in slab_debug() had a logic error where it would
+set trace=1 instead of trace=0. This made trace functionality permanently
+enabled once turned on for any slab cache.
+
+Fixes: a87615b8f9e2 ("SLUB: slabinfo upgrade")
+Cc: stable@vger.kernel.org
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Signed-off-by: Xuewen Wang <wangxuewen@kylinos.cn>
+WARNING: From:/Signed-off-by: email address mismatch: 'From: wangxuewen <18810879172@163.com>' != 'Signed-off-by: wangxuewen <wangxuewen@kylinos.cn>'
+Link: https://patch.msgid.link/20260518062159.80664-2-wangxuewen@kylinos.cn
+Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/mm/slabinfo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/mm/slabinfo.c
++++ b/tools/mm/slabinfo.c
+@@ -795,7 +795,7 @@ static void slab_debug(struct slabinfo *
+ fprintf(stderr, "%s can only enable trace for one slab at a time\n", s->name);
+ }
+ if (!tracing && s->trace)
+- set_obj(s, "trace", 1);
++ set_obj(s, "trace", 0);
+ }
+
+ static void totals(void)
--- /dev/null
+From 3b626ba431c4501512ad07549310685e07fe4706 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Thu, 14 May 2026 08:55:58 +0200
+Subject: X.509: Fix validation of ASN.1 certificate header
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 3b626ba431c4501512ad07549310685e07fe4706 upstream.
+
+x509_load_certificate_list() seeks to enforce that a certificate starts
+with 0x30 0x82 (ASN.1 SEQUENCE tag followed by a length of more than 256
+and less than 65535 bytes).
+
+But it only enforces that *either* of those two byte values are present,
+instead of checking for the *conjunction* of the two values. Fix it.
+
+Fixes: 631cc66eb9ea ("MODSIGN: Provide module signing public keys to the kernel")
+Reported-by: Sashiko <sashiko-bot@kernel.org>
+Closes: https://lore.kernel.org/r/20260508033917.B5873C2BCB0@smtp.kernel.org/
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v3.7+
+Reviewed-by: Ignat Korchagin <ignat@linux.win>
+Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/asymmetric_keys/x509_loader.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/asymmetric_keys/x509_loader.c
++++ b/crypto/asymmetric_keys/x509_loader.c
+@@ -20,7 +20,7 @@ int x509_load_certificate_list(const u8
+ */
+ if (end - p < 4)
+ goto dodgy_cert;
+- if (p[0] != 0x30 &&
++ if (p[0] != 0x30 ||
+ p[1] != 0x82)
+ goto dodgy_cert;
+ plen = (p[2] << 8) | p[3];
projects / thirdparty / kernel / stable-queue.git / commitdiff
