--- /dev/null
+From 47a8aad135ac1aed04b7b0c0a8157fd208075827 Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Mon, 23 Feb 2026 17:45:31 +0000
+Subject: arm64: gcs: Honour mprotect(PROT_NONE) on shadow stack mappings
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+commit 47a8aad135ac1aed04b7b0c0a8157fd208075827 upstream.
+
+vm_get_page_prot() short-circuits the protection_map[] lookup for a
+VM_SHADOW_STACK mapping since it uses a different PIE index from the
+typical read/write/exec permissions. However, the side effect is that it
+also ignores mprotect(PROT_NONE) by creating an accessible PTE.
+
+Special-case the !(vm_flags & VM_ACCESS_FLAGS) flags to use the
+protection_map[VM_NONE] permissions instead. No GCS attributes are
+required for an inaccessible PTE.
+
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Fixes: 6497b66ba694 ("arm64/mm: Map pages for guarded control stack")
+Cc: stable@vger.kernel.org
+Cc: Mark Brown <broonie@kernel.org>
+Cc: Will Deacon <will@kernel.org>
+Cc: David Hildenbrand <david@kernel.org>
+Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/mmap.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/mmap.c
++++ b/arch/arm64/mm/mmap.c
+@@ -91,7 +91,11 @@ pgprot_t vm_get_page_prot(vm_flags_t vm_
+
+ /* Short circuit GCS to avoid bloating the table. */
+ if (system_supports_gcs() && (vm_flags & VM_SHADOW_STACK)) {
+- prot = gcs_page_prot;
++ /* Honour mprotect(PROT_NONE) on shadow stack mappings */
++ if (vm_flags & VM_ACCESS_FLAGS)
++ prot = gcs_page_prot;
++ else
++ prot = pgprot_val(protection_map[VM_NONE]);
+ } else {
+ prot = pgprot_val(protection_map[vm_flags &
+ (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]);
--- /dev/null
+From ad6fface76da42721c15e8fb281570aaa44a2c01 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+Date: Wed, 25 Feb 2026 12:12:49 +0100
+Subject: bpf: Fix kprobe_multi cookies access in show_fdinfo callback
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+commit ad6fface76da42721c15e8fb281570aaa44a2c01 upstream.
+
+We don't check if cookies are available on the kprobe_multi link
+before accessing them in show_fdinfo callback, we should.
+
+Cc: stable@vger.kernel.org
+Fixes: da7e9c0a7fbc ("bpf: Add show_fdinfo for kprobe_multi")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Link: https://lore.kernel.org/r/20260225111249.186230-1-jolsa@kernel.org
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/bpf_trace.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/bpf_trace.c
++++ b/kernel/trace/bpf_trace.c
+@@ -2441,8 +2441,10 @@ static void bpf_kprobe_multi_show_fdinfo
+ struct seq_file *seq)
+ {
+ struct bpf_kprobe_multi_link *kmulti_link;
++ bool has_cookies;
+
+ kmulti_link = container_of(link, struct bpf_kprobe_multi_link, link);
++ has_cookies = !!kmulti_link->cookies;
+
+ seq_printf(seq,
+ "kprobe_cnt:\t%u\n"
+@@ -2454,7 +2456,7 @@ static void bpf_kprobe_multi_show_fdinfo
+ for (int i = 0; i < kmulti_link->cnt; i++) {
+ seq_printf(seq,
+ "%llu\t %pS\n",
+- kmulti_link->cookies[i],
++ has_cookies ? kmulti_link->cookies[i] : 0,
+ (void *)kmulti_link->addrs[i]);
+ }
+ }
--- /dev/null
+From f15fb3d41543244d1179f423da4a4832a55bc050 Mon Sep 17 00:00:00 2001
+From: Mark Harmstone <mark@harmstone.com>
+Date: Fri, 20 Feb 2026 12:53:17 +0000
+Subject: btrfs: fix chunk map leak in btrfs_map_block() after btrfs_chunk_map_num_copies()
+
+From: Mark Harmstone <mark@harmstone.com>
+
+commit f15fb3d41543244d1179f423da4a4832a55bc050 upstream.
+
+Fix a chunk map leak in btrfs_map_block(): if we return early with -EINVAL,
+we're not freeing the chunk map that we've just looked up.
+
+Fixes: 0ae653fbec2b ("btrfs: reduce chunk_map lookups in btrfs_map_block()")
+CC: stable@vger.kernel.org # 6.12+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Mark Harmstone <mark@harmstone.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/volumes.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -6759,8 +6759,10 @@ int btrfs_map_block(struct btrfs_fs_info
+ return PTR_ERR(map);
+
+ num_copies = btrfs_chunk_map_num_copies(map);
+- if (io_geom.mirror_num > num_copies)
+- return -EINVAL;
++ if (io_geom.mirror_num > num_copies) {
++ ret = -EINVAL;
++ goto out;
++ }
+
+ map_offset = logical - map->start;
+ io_geom.raid56_full_stripe_start = (u64)-1;
--- /dev/null
+From ab39cc4cb8ceecdc2b61747433e7237f1ac2b789 Mon Sep 17 00:00:00 2001
+From: David Arcari <darcari@redhat.com>
+Date: Tue, 24 Feb 2026 07:21:06 -0500
+Subject: cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request()
+
+From: David Arcari <darcari@redhat.com>
+
+commit ab39cc4cb8ceecdc2b61747433e7237f1ac2b789 upstream.
+
+The update_cpu_qos_request() function attempts to initialize the 'freq'
+variable by dereferencing 'cpudata' before verifying if the 'policy'
+is valid.
+
+This issue occurs on systems booted with the "nosmt" parameter, where
+all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result,
+any call to update_qos_requests() will result in a NULL pointer
+dereference as the code will attempt to access pstate.turbo_freq using
+the NULL cpudata pointer.
+
+Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap()
+after initializing the 'freq' variable, so it is better to defer the
+'freq' until intel_pstate_get_hwp_cap() has been called.
+
+Fix this by deferring the 'freq' assignment until after the policy and
+driver_data have been validated.
+
+Fixes: ae1bdd23b99f ("cpufreq: intel_pstate: Adjust frequency percentage computations")
+Reported-by: Jirka Hladky <jhladky@redhat.com>
+Closes: https://lore.kernel.org/all/CAE4VaGDfiPvz3AzrwrwM4kWB3SCkMci25nPO8W1JmTBd=xHzZg@mail.gmail.com/
+Signed-off-by: David Arcari <darcari@redhat.com>
+Cc: 6.18+ <stable@vger.kernel.org> # 6.18+
+[ rjw: Added one paragraph to the changelog ]
+Link: https://patch.msgid.link/20260224122106.228116-1-darcari@redhat.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/intel_pstate.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -1663,8 +1663,8 @@ unlock_driver:
+ static void update_cpu_qos_request(int cpu, enum freq_qos_req_type type)
+ {
+ struct cpudata *cpudata = all_cpu_data[cpu];
+- unsigned int freq = cpudata->pstate.turbo_freq;
+ struct freq_qos_request *req;
++ unsigned int freq;
+
+ struct cpufreq_policy *policy __free(put_cpufreq_policy) = cpufreq_cpu_get(cpu);
+ if (!policy)
+@@ -1677,6 +1677,8 @@ static void update_cpu_qos_request(int c
+ if (hwp_active)
+ intel_pstate_get_hwp_cap(cpudata);
+
++ freq = cpudata->pstate.turbo_freq;
++
+ if (type == FREQ_QOS_MIN) {
+ freq = DIV_ROUND_UP(freq * global.min_perf_pct, 100);
+ } else {
--- /dev/null
+From 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 10 Feb 2026 14:58:22 +0100
+Subject: device property: Allow secondary lookup in fwnode_get_next_child_node()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 upstream.
+
+When device_get_child_node_count() got split to the fwnode and device
+respective APIs, the fwnode didn't inherit the ability to traverse over
+the secondary fwnode. Hence any user, that switches from device to fwnode
+API misses this feature. In particular, this was revealed by the commit
+1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
+that effectively broke the GPIO enumeration on Intel Galileo boards.
+Fix this by moving the secondary lookup from device to fwnode API.
+
+Note, in general no device_*() API should go into the depth of the fwnode
+implementation.
+
+Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
+Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Link: https://patch.msgid.link/20260210135822.47335-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/property.c | 27 +++++++++++++--------------
+ 1 file changed, 13 insertions(+), 14 deletions(-)
+
+--- a/drivers/base/property.c
++++ b/drivers/base/property.c
+@@ -797,7 +797,18 @@ struct fwnode_handle *
+ fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
+ struct fwnode_handle *child)
+ {
+- return fwnode_call_ptr_op(fwnode, get_next_child_node, child);
++ struct fwnode_handle *next;
++
++ if (IS_ERR_OR_NULL(fwnode))
++ return NULL;
++
++ /* Try to find a child in primary fwnode */
++ next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
++ if (next)
++ return next;
++
++ /* When no more children in primary, continue with secondary */
++ return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
+ }
+ EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
+
+@@ -841,19 +852,7 @@ EXPORT_SYMBOL_GPL(fwnode_get_next_availa
+ struct fwnode_handle *device_get_next_child_node(const struct device *dev,
+ struct fwnode_handle *child)
+ {
+- const struct fwnode_handle *fwnode = dev_fwnode(dev);
+- struct fwnode_handle *next;
+-
+- if (IS_ERR_OR_NULL(fwnode))
+- return NULL;
+-
+- /* Try to find a child in primary fwnode */
+- next = fwnode_get_next_child_node(fwnode, child);
+- if (next)
+- return next;
+-
+- /* When no more children in primary, continue with secondary */
+- return fwnode_get_next_child_node(fwnode->secondary, child);
++ return fwnode_get_next_child_node(dev_fwnode(dev), child);
+ }
+ EXPORT_SYMBOL_GPL(device_get_next_child_node);
+
--- /dev/null
+From 6b0d812971370c64b837a2db4275410f478272fe Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Wed, 25 Feb 2026 10:51:16 -0600
+Subject: drm/amd: Disable MES LR compute W/A
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 6b0d812971370c64b837a2db4275410f478272fe upstream.
+
+A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable
+MES lr_compute_wa by default") to help with some hangs observed in gfx1151.
+
+This WA didn't fully fix the issue. It was actually fixed by adjusting
+the VGPR size to the correct value that matched the hardware in commit
+b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151").
+
+There are reports of instability on other products with newer GC microcode
+versions, and I believe they're caused by this workaround. As we don't
+need the workaround any more, remove it.
+
+Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151")
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 9973e64bd6ee7642860a6f3b6958cbf14e89cabd)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 5 -----
+ drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 5 -----
+ 2 files changed, 10 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
+@@ -714,11 +714,6 @@ static int mes_v11_0_set_hw_resources(st
+ mes_set_hw_res_pkt.enable_reg_active_poll = 1;
+ mes_set_hw_res_pkt.enable_level_process_quantum_check = 1;
+ mes_set_hw_res_pkt.oversubscription_timer = 50;
+- if ((mes->adev->mes.sched_version & AMDGPU_MES_VERSION_MASK) >= 0x7f)
+- mes_set_hw_res_pkt.enable_lr_compute_wa = 1;
+- else
+- dev_info_once(mes->adev->dev,
+- "MES FW version must be >= 0x7f to enable LR compute workaround.\n");
+
+ if (amdgpu_mes_log_enable) {
+ mes_set_hw_res_pkt.enable_mes_event_int_logging = 1;
+--- a/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c
+@@ -775,11 +775,6 @@ static int mes_v12_0_set_hw_resources(st
+ mes_set_hw_res_pkt.use_different_vmid_compute = 1;
+ mes_set_hw_res_pkt.enable_reg_active_poll = 1;
+ mes_set_hw_res_pkt.enable_level_process_quantum_check = 1;
+- if ((mes->adev->mes.sched_version & AMDGPU_MES_VERSION_MASK) >= 0x82)
+- mes_set_hw_res_pkt.enable_lr_compute_wa = 1;
+- else
+- dev_info_once(adev->dev,
+- "MES FW version must be >= 0x82 to enable LR compute workaround.\n");
+
+ /*
+ * Keep oversubscribe timer for sdma . When we have unmapped doorbell
--- /dev/null
+From ea78f8c68f4f6211c557df49174c54d167821962 Mon Sep 17 00:00:00 2001
+From: Sunil Khatri <sunil.khatri@amd.com>
+Date: Fri, 20 Feb 2026 13:47:58 +0530
+Subject: drm/amdgpu: add upper bound check on user inputs in signal ioctl
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sunil Khatri <sunil.khatri@amd.com>
+
+commit ea78f8c68f4f6211c557df49174c54d167821962 upstream.
+
+Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and
+could be exploited.
+
+So check these input value against AMDGPU_USERQ_MAX_HANDLES
+which is big enough value for genuine use cases and could
+potentially avoid OOM.
+
+Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit be267e15f99bc97cbe202cd556717797cdcf79a5)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+@@ -35,6 +35,8 @@
+ static const struct dma_fence_ops amdgpu_userq_fence_ops;
+ static struct kmem_cache *amdgpu_userq_fence_slab;
+
++#define AMDGPU_USERQ_MAX_HANDLES (1U << 16)
++
+ int amdgpu_userq_fence_slab_init(void)
+ {
+ amdgpu_userq_fence_slab = kmem_cache_create("amdgpu_userq_fence",
+@@ -475,6 +477,11 @@ int amdgpu_userq_signal_ioctl(struct drm
+ if (!amdgpu_userq_enabled(dev))
+ return -ENOTSUPP;
+
++ if (args->num_syncobj_handles > AMDGPU_USERQ_MAX_HANDLES ||
++ args->num_bo_write_handles > AMDGPU_USERQ_MAX_HANDLES ||
++ args->num_bo_read_handles > AMDGPU_USERQ_MAX_HANDLES)
++ return -EINVAL;
++
+ num_syncobj_handles = args->num_syncobj_handles;
+ syncobj_handles = memdup_user(u64_to_user_ptr(args->syncobj_handles),
+ size_mul(sizeof(u32), num_syncobj_handles));
--- /dev/null
+From 64ac7c09fc44985ec9bb6a9db740899fa40ca613 Mon Sep 17 00:00:00 2001
+From: Sunil Khatri <sunil.khatri@amd.com>
+Date: Tue, 24 Feb 2026 12:13:09 +0530
+Subject: drm/amdgpu: add upper bound check on user inputs in wait ioctl
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sunil Khatri <sunil.khatri@amd.com>
+
+commit 64ac7c09fc44985ec9bb6a9db740899fa40ca613 upstream.
+
+Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and
+could be exploited.
+
+So check these input value against AMDGPU_USERQ_MAX_HANDLES
+which is big enough value for genuine use cases and could
+potentially avoid OOM.
+
+v2: squash in Srini's fix
+
+Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit fcec012c664247531aed3e662f4280ff804d1476)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+@@ -667,6 +667,11 @@ int amdgpu_userq_wait_ioctl(struct drm_d
+ if (!amdgpu_userq_enabled(dev))
+ return -ENOTSUPP;
+
++ if (wait_info->num_syncobj_handles > AMDGPU_USERQ_MAX_HANDLES ||
++ wait_info->num_bo_write_handles > AMDGPU_USERQ_MAX_HANDLES ||
++ wait_info->num_bo_read_handles > AMDGPU_USERQ_MAX_HANDLES)
++ return -EINVAL;
++
+ num_read_bo_handles = wait_info->num_bo_read_handles;
+ bo_handles_read = memdup_user(u64_to_user_ptr(wait_info->bo_read_handles),
+ size_mul(sizeof(u32), num_read_bo_handles));
--- /dev/null
+From 49abfa812617a7f2d0132c70d23ac98b389c6ec1 Mon Sep 17 00:00:00 2001
+From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
+Date: Mon, 23 Feb 2026 12:41:30 +0000
+Subject: drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctl
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
+
+commit 49abfa812617a7f2d0132c70d23ac98b389c6ec1 upstream.
+
+Drop reference to syncobj and timeline fence when aborting the ioctl due
+output array being too small.
+
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
+Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL")
+Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
+Cc: Christian König <christian.koenig@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27)
+Cc: <stable@vger.kernel.org> # v6.16+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+@@ -879,6 +879,7 @@ int amdgpu_userq_wait_ioctl(struct drm_d
+ dma_fence_unwrap_for_each(f, &iter, fence) {
+ if (num_fences >= wait_info->num_fences) {
+ r = -EINVAL;
++ dma_fence_put(fence);
+ goto free_fences;
+ }
+
+@@ -903,6 +904,7 @@ int amdgpu_userq_wait_ioctl(struct drm_d
+
+ if (num_fences >= wait_info->num_fences) {
+ r = -EINVAL;
++ dma_fence_put(fence);
+ goto free_fences;
+ }
+
--- /dev/null
+From 803ec1faf7c1823e6e3b1f2aaa81be18528c9436 Mon Sep 17 00:00:00 2001
+From: Osama Abdelkader <osama.abdelkader@gmail.com>
+Date: Mon, 9 Feb 2026 19:41:14 +0100
+Subject: drm/bridge: samsung-dsim: Fix memory leak in error path
+
+From: Osama Abdelkader <osama.abdelkader@gmail.com>
+
+commit 803ec1faf7c1823e6e3b1f2aaa81be18528c9436 upstream.
+
+In samsung_dsim_host_attach(), drm_bridge_add() is called to add the
+bridge. However, if samsung_dsim_register_te_irq() or
+pdata->host_ops->attach() fails afterwards, the function returns
+without removing the bridge, causing a memory leak.
+
+Fix this by adding proper error handling with goto labels to ensure
+drm_bridge_remove() is called in all error paths. Also ensure that
+samsung_dsim_unregister_te_irq() is called if the attach operation
+fails after the TE IRQ has been registered.
+
+samsung_dsim_unregister_te_irq() function is moved without changes
+to be before samsung_dsim_host_attach() to avoid forward declaration.
+
+Fixes: e7447128ca4a ("drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge")
+Cc: stable@vger.kernel.org
+Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
+Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Link: https://patch.msgid.link/20260209184115.10937-1-osama.abdelkader@gmail.com
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/bridge/samsung-dsim.c | 25 ++++++++++++++++---------
+ 1 file changed, 16 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/bridge/samsung-dsim.c
++++ b/drivers/gpu/drm/bridge/samsung-dsim.c
+@@ -1881,6 +1881,14 @@ static int samsung_dsim_register_te_irq(
+ return 0;
+ }
+
++static void samsung_dsim_unregister_te_irq(struct samsung_dsim *dsi)
++{
++ if (dsi->te_gpio) {
++ free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
++ gpiod_put(dsi->te_gpio);
++ }
++}
++
+ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
+ struct mipi_dsi_device *device)
+ {
+@@ -1955,13 +1963,13 @@ of_find_panel_or_bridge:
+ if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
+ ret = samsung_dsim_register_te_irq(dsi, &device->dev);
+ if (ret)
+- return ret;
++ goto err_remove_bridge;
+ }
+
+ if (pdata->host_ops && pdata->host_ops->attach) {
+ ret = pdata->host_ops->attach(dsi, device);
+ if (ret)
+- return ret;
++ goto err_unregister_te_irq;
+ }
+
+ dsi->lanes = device->lanes;
+@@ -1969,14 +1977,13 @@ of_find_panel_or_bridge:
+ dsi->mode_flags = device->mode_flags;
+
+ return 0;
+-}
+
+-static void samsung_dsim_unregister_te_irq(struct samsung_dsim *dsi)
+-{
+- if (dsi->te_gpio) {
+- free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
+- gpiod_put(dsi->te_gpio);
+- }
++err_unregister_te_irq:
++ if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO))
++ samsung_dsim_unregister_te_irq(dsi);
++err_remove_bridge:
++ drm_bridge_remove(&dsi->bridge);
++ return ret;
+ }
+
+ static int samsung_dsim_host_detach(struct mipi_dsi_host *host,
--- /dev/null
+From 0b87d51690dd5131cbe9fbd23746b037aab89815 Mon Sep 17 00:00:00 2001
+From: Franz Schnyder <franz.schnyder@toradex.com>
+Date: Fri, 6 Feb 2026 13:37:36 +0100
+Subject: drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
+
+From: Franz Schnyder <franz.schnyder@toradex.com>
+
+commit 0b87d51690dd5131cbe9fbd23746b037aab89815 upstream.
+
+Fallback to polling to detect hotplug events on systems without
+interrupts.
+
+On systems where the interrupt line of the bridge is not connected,
+the bridge cannot notify hotplug events. Only add the
+DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
+otherwise remain in polling mode.
+
+Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
+Cc: stable@vger.kernel.org # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
+Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+[dianders: Adjusted Fixes/stable line based on discussion]
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Link: https://patch.msgid.link/20260206123758.374555-1-fra.schnyder@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
++++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+@@ -1314,6 +1314,7 @@ static int ti_sn_bridge_probe(struct aux
+ {
+ struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
+ struct device_node *np = pdata->dev->of_node;
++ const struct i2c_client *client = to_i2c_client(pdata->dev);
+ int ret;
+
+ pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0);
+@@ -1332,8 +1333,9 @@ static int ti_sn_bridge_probe(struct aux
+ ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP;
+
+ if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
+- pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT |
+- DRM_BRIDGE_OP_HPD;
++ pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
++ if (client->irq)
++ pdata->bridge.ops |= DRM_BRIDGE_OP_HPD;
+ /*
+ * If comms were already enabled they would have been enabled
+ * with the wrong value of HPD_DISABLE. Update it now. Comms
--- /dev/null
+From eb4a7139e97374f42b7242cc754e77f1623fbcd5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jouni=20H=C3=B6gander?= <jouni.hogander@intel.com>
+Date: Thu, 12 Feb 2026 08:27:31 +0200
+Subject: drm/i915/alpm: ALPM disable fixes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jouni Högander <jouni.hogander@intel.com>
+
+commit eb4a7139e97374f42b7242cc754e77f1623fbcd5 upstream.
+
+PORT_ALPM_CTL is supposed to be written only before link training. Remove
+writing it from ALPM disable.
+
+Also clearing ALPM_CTL_ALPM_AUX_LESS_ENABLE and is not about disabling ALPM
+but switching to AUX-Wake ALPM. Stop touching this bit on ALPM disable.
+
+Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7153
+Fixes: 1ccbf135862b ("drm/i915/psr: Enable ALPM on source side for eDP Panel replay")
+Cc: Animesh Manna <animesh.manna@intel.com>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v6.10+
+Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
+Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
+Link: https://patch.msgid.link/20260212062731.397801-1-jouni.hogander@intel.com
+(cherry picked from commit 008304c9ae75c772d3460040de56e12112cdf5e6)
+Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_alpm.c | 7 +------
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_alpm.c
++++ b/drivers/gpu/drm/i915/display/intel_alpm.c
+@@ -577,12 +577,7 @@ void intel_alpm_disable(struct intel_dp
+ mutex_lock(&intel_dp->alpm_parameters.lock);
+
+ intel_de_rmw(display, ALPM_CTL(display, cpu_transcoder),
+- ALPM_CTL_ALPM_ENABLE | ALPM_CTL_LOBF_ENABLE |
+- ALPM_CTL_ALPM_AUX_LESS_ENABLE, 0);
+-
+- intel_de_rmw(display,
+- PORT_ALPM_CTL(cpu_transcoder),
+- PORT_ALPM_CTL_ALPM_AUX_LESS_ENABLE, 0);
++ ALPM_CTL_ALPM_ENABLE | ALPM_CTL_LOBF_ENABLE, 0);
+
+ drm_dbg_kms(display->drm, "Disabling ALPM\n");
+ mutex_unlock(&intel_dp->alpm_parameters.lock);
--- /dev/null
+From 1bfd7575092420ba5a0b944953c95b74a5646ff8 Mon Sep 17 00:00:00 2001
+From: Shuicheng Lin <shuicheng.lin@intel.com>
+Date: Thu, 19 Feb 2026 23:35:18 +0000
+Subject: drm/xe/sync: Cleanup partially initialized sync on parse failure
+
+From: Shuicheng Lin <shuicheng.lin@intel.com>
+
+commit 1bfd7575092420ba5a0b944953c95b74a5646ff8 upstream.
+
+xe_sync_entry_parse() can allocate references (syncobj, fence, chain fence,
+or user fence) before hitting a later failure path. Several of those paths
+returned directly, leaving partially initialized state and leaking refs.
+
+Route these error paths through a common free_sync label and call
+xe_sync_entry_cleanup(sync) before returning the error.
+
+Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
+Cc: Matthew Brost <matthew.brost@intel.com>
+Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Signed-off-by: Matthew Brost <matthew.brost@intel.com>
+Link: https://patch.msgid.link/20260219233516.2938172-5-shuicheng.lin@intel.com
+(cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)
+Cc: stable@vger.kernel.org
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/xe/xe_sync.c | 24 +++++++++++++++++-------
+ 1 file changed, 17 insertions(+), 7 deletions(-)
+
+--- a/drivers/gpu/drm/xe/xe_sync.c
++++ b/drivers/gpu/drm/xe/xe_sync.c
+@@ -146,8 +146,10 @@ int xe_sync_entry_parse(struct xe_device
+
+ if (!signal) {
+ sync->fence = drm_syncobj_fence_get(sync->syncobj);
+- if (XE_IOCTL_DBG(xe, !sync->fence))
+- return -EINVAL;
++ if (XE_IOCTL_DBG(xe, !sync->fence)) {
++ err = -EINVAL;
++ goto free_sync;
++ }
+ }
+ break;
+
+@@ -167,17 +169,21 @@ int xe_sync_entry_parse(struct xe_device
+
+ if (signal) {
+ sync->chain_fence = dma_fence_chain_alloc();
+- if (!sync->chain_fence)
+- return -ENOMEM;
++ if (!sync->chain_fence) {
++ err = -ENOMEM;
++ goto free_sync;
++ }
+ } else {
+ sync->fence = drm_syncobj_fence_get(sync->syncobj);
+- if (XE_IOCTL_DBG(xe, !sync->fence))
+- return -EINVAL;
++ if (XE_IOCTL_DBG(xe, !sync->fence)) {
++ err = -EINVAL;
++ goto free_sync;
++ }
+
+ err = dma_fence_chain_find_seqno(&sync->fence,
+ sync_in.timeline_value);
+ if (err)
+- return err;
++ goto free_sync;
+ }
+ break;
+
+@@ -216,6 +222,10 @@ int xe_sync_entry_parse(struct xe_device
+ sync->timeline_value = sync_in.timeline_value;
+
+ return 0;
++
++free_sync:
++ xe_sync_entry_cleanup(sync);
++ return err;
+ }
+ ALLOW_ERROR_INJECTION(xe_sync_entry_parse, ERRNO);
+
--- /dev/null
+From ec2cceadfae72304ca19650f9cac4b2a97b8a2fc Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
+Date: Thu, 19 Feb 2026 10:51:33 +0100
+Subject: gpiolib: normalize the return value of gc->get() on behalf of buggy drivers
+
+From: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
+
+commit ec2cceadfae72304ca19650f9cac4b2a97b8a2fc upstream.
+
+Commit 86ef402d805d ("gpiolib: sanitize the return value of
+gpio_chip::get()") started checking the return value of the .get()
+callback in struct gpio_chip. Now - almost a year later - it turns out
+that there are quite a few drivers in tree that can break with this
+change. Partially revert it: normalize the return value in GPIO core but
+also emit a warning.
+
+Cc: stable@vger.kernel.org
+Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()")
+Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Closes: https://lore.kernel.org/all/aZSkqGTqMp_57qC7@google.com/
+Reviewed-by: Linus Walleij <linusw@kernel.org>
+Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Link: https://patch.msgid.link/20260219-gpiolib-set-normalize-v2-1-f84630e45796@oss.qualcomm.com
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpiolib.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -3249,8 +3249,12 @@ static int gpiochip_get(struct gpio_chip
+
+ /* Make sure this is called after checking for gc->get(). */
+ ret = gc->get(gc, offset);
+- if (ret > 1)
+- ret = -EBADE;
++ if (ret > 1) {
++ gpiochip_warn(gc,
++ "invalid return value from gc->get(): %d, consider fixing the driver\n",
++ ret);
++ ret = !!ret;
++ }
+
+ return ret;
+ }
--- /dev/null
+From 326256c0a72d4877cec1d4df85357da106233128 Mon Sep 17 00:00:00 2001
+From: Jakub Staniszewski <jakub.staniszewski@linux.intel.com>
+Date: Tue, 13 Jan 2026 20:38:16 +0100
+Subject: ice: reintroduce retry mechanism for indirect AQ
+
+From: Jakub Staniszewski <jakub.staniszewski@linux.intel.com>
+
+commit 326256c0a72d4877cec1d4df85357da106233128 upstream.
+
+Add retry mechanism for indirect Admin Queue (AQ) commands. To do so we
+need to keep the command buffer.
+
+This technically reverts commit 43a630e37e25
+("ice: remove unused buffer copy code in ice_sq_send_cmd_retry()"),
+but combines it with a fix in the logic by using a kmemdup() call,
+making it more robust and less likely to break in the future due to
+programmer error.
+
+Cc: Michal Schmidt <mschmidt@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 3056df93f7a8 ("ice: Re-send some AQ commands, as result of EBUSY AQ error")
+Signed-off-by: Jakub Staniszewski <jakub.staniszewski@linux.intel.com>
+Co-developed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
+Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/ice/ice_common.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/intel/ice/ice_common.c
++++ b/drivers/net/ethernet/intel/ice/ice_common.c
+@@ -1879,6 +1879,7 @@ ice_sq_send_cmd_retry(struct ice_hw *hw,
+ {
+ struct libie_aq_desc desc_cpy;
+ bool is_cmd_for_retry;
++ u8 *buf_cpy = NULL;
+ u8 idx = 0;
+ u16 opcode;
+ int status;
+@@ -1888,8 +1889,11 @@ ice_sq_send_cmd_retry(struct ice_hw *hw,
+ memset(&desc_cpy, 0, sizeof(desc_cpy));
+
+ if (is_cmd_for_retry) {
+- /* All retryable cmds are direct, without buf. */
+- WARN_ON(buf);
++ if (buf) {
++ buf_cpy = kmemdup(buf, buf_size, GFP_KERNEL);
++ if (!buf_cpy)
++ return -ENOMEM;
++ }
+
+ memcpy(&desc_cpy, desc, sizeof(desc_cpy));
+ }
+@@ -1901,12 +1905,14 @@ ice_sq_send_cmd_retry(struct ice_hw *hw,
+ hw->adminq.sq_last_status != LIBIE_AQ_RC_EBUSY)
+ break;
+
++ if (buf_cpy)
++ memcpy(buf, buf_cpy, buf_size);
+ memcpy(desc, &desc_cpy, sizeof(desc_cpy));
+-
+ msleep(ICE_SQ_SEND_DELAY_TIME_MS);
+
+ } while (++idx < ICE_SQ_SEND_MAX_EXECUTE);
+
++ kfree(buf_cpy);
+ return status;
+ }
+
--- /dev/null
+From d320f160aa5ff36cdf83c645cca52b615e866e32 Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <djwong@kernel.org>
+Date: Mon, 2 Mar 2026 09:30:02 -0800
+Subject: iomap: reject delalloc mappings during writeback
+
+From: Darrick J. Wong <djwong@kernel.org>
+
+commit d320f160aa5ff36cdf83c645cca52b615e866e32 upstream.
+
+Filesystems should never provide a delayed allocation mapping to
+writeback; they're supposed to allocate the space before replying.
+This can lead to weird IO errors and crashes in the block layer if the
+filesystem is being malicious, or if it hadn't set iomap->dev because
+it's a delalloc mapping.
+
+Fix this by failing writeback on delalloc mappings. Currently no
+filesystems actually misbehave in this manner, but we ought to be
+stricter about things like that.
+
+Cc: stable@vger.kernel.org # v5.5
+Fixes: 598ecfbaa742ac ("iomap: lift the xfs writeback code to iomap")
+Signed-off-by: Darrick J. Wong <djwong@kernel.org>
+Link: https://patch.msgid.link/20260302173002.GL13829@frogsfrogsfrogs
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/iomap/ioend.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/fs/iomap/ioend.c
++++ b/fs/iomap/ioend.c
+@@ -163,17 +163,18 @@ ssize_t iomap_add_to_ioend(struct iomap_
+ WARN_ON_ONCE(!folio->private && map_len < dirty_len);
+
+ switch (wpc->iomap.type) {
+- case IOMAP_INLINE:
+- WARN_ON_ONCE(1);
+- return -EIO;
++ case IOMAP_UNWRITTEN:
++ ioend_flags |= IOMAP_IOEND_UNWRITTEN;
++ break;
++ case IOMAP_MAPPED:
++ break;
+ case IOMAP_HOLE:
+ return map_len;
+ default:
+- break;
++ WARN_ON_ONCE(1);
++ return -EIO;
+ }
+
+- if (wpc->iomap.type == IOMAP_UNWRITTEN)
+- ioend_flags |= IOMAP_IOEND_UNWRITTEN;
+ if (wpc->iomap.flags & IOMAP_F_SHARED)
+ ioend_flags |= IOMAP_IOEND_SHARED;
+ if (folio_test_dropbehind(folio))
--- /dev/null
+From f895e5df80316a308c2f7d64d13a78494630ea05 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Thu, 12 Feb 2026 21:52:48 -0600
+Subject: ipmi:si: Don't block module unload if the BMC is messed up
+
+From: Corey Minyard <corey@minyard.net>
+
+commit f895e5df80316a308c2f7d64d13a78494630ea05 upstream.
+
+If the BMC is in a bad state, don't bother waiting for queues messages
+since there can't be any. Otherwise the unload is blocked until the
+BMC is back in a good state.
+
+Reported-by: Rafael J. Wysocki <rafael@kernel.org>
+Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional")
+Cc: stable@vger.kernel.org # 4.18
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -2227,7 +2227,8 @@ static void wait_msg_processed(struct sm
+ unsigned long jiffies_now;
+ long time_diff;
+
+- while (smi_info->curr_msg || (smi_info->si_state != SI_NORMAL)) {
++ while (smi_info->si_state != SI_HOSED &&
++ (smi_info->curr_msg || (smi_info->si_state != SI_NORMAL))) {
+ jiffies_now = jiffies;
+ time_diff = (((long)jiffies_now - (long)smi_info->last_timeout_jiffies)
+ * SI_USEC_PER_JIFFY);
--- /dev/null
+From cae66f1a1dcd23e17da5a015ef9d731129f9d2dd Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Fri, 13 Feb 2026 00:15:04 -0600
+Subject: ipmi:si: Fix check for a misbehaving BMC
+
+From: Corey Minyard <corey@minyard.net>
+
+commit cae66f1a1dcd23e17da5a015ef9d731129f9d2dd upstream.
+
+There is a race on checking the state in the sender, it needs to be
+checked under a lock. But you also need a check to avoid issues with
+a misbehaving BMC for run to completion mode. So leave the check at
+the beginning for run to completion, and add a check under the lock
+to avoid the race.
+
+Reported-by: Rafael J. Wysocki <rafael@kernel.org>
+Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional")
+Cc: stable@vger.kernel.org # 4.18
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 24 +++++++++++++-----------
+ 1 file changed, 13 insertions(+), 11 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -925,9 +925,14 @@ static int sender(void *send_info, struc
+ {
+ struct smi_info *smi_info = send_info;
+ unsigned long flags;
++ int rv = IPMI_CC_NO_ERROR;
+
+ debug_timestamp(smi_info, "Enqueue");
+
++ /*
++ * Check here for run to completion mode. A check under lock is
++ * later.
++ */
+ if (smi_info->si_state == SI_HOSED)
+ return IPMI_BUS_ERR;
+
+@@ -941,18 +946,15 @@ static int sender(void *send_info, struc
+ }
+
+ spin_lock_irqsave(&smi_info->si_lock, flags);
+- /*
+- * The following two lines don't need to be under the lock for
+- * the lock's sake, but they do need SMP memory barriers to
+- * avoid getting things out of order. We are already claiming
+- * the lock, anyway, so just do it under the lock to avoid the
+- * ordering problem.
+- */
+- BUG_ON(smi_info->waiting_msg);
+- smi_info->waiting_msg = msg;
+- check_start_timer_thread(smi_info);
++ if (smi_info->si_state == SI_HOSED) {
++ rv = IPMI_BUS_ERR;
++ } else {
++ BUG_ON(smi_info->waiting_msg);
++ smi_info->waiting_msg = msg;
++ check_start_timer_thread(smi_info);
++ }
+ spin_unlock_irqrestore(&smi_info->si_lock, flags);
+- return IPMI_CC_NO_ERROR;
++ return rv;
+ }
+
+ static void set_run_to_completion(void *send_info, bool i_run_to_completion)
--- /dev/null
+From 52c9ee202edd21d0599ac3b5a6fe1da2a2f053e5 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Fri, 6 Feb 2026 09:59:32 -0600
+Subject: ipmi:si: Handle waiting messages when BMC failure detected
+
+From: Corey Minyard <corey@minyard.net>
+
+commit 52c9ee202edd21d0599ac3b5a6fe1da2a2f053e5 upstream.
+
+If a BMC failure is detected, the current message is returned with an
+error. However, if there was a waiting message, it would not be
+handled.
+
+Add a check for the waiting message after handling the current message.
+
+Suggested-by: Guenter Roeck <linux@roeck-us.net>
+Reported-by: Rafael J. Wysocki <rafael@kernel.org>
+Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/
+Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional")
+Cc: stable@vger.kernel.org # 4.18
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -810,6 +810,12 @@ restart:
+ */
+ return_hosed_msg(smi_info, IPMI_BUS_ERR);
+ }
++ if (smi_info->waiting_msg != NULL) {
++ /* Also handle if there was a message waiting. */
++ smi_info->curr_msg = smi_info->waiting_msg;
++ smi_info->waiting_msg = NULL;
++ return_hosed_msg(smi_info, IPMI_BUS_ERR);
++ }
+ smi_mod_timer(smi_info, jiffies + SI_TIMEOUT_HOSED);
+ goto out;
+ }
--- /dev/null
+From c3bb3295637cc9bf514f690941ca9a385bf30113 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Fri, 6 Feb 2026 10:33:52 -0600
+Subject: ipmi:si: Use a long timeout when the BMC is misbehaving
+
+From: Corey Minyard <corey@minyard.net>
+
+commit c3bb3295637cc9bf514f690941ca9a385bf30113 upstream.
+
+If the driver goes into HOSED state, don't reset the timeout to the
+short timeout in the timeout handler.
+
+Reported-by: Igor Raits <igor@gooddata.com>
+Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/
+Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional")
+Cc: stable@vger.kernel.org # 4.18
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -1114,7 +1114,9 @@ static void smi_timeout(struct timer_lis
+ * SI_USEC_PER_JIFFY);
+ smi_result = smi_event_handler(smi_info, time_diff);
+
+- if ((smi_info->io.irq) && (!smi_info->interrupt_disabled)) {
++ if (smi_info->si_state == SI_HOSED) {
++ timeout = jiffies + SI_TIMEOUT_HOSED;
++ } else if ((smi_info->io.irq) && (!smi_info->interrupt_disabled)) {
+ /* Running with interrupts, only do long timeouts. */
+ timeout = jiffies + SI_TIMEOUT_JIFFIES;
+ smi_inc_stat(smi_info, long_timeouts);
--- /dev/null
+From ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Fri, 6 Feb 2026 15:48:16 +0000
+Subject: irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 upstream.
+
+The ITS driver blindly assumes that EventIDs are in abundant supply, to the
+point where it never checks how many the hardware actually supports.
+
+It turns out that some pretty esoteric integrations make it so that only a
+few bits are available, all the way down to a single bit.
+
+Enforce the advertised limitation at the point of allocating the device
+structure, and hope that the endpoint driver can deal with such limitation.
+
+Fixes: 84a6a2e7fc18d ("irqchip: GICv3: ITS: device allocation and configuration")
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260206154816.3582887-1-maz@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 4 ++++
+ include/linux/irqchip/arm-gic-v3.h | 1 +
+ 2 files changed, 5 insertions(+)
+
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -3475,6 +3475,7 @@ static struct its_device *its_create_dev
+ int lpi_base;
+ int nr_lpis;
+ int nr_ites;
++ int id_bits;
+ int sz;
+
+ if (!its_alloc_device_table(its, dev_id))
+@@ -3486,7 +3487,10 @@ static struct its_device *its_create_dev
+ /*
+ * Even if the device wants a single LPI, the ITT must be
+ * sized as a power of two (and you need at least one bit...).
++ * Also honor the ITS's own EID limit.
+ */
++ id_bits = FIELD_GET(GITS_TYPER_IDBITS, its->typer) + 1;
++ nvecs = min_t(unsigned int, nvecs, BIT(id_bits));
+ nr_ites = max(2, nvecs);
+ sz = nr_ites * (FIELD_GET(GITS_TYPER_ITT_ENTRY_SIZE, its->typer) + 1);
+ sz = max(sz, ITS_ITT_ALIGN);
+--- a/include/linux/irqchip/arm-gic-v3.h
++++ b/include/linux/irqchip/arm-gic-v3.h
+@@ -394,6 +394,7 @@
+ #define GITS_TYPER_VLPIS (1UL << 1)
+ #define GITS_TYPER_ITT_ENTRY_SIZE_SHIFT 4
+ #define GITS_TYPER_ITT_ENTRY_SIZE GENMASK_ULL(7, 4)
++#define GITS_TYPER_IDBITS GENMASK_ULL(12, 8)
+ #define GITS_TYPER_IDBITS_SHIFT 8
+ #define GITS_TYPER_DEVBITS_SHIFT 13
+ #define GITS_TYPER_DEVBITS GENMASK_ULL(17, 13)
--- /dev/null
+From feae40a6a178bb525a15f19288016e5778102a99 Mon Sep 17 00:00:00 2001
+From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Date: Wed, 10 Dec 2025 12:26:51 +0100
+Subject: ixgbevf: fix link setup issue
+
+From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+
+commit feae40a6a178bb525a15f19288016e5778102a99 upstream.
+
+It may happen that VF spawned for E610 adapter has problem with setting
+link up. This happens when ixgbevf supporting mailbox API 1.6 cooperates
+with PF driver which doesn't support this version of API, and hence
+doesn't support new approach for getting PF link data.
+
+In that case VF asks PF to provide link data but as PF doesn't support
+it, returns -EOPNOTSUPP what leads to early bail from link configuration
+sequence.
+
+Avoid such situation by using legacy VFLINKS approach whenever negotiated
+API version is less than 1.6.
+
+To reproduce the issue just create VF and set its link up - adapter must
+be any from the E610 family, ixgbevf must support API 1.6 or higher while
+ixgbevf must not.
+
+Fixes: 53f0eb62b4d2 ("ixgbevf: fix getting link speed data for E610 devices")
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com>
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/ixgbevf/vf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
++++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
+@@ -852,7 +852,8 @@ static s32 ixgbevf_check_mac_link_vf(str
+ if (!mac->get_link_status)
+ goto out;
+
+- if (hw->mac.type == ixgbe_mac_e610_vf) {
++ if (hw->mac.type == ixgbe_mac_e610_vf &&
++ hw->api_version >= ixgbe_mbox_api_16) {
+ ret_val = ixgbevf_get_pf_link_state(hw, speed, link_up);
+ if (ret_val)
+ goto out;
--- /dev/null
+From 201ceb94aa1def0024a7c18ce643e5f65026be06 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Mon, 23 Feb 2026 19:37:51 -0800
+Subject: kunit: irq: Ensure timer doesn't fire too frequently
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 201ceb94aa1def0024a7c18ce643e5f65026be06 upstream.
+
+Fix a bug where kunit_run_irq_test() could hang if the system is too
+slow. This was noticed with the crypto library tests in certain VMs.
+
+Specifically, if kunit_irq_test_timer_func() and the associated hrtimer
+code took over 5us to run, then the CPU would spend all its time
+executing that code in hardirq context. As a result, the task executing
+kunit_run_irq_test() never had a chance to run, exit the loop, and
+cancel the timer.
+
+To fix it, make kunit_irq_test_timer_func() increase the timer interval
+when the other contexts aren't having a chance to run.
+
+Fixes: 950a81224e8b ("lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.py")
+Cc: stable@vger.kernel.org
+Reviewed-by: David Gow <david@davidgow.net>
+Link: https://lore.kernel.org/r/20260224033751.97615-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/kunit/run-in-irq-context.h | 44 +++++++++++++++++++-----------
+ 1 file changed, 28 insertions(+), 16 deletions(-)
+
+diff --git a/include/kunit/run-in-irq-context.h b/include/kunit/run-in-irq-context.h
+index c89b1b1b12dd..bfe60d6cf28d 100644
+--- a/include/kunit/run-in-irq-context.h
++++ b/include/kunit/run-in-irq-context.h
+@@ -12,16 +12,16 @@
+ #include <linux/hrtimer.h>
+ #include <linux/workqueue.h>
+
+-#define KUNIT_IRQ_TEST_HRTIMER_INTERVAL us_to_ktime(5)
+-
+ struct kunit_irq_test_state {
+ bool (*func)(void *test_specific_state);
+ void *test_specific_state;
+ bool task_func_reported_failure;
+ bool hardirq_func_reported_failure;
+ bool softirq_func_reported_failure;
++ atomic_t task_func_calls;
+ atomic_t hardirq_func_calls;
+ atomic_t softirq_func_calls;
++ ktime_t interval;
+ struct hrtimer timer;
+ struct work_struct bh_work;
+ };
+@@ -30,14 +30,25 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer)
+ {
+ struct kunit_irq_test_state *state =
+ container_of(timer, typeof(*state), timer);
++ int task_calls, hardirq_calls, softirq_calls;
+
+ WARN_ON_ONCE(!in_hardirq());
+- atomic_inc(&state->hardirq_func_calls);
++ task_calls = atomic_read(&state->task_func_calls);
++ hardirq_calls = atomic_inc_return(&state->hardirq_func_calls);
++ softirq_calls = atomic_read(&state->softirq_func_calls);
++
++ /*
++ * If the timer is firing too often for the softirq or task to ever have
++ * a chance to run, increase the timer interval. This is needed on very
++ * slow systems.
++ */
++ if (hardirq_calls >= 20 && (softirq_calls == 0 || task_calls == 0))
++ state->interval = ktime_add_ns(state->interval, 250);
+
+ if (!state->func(state->test_specific_state))
+ state->hardirq_func_reported_failure = true;
+
+- hrtimer_forward_now(&state->timer, KUNIT_IRQ_TEST_HRTIMER_INTERVAL);
++ hrtimer_forward_now(&state->timer, state->interval);
+ queue_work(system_bh_wq, &state->bh_work);
+ return HRTIMER_RESTART;
+ }
+@@ -86,10 +97,14 @@ static inline void kunit_run_irq_test(struct kunit *test, bool (*func)(void *),
+ struct kunit_irq_test_state state = {
+ .func = func,
+ .test_specific_state = test_specific_state,
++ /*
++ * Start with a 5us timer interval. If the system can't keep
++ * up, kunit_irq_test_timer_func() will increase it.
++ */
++ .interval = us_to_ktime(5),
+ };
+ unsigned long end_jiffies;
+- int hardirq_calls, softirq_calls;
+- bool allctx = false;
++ int task_calls, hardirq_calls, softirq_calls;
+
+ /*
+ * Set up a hrtimer (the way we access hardirq context) and a work
+@@ -104,21 +119,18 @@ static inline void kunit_run_irq_test(struct kunit *test, bool (*func)(void *),
+ * and hardirq), or 1 second, whichever comes first.
+ */
+ end_jiffies = jiffies + HZ;
+- hrtimer_start(&state.timer, KUNIT_IRQ_TEST_HRTIMER_INTERVAL,
+- HRTIMER_MODE_REL_HARD);
+- for (int task_calls = 0, calls = 0;
+- ((calls < max_iterations) || !allctx) &&
+- !time_after(jiffies, end_jiffies);
+- task_calls++) {
++ hrtimer_start(&state.timer, state.interval, HRTIMER_MODE_REL_HARD);
++ do {
+ if (!func(test_specific_state))
+ state.task_func_reported_failure = true;
+
++ task_calls = atomic_inc_return(&state.task_func_calls);
+ hardirq_calls = atomic_read(&state.hardirq_func_calls);
+ softirq_calls = atomic_read(&state.softirq_func_calls);
+- calls = task_calls + hardirq_calls + softirq_calls;
+- allctx = (task_calls > 0) && (hardirq_calls > 0) &&
+- (softirq_calls > 0);
+- }
++ } while ((task_calls + hardirq_calls + softirq_calls < max_iterations ||
++ (task_calls == 0 || hardirq_calls == 0 ||
++ softirq_calls == 0)) &&
++ !time_after(jiffies, end_jiffies));
+
+ /* Cancel the timer and work. */
+ hrtimer_cancel(&state.timer);
+--
+2.53.0
+
--- /dev/null
+From d210fdcac9c0d1380eab448aebc93f602c1cd4e6 Mon Sep 17 00:00:00 2001
+From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
+Date: Mon, 23 Feb 2026 17:10:59 -0800
+Subject: mm/damon/core: clear walk_control on inactive context in damos_walk()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
+
+commit d210fdcac9c0d1380eab448aebc93f602c1cd4e6 upstream.
+
+damos_walk() sets ctx->walk_control to the caller-provided control
+structure before checking whether the context is running. If the context
+is inactive (damon_is_running() returns false), the function returns
+-EINVAL without clearing ctx->walk_control. This leaves a dangling
+pointer to a stack-allocated structure that will be freed when the caller
+returns.
+
+This is structurally identical to the bug fixed in commit f9132fbc2e83
+("mm/damon/core: remove call_control in inactive contexts") for
+damon_call(), which had the same pattern of linking a control object and
+returning an error without unlinking it.
+
+The dangling walk_control pointer can cause:
+1. Use-after-free if the context is later started and kdamond
+ dereferences ctx->walk_control (e.g., in damos_walk_cancel()
+ which writes to control->canceled and calls complete())
+2. Permanent -EBUSY from subsequent damos_walk() calls, since the
+ stale pointer is non-NULL
+
+Nonetheless, the real user impact is quite restrictive. The
+use-after-free is impossible because there is no damos_walk() callers who
+starts the context later. The permanent -EBUSY can actually confuse
+users, as DAMON is not running. But the symptom is kept only while the
+context is turned off. Turning it on again will make DAMON internally
+uses a newly generated damon_ctx object that doesn't have the invalid
+damos_walk_control pointer, so everything will work fine again.
+
+Fix this by clearing ctx->walk_control under walk_control_lock before
+returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.
+
+Link: https://lkml.kernel.org/r/20260224011102.56033-1-sj@kernel.org
+Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
+Reported-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
+Closes: https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com
+Signed-off-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> [6.14+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/core.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/mm/damon/core.c
++++ b/mm/damon/core.c
+@@ -1526,8 +1526,13 @@ int damos_walk(struct damon_ctx *ctx, st
+ }
+ ctx->walk_control = control;
+ mutex_unlock(&ctx->walk_control_lock);
+- if (!damon_is_running(ctx))
++ if (!damon_is_running(ctx)) {
++ mutex_lock(&ctx->walk_control_lock);
++ if (ctx->walk_control == control)
++ ctx->walk_control = NULL;
++ mutex_unlock(&ctx->walk_control_lock);
+ return -EINVAL;
++ }
+ wait_for_completion(&control->completion);
+ if (control->canceled)
+ return -ECANCELED;
--- /dev/null
+From 8dafa9f5900c4855a65dbfee51e3bd00636deee1 Mon Sep 17 00:00:00 2001
+From: Harry Yoo <harry.yoo@oracle.com>
+Date: Mon, 9 Mar 2026 16:22:19 +0900
+Subject: mm/slab: fix an incorrect check in obj_exts_alloc_size()
+
+From: Harry Yoo <harry.yoo@oracle.com>
+
+commit 8dafa9f5900c4855a65dbfee51e3bd00636deee1 upstream.
+
+obj_exts_alloc_size() prevents recursive allocation of slabobj_ext
+array from the same cache, to avoid creating slabs that are never freed.
+
+There is one mistake that returns the original size when memory
+allocation profiling is disabled. The assumption was that
+memcg-triggered slabobj_ext allocation is always served from
+KMALLOC_CGROUP type. But this is wrong [1]: when the caller specifies
+both __GFP_RECLAIMABLE and __GFP_ACCOUNT with SLUB_TINY enabled, the
+allocation is served from normal kmalloc. This is because kmalloc_type()
+prioritizes __GFP_RECLAIMABLE over __GFP_ACCOUNT, and SLUB_TINY aliases
+KMALLOC_RECLAIM with KMALLOC_NORMAL.
+
+As a result, the recursion guard is bypassed and the problematic slabs
+can be created. Fix this by removing the mem_alloc_profiling_enabled()
+check entirely. The remaining is_kmalloc_normal() check is still
+sufficient to detect whether the cache is of KMALLOC_NORMAL type and
+avoid bumping the size if it's not.
+
+Without SLUB_TINY, no functional change intended.
+With SLUB_TINY, allocations with __GFP_ACCOUNT|__GFP_RECLAIMABLE
+now allocate a larger array if the sizes equal.
+
+Reported-by: Zw Tang <shicenci@gmail.com>
+Fixes: 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab")
+Closes: https://lore.kernel.org/linux-mm/CAPHJ_VKuMKSke8b11AZQw1PTSFN4n2C0gFxC6xGOG0ZLHgPmnA@mail.gmail.com [1]
+Cc: stable@vger.kernel.org
+Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
+Link: https://patch.msgid.link/20260309072219.22653-1-harry.yoo@oracle.com
+Tested-by: Zw Tang <shicenci@gmail.com>
+Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -2113,13 +2113,6 @@ static inline size_t obj_exts_alloc_size
+ size_t sz = sizeof(struct slabobj_ext) * slab->objects;
+ struct kmem_cache *obj_exts_cache;
+
+- /*
+- * slabobj_ext array for KMALLOC_CGROUP allocations
+- * are served from KMALLOC_NORMAL caches.
+- */
+- if (!mem_alloc_profiling_enabled())
+- return sz;
+-
+ if (sz > KMALLOC_MAX_CACHE_SIZE)
+ return sz;
+
--- /dev/null
+From 92978c83bb4eef55d02a6c990c01c423131eefa7 Mon Sep 17 00:00:00 2001
+From: Kuniyuki Iwashima <kuniyu@google.com>
+Date: Sat, 24 Jan 2026 04:18:41 +0000
+Subject: nfsd: Fix cred ref leak in nfsd_nl_listener_set_doit().
+
+From: Kuniyuki Iwashima <kuniyu@google.com>
+
+commit 92978c83bb4eef55d02a6c990c01c423131eefa7 upstream.
+
+nfsd_nl_listener_set_doit() uses get_current_cred() without
+put_cred().
+
+As we can see from other callers, svc_xprt_create_from_sa()
+does not require the extra refcount.
+
+nfsd_nl_listener_set_doit() is always in the process context,
+sendmsg(), and current->cred does not go away.
+
+Let's use current_cred() in nfsd_nl_listener_set_doit().
+
+Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfsctl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfsd/nfsctl.c
++++ b/fs/nfsd/nfsctl.c
+@@ -1993,7 +1993,7 @@ int nfsd_nl_listener_set_doit(struct sk_
+ }
+
+ ret = svc_xprt_create_from_sa(serv, xcl_name, net, sa, 0,
+- get_current_cred());
++ current_cred());
+ /* always save the latest error */
+ if (ret < 0)
+ err = ret;
--- /dev/null
+From 9478c166c46934160135e197b049b5a05753f2ad Mon Sep 17 00:00:00 2001
+From: Dave Airlie <airlied@redhat.com>
+Date: Thu, 21 Nov 2024 11:46:01 +1000
+Subject: nouveau/gsp: drop WARN_ON in ACPI probes
+
+From: Dave Airlie <airlied@redhat.com>
+
+commit 9478c166c46934160135e197b049b5a05753f2ad upstream.
+
+These WARN_ONs seem to trigger a lot, and we don't seem to have a
+plan to fix them, so just drop them, as they are most likely
+harmless.
+
+Cc: stable@vger.kernel.org
+Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Link: https://patch.msgid.link/20241121014601.229391-1-airlied@gmail.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
+@@ -737,8 +737,8 @@ r535_gsp_acpi_caps(acpi_handle handle, C
+ if (!obj)
+ goto done;
+
+- if (WARN_ON(obj->type != ACPI_TYPE_BUFFER) ||
+- WARN_ON(obj->buffer.length != 4))
++ if (obj->type != ACPI_TYPE_BUFFER ||
++ obj->buffer.length != 4)
+ goto done;
+
+ caps->status = 0;
+@@ -773,8 +773,8 @@ r535_gsp_acpi_jt(acpi_handle handle, JT_
+ if (!obj)
+ goto done;
+
+- if (WARN_ON(obj->type != ACPI_TYPE_BUFFER) ||
+- WARN_ON(obj->buffer.length != 4))
++ if (obj->type != ACPI_TYPE_BUFFER ||
++ obj->buffer.length != 4)
+ goto done;
+
+ jt->status = 0;
+@@ -861,8 +861,8 @@ r535_gsp_acpi_dod(acpi_handle handle, DO
+
+ _DOD = output.pointer;
+
+- if (WARN_ON(_DOD->type != ACPI_TYPE_PACKAGE) ||
+- WARN_ON(_DOD->package.count > ARRAY_SIZE(dod->acpiIdList)))
++ if (_DOD->type != ACPI_TYPE_PACKAGE ||
++ _DOD->package.count > ARRAY_SIZE(dod->acpiIdList))
+ return;
+
+ for (int i = 0; i < _DOD->package.count; i++) {
--- /dev/null
+From d879ac6756b662a085a743e76023c768c3241579 Mon Sep 17 00:00:00 2001
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+Date: Tue, 24 Feb 2026 07:41:07 +0100
+Subject: s390/pfault: Fix virtual vs physical address confusion
+
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+
+commit d879ac6756b662a085a743e76023c768c3241579 upstream.
+
+When Linux is running as guest, runs a user space process and the
+user space process accesses a page that the host has paged out,
+the guest gets a pfault interrupt and schedules a different process.
+Without this mechanism the host would have to suspend the whole
+virtual CPU until the page has been paged in.
+
+To setup the pfault interrupt the real address of parameter list
+should be passed to DIAGNOSE 0x258, but a virtual address is passed
+instead.
+
+That has a performance impact, since the pfault setup never succeeds,
+the interrupt is never delivered to a guest and the whole virtual CPU
+is suspended as result.
+
+Cc: stable@vger.kernel.org
+Fixes: c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces")
+Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/mm/pfault.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/mm/pfault.c
++++ b/arch/s390/mm/pfault.c
+@@ -62,7 +62,7 @@ int __pfault_init(void)
+ "0: nopr %%r7\n"
+ EX_TABLE(0b, 0b)
+ : [rc] "+d" (rc)
+- : [refbk] "a" (&pfault_init_refbk), "m" (pfault_init_refbk)
++ : [refbk] "a" (virt_to_phys(&pfault_init_refbk)), "m" (pfault_init_refbk)
+ : "cc");
+ return rc;
+ }
+@@ -84,7 +84,7 @@ void __pfault_fini(void)
+ "0: nopr %%r7\n"
+ EX_TABLE(0b, 0b)
+ :
+- : [refbk] "a" (&pfault_fini_refbk), "m" (pfault_fini_refbk)
++ : [refbk] "a" (virt_to_phys(&pfault_fini_refbk)), "m" (pfault_fini_refbk)
+ : "cc");
+ }
+
revert-tcpm-allow-looking-for-role_sw-device-in-the-main-node.patch
revert-ptdesc-remove-references-to-folios-from-__pagetable_ctor-and-pagetable_dtor.patch
kthread-consolidate-kthread-exit-paths-to-prevent-use-after-free.patch
+cpufreq-intel_pstate-fix-null-pointer-dereference-in-update_cpu_qos_request.patch
+drm-amdgpu-add-upper-bound-check-on-user-inputs-in-signal-ioctl.patch
+drm-amdgpu-userq-fix-reference-leak-in-amdgpu_userq_wait_ioctl.patch
+drm-amdgpu-add-upper-bound-check-on-user-inputs-in-wait-ioctl.patch
+drm-amd-disable-mes-lr-compute-w-a.patch
+ipmi-si-don-t-block-module-unload-if-the-bmc-is-messed-up.patch
+ipmi-si-use-a-long-timeout-when-the-bmc-is-misbehaving.patch
+drm-bridge-samsung-dsim-fix-memory-leak-in-error-path.patch
+drm-bridge-ti-sn65dsi86-enable-hpd-polling-if-irq-is-not-used.patch
+ipmi-si-handle-waiting-messages-when-bmc-failure-detected.patch
+nouveau-gsp-drop-warn_on-in-acpi-probes.patch
+drm-i915-alpm-alpm-disable-fixes.patch
+gpiolib-normalize-the-return-value-of-gc-get-on-behalf-of-buggy-drivers.patch
+ipmi-si-fix-check-for-a-misbehaving-bmc.patch
+drm-xe-sync-cleanup-partially-initialized-sync-on-parse-failure.patch
+s390-pfault-fix-virtual-vs-physical-address-confusion.patch
+bpf-fix-kprobe_multi-cookies-access-in-show_fdinfo-callback.patch
+arm64-gcs-honour-mprotect-prot_none-on-shadow-stack-mappings.patch
+nfsd-fix-cred-ref-leak-in-nfsd_nl_listener_set_doit.patch
+device-property-allow-secondary-lookup-in-fwnode_get_next_child_node.patch
+irqchip-gic-v3-its-limit-number-of-per-device-msis-to-the-range-the-its-supports.patch
+btrfs-fix-chunk-map-leak-in-btrfs_map_block-after-btrfs_chunk_map_num_copies.patch
+iomap-reject-delalloc-mappings-during-writeback.patch
+ice-reintroduce-retry-mechanism-for-indirect-aq.patch
+kunit-irq-ensure-timer-doesn-t-fire-too-frequently.patch
+ixgbevf-fix-link-setup-issue.patch
+mm-damon-core-clear-walk_control-on-inactive-context-in-damos_walk.patch
+mm-slab-fix-an-incorrect-check-in-obj_exts_alloc_size.patch
+staging-sm750fb-add-missing-pci_release_region-on-error-and-removal.patch
+staging-rtl8723bs-properly-validate-the-data-in-rtw_get_ie_ex.patch
+staging-rtl8723bs-fix-potential-out-of-bounds-read-in-rtw_restruct_wmm_ie.patch
--- /dev/null
+From a75281626fc8fa6dc6c9cc314ee423e8bc45203b Mon Sep 17 00:00:00 2001
+From: Luka Gejak <luka.gejak@linux.dev>
+Date: Tue, 24 Feb 2026 14:26:47 +0100
+Subject: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie
+
+From: Luka Gejak <luka.gejak@linux.dev>
+
+commit a75281626fc8fa6dc6c9cc314ee423e8bc45203b upstream.
+
+The current code checks 'i + 5 < in_len' at the end of the if statement.
+However, it accesses 'in_ie[i + 5]' before that check, which can lead
+to an out-of-bounds read. Move the length check to the beginning of the
+conditional to ensure the index is within bounds before accessing the
+array.
+
+Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
+Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
+Link: https://patch.msgid.link/20260224132647.11642-2-luka.gejak@linux.dev
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8723bs/core/rtw_mlme.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
++++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
+@@ -2008,7 +2008,10 @@ int rtw_restruct_wmm_ie(struct adapter *
+ while (i < in_len) {
+ ielength = initial_out_len;
+
+- if (in_ie[i] == 0xDD && in_ie[i+2] == 0x00 && in_ie[i+3] == 0x50 && in_ie[i+4] == 0xF2 && in_ie[i+5] == 0x02 && i+5 < in_len) { /* WMM element ID and OUI */
++ if (i + 5 < in_len &&
++ in_ie[i] == 0xDD && in_ie[i + 2] == 0x00 &&
++ in_ie[i + 3] == 0x50 && in_ie[i + 4] == 0xF2 &&
++ in_ie[i + 5] == 0x02) {
+ for (j = i; j < i + 9; j++) {
+ out_ie[ielength] = in_ie[j];
+ ielength++;
--- /dev/null
+From f0109b9d3e1e455429279d602f6276e34689750a Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Mon, 23 Feb 2026 14:31:35 +0100
+Subject: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit f0109b9d3e1e455429279d602f6276e34689750a upstream.
+
+Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds
+read in rtw_get_ie() parser"), we don't trust the data in the frame so
+we should check the length better before acting on it
+
+Cc: stable <stable@kernel.org>
+Assisted-by: gkh_clanker_2000
+Tested-by: Navaneeth K <knavaneeth786@gmail.com>
+Reviewed-by: Navaneeth K <knavaneeth786@gmail.com>
+Link: https://patch.msgid.link/2026022336-arrange-footwork-6e54@gregkh
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
++++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+@@ -187,20 +187,25 @@ u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len
+
+ cnt = 0;
+
+- while (cnt < in_len) {
++ while (cnt + 2 <= in_len) {
++ u8 ie_len = in_ie[cnt + 1];
++
++ if (cnt + 2 + ie_len > in_len)
++ break;
++
+ if (eid == in_ie[cnt]
+- && (!oui || !memcmp(&in_ie[cnt+2], oui, oui_len))) {
++ && (!oui || (ie_len >= oui_len && !memcmp(&in_ie[cnt + 2], oui, oui_len)))) {
+ target_ie = &in_ie[cnt];
+
+ if (ie)
+- memcpy(ie, &in_ie[cnt], in_ie[cnt+1]+2);
++ memcpy(ie, &in_ie[cnt], ie_len + 2);
+
+ if (ielen)
+- *ielen = in_ie[cnt+1]+2;
++ *ielen = ie_len + 2;
+
+ break;
+ }
+- cnt += in_ie[cnt+1]+2; /* goto next */
++ cnt += ie_len + 2; /* goto next */
+ }
+
+ return target_ie;
--- /dev/null
+From 8225489ddb900656cc21573b4e1b00c9181fd777 Mon Sep 17 00:00:00 2001
+From: Artem Lytkin <iprintercanon@gmail.com>
+Date: Mon, 16 Feb 2026 20:20:38 +0000
+Subject: staging: sm750fb: add missing pci_release_region on error and removal
+
+From: Artem Lytkin <iprintercanon@gmail.com>
+
+commit 8225489ddb900656cc21573b4e1b00c9181fd777 upstream.
+
+hw_sm750_map() calls pci_request_region() but never releases the
+region on error paths or in lynxfb_pci_remove(). This causes a
+resource leak that prevents the PCI region from being mapped again
+after driver removal or a failed probe. A TODO comment in the code
+acknowledges this missing cleanup.
+
+Restructure the error handling in hw_sm750_map() to properly release
+the PCI region on ioremap failures, and add pci_release_region() to
+lynxfb_pci_remove().
+
+Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>
+Cc: stable <stable@kernel.org>
+Link: https://patch.msgid.link/20260216202038.1828-1-iprintercanon@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/sm750fb/sm750.c | 1 +
+ drivers/staging/sm750fb/sm750_hw.c | 22 +++++++++++-----------
+ 2 files changed, 12 insertions(+), 11 deletions(-)
+
+--- a/drivers/staging/sm750fb/sm750.c
++++ b/drivers/staging/sm750fb/sm750.c
+@@ -1118,6 +1118,7 @@ static void lynxfb_pci_remove(struct pci
+
+ iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pvMem);
++ pci_release_region(pdev, 1);
+ kfree(g_settings);
+ }
+
+--- a/drivers/staging/sm750fb/sm750_hw.c
++++ b/drivers/staging/sm750fb/sm750_hw.c
+@@ -36,16 +36,11 @@ int hw_sm750_map(struct sm750_dev *sm750
+
+ pr_info("mmio phyAddr = %lx\n", sm750_dev->vidreg_start);
+
+- /*
+- * reserve the vidreg space of smi adaptor
+- * if you do this, you need to add release region code
+- * in lynxfb_remove, or memory will not be mapped again
+- * successfully
+- */
++ /* reserve the vidreg space of smi adaptor */
+ ret = pci_request_region(pdev, 1, "sm750fb");
+ if (ret) {
+ pr_err("Can not request PCI regions.\n");
+- goto exit;
++ return ret;
+ }
+
+ /* now map mmio and vidmem */
+@@ -54,7 +49,7 @@ int hw_sm750_map(struct sm750_dev *sm750
+ if (!sm750_dev->pvReg) {
+ pr_err("mmio failed\n");
+ ret = -EFAULT;
+- goto exit;
++ goto err_release_region;
+ }
+ pr_info("mmio virtual addr = %p\n", sm750_dev->pvReg);
+
+@@ -79,13 +74,18 @@ int hw_sm750_map(struct sm750_dev *sm750
+ sm750_dev->pvMem =
+ ioremap_wc(sm750_dev->vidmem_start, sm750_dev->vidmem_size);
+ if (!sm750_dev->pvMem) {
+- iounmap(sm750_dev->pvReg);
+ pr_err("Map video memory failed\n");
+ ret = -EFAULT;
+- goto exit;
++ goto err_unmap_reg;
+ }
+ pr_info("video memory vaddr = %p\n", sm750_dev->pvMem);
+-exit:
++
++ return 0;
++
++err_unmap_reg:
++ iounmap(sm750_dev->pvReg);
++err_release_region:
++ pci_release_region(pdev, 1);
+ return ret;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
