From: Greg Kroah-Hartman Date: Thu, 7 May 2026 11:34:17 +0000 (+0200) Subject: 6.12-stable patches X-Git-Tag: v6.6.138~8 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=20015c1e1c9402465193f712f3e78a1711e85e45;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: acpi-cppc-fix-related_cpus-inconsistency-during-cpu-hotplug.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-video-force-native-backlight-on-hp-omen-16-8a44.patch asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch fbdev-udlfb-add-vm_ops-to-dlfb_ops_mmap-to-prevent-use-after-free.patch iommufd-fix-a-race-with-concurrent-allocation-and-unmap.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 ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch scsi-target-configfs-bound-snprintf-return-in-tg_pt_gp_members_show.patch series spi-rockchip-fix-controller-deregistration.patch --- diff --git a/queue-6.12/acpi-cppc-fix-related_cpus-inconsistency-during-cpu-hotplug.patch b/queue-6.12/acpi-cppc-fix-related_cpus-inconsistency-during-cpu-hotplug.patch new file mode 100644 index 0000000000..a5bd916f03 --- /dev/null +++ b/queue-6.12/acpi-cppc-fix-related_cpus-inconsistency-during-cpu-hotplug.patch @@ -0,0 +1,140 @@ +From 75141a770f4f8225d316f6c7e146723a32e9720e Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Fri, 17 Apr 2026 12:01:12 +0800 +Subject: ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug + +From: Jinjie Ruan + +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 +Fixes: 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs") +Co-developed-by: Sean Kelley +Signed-off-by: Sean Kelley +Signed-off-by: Jinjie Ruan +[ rjw: Changelog edits ] +Link: https://patch.msgid.link/20260417040112.3727756-1-ruanjinjie@huawei.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -349,7 +349,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) +@@ -511,13 +511,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) diff --git a/queue-6.12/acpi-scan-use-acpi_dev_put-in-object-add-error-paths.patch b/queue-6.12/acpi-scan-use-acpi_dev_put-in-object-add-error-paths.patch new file mode 100644 index 0000000000..7227952a04 --- /dev/null +++ b/queue-6.12/acpi-scan-use-acpi_dev_put-in-object-add-error-paths.patch @@ -0,0 +1,61 @@ +From 9c0acc169ac71535477caedea8315f7041c5f07c Mon Sep 17 00:00:00 2001 +From: Guangshuo Li +Date: Mon, 13 Apr 2026 21:53:43 +0800 +Subject: ACPI: scan: Use acpi_dev_put() in object add error paths + +From: Guangshuo Li + +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 +Signed-off-by: Guangshuo Li +Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -986,7 +986,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 +@@ -1914,7 +1914,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; + } + diff --git a/queue-6.12/acpi-video-add-backlight-native-quirk-for-dell-optiplex-7770-aio.patch b/queue-6.12/acpi-video-add-backlight-native-quirk-for-dell-optiplex-7770-aio.patch new file mode 100644 index 0000000000..83c1ff7faa --- /dev/null +++ b/queue-6.12/acpi-video-add-backlight-native-quirk-for-dell-optiplex-7770-aio.patch @@ -0,0 +1,49 @@ +From ad7997f5a01af6f711fe6b6a2df578b964109d49 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Jan=20Sch=C3=A4r?= +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 + +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 +Signed-off-by: Jan Schär +Reviewed-by: Hans de Goede +Link: https://patch.msgid.link/20260411092606.47925-1-jan@jschaer.ch +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-6.12/acpi-video-force-native-backlight-on-hp-omen-16-8a44.patch b/queue-6.12/acpi-video-force-native-backlight-on-hp-omen-16-8a44.patch new file mode 100644 index 0000000000..c2eaea7e3a --- /dev/null +++ b/queue-6.12/acpi-video-force-native-backlight-on-hp-omen-16-8a44.patch @@ -0,0 +1,49 @@ +From 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 Mon Sep 17 00:00:00 2001 +From: Shivam Kalra +Date: Sun, 26 Apr 2026 19:38:41 +0530 +Subject: ACPI: video: force native backlight on HP OMEN 16 (8A44) + +From: Shivam Kalra + +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 +Signed-off-by: Shivam Kalra +Link: https://patch.msgid.link/20260426-omen-16-backlight-fix-v1-1-62364f268ea6@zohomail.in +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.12/asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch b/queue-6.12/asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch new file mode 100644 index 0000000000..98844b8c49 --- /dev/null +++ b/queue-6.12/asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch @@ -0,0 +1,37 @@ +From c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Thu, 26 Mar 2026 14:52:41 +0000 +Subject: ASoC: SOF: Don't allow pointer operations on unconfigured streams + +From: Mark Brown + +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 +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/sof/compress.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/soc/sof/compress.c ++++ b/sound/soc/sof/compress.c +@@ -371,6 +371,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, diff --git a/queue-6.12/fbdev-udlfb-add-vm_ops-to-dlfb_ops_mmap-to-prevent-use-after-free.patch b/queue-6.12/fbdev-udlfb-add-vm_ops-to-dlfb_ops_mmap-to-prevent-use-after-free.patch new file mode 100644 index 0000000000..560e1066ab --- /dev/null +++ b/queue-6.12/fbdev-udlfb-add-vm_ops-to-dlfb_ops_mmap-to-prevent-use-after-free.patch @@ -0,0 +1,111 @@ +From 8de779dc40d35d39fa07387b6f921eb11df0f511 Mon Sep 17 00:00:00 2001 +From: Rajat Gupta +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 + +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 +Acked-by: Greg Kroah-Hartman +Cc: stable@vger.kernel.org +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-6.12/iommufd-fix-a-race-with-concurrent-allocation-and-unmap.patch b/queue-6.12/iommufd-fix-a-race-with-concurrent-allocation-and-unmap.patch new file mode 100644 index 0000000000..028a4c92f4 --- /dev/null +++ b/queue-6.12/iommufd-fix-a-race-with-concurrent-allocation-and-unmap.patch @@ -0,0 +1,54 @@ +From 8602018b1f17fbdaa5e5d79f4c8603ad20640c12 Mon Sep 17 00:00:00 2001 +From: Sina Hassani +Date: Fri, 10 Apr 2026 11:32:44 -0700 +Subject: iommufd: Fix a race with concurrent allocation and unmap + +From: Sina Hassani + +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 +Reviewed-by: Kevin Tian +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -724,6 +724,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: diff --git a/queue-6.12/ipmi-add-limits-to-event-and-receive-message-requests.patch b/queue-6.12/ipmi-add-limits-to-event-and-receive-message-requests.patch new file mode 100644 index 0000000000..c19fe2ee5b --- /dev/null +++ b/queue-6.12/ipmi-add-limits-to-event-and-receive-message-requests.patch @@ -0,0 +1,209 @@ +From c4cca236968683eb0d59abfb12d5c7e4d8514227 Mon Sep 17 00:00:00 2001 +From: Corey Minyard +Date: Mon, 20 Apr 2026 12:39:51 -0500 +Subject: ipmi: Add limits to event and receive message requests + +From: Corey Minyard + +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 +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -162,6 +162,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; + +@@ -394,7 +398,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) +@@ -405,7 +412,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; ++ } + } + + /* +@@ -579,6 +589,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; +@@ -624,6 +635,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 +@@ -662,6 +678,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 +@@ -790,6 +811,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. + */ +@@ -822,15 +863,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); diff --git a/queue-6.12/ipmi-check-event-message-buffer-response-for-bad-data.patch b/queue-6.12/ipmi-check-event-message-buffer-response-for-bad-data.patch new file mode 100644 index 0000000000..196fb876d8 --- /dev/null +++ b/queue-6.12/ipmi-check-event-message-buffer-response-for-bad-data.patch @@ -0,0 +1,44 @@ +From 36920f30e78e69df01f9691c470b6f3ba8aebf98 Mon Sep 17 00:00:00 2001 +From: Corey Minyard +Date: Mon, 20 Apr 2026 12:50:09 -0500 +Subject: ipmi: Check event message buffer response for bad data + +From: Corey Minyard + +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 +Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/ +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: +Signed-off-by: Corey Minyard +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -625,7 +625,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); + diff --git a/queue-6.12/ipmi-si-return-state-to-normal-if-message-allocation-fails.patch b/queue-6.12/ipmi-si-return-state-to-normal-if-message-allocation-fails.patch new file mode 100644 index 0000000000..c2eacb0de4 --- /dev/null +++ b/queue-6.12/ipmi-si-return-state-to-normal-if-message-allocation-fails.patch @@ -0,0 +1,44 @@ +From 09dd798270ff582d7309f285d4aaf5dbebae01cb Mon Sep 17 00:00:00 2001 +From: Corey Minyard +Date: Mon, 20 Apr 2026 13:02:18 -0500 +Subject: ipmi:si: Return state to normal if message allocation fails + +From: Corey Minyard + +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: +Signed-off-by: Corey Minyard +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -481,15 +481,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 && diff --git a/queue-6.12/ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch b/queue-6.12/ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch new file mode 100644 index 0000000000..fe37741702 --- /dev/null +++ b/queue-6.12/ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch @@ -0,0 +1,190 @@ +From c444139cb747bf6de1922b39900fdf02281490f4 Mon Sep 17 00:00:00 2001 +From: DaeMyung Kang +Date: Sat, 25 Apr 2026 18:38:28 +0900 +Subject: ksmbd: rewrite stop_sessions() with restartable iteration + +From: DaeMyung Kang + +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 +Acked-by: Namjae Jeon +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -475,24 +475,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 +@@ -46,6 +46,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) diff --git a/queue-6.12/scsi-target-configfs-bound-snprintf-return-in-tg_pt_gp_members_show.patch b/queue-6.12/scsi-target-configfs-bound-snprintf-return-in-tg_pt_gp_members_show.patch new file mode 100644 index 0000000000..ee3495f6f4 --- /dev/null +++ b/queue-6.12/scsi-target-configfs-bound-snprintf-return-in-tg_pt_gp_members_show.patch @@ -0,0 +1,46 @@ +From 772a896a56e0e3ef9424a025cec9176f9d8f4552 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +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 + +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 +Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") +Assisted-by: gregkh_clanker_t1000 +Signed-off-by: Greg Kroah-Hartman +Link: https://patch.msgid.link/2026041159-garter-theft-3be0@gregkh +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -3172,7 +3172,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; diff --git a/queue-6.12/series b/queue-6.12/series new file mode 100644 index 0000000000..0542d76f90 --- /dev/null +++ b/queue-6.12/series @@ -0,0 +1,13 @@ +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-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 +iommufd-fix-a-race-with-concurrent-allocation-and-unmap.patch +asoc-sof-don-t-allow-pointer-operations-on-unconfigured-streams.patch +spi-rockchip-fix-controller-deregistration.patch +ksmbd-rewrite-stop_sessions-with-restartable-iteration.patch diff --git a/queue-6.12/spi-rockchip-fix-controller-deregistration.patch b/queue-6.12/spi-rockchip-fix-controller-deregistration.patch new file mode 100644 index 0000000000..81661dffee --- /dev/null +++ b/queue-6.12/spi-rockchip-fix-controller-deregistration.patch @@ -0,0 +1,43 @@ +From 53e7a16070feb7d1d4d81a583eaac5e25048b9c3 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Tue, 24 Mar 2026 09:23:23 +0100 +Subject: spi: rockchip: fix controller deregistration + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Link: https://patch.msgid.link/20260324082326.901043-3-johan@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -914,7 +914,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; +@@ -942,6 +942,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);