--- /dev/null
+From 3ea4415015d690a51a3fb1f98dfc9a02f88f7bc4 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Mon, 20 Apr 2026 02:27:13 -0700
+Subject: ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
+
+From: Breno Leitao <leitao@debian.org>
+
+commit 3ea4415015d690a51a3fb1f98dfc9a02f88f7bc4 upstream.
+
+Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
+acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
+call from acpi_processor_setup_cpuidle_dev(), where its return value was
+ignored, to acpi_processor_get_power_info(), where it is now treated as
+a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
+returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
+busy-poll when idle.
+
+On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
+(only WFI, no deep PSCI states beyond it), so the previous
+"count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
+returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
+
+The lpi_states count is already validated in acpi_processor_get_lpi_info(),
+so the check here is redundant. Simplify the loop to iterate over
+lpi_states[1..power.count). When only WFI is present, the loop body
+simply does not execute and the function returns 0, which is the correct
+outcome: there is nothing to validate for FFH and no error to report.
+
+Suggested-by: Huisong Li <lihuisong@huawei.com>
+Cc: stable@vger.kernel.org
+Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/arm64/cpuidle.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
+index 801f9c450142..c68a5db8ebba 100644
+--- a/drivers/acpi/arm64/cpuidle.c
++++ b/drivers/acpi/arm64/cpuidle.c
+@@ -16,7 +16,7 @@
+
+ static int psci_acpi_cpu_init_idle(unsigned int cpu)
+ {
+- int i, count;
++ int i;
+ struct acpi_lpi_state *lpi;
+ struct acpi_processor *pr = per_cpu(processors, cpu);
+
+@@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
+ if (!psci_ops.cpu_suspend)
+ return -EOPNOTSUPP;
+
+- count = pr->power.count - 1;
+- if (count <= 0)
+- return -ENODEV;
+-
+- for (i = 0; i < count; i++) {
++ for (i = 1; i < pr->power.count; i++) {
+ u32 state;
+
+- lpi = &pr->power.lpi_states[i + 1];
++ lpi = &pr->power.lpi_states[i];
+ /*
+ * Only bits[31:0] represent a PSCI power_state while
+ * bits[63:32] must be 0x0 as per ARM ACPI FFH Specification
+--
+2.54.0
+
--- /dev/null
+From 75141a770f4f8225d316f6c7e146723a32e9720e Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Fri, 17 Apr 2026 12:01:12 +0800
+Subject: ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+commit 75141a770f4f8225d316f6c7e146723a32e9720e upstream.
+
+When concurrently bringing up and down two SMT threads of a physical
+core, many warning call traces occur as below:
+
+The issue timeline is as follows:
+
+ 1. When the system starts,
+ cpufreq: CPU: 220, policy->related_cpus: 220-221, policy->cpus: 220-221
+
+ 2. Offline CPU 220 and CPU 221.
+
+ 3. Online CPU 220
+ - CPU 221 is now offline, as acpi_get_psd_map() use
+ for_each_online_cpu(), so the cpu_data->shared_cpu_map,
+ policy->cpus, and related_cpus has only CPU 220.
+
+ cpufreq: CPU: 220, policy->related_cpus: 220, policy->cpus: 220
+
+ 4. Offline CPU 220
+
+ 5. Online CPU 221, the below call trace occurs:
+ - Since CPU 220 and CPU 221 share one policy, and
+ policy->related_cpus = 220 after step 3, so CPU 221
+ is not in policy->related_cpus but
+ per_cpu(cpufreq_cpu_data, cpu221) is not NULL.
+
+After reverting commit 56eb0c0ed345 ("ACPI: CPPC: Fix remaining
+for_each_possible_cpu() to use online CPUs"), the issue disappeared.
+
+The _PSD (P-State Dependency) defines the hardware-level dependency of
+frequency control across CPU cores. Since this relationship is a physical
+attribute of the hardware topology, it remains constant regardless of the
+online or offline status of the CPUs.
+
+Using for_each_online_cpu() in acpi_get_psd_map() is problematic. If a
+CPU is offline, it will be excluded from the shared_cpu_map.
+Consequently, if that CPU is brought online later, the kernel will fail
+to recognize it as part of any shared frequency domain.
+
+Switch back to for_each_possible_cpu() to ensure that all cores defined
+in the ACPI tables are correctly mapped into their respective performance
+domains from the start. This aligns with the logic of policy->related_cpus,
+which must encompass all potentially available cores in the domain to
+prevent logic gaps during CPU hotplug operations.
+
+To resolve the original issue regarding the "nosmt" or "nosmt=force"
+boot parameter, as send_pcc_cmd() function already does if (!desc)
+continue, so reverting that loop back to for_each_possible_cpu() is ok,
+only need to change the match_cpc_ptr NULL case in acpi_get_psd_map() to
+continue as Sean suggested.
+
+How to reproduce, on arm64 machine with SMT support which use acpi cppc
+cpufreq driver:
+
+ bash test.sh 220 & bash test.sh 221 &
+
+ The test.sh is as below:
+ while true
+ do
+ echo 0 > /sys/devices/system/cpu/cpu${1}/online
+ sleep 0.5
+ cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus
+ echo 1 > /sys/devices/system/cpu/cpu${1}/online
+ cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus
+ done
+
+ CPU: 221 PID: 1119 Comm: cpuhp/221 Kdump: loaded Not tainted 6.6.0debug+ #5
+ Hardware name: To be filled by O.E.M. S920X20/BC83AMDA01-7270Z, BIOS 20.39 09/04/2024
+ pstate: a1400009 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
+ pc : cpufreq_online+0x8ac/0xa90
+ lr : cpuhp_cpufreq_online+0x18/0x30
+ sp : ffff80008739bce0
+ x29: ffff80008739bce0 x28: 0000000000000000 x27: ffff28400ca32200
+ x26: 0000000000000000 x25: 0000000000000003 x24: ffffd483503ff000
+ x23: ffffd483504051a0 x22: ffffd48350024a00 x21: 00000000000000dd
+ x20: 000000000000001d x19: ffff28400ca32000 x18: 0000000000000000
+ x17: 0000000000000020 x16: ffffd4834e6a3fc8 x15: 0000000000000020
+ x14: 0000000000000008 x13: 0000000000000001 x12: 00000000ffffffff
+ x11: 0000000000000040 x10: ffffd48350430728 x9 : ffffd4834f087c78
+ x8 : 0000000000000001 x7 : ffff2840092bdf00 x6 : ffffd483504264f0
+ x5 : ffffd48350405000 x4 : ffff283f7f95cc60 x3 : 0000000000000000
+ x2 : ffff53bc2f94b000 x1 : 00000000000000dd x0 : 0000000000000000
+ Call trace:
+ cpufreq_online+0x8ac/0xa90
+ cpuhp_cpufreq_online+0x18/0x30
+ cpuhp_invoke_callback+0x128/0x580
+ cpuhp_thread_fun+0x110/0x1b0
+ smpboot_thread_fn+0x140/0x190
+ kthread+0xec/0x100
+ ret_from_fork+0x10/0x20
+ ---[ end trace 0000000000000000 ]---
+
+Cc: All applicable <stable@vger.kernel.org>
+Fixes: 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs")
+Co-developed-by: Sean Kelley <skelley@nvidia.com>
+Signed-off-by: Sean Kelley <skelley@nvidia.com>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+[ rjw: Changelog edits ]
+Link: https://patch.msgid.link/20260417040112.3727756-1-ruanjinjie@huawei.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/cppc_acpi.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/acpi/cppc_acpi.c
++++ b/drivers/acpi/cppc_acpi.c
+@@ -362,7 +362,7 @@ static int send_pcc_cmd(int pcc_ss_id, u
+ end:
+ if (cmd == CMD_WRITE) {
+ if (unlikely(ret)) {
+- for_each_online_cpu(i) {
++ for_each_possible_cpu(i) {
+ struct cpc_desc *desc = per_cpu(cpc_desc_ptr, i);
+
+ if (!desc)
+@@ -524,13 +524,13 @@ int acpi_get_psd_map(unsigned int cpu, s
+ else if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ANY)
+ cpu_data->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+
+- for_each_online_cpu(i) {
++ for_each_possible_cpu(i) {
+ if (i == cpu)
+ continue;
+
+ match_cpc_ptr = per_cpu(cpc_desc_ptr, i);
+ if (!match_cpc_ptr)
+- goto err_fault;
++ continue;
+
+ match_pdomain = &(match_cpc_ptr->domain_info);
+ if (match_pdomain->domain != pdomain->domain)
--- /dev/null
+From 9c0acc169ac71535477caedea8315f7041c5f07c Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Mon, 13 Apr 2026 21:53:43 +0800
+Subject: ACPI: scan: Use acpi_dev_put() in object add error paths
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit 9c0acc169ac71535477caedea8315f7041c5f07c upstream.
+
+After acpi_init_device_object(), the lifetime of struct acpi_device is
+managed by the driver core through reference counting.
+
+Both acpi_add_power_resource() and acpi_add_single_object() call
+acpi_init_device_object() and then invoke acpi_device_add(). If that
+fails, their error paths call the release callback directly instead of
+dropping the device reference through acpi_dev_put().
+
+This bypasses the normal device lifetime rules and frees the object
+without releasing the reference acquired by device_initialize(), which
+may lead to a refcount leak.
+
+The issue was identified by a static analysis tool I developed and
+confirmed by manual review.
+
+Fix both error paths by using acpi_dev_put() and let the release
+callback handle the final cleanup.
+
+Fixes: 781d737c7466 ("ACPI: Drop power resources driver")
+Fixes: 718fb0de8ff88 ("ACPI: fix NULL bug for HID/UID string")
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com
+Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/power.c | 2 +-
+ drivers/acpi/scan.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/acpi/power.c
++++ b/drivers/acpi/power.c
+@@ -991,7 +991,7 @@ struct acpi_device *acpi_add_power_resou
+ return device;
+
+ err:
+- acpi_release_power_resource(&device->dev);
++ acpi_dev_put(device);
+ return NULL;
+ }
+
+--- a/drivers/acpi/scan.c
++++ b/drivers/acpi/scan.c
+@@ -1900,7 +1900,7 @@ static int acpi_add_single_object(struct
+ result = acpi_device_add(device);
+
+ if (result) {
+- acpi_device_release(&device->dev);
++ acpi_dev_put(device);
+ return result;
+ }
+
--- /dev/null
+From ad7997f5a01af6f711fe6b6a2df578b964109d49 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jan=20Sch=C3=A4r?= <jan@jschaer.ch>
+Date: Sat, 11 Apr 2026 11:26:06 +0200
+Subject: ACPI: video: Add backlight=native quirk for Dell OptiPlex 7770 AIO
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jan Schär <jan@jschaer.ch>
+
+commit ad7997f5a01af6f711fe6b6a2df578b964109d49 upstream.
+
+The Dell OptiPlex 7770 AIO needs the same quirk as the 7760 AIO. The
+backlight can be controlled with the native controller, intel_backlight,
+but not with dell_uart_backlight.
+
+I dumped the DSDT using acpidump, acpixtract and iasl, and confirmed
+that it contains the DELL0501 device. When loading the
+dell_uart_backlight driver with `rmmod dell_uart_backlight`, `modprobe
+dell_uart_backlight dyndbg`, it reports "Firmware version: GL_Re_V18".
+
+Fixes: cd8e468efb4f ("ACPI: video: Add Dell UART backlight controller detection")
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Jan Schär <jan@jschaer.ch>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260411092606.47925-1-jan@jschaer.ch
+Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/video_detect.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -878,6 +878,14 @@ static const struct dmi_system_id video_
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7760 AIO"),
+ },
+ },
++ {
++ .callback = video_detect_force_native,
++ /* Dell OptiPlex 7770 AIO */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7770 AIO"),
++ },
++ },
+
+ /*
+ * Models which have nvidia-ec-wmi support, but should not use it.
--- /dev/null
+From 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 Mon Sep 17 00:00:00 2001
+From: Shivam Kalra <shivamkalra98@zohomail.in>
+Date: Sun, 26 Apr 2026 19:38:41 +0530
+Subject: ACPI: video: force native backlight on HP OMEN 16 (8A44)
+
+From: Shivam Kalra <shivamkalra98@zohomail.in>
+
+commit 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 upstream.
+
+The HP OMEN 16 Gaming Laptop (board name 8A44) has a mux-less hybrid
+GPU configuration with AMD Rembrandt (Radeon 680M) and NVIDIA GA104
+(RTX 3070 Ti). The internal eDP panel is wired to the AMD iGPU.
+
+When Nouveau loads without GSP firmware, the ACPI video backlight
+device (acpi_video0) gets registered alongside the native AMD
+backlight (amdgpu_bl2). In this state, writes to amdgpu_bl2 update
+the software brightness value but fail to change the physical panel
+brightness.
+
+Force native backlight to prevent acpi_video0 from registering.
+Confirmed that booting with acpi_backlight=native resolves the
+issue.
+
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
+Link: https://patch.msgid.link/20260426-omen-16-backlight-fix-v1-1-62364f268ea6@zohomail.in
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/video_detect.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -907,6 +907,14 @@ static const struct dmi_system_id video_
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15 3535"),
+ },
+ },
++ {
++ .callback = video_detect_force_native,
++ /* HP OMEN Gaming Laptop 16-n0xxx */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16-n0xxx"),
++ },
++ },
+
+ /*
+ * x86 android tablets which directly control the backlight through
--- /dev/null
+From c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8 Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Thu, 26 Mar 2026 14:52:41 +0000
+Subject: ASoC: SOF: Don't allow pointer operations on unconfigured streams
+
+From: Mark Brown <broonie@kernel.org>
+
+commit c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8 upstream.
+
+When reporting the pointer for a compressed stream we report the current
+I/O frame position by dividing the position by the number of channels
+multiplied by the number of container bytes. These values default to 0 and
+are only configured as part of setting the stream parameters so this allows
+a divide by zero to be configured. Validate that they are non zero,
+returning an error if not
+
+Fixes: c1a731c71359 ("ASoC: SOF: compress: Add support for computing timestamps")
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260326-asoc-compress-tstamp-params-v1-1-3dc735b3d599@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/sof/compress.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/soc/sof/compress.c
++++ b/sound/soc/sof/compress.c
+@@ -379,6 +379,9 @@ static int sof_compr_pointer(struct snd_
+ if (!spcm)
+ return -EINVAL;
+
++ if (!sstream->channels || !sstream->sample_container_bytes)
++ return -EBUSY;
++
+ tstamp->sampling_rate = sstream->sampling_rate;
+ tstamp->copied_total = sstream->copied_total;
+ tstamp->pcm_io_frames = div_u64(spcm->stream[cstream->direction].posn.dai_posn,
--- /dev/null
+From 8de779dc40d35d39fa07387b6f921eb11df0f511 Mon Sep 17 00:00:00 2001
+From: Rajat Gupta <rajgupt@qti.qualcomm.com>
+Date: Sun, 3 May 2026 20:51:10 -0700
+Subject: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free
+
+From: Rajat Gupta <rajgupt@qti.qualcomm.com>
+
+commit 8de779dc40d35d39fa07387b6f921eb11df0f511 upstream.
+
+dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages
+to userspace but sets no vm_ops on the VMA. This means the kernel cannot
+track active mmaps. When dlfb_realloc_framebuffer() replaces the backing
+buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.
+On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages
+while userspace PTEs still reference them, resulting in a use-after-free:
+the process retains read/write access to freed kernel pages.
+
+Add vm_operations_struct with open/close callbacks that maintain an
+atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),
+check mmap_count and return -EBUSY if the buffer is currently mapped,
+preventing buffer replacement while userspace holds stale PTEs.
+
+Tested with PoC using dummy_hcd + raw_gadget USB device emulation.
+
+Signed-off-by: Rajat Gupta <rajgupt@qti.qualcomm.com>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/udlfb.c | 31 ++++++++++++++++++++++++++++++-
+ include/video/udlfb.h | 1 +
+ 2 files changed, 31 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/udlfb.c
++++ b/drivers/video/fbdev/udlfb.c
+@@ -321,12 +321,32 @@ static int dlfb_set_video_mode(struct dl
+ return retval;
+ }
+
++static void dlfb_vm_open(struct vm_area_struct *vma)
++{
++ struct dlfb_data *dlfb = vma->vm_private_data;
++
++ atomic_inc(&dlfb->mmap_count);
++}
++
++static void dlfb_vm_close(struct vm_area_struct *vma)
++{
++ struct dlfb_data *dlfb = vma->vm_private_data;
++
++ atomic_dec(&dlfb->mmap_count);
++}
++
++static const struct vm_operations_struct dlfb_vm_ops = {
++ .open = dlfb_vm_open,
++ .close = dlfb_vm_close,
++};
++
+ static int dlfb_ops_mmap(struct fb_info *info, struct vm_area_struct *vma)
+ {
+ unsigned long start = vma->vm_start;
+ unsigned long size = vma->vm_end - vma->vm_start;
+ unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
+ unsigned long page, pos;
++ struct dlfb_data *dlfb = info->par;
+
+ if (info->fbdefio)
+ return fb_deferred_io_mmap(info, vma);
+@@ -358,6 +378,9 @@ static int dlfb_ops_mmap(struct fb_info
+ size = 0;
+ }
+
++ vma->vm_ops = &dlfb_vm_ops;
++ vma->vm_private_data = dlfb;
++ atomic_inc(&dlfb->mmap_count);
+ return 0;
+ }
+
+@@ -1176,7 +1199,6 @@ static void dlfb_deferred_vfree(struct d
+
+ /*
+ * Assumes &info->lock held by caller
+- * Assumes no active clients have framebuffer open
+ */
+ static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct fb_info *info, u32 new_len)
+ {
+@@ -1188,6 +1210,13 @@ static int dlfb_realloc_framebuffer(stru
+ new_len = PAGE_ALIGN(new_len);
+
+ if (new_len > old_len) {
++ if (atomic_read(&dlfb->mmap_count) > 0) {
++ dev_warn(info->dev,
++ "refusing realloc: %d active mmaps\n",
++ atomic_read(&dlfb->mmap_count));
++ return -EBUSY;
++ }
++
+ /*
+ * Alloc system memory for virtual framebuffer
+ */
+--- a/include/video/udlfb.h
++++ b/include/video/udlfb.h
+@@ -56,6 +56,7 @@ struct dlfb_data {
+ spinlock_t damage_lock;
+ struct work_struct damage_work;
+ struct fb_ops ops;
++ atomic_t mmap_count;
+ /* blit-only rendering path metrics, exposed through sysfs */
+ atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */
+ atomic_t bytes_identical; /* saved effort with backbuffer comparison */
--- /dev/null
+From 8602018b1f17fbdaa5e5d79f4c8603ad20640c12 Mon Sep 17 00:00:00 2001
+From: Sina Hassani <sina@openai.com>
+Date: Fri, 10 Apr 2026 11:32:44 -0700
+Subject: iommufd: Fix a race with concurrent allocation and unmap
+
+From: Sina Hassani <sina@openai.com>
+
+commit 8602018b1f17fbdaa5e5d79f4c8603ad20640c12 upstream.
+
+iopt_unmap_iova_range() releases the lock on iova_rwsem inside the loop
+body when getting to the more expensive unmap operations. This is fine on
+its own, except the loop condition is based on the first area that matches
+the unmap address range. If a concurrent call to map picks an area that
+was unmapped in previous iterations, the loop mistakenly tries to unmap
+it.
+
+This is reproducible by having one userspace thread map buffers and pass
+them to another thread that unmaps them. The problem manifests as EBUSY
+errors with single page mappings.
+
+Fix this by advancing the start pointer after unmapping an area. This
+ensures each iteration only examines the IOVA range that remains mapped,
+which is guaranteed not to have overlaps.
+
+Cc: stable@vger.kernel.org
+Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping")
+Link: https://patch.msgid.link/r/CAAJpGJSR4r_ds1JOjmkqHtsBPyxu8GntoeW08Sk5RNQPmgi+tg@mail.gmail.com
+Signed-off-by: Sina Hassani <sina@openai.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/io_pagetable.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/iommu/iommufd/io_pagetable.c
++++ b/drivers/iommu/iommufd/io_pagetable.c
+@@ -814,6 +814,16 @@ again:
+ unmapped_bytes += area_last - area_first + 1;
+
+ down_write(&iopt->iova_rwsem);
++
++ /*
++ * After releasing the iova_rwsem concurrent allocation could
++ * place new areas at IOVAs we have already unmapped. Keep
++ * moving the start of the search forward to ignore the area
++ * already unmapped.
++ */
++ if (area_last >= last)
++ break;
++ start = area_last + 1;
+ }
+
+ out_unlock_iova:
--- /dev/null
+From c4cca236968683eb0d59abfb12d5c7e4d8514227 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Mon, 20 Apr 2026 12:39:51 -0500
+Subject: ipmi: Add limits to event and receive message requests
+
+From: Corey Minyard <corey@minyard.net>
+
+commit c4cca236968683eb0d59abfb12d5c7e4d8514227 upstream.
+
+The driver would just fetch events and receive messages until the
+BMC said it was done. To avoid issues with BMCs that never say they are
+done, add a limit of 10 fetches at a time.
+
+In addition, an si interface has an attn state it can return from the
+hardware which is supposed to cause a flag fetch to see if the driver
+needs to fetch events or message or a few other things. If the attn
+bit gets stuck, it's a similar problem. So allow messages in between
+flag fetches so the driver itself doesn't get stuck.
+
+This is a more general fix than the previous fix for the specific bad
+BMC, but should fix the more general issue of a BMC that won't stop
+saying it has data.
+
+This has been there from the beginning of the driver. It's not a bug
+per-se, but it is accounting for bugs in BMCs.
+
+Reported-by: Matt Fleming <mfleming@cloudflare.com>
+Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/
+Fixes: <1da177e4c3f4> ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 54 +++++++++++++++++++++++++++++++--------
+ drivers/char/ipmi/ipmi_ssif.c | 23 +++++++++++++++-
+ 2 files changed, 64 insertions(+), 13 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -168,6 +168,10 @@ struct smi_info {
+ OEM2_DATA_AVAIL)
+ unsigned char msg_flags;
+
++ /* When requesting events and messages, don't do it forever. */
++ unsigned int num_requests_in_a_row;
++ bool last_was_flag_fetch;
++
+ /* Does the BMC have an event buffer? */
+ bool has_event_buffer;
+
+@@ -410,7 +414,10 @@ static void start_getting_msg_queue(stru
+
+ start_new_msg(smi_info, smi_info->curr_msg->data,
+ smi_info->curr_msg->data_size);
+- smi_info->si_state = SI_GETTING_MESSAGES;
++ if (smi_info->si_state != SI_GETTING_MESSAGES) {
++ smi_info->num_requests_in_a_row = 0;
++ smi_info->si_state = SI_GETTING_MESSAGES;
++ }
+ }
+
+ static void start_getting_events(struct smi_info *smi_info)
+@@ -421,7 +428,10 @@ static void start_getting_events(struct
+
+ start_new_msg(smi_info, smi_info->curr_msg->data,
+ smi_info->curr_msg->data_size);
+- smi_info->si_state = SI_GETTING_EVENTS;
++ if (smi_info->si_state != SI_GETTING_EVENTS) {
++ smi_info->num_requests_in_a_row = 0;
++ smi_info->si_state = SI_GETTING_EVENTS;
++ }
+ }
+
+ /*
+@@ -595,6 +605,7 @@ static void handle_transaction_done(stru
+ smi_info->si_state = SI_NORMAL;
+ } else {
+ smi_info->msg_flags = msg[3];
++ smi_info->last_was_flag_fetch = true;
+ handle_flags(smi_info);
+ }
+ break;
+@@ -640,6 +651,11 @@ static void handle_transaction_done(stru
+ } else {
+ smi_inc_stat(smi_info, events);
+
++ smi_info->num_requests_in_a_row++;
++ if (smi_info->num_requests_in_a_row > 10)
++ /* Stop if we do this too many times. */
++ smi_info->msg_flags &= ~EVENT_MSG_BUFFER_FULL;
++
+ /*
+ * Do this before we deliver the message
+ * because delivering the message releases the
+@@ -678,6 +694,11 @@ static void handle_transaction_done(stru
+ } else {
+ smi_inc_stat(smi_info, incoming_messages);
+
++ smi_info->num_requests_in_a_row++;
++ if (smi_info->num_requests_in_a_row > 10)
++ /* Stop if we do this too many times. */
++ smi_info->msg_flags &= ~RECEIVE_MSG_AVAIL;
++
+ /*
+ * Do this before we deliver the message
+ * because delivering the message releases the
+@@ -820,6 +841,26 @@ restart:
+ }
+
+ /*
++ * If we are currently idle, or if the last thing that was
++ * done was a flag fetch and there is a message pending, try
++ * to start the next message.
++ *
++ * We do the waiting message check to avoid a stuck flag
++ * completely wedging the driver. Let a message through
++ * in between flag operations if that happens.
++ */
++ if (si_sm_result == SI_SM_IDLE ||
++ (si_sm_result == SI_SM_ATTN && smi_info->waiting_msg &&
++ smi_info->last_was_flag_fetch)) {
++ smi_info->last_was_flag_fetch = false;
++ smi_inc_stat(smi_info, idles);
++
++ si_sm_result = start_next_msg(smi_info);
++ if (si_sm_result != SI_SM_IDLE)
++ goto restart;
++ }
++
++ /*
+ * We prefer handling attn over new messages. But don't do
+ * this if there is not yet an upper layer to handle anything.
+ */
+@@ -846,15 +887,6 @@ restart:
+ }
+ }
+
+- /* If we are currently idle, try to start the next message. */
+- if (si_sm_result == SI_SM_IDLE) {
+- smi_inc_stat(smi_info, idles);
+-
+- si_sm_result = start_next_msg(smi_info);
+- if (si_sm_result != SI_SM_IDLE)
+- goto restart;
+- }
+-
+ if ((si_sm_result == SI_SM_IDLE)
+ && (atomic_read(&smi_info->req_events))) {
+ /*
+--- a/drivers/char/ipmi/ipmi_ssif.c
++++ b/drivers/char/ipmi/ipmi_ssif.c
+@@ -225,6 +225,9 @@ struct ssif_info {
+ bool has_event_buffer;
+ bool supports_alert;
+
++ /* When requesting events and messages, don't do it forever. */
++ unsigned int num_requests_in_a_row;
++
+ /*
+ * Used to tell what we should do with alerts. If we are
+ * waiting on a response, read the data immediately.
+@@ -413,7 +416,10 @@ static void start_event_fetch(struct ssi
+ }
+
+ ssif_info->curr_msg = msg;
+- ssif_info->ssif_state = SSIF_GETTING_EVENTS;
++ if (ssif_info->ssif_state != SSIF_GETTING_EVENTS) {
++ ssif_info->num_requests_in_a_row = 0;
++ ssif_info->ssif_state = SSIF_GETTING_EVENTS;
++ }
+ ipmi_ssif_unlock_cond(ssif_info, flags);
+
+ msg->data[0] = (IPMI_NETFN_APP_REQUEST << 2);
+@@ -436,7 +442,10 @@ static void start_recv_msg_fetch(struct
+ }
+
+ ssif_info->curr_msg = msg;
+- ssif_info->ssif_state = SSIF_GETTING_MESSAGES;
++ if (ssif_info->ssif_state != SSIF_GETTING_MESSAGES) {
++ ssif_info->num_requests_in_a_row = 0;
++ ssif_info->ssif_state = SSIF_GETTING_MESSAGES;
++ }
+ ipmi_ssif_unlock_cond(ssif_info, flags);
+
+ msg->data[0] = (IPMI_NETFN_APP_REQUEST << 2);
+@@ -843,6 +852,11 @@ static void msg_done_handler(struct ssif
+ ssif_info->msg_flags &= ~EVENT_MSG_BUFFER_FULL;
+ handle_flags(ssif_info, flags);
+ } else {
++ ssif_info->num_requests_in_a_row++;
++ if (ssif_info->num_requests_in_a_row > 10)
++ /* Stop if we do this too many times. */
++ ssif_info->msg_flags &= ~EVENT_MSG_BUFFER_FULL;
++
+ handle_flags(ssif_info, flags);
+ ssif_inc_stat(ssif_info, events);
+ deliver_recv_msg(ssif_info, msg);
+@@ -876,6 +890,11 @@ static void msg_done_handler(struct ssif
+ ssif_info->msg_flags &= ~RECEIVE_MSG_AVAIL;
+ handle_flags(ssif_info, flags);
+ } else {
++ ssif_info->num_requests_in_a_row++;
++ if (ssif_info->num_requests_in_a_row > 10)
++ /* Stop if we do this too many times. */
++ ssif_info->msg_flags &= ~RECEIVE_MSG_AVAIL;
++
+ ssif_inc_stat(ssif_info, incoming_messages);
+ handle_flags(ssif_info, flags);
+ deliver_recv_msg(ssif_info, msg);
--- /dev/null
+From 36920f30e78e69df01f9691c470b6f3ba8aebf98 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Mon, 20 Apr 2026 12:50:09 -0500
+Subject: ipmi: Check event message buffer response for bad data
+
+From: Corey Minyard <corey@minyard.net>
+
+commit 36920f30e78e69df01f9691c470b6f3ba8aebf98 upstream.
+
+The event message buffer response data size got checked later when
+processing, but check it right after the response comes back. It
+appears some BMCs may return an empty message instead of an error
+when fetching events.
+
+There are apparently some new BMCs that make this error, so we need to
+compensate.
+
+Reported-by: Matt Fleming <mfleming@cloudflare.com>
+Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -641,7 +641,13 @@ static void handle_transaction_done(stru
+ */
+ msg = smi_info->curr_msg;
+ smi_info->curr_msg = NULL;
+- if (msg->rsp[2] != 0) {
++ /*
++ * It appears some BMCs, with no event data, return no
++ * data in the message and not a 0x80 error as the
++ * spec says they should. Shut down processing if
++ * the data is not the right length.
++ */
++ if (msg->rsp[2] != 0 || msg->rsp_size != 19) {
+ /* Error getting event, probably done. */
+ msg->done(msg);
+
--- /dev/null
+From 09dd798270ff582d7309f285d4aaf5dbebae01cb Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Mon, 20 Apr 2026 13:02:18 -0500
+Subject: ipmi:si: Return state to normal if message allocation fails
+
+From: Corey Minyard <corey@minyard.net>
+
+commit 09dd798270ff582d7309f285d4aaf5dbebae01cb upstream.
+
+There were places where nothing would get started if a message
+allocation failed, so the driver needs to return to normal state.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -497,15 +497,19 @@ retry:
+ } else if (smi_info->msg_flags & RECEIVE_MSG_AVAIL) {
+ /* Messages available. */
+ smi_info->curr_msg = alloc_msg_handle_irq(smi_info);
+- if (!smi_info->curr_msg)
++ if (!smi_info->curr_msg) {
++ smi_info->si_state = SI_NORMAL;
+ return;
++ }
+
+ start_getting_msg_queue(smi_info);
+ } else if (smi_info->msg_flags & EVENT_MSG_BUFFER_FULL) {
+ /* Events available. */
+ smi_info->curr_msg = alloc_msg_handle_irq(smi_info);
+- if (!smi_info->curr_msg)
++ if (!smi_info->curr_msg) {
++ smi_info->si_state = SI_NORMAL;
+ return;
++ }
+
+ start_getting_events(smi_info);
+ } else if (smi_info->msg_flags & OEM_DATA_AVAIL &&
--- /dev/null
+From c444139cb747bf6de1922b39900fdf02281490f4 Mon Sep 17 00:00:00 2001
+From: DaeMyung Kang <charsyam@gmail.com>
+Date: Sat, 25 Apr 2026 18:38:28 +0900
+Subject: ksmbd: rewrite stop_sessions() with restartable iteration
+
+From: DaeMyung Kang <charsyam@gmail.com>
+
+commit c444139cb747bf6de1922b39900fdf02281490f4 upstream.
+
+stop_sessions() walks conn_list with hash_for_each() and, for every
+entry, drops conn_list_lock across the transport ->shutdown() call
+before re-acquiring the read lock to continue the loop. The hash
+walk relies on cross-iteration state (the current bucket and the
+hlist position), which is not preserved across unlock/relock: if
+another thread performs a list mutation during the unlocked window,
+the ongoing iteration becomes unreliable and can re-visit
+connections that have already been handled or skip connections that
+have not. The outer `if (!hash_empty(conn_list)) goto again;` retry
+masks the symptom in the common case but does not address the
+unsafe iteration itself.
+
+Reframe the loop so it never relies on iterator state across
+unlock/relock. Under conn_list_lock held for read, pick the first
+connection whose ->shutdown() has not yet been issued by this path,
+pin it by taking an extra reference, record that fact on the
+connection and mark it EXITING while still inside the locked walk,
+then drop the lock. Then call ->shutdown() outside the lock, drop
+the pin (freeing the connection if the handler already released its
+reference), and restart from the top.
+
+Use a new per-connection flag, conn->stop_called, as the "shutdown
+issued from stop_sessions()" marker rather than reusing the status
+state. ksmbd_conn_set_exiting() is also invoked by
+ksmbd_sessions_deregister() on sibling channels of a multichannel
+session without issuing a transport shutdown, so treating
+KSMBD_SESS_EXITING as "already handled here" would skip connections
+that still need shutdown() to wake their handler out of recv(),
+leaving the outer retry waiting indefinitely for the hash to drain.
+stop_sessions() is serialised by init_lock in
+ksmbd_conn_transport_destroy(), so writing stop_called under the
+read lock has no other writer.
+
+Set EXITING inside the locked walk so the selection, the stop_called
+marker, and the status transition all happen together, and guard
+against regressing a connection that has already advanced to
+KSMBD_SESS_RELEASING on its own (for example, if the handler exited
+its receive loop for an unrelated reason between teardown steps).
+
+When the pin drop is the last put, release the transport and pair
+ida_destroy(&target->async_ida) with the ida_init() done in
+ksmbd_conn_alloc(), so stop_sessions() retiring a connection on its
+own does not leak the xarray backing of the embedded async_ida.
+
+The outer retry with msleep() is kept to wait for handler threads to
+reach ksmbd_conn_free() and drain the hash.
+
+Observed with an instrumented build that logs one line per visit and
+widens the unlocked window before ->shutdown() by 200 ms, under
+five concurrent cifs mounts (nosharesock, one connection each):
+
+ * Current code: the same connection address is revisited many
+ times during a single stop_sessions() call and ->shutdown() is
+ invoked well beyond the number of live connections before the
+ hash finally drains.
+
+ * Rewritten code: each live connection produces exactly one
+ ->shutdown() call; the function returns as soon as the hash is
+ empty.
+
+Functional teardown via `ksmbd.control --shutdown` with the same
+five mounts completes cleanly on the rewritten path.
+
+Performance is observably unchanged. Tearing down N concurrent
+nosharesock cifs connections with `ksmbd.control --shutdown` +
+`rmmod ksmbd` takes essentially the same wall time before and after
+the rewrite:
+
+ N before after
+ 10 4.93s 5.34s
+ 30 7.34s 7.03s
+ 50 7.31s 7.01s (3-run avg: 7.04s vs 7.25s)
+ 100 6.98s 6.78s
+ 200 6.77s 6.89s
+
+and the number of ->shutdown() calls equals the number of live
+connections on both paths when the race is not widened. The
+teardown is dominated by the msleep(100)-based outer retry waiting
+for handler threads to run ksmbd_conn_free(), not by the iteration
+itself; the restartable loop's worst-case O(N^2) visit cost is in
+the microseconds even at N=200 and sits far below the msleep(100)
+granularity.
+
+Applied alone on top of ksmbd-for-next-next, this patch does not
+introduce a new leak site. Under the same reproducer (10x
+concurrent-holders + ss -K + ksmbd.control --shutdown + rmmod), the
+tree still shows the pre-existing per-connection transport leak
+count that arises when the last refcount drop lands in one of
+ksmbd_conn_r_count_dec(), __free_opinfo() or session_fd_check() -
+all of which end with a bare kfree() today. kmemleak backtraces
+for the unreferenced objects point into the TCP accept path
+(sk_clone -> inet_csk_clone_lock, sock_alloc_inode) and none
+involve stop_sessions(). Plugging those bare-kfree sites is the
+responsibility of the follow-up patch.
+
+Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
+Cc: stable@vger.kernel.org
+Signed-off-by: DaeMyung Kang <charsyam@gmail.com>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/connection.c | 46 +++++++++++++++++++++++++++++++++++++--------
+ fs/smb/server/connection.h | 1
+ 2 files changed, 39 insertions(+), 8 deletions(-)
+
+--- a/fs/smb/server/connection.c
++++ b/fs/smb/server/connection.c
+@@ -535,24 +535,54 @@ out:
+
+ static void stop_sessions(void)
+ {
+- struct ksmbd_conn *conn;
++ struct ksmbd_conn *conn, *target;
+ struct ksmbd_transport *t;
++ bool any;
+ int bkt;
+
++ /*
++ * Serialised via init_lock; no concurrent stop_sessions() can
++ * touch conn->stop_called, so writing it under the read lock is
++ * safe.
++ */
+ again:
++ target = NULL;
++ any = false;
+ down_read(&conn_list_lock);
+ hash_for_each(conn_list, bkt, conn, hlist) {
+- t = conn->transport;
+- ksmbd_conn_set_exiting(conn);
+- if (t->ops->shutdown) {
+- up_read(&conn_list_lock);
++ any = true;
++ if (conn->stop_called)
++ continue;
++ atomic_inc(&conn->refcnt);
++ conn->stop_called = true;
++ /*
++ * Mark the connection EXITING while still holding the
++ * read lock so the selection and the status transition
++ * happen together. Do not regress a connection that has
++ * already advanced to RELEASING on its own (e.g. the
++ * handler exited its receive loop for an unrelated
++ * reason).
++ */
++ if (READ_ONCE(conn->status) != KSMBD_SESS_RELEASING)
++ ksmbd_conn_set_exiting(conn);
++ target = conn;
++ break;
++ }
++ up_read(&conn_list_lock);
++
++ if (target) {
++ t = target->transport;
++ if (t->ops->shutdown)
+ t->ops->shutdown(t);
+- down_read(&conn_list_lock);
++ if (atomic_dec_and_test(&target->refcnt)) {
++ ida_destroy(&target->async_ida);
++ t->ops->free_transport(t);
++ kfree(target);
+ }
++ goto again;
+ }
+- up_read(&conn_list_lock);
+
+- if (!hash_empty(conn_list)) {
++ if (any) {
+ msleep(100);
+ goto again;
+ }
+--- a/fs/smb/server/connection.h
++++ b/fs/smb/server/connection.h
+@@ -49,6 +49,7 @@ struct ksmbd_conn {
+ struct mutex srv_mutex;
+ int status;
+ unsigned int cli_cap;
++ bool stop_called;
+ union {
+ __be32 inet_addr;
+ #if IS_ENABLED(CONFIG_IPV6)
--- /dev/null
+From 772a896a56e0e3ef9424a025cec9176f9d8f4552 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Sat, 11 Apr 2026 14:06:00 +0200
+Subject: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 772a896a56e0e3ef9424a025cec9176f9d8f4552 upstream.
+
+target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a
+256-byte stack buffer, then will memcpy() cur_len bytes from that
+buffer. snprintf() returns the length the output would have had, which
+can exceed the buffer size when the fabric WWN is long because iSCSI IQN
+names can be up to 223 bytes. The check at the memcpy() site only
+guards the destination page write, not the source read, so memcpy() will
+read past the stack buffer and copy adjacent stack contents to the sysfs
+reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()
+will be triggered.
+
+Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length
+check to avoid buffer overflow") added the same bound to the
+target_lu_gp_members_show() but the tg_pt_gp variant was missed so
+resolve that here.
+
+Cc: Martin K. Petersen <martin.petersen@oracle.com>
+Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6")
+Assisted-by: gregkh_clanker_t1000
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Link: https://patch.msgid.link/2026041159-garter-theft-3be0@gregkh
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/target_core_configfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/target/target_core_configfs.c
++++ b/drivers/target/target_core_configfs.c
+@@ -3227,7 +3227,7 @@ static ssize_t target_tg_pt_gp_members_s
+ config_item_name(&lun->lun_group.cg_item));
+ cur_len++; /* Extra byte for NULL terminator */
+
+- if ((cur_len + len) > PAGE_SIZE) {
++ if (cur_len > TG_PT_GROUP_NAME_BUF || (cur_len + len) > PAGE_SIZE) {
+ pr_warn("Ran out of lu_gp_show_attr"
+ "_members buffer\n");
+ break;
--- /dev/null
+scsi-target-configfs-bound-snprintf-return-in-tg_pt_gp_members_show.patch
+ipmi-add-limits-to-event-and-receive-message-requests.patch
+ipmi-check-event-message-buffer-response-for-bad-data.patch
+ipmi-si-return-state-to-normal-if-message-allocation-fails.patch
+fbdev-udlfb-add-vm_ops-to-dlfb_ops_mmap-to-prevent-use-after-free.patch
+acpi-arm64-cpuidle-tolerate-platforms-with-no-deep-psci-idle-states.patch
+acpi-scan-use-acpi_dev_put-in-object-add-error-paths.patch
+acpi-video-add-backlight-native-quirk-for-dell-optiplex-7770-aio.patch
+acpi-cppc-fix-related_cpus-inconsistency-during-cpu-hotplug.patch
+acpi-video-force-native-backlight-on-hp-omen-16-8a44.patch
+tracepoint-balance-regfunc-on-func_add-failure-in-tracepoint_add_func.patch
+iommufd-fix-a-race-with-concurrent-allocation-and-unmap.patch
+asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch
+wifi-mt76-mt7925-fix-incorrect-tlv-length-in-clc-command.patch
+spi-rockchip-fix-controller-deregistration.patch
+ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch
--- /dev/null
+From 53e7a16070feb7d1d4d81a583eaac5e25048b9c3 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Tue, 24 Mar 2026 09:23:23 +0100
+Subject: spi: rockchip: fix controller deregistration
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 53e7a16070feb7d1d4d81a583eaac5e25048b9c3 upstream.
+
+Make sure to deregister the controller before freeing underlying
+resources like DMA channels during driver unbind.
+
+Fixes: 64e36824b32b ("spi/rockchip: add driver for Rockchip RK3xxx SoCs integrated SPI")
+Cc: stable@vger.kernel.org # 3.17
+Cc: addy ke <addy.ke@rock-chips.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20260324082326.901043-3-johan@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/spi/spi-rockchip.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/spi/spi-rockchip.c
++++ b/drivers/spi/spi-rockchip.c
+@@ -908,7 +908,7 @@ static int rockchip_spi_probe(struct pla
+ break;
+ }
+
+- ret = devm_spi_register_controller(&pdev->dev, ctlr);
++ ret = spi_register_controller(ctlr);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to register controller\n");
+ goto err_free_dma_rx;
+@@ -936,6 +936,8 @@ static void rockchip_spi_remove(struct p
+
+ pm_runtime_get_sync(&pdev->dev);
+
++ spi_unregister_controller(ctlr);
++
+ pm_runtime_put_noidle(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
--- /dev/null
+From fad217e16fded7f3c09f8637b0f6a224d58b5f2e Mon Sep 17 00:00:00 2001
+From: David Carlier <devnexen@gmail.com>
+Date: Mon, 13 Apr 2026 20:06:01 +0100
+Subject: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()
+
+From: David Carlier <devnexen@gmail.com>
+
+commit fad217e16fded7f3c09f8637b0f6a224d58b5f2e upstream.
+
+When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func()
+invokes the subsystem's ext->regfunc() before attempting to install the
+new probe via func_add(). If func_add() then fails (for example, when
+allocate_probes() cannot allocate a new probe array under memory pressure
+and returns -ENOMEM), the function returns the error without calling the
+matching ext->unregfunc(), leaving the side effects of regfunc() behind
+with no installed probe to justify them.
+
+For syscall tracepoints this is particularly unpleasant: syscall_regfunc()
+bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.
+After a leaked failure, the refcount is stuck at a non-zero value with no
+consumer, and every task continues paying the syscall trace entry/exit
+overhead until reboot. Other subsystems providing regfunc()/unregfunc()
+pairs exhibit similarly scoped persistent state.
+
+Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the
+func_add() error path, gated on the same condition used there so the
+unwind is symmetric with the registration.
+
+Fixes: 8cf868affdc4 ("tracing: Have the reg function allow to fail")
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://patch.msgid.link/20260413190601.21993-1-devnexen@gmail.com
+Signed-off-by: David Carlier <devnexen@gmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/tracepoint.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/tracepoint.c
++++ b/kernel/tracepoint.c
+@@ -300,6 +300,8 @@ static int tracepoint_add_func(struct tr
+ lockdep_is_held(&tracepoints_mutex));
+ old = func_add(&tp_funcs, func, prio);
+ if (IS_ERR(old)) {
++ if (tp->ext && tp->ext->unregfunc && !static_key_enabled(&tp->key))
++ tp->ext->unregfunc();
+ WARN_ON_ONCE(warn && PTR_ERR(old) != -ENOMEM);
+ return PTR_ERR(old);
+ }
--- /dev/null
+From 62e037aa8cf5a69b7ea63336705a35c897b9db2b Mon Sep 17 00:00:00 2001
+From: Quan Zhou <quan.zhou@mediatek.com>
+Date: Wed, 25 Feb 2026 17:47:22 +0800
+Subject: wifi: mt76: mt7925: fix incorrect TLV length in CLC command
+
+From: Quan Zhou <quan.zhou@mediatek.com>
+
+commit 62e037aa8cf5a69b7ea63336705a35c897b9db2b upstream.
+
+The previous implementation of __mt7925_mcu_set_clc() set the TLV length
+field (.len) incorrectly during CLC command construction. The length was
+initialized as sizeof(req) - 4, regardless of the actual segment length.
+This could cause the WiFi firmware to misinterpret the command payload,
+resulting in command execution errors.
+
+This patch moves the TLV length assignment to after the segment is
+selected, and sets .len to sizeof(req) + seg->len - 4, matching the
+actual command content. This ensures the firmware receives the
+correct TLV length and parses the command properly.
+
+Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
+Cc: stable@vger.kernel.org
+Signed-off-by: Quan Zhou <quan.zhou@mediatek.com>
+Acked-by: Sean Wang <sean.wang@mediatek.com>
+Link: https://patch.msgid.link/f56ae0e705774dfa8aab3b99e5bbdc92cd93523e.1772011204.git.quan.zhou@mediatek.com
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+@@ -3375,7 +3375,6 @@ __mt7925_mcu_set_clc(struct mt792x_dev *
+ u8 rsvd[64];
+ } __packed req = {
+ .tag = cpu_to_le16(0x3),
+- .len = cpu_to_le16(sizeof(req) - 4),
+
+ .idx = idx,
+ .env = env_cap,
+@@ -3404,6 +3403,7 @@ __mt7925_mcu_set_clc(struct mt792x_dev *
+ memcpy(req.type, rule->type, 2);
+
+ req.size = cpu_to_le16(seg->len);
++ req.len = cpu_to_le16(sizeof(req) + seg->len - 4);
+ dev->phy.clc_chan_conf = clc->ver == 1 ? 0xff : rule->flag;
+ skb = __mt76_mcu_msg_alloc(&dev->mt76, &req,
+ le16_to_cpu(req.size) + sizeof(req),
projects / thirdparty / kernel / stable-queue.git / commitdiff
