--- /dev/null
+From 82420bd4e17bdaba8453fbf9e10c58c9ed0c9727 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 6 Nov 2025 11:46:45 +0100
+Subject: ALSA: hda/hdmi: Fix breakage at probing nvhdmi-mcp driver
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 82420bd4e17bdaba8453fbf9e10c58c9ed0c9727 upstream.
+
+After restructuring and splitting the HDMI codec driver code, each
+HDMI codec driver contains the own build_controls and build_pcms ops.
+A copy-n-paste error put the wrong entries for nvhdmi-mcp driver; both
+build_controls and build_pcms are swapped. Unfortunately both
+callbacks have the very same form, and the compiler didn't complain
+it, either. This resulted in a NULL dereference because the PCM
+instance hasn't been initialized at calling the build_controls
+callback.
+
+Fix it by passing the proper entries.
+
+Fixes: ad781b550f9a ("ALSA: hda/hdmi: Rewrite to new probe method")
+Cc: <stable@vger.kernel.org>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=220743
+Link: https://patch.msgid.link/20251106104647.25805-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/hda/codecs/hdmi/nvhdmi-mcp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/hda/codecs/hdmi/nvhdmi-mcp.c
++++ b/sound/hda/codecs/hdmi/nvhdmi-mcp.c
+@@ -351,8 +351,8 @@ static int nvhdmi_mcp_probe(struct hda_c
+ static const struct hda_codec_ops nvhdmi_mcp_codec_ops = {
+ .probe = nvhdmi_mcp_probe,
+ .remove = snd_hda_hdmi_simple_remove,
+- .build_controls = nvhdmi_mcp_build_pcms,
+- .build_pcms = nvhdmi_mcp_build_controls,
++ .build_pcms = nvhdmi_mcp_build_pcms,
++ .build_controls = nvhdmi_mcp_build_controls,
+ .init = nvhdmi_mcp_init,
+ .unsol_event = snd_hda_hdmi_simple_unsol_event,
+ };
--- /dev/null
+From 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sun, 9 Nov 2025 10:12:07 +0100
+Subject: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf upstream.
+
+The PCM stream data in USB-audio driver is transferred over USB URB
+packet buffers, and each packet size is determined dynamically. The
+packet sizes are limited by some factors such as wMaxPacketSize USB
+descriptor. OTOH, in the current code, the actually used packet sizes
+are determined only by the rate and the PPS, which may be bigger than
+the size limit above. This results in a buffer overflow, as reported
+by syzbot.
+
+Basically when the limit is smaller than the calculated packet size,
+it implies that something is wrong, most likely a weird USB
+descriptor. So the best option would be just to return an error at
+the parameter setup time before doing any further operations.
+
+This patch introduces such a sanity check, and returns -EINVAL when
+the packet size is greater than maxpacksize. The comparison with
+ep->packsize[1] alone should suffice since it's always equal or
+greater than ep->packsize[0].
+
+Reported-by: syzbot+bfd77469c8966de076f7@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7
+Link: https://lore.kernel.org/690b6b46.050a0220.3d0d33.0054.GAE@google.com
+Cc: Lizhi Xu <lizhi.xu@windriver.com>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20251109091211.12739-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/endpoint.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -1386,6 +1386,11 @@ int snd_usb_endpoint_set_params(struct s
+ ep->sample_rem = ep->cur_rate % ep->pps;
+ ep->packsize[0] = ep->cur_rate / ep->pps;
+ ep->packsize[1] = (ep->cur_rate + (ep->pps - 1)) / ep->pps;
++ if (ep->packsize[1] > ep->maxpacksize) {
++ usb_audio_dbg(chip, "Too small maxpacksize %u for rate %u / pps %u\n",
++ ep->maxpacksize, ep->cur_rate, ep->pps);
++ return -EINVAL;
++ }
+
+ /* calculate the frequency in 16.16 format */
+ ep->freqm = ep->freqn;
--- /dev/null
+From 1a58d865f423f4339edf59053e496089075fa950 Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Wed, 29 Oct 2025 15:17:58 +0800
+Subject: ASoC: sdw_utils: fix device reference leak in is_sdca_endpoint_present()
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit 1a58d865f423f4339edf59053e496089075fa950 upstream.
+
+The bus_find_device_by_name() function returns a device pointer with an
+incremented reference count, but the original code was missing put_device()
+calls in some return paths, leading to reference count leaks.
+
+Fix this by ensuring put_device() is called before function exit after
+ bus_find_device_by_name() succeeds
+
+This follows the same pattern used elsewhere in the kernel where
+bus_find_device_by_name() is properly paired with put_device().
+
+Found via static analysis and code review.
+
+Fixes: 4f8ef33dd44a ("ASoC: soc_sdw_utils: skip the endpoint that doesn't present")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Link: https://patch.msgid.link/20251029071804.8425-1-linmq006@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/sdw_utils/soc_sdw_utils.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/sound/soc/sdw_utils/soc_sdw_utils.c
++++ b/sound/soc/sdw_utils/soc_sdw_utils.c
+@@ -1239,7 +1239,7 @@ static int is_sdca_endpoint_present(stru
+ struct sdw_slave *slave;
+ struct device *sdw_dev;
+ const char *sdw_codec_name;
+- int i;
++ int ret, i;
+
+ dlc = kzalloc(sizeof(*dlc), GFP_KERNEL);
+ if (!dlc)
+@@ -1269,13 +1269,16 @@ static int is_sdca_endpoint_present(stru
+ }
+
+ slave = dev_to_sdw_dev(sdw_dev);
+- if (!slave)
+- return -EINVAL;
++ if (!slave) {
++ ret = -EINVAL;
++ goto put_device;
++ }
+
+ /* Make sure BIOS provides SDCA properties */
+ if (!slave->sdca_data.interface_revision) {
+ dev_warn(&slave->dev, "SDCA properties not found in the BIOS\n");
+- return 1;
++ ret = 1;
++ goto put_device;
+ }
+
+ for (i = 0; i < slave->sdca_data.num_functions; i++) {
+@@ -1284,7 +1287,8 @@ static int is_sdca_endpoint_present(stru
+ if (dai_type == dai_info->dai_type) {
+ dev_dbg(&slave->dev, "DAI type %d sdca function %s found\n",
+ dai_type, slave->sdca_data.function[i].name);
+- return 1;
++ ret = 1;
++ goto put_device;
+ }
+ }
+
+@@ -1292,7 +1296,11 @@ static int is_sdca_endpoint_present(stru
+ "SDCA device function for DAI type %d not supported, skip endpoint\n",
+ dai_info->dai_type);
+
+- return 0;
++ ret = 0;
++
++put_device:
++ put_device(sdw_dev);
++ return ret;
+ }
+
+ int asoc_sdw_parse_sdw_endpoints(struct snd_soc_card *card,
--- /dev/null
+From e8c73eb7db0a498cd4b22d2819e6ab1a6f506bd6 Mon Sep 17 00:00:00 2001
+From: Edward Adam Davis <eadavis@qq.com>
+Date: Fri, 7 Nov 2025 22:01:39 +0800
+Subject: cifs: client: fix memory leak in smb3_fs_context_parse_param
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+commit e8c73eb7db0a498cd4b22d2819e6ab1a6f506bd6 upstream.
+
+The user calls fsconfig twice, but when the program exits, free() only
+frees ctx->source for the second fsconfig, not the first.
+Regarding fc->source, there is no code in the fs context related to its
+memory reclamation.
+
+To fix this memory leak, release the source memory corresponding to ctx
+or fc before each parsing.
+
+syzbot reported:
+BUG: memory leak
+unreferenced object 0xffff888128afa360 (size 96):
+ backtrace (crc 79c9c7ba):
+ kstrdup+0x3c/0x80 mm/util.c:84
+ smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444
+
+BUG: memory leak
+unreferenced object 0xffff888112c7d900 (size 96):
+ backtrace (crc 79c9c7ba):
+ smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629
+ smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
+
+Reported-by: syzbot+72afd4c236e6bc3f4bac@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=72afd4c236e6bc3f4bac
+Cc: stable@vger.kernel.org
+Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Signed-off-by: Edward Adam Davis <eadavis@qq.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/fs_context.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/smb/client/fs_context.c
++++ b/fs/smb/client/fs_context.c
+@@ -1437,12 +1437,14 @@ static int smb3_fs_context_parse_param(s
+ cifs_errorf(fc, "Unknown error parsing devname\n");
+ goto cifs_parse_mount_err;
+ }
++ kfree(ctx->source);
+ ctx->source = smb3_fs_context_fullpath(ctx, '/');
+ if (IS_ERR(ctx->source)) {
+ ctx->source = NULL;
+ cifs_errorf(fc, "OOM when copying UNC string\n");
+ goto cifs_parse_mount_err;
+ }
++ kfree(fc->source);
+ fc->source = kstrdup(ctx->source, GFP_KERNEL);
+ if (fc->source == NULL) {
+ cifs_errorf(fc, "OOM when copying UNC string\n");
--- /dev/null
+From 1abbdf3d57aa964e572940d67c9ec5dc87710738 Mon Sep 17 00:00:00 2001
+From: Hao Ge <gehao@kylinos.cn>
+Date: Wed, 29 Oct 2025 09:43:17 +0800
+Subject: codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Hao Ge <gehao@kylinos.cn>
+
+commit 1abbdf3d57aa964e572940d67c9ec5dc87710738 upstream.
+
+When alloc_slab_obj_exts() fails and then later succeeds in allocating a
+slab extension vector, it calls handle_failed_objexts_alloc() to mark all
+objects in the vector as empty. As a result all objects in this slab
+(slabA) will have their extensions set to CODETAG_EMPTY.
+
+Later on if this slabA is used to allocate a slabobj_ext vector for
+another slab (slabB), we end up with the slabB->obj_exts pointing to a
+slabobj_ext vector that itself has a non-NULL slabobj_ext equal to
+CODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called to
+free slabB->obj_exts vector.
+
+free_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which will
+generate a warning because it expects slabobj_ext vectors to have a NULL
+obj_ext, not CODETAG_EMPTY.
+
+Modify mark_objexts_empty() to skip the warning and setting the obj_ext
+value if it's already set to CODETAG_EMPTY.
+
+
+To quickly detect this WARN, I modified the code from
+WARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1);
+
+We then obtained this message:
+
+[21630.898561] ------------[ cut here ]------------
+[21630.898596] kernel BUG at mm/slub.c:2050!
+[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
+[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1
+vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap
+vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace
+netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs
+blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel
+udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
+nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct
+nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
+nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink
+virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper
+drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi
+net_failover virtio_console failover virtio_mmio dm_mirror
+dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci
+virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4
+aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]
+[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump:
+loaded Tainted: GÂ Â Â Â Â Â Â WÂ Â Â Â Â Â Â Â Â Â 6.18.0-rc1+ #74 PREEMPT(voluntary)
+[21630.910495] Tainted: [W]=WARN
+[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
+2/2/2022
+[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
+BTYPE=--)
+[21630.912392] pc : __free_slab+0x228/0x250
+[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp :
+ffff8000a02f73e0
+[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27:
+ffff0000c0011c40
+[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24:
+ffff000102199b40
+[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21:
+ffff0000c0011c40
+[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18:
+0000000000000000
+[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15:
+0000000000000000
+[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12:
+ffff70001405ee66
+[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 :
+ffff800080a295dc
+[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 :
+0000000000003000
+[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 :
+0000000000000007
+[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 :
+0000000000000001
+[21630.921810] Call trace:
+[21630.922130]Â __free_slab+0x228/0x250 (P)
+[21630.922669]Â free_slab+0x38/0x118
+[21630.923079]Â free_to_partial_list+0x1d4/0x340
+[21630.923591]Â __slab_free+0x24c/0x348
+[21630.924024]Â ___cache_free+0xf0/0x110
+[21630.924468]Â qlist_free_all+0x78/0x130
+[21630.924922]Â kasan_quarantine_reduce+0x114/0x148
+[21630.925525]Â __kasan_slab_alloc+0x7c/0xb0
+[21630.926006]Â kmem_cache_alloc_noprof+0x164/0x5c8
+[21630.926699]Â __alloc_object+0x44/0x1f8
+[21630.927153]Â __create_object+0x34/0xc8
+[21630.927604]Â kmemleak_alloc+0xb8/0xd8
+[21630.928052]Â kmem_cache_alloc_noprof+0x368/0x5c8
+[21630.928606]Â getname_flags.part.0+0xa4/0x610
+[21630.929112]Â getname_flags+0x80/0xd8
+[21630.929557]Â vfs_fstatat+0xc8/0xe0
+[21630.929975]Â __do_sys_newfstatat+0xa0/0x100
+[21630.930469]Â __arm64_sys_newfstatat+0x90/0xd8
+[21630.931046]Â invoke_syscall+0xd4/0x258
+[21630.931685]Â el0_svc_common.constprop.0+0xb4/0x240
+[21630.932467]Â do_el0_svc+0x48/0x68
+[21630.932972]Â el0_svc+0x40/0xe0
+[21630.933472]Â el0t_64_sync_handler+0xa0/0xe8
+[21630.934151]Â el0t_64_sync+0x1ac/0x1b0
+[21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000)
+[21630.936461] SMP: stopping secondary CPUs
+[21630.939550] Starting crashdump kernel...
+[21630.940108] Bye!
+
+Link: https://lkml.kernel.org/r/20251029014317.1533488-1-hao.ge@linux.dev
+Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
+Signed-off-by: Hao Ge <gehao@kylinos.cn>
+Reviewed-by: Suren Baghdasaryan <surenb@google.com>
+Cc: Christoph Lameter (Ampere) <cl@gentwo.org>
+Cc: David Rientjes <rientjes@google.com>
+Cc: gehao <gehao@kylinos.cn>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: Shakeel Butt <shakeel.butt@linux.dev>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -1970,7 +1970,11 @@ static inline void mark_objexts_empty(st
+ if (slab_exts) {
+ unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
+ obj_exts_slab, obj_exts);
+- /* codetag should be NULL */
++
++ if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
++ return;
++
++ /* codetag should be NULL here */
+ WARN_ON(slab_exts[offs].ref.ct);
+ set_codetag_empty(&slab_exts[offs].ref);
+ }
--- /dev/null
+From 00fbff75c5acb4755f06f08bd1071879c63940c5 Mon Sep 17 00:00:00 2001
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+Date: Sun, 2 Nov 2025 01:07:41 +0530
+Subject: crash: fix crashkernel resource shrink
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+commit 00fbff75c5acb4755f06f08bd1071879c63940c5 upstream.
+
+When crashkernel is configured with a high reservation, shrinking its
+value below the low crashkernel reservation causes two issues:
+
+1. Invalid crashkernel resource objects
+2. Kernel crash if crashkernel shrinking is done twice
+
+For example, with crashkernel=200M,high, the kernel reserves 200MB of high
+memory and some default low memory (say 256MB). The reservation appears
+as:
+
+cat /proc/iomem | grep -i crash
+af000000-beffffff : Crash kernel
+433000000-43f7fffff : Crash kernel
+
+If crashkernel is then shrunk to 50MB (echo 52428800 >
+/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:
+af000000-beffffff : Crash kernel
+
+Instead, it should show 50MB:
+af000000-b21fffff : Crash kernel
+
+Further shrinking crashkernel to 40MB causes a kernel crash with the
+following trace (x86):
+
+BUG: kernel NULL pointer dereference, address: 0000000000000038
+PGD 0 P4D 0
+Oops: 0000 [#1] PREEMPT SMP NOPTI
+<snip...>
+Call Trace: <TASK>
+? __die_body.cold+0x19/0x27
+? page_fault_oops+0x15a/0x2f0
+? search_module_extables+0x19/0x60
+? search_bpf_extables+0x5f/0x80
+? exc_page_fault+0x7e/0x180
+? asm_exc_page_fault+0x26/0x30
+? __release_resource+0xd/0xb0
+release_resource+0x26/0x40
+__crash_shrink_memory+0xe5/0x110
+crash_shrink_memory+0x12a/0x190
+kexec_crash_size_store+0x41/0x80
+kernfs_fop_write_iter+0x141/0x1f0
+vfs_write+0x294/0x460
+ksys_write+0x6d/0xf0
+<snip...>
+
+This happens because __crash_shrink_memory()/kernel/crash_core.c
+incorrectly updates the crashk_res resource object even when
+crashk_low_res should be updated.
+
+Fix this by ensuring the correct crashkernel resource object is updated
+when shrinking crashkernel memory.
+
+Link: https://lkml.kernel.org/r/20251101193741.289252-1-sourabhjain@linux.ibm.com
+Fixes: 16c6006af4d4 ("kexec: enable kexec_crash_size to support two crash kernel regions")
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Acked-by: Baoquan He <bhe@redhat.com>
+Cc: Zhen Lei <thunder.leizhen@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/crash_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/crash_core.c
++++ b/kernel/crash_core.c
+@@ -367,7 +367,7 @@ static int __crash_shrink_memory(struct
+ old_res->start = 0;
+ old_res->end = 0;
+ } else {
+- crashk_res.end = ram_res->start - 1;
++ old_res->end = ram_res->start - 1;
+ }
+
+ crash_free_reserved_phys_range(ram_res->start, ram_res->end);
--- /dev/null
+From 59b0afd01b2ce353ab422ea9c8375b03db313a21 Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Mon, 27 Oct 2025 23:09:34 +0800
+Subject: crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit 59b0afd01b2ce353ab422ea9c8375b03db313a21 upstream.
+
+The qm_get_qos_value() function calls bus_find_device_by_name() which
+increases the device reference count, but fails to call put_device()
+to balance the reference count and lead to a device reference leak.
+
+Add put_device() calls in both the error path and success path to
+properly balance the reference count.
+
+Found via static analysis.
+
+Fixes: 22d7a6c39cab ("crypto: hisilicon/qm - add pci bdf number check")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Reviewed-by: Longfang Liu <liulongfang@huawei.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/hisilicon/qm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/crypto/hisilicon/qm.c
++++ b/drivers/crypto/hisilicon/qm.c
+@@ -3857,10 +3857,12 @@ static ssize_t qm_get_qos_value(struct h
+ pdev = container_of(dev, struct pci_dev, dev);
+ if (pci_physfn(pdev) != qm->pdev) {
+ pci_err(qm->pdev, "the pdev input does not match the pf!\n");
++ put_device(dev);
+ return -EINVAL;
+ }
+
+ *fun_index = pdev->devfn;
++ put_device(dev);
+
+ return 0;
+ }
--- /dev/null
+From 895b4c0c79b092d732544011c3cecaf7322c36a1 Mon Sep 17 00:00:00 2001
+From: Wei Yang <albinwyang@tencent.com>
+Date: Sat, 25 Oct 2025 10:42:33 +0800
+Subject: fs/proc: fix uaf in proc_readdir_de()
+
+From: Wei Yang <albinwyang@tencent.com>
+
+commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream.
+
+Pde is erased from subdir rbtree through rb_erase(), but not set the node
+to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()
+set the erased node to EMPTY, then pde_subdir_next() will return NULL to
+avoid uaf access.
+
+We found an uaf issue while using stress-ng testing, need to run testcase
+getdent and tun in the same time. The steps of the issue is as follows:
+
+1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current
+ pde is tun3;
+
+2) in the [time windows] unregister netdevice tun3 and tun2, and erase
+ them from rbtree. erase tun3 first, and then erase tun2. the
+ pde(tun2) will be released to slab;
+
+3) continue to getdent process, then pde_subdir_next() will return
+ pde(tun2) which is released, it will case uaf access.
+
+CPU 0 | CPU 1
+-------------------------------------------------------------------------
+traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2
+sys_getdents64() |
+ iterate_dir() |
+ proc_readdir() |
+ proc_readdir_de() | snmp6_unregister_dev()
+ pde_get(de); | proc_remove()
+ read_unlock(&proc_subdir_lock); | remove_proc_subtree()
+ | write_lock(&proc_subdir_lock);
+ [time window] | rb_erase(&root->subdir_node, &parent->subdir);
+ | write_unlock(&proc_subdir_lock);
+ read_lock(&proc_subdir_lock); |
+ next = pde_subdir_next(de); |
+ pde_put(de); |
+ de = next; //UAF |
+
+rbtree of dev_snmp6
+ |
+ pde(tun3)
+ / \
+ NULL pde(tun2)
+
+Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com
+Signed-off-by: Wei Yang <albinwyang@tencent.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: wangzijie <wangzijie1@honor.com>
+Cc: Alexey Dobriyan <adobriyan@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/proc/generic.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/fs/proc/generic.c
++++ b/fs/proc/generic.c
+@@ -698,6 +698,12 @@ void pde_put(struct proc_dir_entry *pde)
+ }
+ }
+
++static void pde_erase(struct proc_dir_entry *pde, struct proc_dir_entry *parent)
++{
++ rb_erase(&pde->subdir_node, &parent->subdir);
++ RB_CLEAR_NODE(&pde->subdir_node);
++}
++
+ /*
+ * Remove a /proc entry and free it if it's not currently in use.
+ */
+@@ -720,7 +726,7 @@ void remove_proc_entry(const char *name,
+ WARN(1, "removing permanent /proc entry '%s'", de->name);
+ de = NULL;
+ } else {
+- rb_erase(&de->subdir_node, &parent->subdir);
++ pde_erase(de, parent);
+ if (S_ISDIR(de->mode))
+ parent->nlink--;
+ }
+@@ -764,7 +770,7 @@ int remove_proc_subtree(const char *name
+ root->parent->name, root->name);
+ return -EINVAL;
+ }
+- rb_erase(&root->subdir_node, &parent->subdir);
++ pde_erase(root, parent);
+
+ de = root;
+ while (1) {
+@@ -776,7 +782,7 @@ int remove_proc_subtree(const char *name
+ next->parent->name, next->name);
+ return -EINVAL;
+ }
+- rb_erase(&next->subdir_node, &de->subdir);
++ pde_erase(next, de);
+ de = next;
+ continue;
+ }
--- /dev/null
+From 56b3c85e153b84f27e6cff39623ba40a1ad299d3 Mon Sep 17 00:00:00 2001
+From: Song Liu <song@kernel.org>
+Date: Mon, 27 Oct 2025 10:50:21 -0700
+Subject: ftrace: Fix BPF fexit with livepatch
+
+From: Song Liu <song@kernel.org>
+
+commit 56b3c85e153b84f27e6cff39623ba40a1ad299d3 upstream.
+
+When livepatch is attached to the same function as bpf trampoline with
+a fexit program, bpf trampoline code calls register_ftrace_direct()
+twice. The first time will fail with -EAGAIN, and the second time it
+will succeed. This requires register_ftrace_direct() to unregister
+the address on the first attempt. Otherwise, the bpf trampoline cannot
+attach. Here is an easy way to reproduce this issue:
+
+ insmod samples/livepatch/livepatch-sample.ko
+ bpftrace -e 'fexit:cmdline_proc_show {}'
+ ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show...
+
+Fix this by cleaning up the hash when register_ftrace_function_nolock hits
+errors.
+
+Also, move the code that resets ops->func and ops->trampoline to the error
+path of register_ftrace_direct(); and add a helper function reset_direct()
+in register_ftrace_direct() and unregister_ftrace_direct().
+
+Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use")
+Cc: stable@vger.kernel.org # v6.6+
+Reported-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
+Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crowdstrike.com/
+Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
+Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Reviewed-by: Jiri Olsa <jolsa@kernel.org>
+Link: https://lore.kernel.org/r/20251027175023.1521602-2-song@kernel.org
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/bpf/trampoline.c | 5 -----
+ kernel/trace/ftrace.c | 20 ++++++++++++++------
+ 2 files changed, 14 insertions(+), 11 deletions(-)
+
+--- a/kernel/bpf/trampoline.c
++++ b/kernel/bpf/trampoline.c
+@@ -479,11 +479,6 @@ again:
+ * BPF_TRAMP_F_SHARE_IPMODIFY is set, we can generate the
+ * trampoline again, and retry register.
+ */
+- /* reset fops->func and fops->trampoline for re-register */
+- tr->fops->func = NULL;
+- tr->fops->trampoline = 0;
+-
+- /* free im memory and reallocate later */
+ bpf_tramp_image_free(im);
+ goto again;
+ }
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -5953,6 +5953,17 @@ static void register_ftrace_direct_cb(st
+ free_ftrace_hash(fhp);
+ }
+
++static void reset_direct(struct ftrace_ops *ops, unsigned long addr)
++{
++ struct ftrace_hash *hash = ops->func_hash->filter_hash;
++
++ remove_direct_functions_hash(hash, addr);
++
++ /* cleanup for possible another register call */
++ ops->func = NULL;
++ ops->trampoline = 0;
++}
++
+ /**
+ * register_ftrace_direct - Call a custom trampoline directly
+ * for multiple functions registered in @ops
+@@ -6048,6 +6059,8 @@ int register_ftrace_direct(struct ftrace
+ ops->direct_call = addr;
+
+ err = register_ftrace_function_nolock(ops);
++ if (err)
++ reset_direct(ops, addr);
+
+ out_unlock:
+ mutex_unlock(&direct_mutex);
+@@ -6080,7 +6093,6 @@ EXPORT_SYMBOL_GPL(register_ftrace_direct
+ int unregister_ftrace_direct(struct ftrace_ops *ops, unsigned long addr,
+ bool free_filters)
+ {
+- struct ftrace_hash *hash = ops->func_hash->filter_hash;
+ int err;
+
+ if (check_direct_multi(ops))
+@@ -6090,13 +6102,9 @@ int unregister_ftrace_direct(struct ftra
+
+ mutex_lock(&direct_mutex);
+ err = unregister_ftrace_function(ops);
+- remove_direct_functions_hash(hash, addr);
++ reset_direct(ops, addr);
+ mutex_unlock(&direct_mutex);
+
+- /* cleanup for possible another register call */
+- ops->func = NULL;
+- ops->trampoline = 0;
+-
+ if (free_filters)
+ ftrace_free_filter(ops);
+ return err;
--- /dev/null
+From fdf302e6bea1822a9144a0cc2e8e17527e746162 Mon Sep 17 00:00:00 2001
+From: Sami Tolvanen <samitolvanen@google.com>
+Date: Mon, 10 Nov 2025 14:19:13 +0100
+Subject: gendwarfksyms: Skip files with no exports
+
+From: Sami Tolvanen <samitolvanen@google.com>
+
+commit fdf302e6bea1822a9144a0cc2e8e17527e746162 upstream.
+
+Starting with Rust 1.91.0 (released 2025-10-30), in upstream commit
+ab91a63d403b ("Ignore intrinsic calls in cross-crate-inlining cost model")
+[1][2], `bindings.o` stops containing DWARF debug information because the
+`Default` implementations contained `write_bytes()` calls which are now
+ignored in that cost model (note that `CLIPPY=1` does not reproduce it).
+
+This means `gendwarfksyms` complains:
+
+ RUSTC L rust/bindings.o
+ error: gendwarfksyms: process_module: dwarf_get_units failed: no debugging information?
+
+There are several alternatives that would work here: conditionally
+skipping in the cases needed (but that is subtle and brittle), forcing
+DWARF generation with e.g. a dummy `static` (ugly and we may need to
+do it in several crates), skipping the call to the tool in the Kbuild
+command when there are no exports (fine) or teaching the tool to do so
+itself (simple and clean).
+
+Thus do the last one: don't attempt to process files if we have no symbol
+versions to calculate.
+
+ [ I used the commit log of my patch linked below since it explained the
+ root issue and expanded it a bit more to summarize the alternatives.
+
+ - Miguel ]
+
+Cc: stable@vger.kernel.org # Needed in 6.17.y.
+Reported-by: Haiyue Wang <haiyuewa@163.com>
+Closes: https://lore.kernel.org/rust-for-linux/b8c1c73d-bf8b-4bf2-beb1-84ffdcd60547@163.com/
+Suggested-by: Miguel Ojeda <ojeda@kernel.org>
+Link: https://lore.kernel.org/rust-for-linux/CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N0w6GqTF-kJOeiSw@mail.gmail.com/
+Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a72984ed99 [1]
+Link: https://github.com/rust-lang/rust/pull/145910 [2]
+Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
+Tested-by: Haiyue Wang <haiyuewa@163.com>
+Reviewed-by: Alice Ryhl <aliceryhl@google.com>
+Link: https://patch.msgid.link/20251110131913.1789896-1-ojeda@kernel.org
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/gendwarfksyms/gendwarfksyms.c | 3 ++-
+ scripts/gendwarfksyms/gendwarfksyms.h | 2 +-
+ scripts/gendwarfksyms/symbols.c | 4 +++-
+ 3 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/scripts/gendwarfksyms/gendwarfksyms.c b/scripts/gendwarfksyms/gendwarfksyms.c
+index 08ae61eb327e..f5203d1640ee 100644
+--- a/scripts/gendwarfksyms/gendwarfksyms.c
++++ b/scripts/gendwarfksyms/gendwarfksyms.c
+@@ -138,7 +138,8 @@ int main(int argc, char **argv)
+ error("no input files?");
+ }
+
+- symbol_read_exports(stdin);
++ if (!symbol_read_exports(stdin))
++ return 0;
+
+ if (symtypes_file) {
+ symfile = fopen(symtypes_file, "w");
+diff --git a/scripts/gendwarfksyms/gendwarfksyms.h b/scripts/gendwarfksyms/gendwarfksyms.h
+index d9c06d2cb1df..32cec8f7695a 100644
+--- a/scripts/gendwarfksyms/gendwarfksyms.h
++++ b/scripts/gendwarfksyms/gendwarfksyms.h
+@@ -123,7 +123,7 @@ struct symbol {
+ typedef void (*symbol_callback_t)(struct symbol *, void *arg);
+
+ bool is_symbol_ptr(const char *name);
+-void symbol_read_exports(FILE *file);
++int symbol_read_exports(FILE *file);
+ void symbol_read_symtab(int fd);
+ struct symbol *symbol_get(const char *name);
+ void symbol_set_ptr(struct symbol *sym, Dwarf_Die *ptr);
+diff --git a/scripts/gendwarfksyms/symbols.c b/scripts/gendwarfksyms/symbols.c
+index 35ed594f0749..ecddcb5ffcdf 100644
+--- a/scripts/gendwarfksyms/symbols.c
++++ b/scripts/gendwarfksyms/symbols.c
+@@ -128,7 +128,7 @@ static bool is_exported(const char *name)
+ return for_each(name, NULL, NULL) > 0;
+ }
+
+-void symbol_read_exports(FILE *file)
++int symbol_read_exports(FILE *file)
+ {
+ struct symbol *sym;
+ char *line = NULL;
+@@ -159,6 +159,8 @@ void symbol_read_exports(FILE *file)
+
+ free(line);
+ debug("%d exported symbols", nsym);
++
++ return nsym;
+ }
+
+ static void get_symbol(struct symbol *sym, void *arg)
+--
+2.52.0
+
--- /dev/null
+From d3c9c213c0b86ac5dd8fe2c53c24db20f1f510bc Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Mon, 10 Nov 2025 14:30:41 -0700
+Subject: io_uring/rw: ensure allocated iovec gets cleared for early failure
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit d3c9c213c0b86ac5dd8fe2c53c24db20f1f510bc upstream.
+
+A previous commit reused the recyling infrastructure for early cleanup,
+but this is not enough for the case where our internal caches have
+overflowed. If this happens, then the allocated iovec can get leaked if
+the request is also aborted early.
+
+Reinstate the previous forced free of the iovec for that situation.
+
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+3c93637d7648c24e1fd0@syzkaller.appspotmail.com
+Tested-by: syzbot+3c93637d7648c24e1fd0@syzkaller.appspotmail.com
+Fixes: 9ac273ae3dc2 ("io_uring/rw: use io_rw_recycle() from cleanup path")
+Link: https://lore.kernel.org/io-uring/69122a59.a70a0220.22f260.00fd.GAE@google.com/
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/rw.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/io_uring/rw.c
++++ b/io_uring/rw.c
+@@ -461,7 +461,10 @@ int io_read_mshot_prep(struct io_kiocb *
+
+ void io_readv_writev_cleanup(struct io_kiocb *req)
+ {
++ struct io_async_rw *rw = req->async_data;
++
+ lockdep_assert_held(&req->ctx->uring_lock);
++ io_vec_free(&rw->vec);
+ io_rw_recycle(req, 0);
+ }
+
--- /dev/null
+From ac1499fcd40fe06479e9b933347b837ccabc2a40 Mon Sep 17 00:00:00 2001
+From: Chuang Wang <nashuiliang@gmail.com>
+Date: Tue, 11 Nov 2025 14:43:24 +0800
+Subject: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
+
+From: Chuang Wang <nashuiliang@gmail.com>
+
+commit ac1499fcd40fe06479e9b933347b837ccabc2a40 upstream.
+
+The sit driver's packet transmission path calls: sit_tunnel_xmit() ->
+update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called
+to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
+
+The race window is between fnhe_remove_oldest() selecting fnheX for
+deletion and the subsequent kfree_rcu(). During this time, the
+concurrent path's __mkroute_output() -> find_exception() can fetch the
+soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a
+new dst using a dst_hold(). When the original fnheX is freed via RCU,
+the dst reference remains permanently leaked.
+
+CPU 0 CPU 1
+__mkroute_output()
+ find_exception() [fnheX]
+ update_or_create_fnhe()
+ fnhe_remove_oldest() [fnheX]
+ rt_bind_exception() [bind dst]
+ RCU callback [fnheX freed, dst leak]
+
+This issue manifests as a device reference count leak and a warning in
+dmesg when unregistering the net device:
+
+ unregister_netdevice: waiting for sitX to become free. Usage count = N
+
+Ido Schimmel provided the simple test validation method [1].
+
+The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().
+Since rt_bind_exception() checks this field, setting it to zero prevents
+the stale fnhe from being reused and bound to a new dst just before it
+is freed.
+
+[1]
+ip netns add ns1
+ip -n ns1 link set dev lo up
+ip -n ns1 address add 192.0.2.1/32 dev lo
+ip -n ns1 link add name dummy1 up type dummy
+ip -n ns1 route add 192.0.2.2/32 dev dummy1
+ip -n ns1 link add name gretap1 up arp off type gretap \
+ local 192.0.2.1 remote 192.0.2.2
+ip -n ns1 route add 198.51.0.0/16 dev gretap1
+taskset -c 0 ip netns exec ns1 mausezahn gretap1 \
+ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
+taskset -c 2 ip netns exec ns1 mausezahn gretap1 \
+ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
+sleep 10
+ip netns pids ns1 | xargs kill
+ip netns del ns1
+
+Cc: stable@vger.kernel.org
+Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible")
+Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://patch.msgid.link/20251111064328.24440-1-nashuiliang@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/route.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/net/ipv4/route.c
++++ b/net/ipv4/route.c
+@@ -606,6 +606,11 @@ static void fnhe_remove_oldest(struct fn
+ oldest_p = fnhe_p;
+ }
+ }
++
++ /* Clear oldest->fnhe_daddr to prevent this fnhe from being
++ * rebound with new dsts in rt_bind_exception().
++ */
++ oldest->fnhe_daddr = 0;
+ fnhe_flush_routes(oldest);
+ *oldest_p = oldest->fnhe_next;
+ kfree_rcu(oldest, rcu);
--- /dev/null
+From 2f6ce7e714ef842e43120ecd6a7ed287b502026d Mon Sep 17 00:00:00 2001
+From: Quanmin Yan <yanquanmin1@huawei.com>
+Date: Thu, 30 Oct 2025 10:07:45 +0800
+Subject: mm/damon/stat: change last_refresh_jiffies to a global variable
+
+From: Quanmin Yan <yanquanmin1@huawei.com>
+
+commit 2f6ce7e714ef842e43120ecd6a7ed287b502026d upstream.
+
+Patch series "mm/damon: fixes for the jiffies-related issues", v2.
+
+On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make
+jiffies wrap bugs appear earlier. However, this may cause the
+time_before() series of functions to return unexpected values, resulting
+in DAMON not functioning as intended. Meanwhile, similar issues exist in
+some specific user operation scenarios.
+
+This patchset addresses these issues. The first patch is about the
+DAMON_STAT module, and the second patch is about the core layer's sysfs.
+
+
+This patch (of 2):
+
+In DAMON_STAT's damon_stat_damon_call_fn(), time_before_eq() is used to
+avoid unnecessarily frequent stat update.
+
+On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make
+jiffies wrap bugs appear earlier. However, this causes time_before_eq()
+in DAMON_STAT to unexpectedly return true during the first 5 minutes after
+boot on 32-bit systems (see [1] for more explanation, which fixes another
+jiffies-related issue before). As a result, DAMON_STAT does not update
+any monitoring results during that period, which becomes more confusing
+when DAMON_STAT_ENABLED_DEFAULT is enabled.
+
+There is also an issue unrelated to the system's word size[2]: if the user
+stops DAMON_STAT just after last_refresh_jiffies is updated and restarts
+it after 5 seconds or a longer delay, last_refresh_jiffies will retain an
+older value, causing time_before_eq() to return false and the update to
+happen earlier than expected.
+
+Fix these issues by making last_refresh_jiffies a global variable and
+initializing it each time DAMON_STAT is started.
+
+Link: https://lkml.kernel.org/r/20251030020746.967174-2-yanquanmin1@huawei.com
+Link: https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com [1]
+Link: https://lore.kernel.org/all/20251028143250.50144-1-sj@kernel.org/ [2]
+Fixes: fabdd1e911da ("mm/damon/stat: calculate and expose estimated memory bandwidth")
+Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com>
+Suggested-by: SeongJae Park <sj@kernel.org>
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: ze zuo <zuoze1@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/stat.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/mm/damon/stat.c
++++ b/mm/damon/stat.c
+@@ -41,6 +41,8 @@ MODULE_PARM_DESC(memory_idle_ms_percenti
+
+ static struct damon_ctx *damon_stat_context;
+
++static unsigned long damon_stat_last_refresh_jiffies;
++
+ static void damon_stat_set_estimated_memory_bandwidth(struct damon_ctx *c)
+ {
+ struct damon_target *t;
+@@ -125,13 +127,12 @@ static void damon_stat_set_idletime_perc
+ static int damon_stat_damon_call_fn(void *data)
+ {
+ struct damon_ctx *c = data;
+- static unsigned long last_refresh_jiffies;
+
+ /* avoid unnecessarily frequent stat update */
+- if (time_before_eq(jiffies, last_refresh_jiffies +
++ if (time_before_eq(jiffies, damon_stat_last_refresh_jiffies +
+ msecs_to_jiffies(5 * MSEC_PER_SEC)))
+ return 0;
+- last_refresh_jiffies = jiffies;
++ damon_stat_last_refresh_jiffies = jiffies;
+
+ damon_stat_set_estimated_memory_bandwidth(c);
+ damon_stat_set_idletime_percentiles(c);
+@@ -204,6 +205,8 @@ static int damon_stat_start(void)
+ err = damon_start(&damon_stat_context, 1, true);
+ if (err)
+ return err;
++
++ damon_stat_last_refresh_jiffies = jiffies;
+ call_control.data = damon_stat_context;
+ return damon_call(damon_stat_context, &call_control);
+ }
--- /dev/null
+From 9fd7bb5083d1e1027b8ac1e365c29921ab88b177 Mon Sep 17 00:00:00 2001
+From: Quanmin Yan <yanquanmin1@huawei.com>
+Date: Thu, 30 Oct 2025 10:07:46 +0800
+Subject: mm/damon/sysfs: change next_update_jiffies to a global variable
+
+From: Quanmin Yan <yanquanmin1@huawei.com>
+
+commit 9fd7bb5083d1e1027b8ac1e365c29921ab88b177 upstream.
+
+In DAMON's damon_sysfs_repeat_call_fn(), time_before() is used to compare
+the current jiffies with next_update_jiffies to determine whether to
+update the sysfs files at this moment.
+
+On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make
+jiffies wrap bugs appear earlier. However, this causes time_before() in
+damon_sysfs_repeat_call_fn() to unexpectedly return true during the first
+5 minutes after boot on 32-bit systems (see [1] for more explanation,
+which fixes another jiffies-related issue before). As a result, DAMON
+does not update sysfs files during that period.
+
+There is also an issue unrelated to the system's word size[2]: if the
+user stops DAMON just after next_update_jiffies is updated and restarts
+it after 'refresh_ms' or a longer delay, next_update_jiffies will retain
+an older value, causing time_before() to return false and the update to
+happen earlier than expected.
+
+Fix these issues by making next_update_jiffies a global variable and
+initializing it each time DAMON is started.
+
+Link: https://lkml.kernel.org/r/20251030020746.967174-3-yanquanmin1@huawei.com
+Link: https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com [1]
+Link: https://lore.kernel.org/all/20251029013038.66625-1-sj@kernel.org/ [2]
+Fixes: d809a7c64ba8 ("mm/damon/sysfs: implement refresh_ms file internal work")
+Suggested-by: SeongJae Park <sj@kernel.org>
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: ze zuo <zuoze1@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/sysfs.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/mm/damon/sysfs.c
++++ b/mm/damon/sysfs.c
+@@ -1514,16 +1514,17 @@ static struct damon_ctx *damon_sysfs_bui
+ return ctx;
+ }
+
++static unsigned long damon_sysfs_next_update_jiffies;
++
+ static int damon_sysfs_repeat_call_fn(void *data)
+ {
+ struct damon_sysfs_kdamond *sysfs_kdamond = data;
+- static unsigned long next_update_jiffies;
+
+ if (!sysfs_kdamond->refresh_ms)
+ return 0;
+- if (time_before(jiffies, next_update_jiffies))
++ if (time_before(jiffies, damon_sysfs_next_update_jiffies))
+ return 0;
+- next_update_jiffies = jiffies +
++ damon_sysfs_next_update_jiffies = jiffies +
+ msecs_to_jiffies(sysfs_kdamond->refresh_ms);
+
+ if (!mutex_trylock(&damon_sysfs_lock))
+@@ -1569,6 +1570,9 @@ static int damon_sysfs_turn_damon_on(str
+ }
+ kdamond->damon_ctx = ctx;
+
++ damon_sysfs_next_update_jiffies =
++ jiffies + msecs_to_jiffies(kdamond->refresh_ms);
++
+ repeat_call_control->fn = damon_sysfs_repeat_call_fn;
+ repeat_call_control->data = kdamond;
+ repeat_call_control->repeat = true;
--- /dev/null
+From f1d47cafe513b5552a5b20a7af0936d9070a8a78 Mon Sep 17 00:00:00 2001
+From: Zi Yan <ziy@nvidia.com>
+Date: Wed, 5 Nov 2025 11:29:10 -0500
+Subject: mm/huge_memory: fix folio split check for anon folios in swapcache
+
+From: Zi Yan <ziy@nvidia.com>
+
+commit f1d47cafe513b5552a5b20a7af0936d9070a8a78 upstream.
+
+Both uniform and non uniform split check missed the check to prevent
+splitting anon folios in swapcache to non-zero order.
+
+Splitting anon folios in swapcache to non-zero order can cause data
+corruption since swapcache only support PMD order and order-0 entries.
+This can happen when one use split_huge_pages under debugfs to split
+anon folios in swapcache.
+
+In-tree callers do not perform such an illegal operation. Only debugfs
+interface could trigger it. I will put adding a test case on my TODO
+list.
+
+Fix the check.
+
+Link: https://lkml.kernel.org/r/20251105162910.752266-1-ziy@nvidia.com
+Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()")
+Signed-off-by: Zi Yan <ziy@nvidia.com>
+Reported-by: "David Hildenbrand (Red Hat)" <david@kernel.org>
+Closes: https://lore.kernel.org/all/dc0ecc2c-4089-484f-917f-920fdca4c898@kernel.org/
+Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
+Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
+Cc: Barry Song <baohua@kernel.org>
+Cc: Dev Jain <dev.jain@arm.com>
+Cc: Lance Yang <lance.yang@linux.dev>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Nico Pache <npache@redhat.com>
+Cc: Ryan Roberts <ryan.roberts@arm.com>
+Cc: Wei Yang <richard.weiyang@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/huge_memory.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -3529,7 +3529,8 @@ bool non_uniform_split_supported(struct
+ /* order-1 is not supported for anonymous THP. */
+ VM_WARN_ONCE(warns && new_order == 1,
+ "Cannot split to order-1 folio");
+- return new_order != 1;
++ if (new_order == 1)
++ return false;
+ } else if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) &&
+ !mapping_large_folio_support(folio->mapping)) {
+ /*
+@@ -3560,7 +3561,8 @@ bool uniform_split_supported(struct foli
+ if (folio_test_anon(folio)) {
+ VM_WARN_ONCE(warns && new_order == 1,
+ "Cannot split to order-1 folio");
+- return new_order != 1;
++ if (new_order == 1)
++ return false;
+ } else if (new_order) {
+ if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) &&
+ !mapping_large_folio_support(folio->mapping)) {
--- /dev/null
+From fa5a061700364bc28ee1cb1095372f8033645dcb Mon Sep 17 00:00:00 2001
+From: Zi Yan <ziy@nvidia.com>
+Date: Wed, 22 Oct 2025 23:05:21 -0400
+Subject: mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order
+
+From: Zi Yan <ziy@nvidia.com>
+
+commit fa5a061700364bc28ee1cb1095372f8033645dcb upstream.
+
+folio split clears PG_has_hwpoisoned, but the flag should be preserved in
+after-split folios containing pages with PG_hwpoisoned flag if the folio
+is split to >0 order folios. Scan all pages in a to-be-split folio to
+determine which after-split folios need the flag.
+
+An alternatives is to change PG_has_hwpoisoned to PG_maybe_hwpoisoned to
+avoid the scan and set it on all after-split folios, but resulting false
+positive has undesirable negative impact. To remove false positive,
+caller of folio_test_has_hwpoisoned() and folio_contain_hwpoisoned_page()
+needs to do the scan. That might be causing a hassle for current and
+future callers and more costly than doing the scan in the split code.
+More details are discussed in [1].
+
+This issue can be exposed via:
+1. splitting a has_hwpoisoned folio to >0 order from debugfs interface;
+2. truncating part of a has_hwpoisoned folio in
+ truncate_inode_partial_folio().
+
+And later accesses to a hwpoisoned page could be possible due to the
+missing has_hwpoisoned folio flag. This will lead to MCE errors.
+
+Link: https://lore.kernel.org/all/CAHbLzkoOZm0PXxE9qwtF4gKR=cpRXrSrJ9V9Pm2DJexs985q4g@mail.gmail.com/ [1]
+Link: https://lkml.kernel.org/r/20251023030521.473097-1-ziy@nvidia.com
+Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages")
+Signed-off-by: Zi Yan <ziy@nvidia.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Yang Shi <yang@os.amperecomputing.com>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Reviewed-by: Lance Yang <lance.yang@linux.dev>
+Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
+Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
+Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
+Cc: Pankaj Raghav <kernel@pankajraghav.com>
+Cc: Barry Song <baohua@kernel.org>
+Cc: Dev Jain <dev.jain@arm.com>
+Cc: Jane Chu <jane.chu@oracle.com>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Luis Chamberalin <mcgrof@kernel.org>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
+Cc: Nico Pache <npache@redhat.com>
+Cc: Ryan Roberts <ryan.roberts@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/huge_memory.c | 23 ++++++++++++++++++++---
+ 1 file changed, 20 insertions(+), 3 deletions(-)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -3271,6 +3271,14 @@ bool can_split_folio(struct folio *folio
+ caller_pins;
+ }
+
++static bool page_range_has_hwpoisoned(struct page *page, long nr_pages)
++{
++ for (; nr_pages; page++, nr_pages--)
++ if (PageHWPoison(page))
++ return true;
++ return false;
++}
++
+ /*
+ * It splits @folio into @new_order folios and copies the @folio metadata to
+ * all the resulting folios.
+@@ -3278,17 +3286,24 @@ bool can_split_folio(struct folio *folio
+ static void __split_folio_to_order(struct folio *folio, int old_order,
+ int new_order)
+ {
++ /* Scan poisoned pages when split a poisoned folio to large folios */
++ const bool handle_hwpoison = folio_test_has_hwpoisoned(folio) && new_order;
+ long new_nr_pages = 1 << new_order;
+ long nr_pages = 1 << old_order;
+ long i;
+
++ folio_clear_has_hwpoisoned(folio);
++
++ /* Check first new_nr_pages since the loop below skips them */
++ if (handle_hwpoison &&
++ page_range_has_hwpoisoned(folio_page(folio, 0), new_nr_pages))
++ folio_set_has_hwpoisoned(folio);
+ /*
+ * Skip the first new_nr_pages, since the new folio from them have all
+ * the flags from the original folio.
+ */
+ for (i = new_nr_pages; i < nr_pages; i += new_nr_pages) {
+ struct page *new_head = &folio->page + i;
+-
+ /*
+ * Careful: new_folio is not a "real" folio before we cleared PageTail.
+ * Don't pass it around before clear_compound_head().
+@@ -3330,6 +3345,10 @@ static void __split_folio_to_order(struc
+ (1L << PG_dirty) |
+ LRU_GEN_MASK | LRU_REFS_MASK));
+
++ if (handle_hwpoison &&
++ page_range_has_hwpoisoned(new_head, new_nr_pages))
++ folio_set_has_hwpoisoned(new_folio);
++
+ new_folio->mapping = folio->mapping;
+ new_folio->index = folio->index + i;
+
+@@ -3430,8 +3449,6 @@ static int __split_unmapped_folio(struct
+ if (folio_test_anon(folio))
+ mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
+
+- folio_clear_has_hwpoisoned(folio);
+-
+ /*
+ * split to new_order one order at a time. For uniform split,
+ * folio is split to new_order directly.
--- /dev/null
+From 7e76b75e5ab3339bebab3a4738226cd9b27d8c42 Mon Sep 17 00:00:00 2001
+From: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com>
+Date: Tue, 30 Sep 2025 13:56:01 +0200
+Subject: mm/kmsan: fix kmsan kmalloc hook when no stack depots are allocated yet
+
+From: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com>
+
+commit 7e76b75e5ab3339bebab3a4738226cd9b27d8c42 upstream.
+
+If no stack depot is allocated yet, due to masking out __GFP_RECLAIM flags
+kmsan called from kmalloc cannot allocate stack depot. kmsan fails to
+record origin and report issues. This may result in KMSAN failing to
+report issues.
+
+Reusing flags from kmalloc without modifying them should be safe for kmsan.
+For example, such chain of calls is possible:
+test_uninit_kmalloc -> kmalloc -> __kmalloc_cache_noprof ->
+slab_alloc_node -> slab_post_alloc_hook ->
+kmsan_slab_alloc -> kmsan_internal_poison_memory.
+
+Only when it is called in a context without flags present should
+__GFP_RECLAIM flags be masked.
+
+With this change all kmsan tests start working reliably.
+
+Eric reported:
+
+: Yes, KMSAN seems to be at least partially broken currently. Besides the
+: fact that the kmsan KUnit test is currently failing (which I reported at
+: https://lore.kernel.org/r/20250911175145.GA1376@sol), I've confirmed that
+: the poly1305 KUnit test causes a KMSAN warning with Aleksei's patch
+: applied but does not cause a warning without it. The warning did get
+: reached via syzbot somehow
+: (https://lore.kernel.org/r/751b3d80293a6f599bb07770afcef24f623c7da0.1761026343.git.xiaopei01@kylinos.cn/),
+: so KMSAN must still work in some cases. But it didn't work for me.
+
+Link: https://lkml.kernel.org/r/20250930115600.709776-2-aleksei.nikiforov@linux.ibm.com
+Link: https://lkml.kernel.org/r/20251022030213.GA35717@sol
+Fixes: 97769a53f117 ("mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation")
+Signed-off-by: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com>
+Reviewed-by: Alexander Potapenko <glider@google.com>
+Tested-by: Eric Biggers <ebiggers@kernel.org>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Dmitriy Vyukov <dvyukov@google.com>
+Cc: Ilya Leoshkevich <iii@linux.ibm.com>
+Cc: Marco Elver <elver@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kmsan/core.c | 3 ---
+ mm/kmsan/hooks.c | 6 ++++--
+ mm/kmsan/shadow.c | 2 +-
+ 3 files changed, 5 insertions(+), 6 deletions(-)
+
+--- a/mm/kmsan/core.c
++++ b/mm/kmsan/core.c
+@@ -72,9 +72,6 @@ depot_stack_handle_t kmsan_save_stack_wi
+
+ nr_entries = stack_trace_save(entries, KMSAN_STACK_DEPTH, 0);
+
+- /* Don't sleep. */
+- flags &= ~(__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM);
+-
+ handle = stack_depot_save(entries, nr_entries, flags);
+ return stack_depot_set_extra_bits(handle, extra);
+ }
+--- a/mm/kmsan/hooks.c
++++ b/mm/kmsan/hooks.c
+@@ -84,7 +84,8 @@ void kmsan_slab_free(struct kmem_cache *
+ if (s->ctor)
+ return;
+ kmsan_enter_runtime();
+- kmsan_internal_poison_memory(object, s->object_size, GFP_KERNEL,
++ kmsan_internal_poison_memory(object, s->object_size,
++ GFP_KERNEL & ~(__GFP_RECLAIM),
+ KMSAN_POISON_CHECK | KMSAN_POISON_FREE);
+ kmsan_leave_runtime();
+ }
+@@ -114,7 +115,8 @@ void kmsan_kfree_large(const void *ptr)
+ kmsan_enter_runtime();
+ page = virt_to_head_page((void *)ptr);
+ KMSAN_WARN_ON(ptr != page_address(page));
+- kmsan_internal_poison_memory((void *)ptr, page_size(page), GFP_KERNEL,
++ kmsan_internal_poison_memory((void *)ptr, page_size(page),
++ GFP_KERNEL & ~(__GFP_RECLAIM),
+ KMSAN_POISON_CHECK | KMSAN_POISON_FREE);
+ kmsan_leave_runtime();
+ }
+--- a/mm/kmsan/shadow.c
++++ b/mm/kmsan/shadow.c
+@@ -208,7 +208,7 @@ void kmsan_free_page(struct page *page,
+ return;
+ kmsan_enter_runtime();
+ kmsan_internal_poison_memory(page_address(page), page_size(page),
+- GFP_KERNEL,
++ GFP_KERNEL & ~(__GFP_RECLAIM),
+ KMSAN_POISON_CHECK | KMSAN_POISON_FREE);
+ kmsan_leave_runtime();
+ }
--- /dev/null
+From 0d6c356dd6547adac2b06b461528e3573f52d953 Mon Sep 17 00:00:00 2001
+From: "Isaac J. Manjarres" <isaacmanjarres@google.com>
+Date: Tue, 28 Oct 2025 12:10:12 -0700
+Subject: mm/mm_init: fix hash table order logging in alloc_large_system_hash()
+
+From: Isaac J. Manjarres <isaacmanjarres@google.com>
+
+commit 0d6c356dd6547adac2b06b461528e3573f52d953 upstream.
+
+When emitting the order of the allocation for a hash table,
+alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log
+base 2 of the allocation size. This is not correct if the allocation size
+is smaller than a page, and yields a negative value for the order as seen
+below:
+
+TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP
+bind hash table entries: 32 (order: -2, 1024 bytes, linear)
+
+Use get_order() to compute the order when emitting the hash table
+information to correctly handle cases where the allocation size is smaller
+than a page:
+
+TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP
+bind hash table entries: 32 (order: 0, 1024 bytes, linear)
+
+Link: https://lkml.kernel.org/r/20251028191020.413002-1-isaacmanjarres@google.com
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
+Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mm_init.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/mm_init.c
++++ b/mm/mm_init.c
+@@ -2537,7 +2537,7 @@ void *__init alloc_large_system_hash(con
+ panic("Failed to allocate %s hash table\n", tablename);
+
+ pr_info("%s hash table entries: %ld (order: %d, %lu bytes, %s)\n",
+- tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size,
++ tablename, 1UL << log2qty, get_order(size), size,
+ virt ? (huge ? "vmalloc hugepage" : "vmalloc") : "linear");
+
+ if (_hash_shift)
--- /dev/null
+From 04d1c9d60c6ec4c0003d433572eaa45f8b217788 Mon Sep 17 00:00:00 2001
+From: Dev Jain <dev.jain@arm.com>
+Date: Tue, 28 Oct 2025 12:09:52 +0530
+Subject: mm/mremap: honour writable bit in mremap pte batching
+
+From: Dev Jain <dev.jain@arm.com>
+
+commit 04d1c9d60c6ec4c0003d433572eaa45f8b217788 upstream.
+
+Currently mremap folio pte batch ignores the writable bit during figuring
+out a set of similar ptes mapping the same folio. Suppose that the first
+pte of the batch is writable while the others are not - set_ptes will end
+up setting the writable bit on the other ptes, which is a violation of
+mremap semantics. Therefore, use FPB_RESPECT_WRITE to check the writable
+bit while determining the pte batch.
+
+Link: https://lkml.kernel.org/r/20251028063952.90313-1-dev.jain@arm.com
+Signed-off-by: Dev Jain <dev.jain@arm.com>
+Fixes: f822a9a81a31 ("mm: optimize mremap() by PTE batching")
+Reported-by: David Hildenbrand <david@redhat.com>
+Debugged-by: David Hildenbrand <david@redhat.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Acked-by: Pedro Falcato <pfalcato@suse.de>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Barry Song <baohua@kernel.org>
+Cc: Jann Horn <jannh@google.com>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org> [6.17+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mremap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/mremap.c b/mm/mremap.c
+index bd7314898ec5..419a0ea0a870 100644
+--- a/mm/mremap.c
++++ b/mm/mremap.c
+@@ -187,7 +187,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr
+ if (!folio || !folio_test_large(folio))
+ return 1;
+
+- return folio_pte_batch(folio, ptep, pte, max_nr);
++ return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, FPB_RESPECT_WRITE);
+ }
+
+ static int move_ptes(struct pagetable_move_control *pmc,
+--
+2.52.0
+
--- /dev/null
+From 6f86d0534fddfbd08687fa0f01479d4226bc3c3d Mon Sep 17 00:00:00 2001
+From: Lance Yang <lance.yang@linux.dev>
+Date: Fri, 31 Oct 2025 20:09:55 +0800
+Subject: mm/secretmem: fix use-after-free race in fault handler
+
+From: Lance Yang <lance.yang@linux.dev>
+
+commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d upstream.
+
+When a page fault occurs in a secret memory file created with
+`memfd_secret(2)`, the kernel will allocate a new folio for it, mark the
+underlying page as not-present in the direct map, and add it to the file
+mapping.
+
+If two tasks cause a fault in the same page concurrently, both could end
+up allocating a folio and removing the page from the direct map, but only
+one would succeed in adding the folio to the file mapping. The task that
+failed undoes the effects of its attempt by (a) freeing the folio again
+and (b) putting the page back into the direct map. However, by doing
+these two operations in this order, the page becomes available to the
+allocator again before it is placed back in the direct mapping.
+
+If another task attempts to allocate the page between (a) and (b), and the
+kernel tries to access it via the direct map, it would result in a
+supervisor not-present page fault.
+
+Fix the ordering to restore the direct map before the folio is freed.
+
+Link: https://lkml.kernel.org/r/20251031120955.92116-1-lance.yang@linux.dev
+Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
+Signed-off-by: Lance Yang <lance.yang@linux.dev>
+Reported-by: Google Big Sleep <big-sleep-vuln-reports@google.com>
+Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWKrdQJ-ATdg@mail.gmail.com/
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/secretmem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/secretmem.c
++++ b/mm/secretmem.c
+@@ -82,13 +82,13 @@ retry:
+ __folio_mark_uptodate(folio);
+ err = filemap_add_folio(mapping, folio, offset, gfp);
+ if (unlikely(err)) {
+- folio_put(folio);
+ /*
+ * If a split of large page was required, it
+ * already happened when we marked the page invalid
+ * which guarantees that this call won't fail
+ */
+ set_direct_map_default_noflush(folio_page(folio, 0));
++ folio_put(folio);
+ if (err == -EEXIST)
+ goto retry;
+
--- /dev/null
+From fc745ff317566ec299e16346ebb9eacc8fe5b9d2 Mon Sep 17 00:00:00 2001
+From: Kairui Song <kasong@tencent.com>
+Date: Wed, 22 Oct 2025 18:57:19 +0800
+Subject: mm/shmem: fix THP allocation and fallback loop
+
+From: Kairui Song <kasong@tencent.com>
+
+commit fc745ff317566ec299e16346ebb9eacc8fe5b9d2 upstream.
+
+The order check and fallback loop is updating the index value on every
+loop. This will cause the index to be wrongly aligned by a larger value
+while the loop shrinks the order.
+
+This may result in inserting and returning a folio of the wrong index and
+cause data corruption with some userspace workloads [1].
+
+[kasong@tencent.com: introduce a temporary variable to improve code]
+ Link: https://lkml.kernel.org/r/20251023065913.36925-1-ryncsn@gmail.com
+ Link: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/ [1]
+Link: https://lkml.kernel.org/r/20251022105719.18321-1-ryncsn@gmail.com
+Link: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/ [1]
+Fixes: e7a2ab7b3bb5 ("mm: shmem: add mTHP support for anonymous shmem")
+Closes: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/
+Signed-off-by: Kairui Song <kasong@tencent.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Acked-by: Zi Yan <ziy@nvidia.com>
+Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
+Reviewed-by: Barry Song <baohua@kernel.org>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Dev Jain <dev.jain@arm.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Nico Pache <npache@redhat.com>
+Cc: Ryan Roberts <ryan.roberts@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/shmem.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -1919,6 +1919,7 @@ static struct folio *shmem_alloc_and_add
+ struct shmem_inode_info *info = SHMEM_I(inode);
+ unsigned long suitable_orders = 0;
+ struct folio *folio = NULL;
++ pgoff_t aligned_index;
+ long pages;
+ int error, order;
+
+@@ -1932,10 +1933,12 @@ static struct folio *shmem_alloc_and_add
+ order = highest_order(suitable_orders);
+ while (suitable_orders) {
+ pages = 1UL << order;
+- index = round_down(index, pages);
+- folio = shmem_alloc_folio(gfp, order, info, index);
+- if (folio)
++ aligned_index = round_down(index, pages);
++ folio = shmem_alloc_folio(gfp, order, info, aligned_index);
++ if (folio) {
++ index = aligned_index;
+ goto allocated;
++ }
+
+ if (pages == HPAGE_PMD_NR)
+ count_vm_event(THP_FILE_FALLBACK);
--- /dev/null
+From 1c2a936edd71e133f2806e68324ec81a4eb07588 Mon Sep 17 00:00:00 2001
+From: Kairui Song <kasong@tencent.com>
+Date: Tue, 11 Nov 2025 21:36:08 +0800
+Subject: mm, swap: fix potential UAF issue for VMA readahead
+
+From: Kairui Song <kasong@tencent.com>
+
+commit 1c2a936edd71e133f2806e68324ec81a4eb07588 upstream.
+
+Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device
+pinning"), the common helper for allocating and preparing a folio in the
+swap cache layer no longer tries to get a swap device reference
+internally, because all callers of __read_swap_cache_async are already
+holding a swap entry reference. The repeated swap device pinning isn't
+needed on the same swap device.
+
+Caller of VMA readahead is also holding a reference to the target entry's
+swap device, but VMA readahead walks the page table, so it might encounter
+swap entries from other devices, and call __read_swap_cache_async on
+another device without holding a reference to it.
+
+So it is possible to cause a UAF when swapoff of device A raced with
+swapin on device B, and VMA readahead tries to read swap entries from
+device A. It's not easy to trigger, but in theory, it could cause real
+issues.
+
+Make VMA readahead try to get the device reference first if the swap
+device is a different one from the target entry.
+
+Link: https://lkml.kernel.org/r/20251111-swap-fix-vma-uaf-v1-1-41c660e58562@tencent.com
+Fixes: 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning")
+Suggested-by: Huang Ying <ying.huang@linux.alibaba.com>
+Signed-off-by: Kairui Song <kasong@tencent.com>
+Acked-by: Chris Li <chrisl@kernel.org>
+Cc: Baoquan He <bhe@redhat.com>
+Cc: Barry Song <baohua@kernel.org>
+Cc: Kemeng Shi <shikemeng@huaweicloud.com>
+Cc: Nhat Pham <nphamcs@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/swap_state.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/mm/swap_state.c
++++ b/mm/swap_state.c
+@@ -746,6 +746,8 @@ static struct folio *swap_vma_readahead(
+
+ blk_start_plug(&plug);
+ for (addr = start; addr < end; ilx++, addr += PAGE_SIZE) {
++ struct swap_info_struct *si = NULL;
++
+ if (!pte++) {
+ pte = pte_offset_map(vmf->pmd, addr);
+ if (!pte)
+@@ -759,8 +761,19 @@ static struct folio *swap_vma_readahead(
+ continue;
+ pte_unmap(pte);
+ pte = NULL;
++ /*
++ * Readahead entry may come from a device that we are not
++ * holding a reference to, try to grab a reference, or skip.
++ */
++ if (swp_type(entry) != swp_type(targ_entry)) {
++ si = get_swap_device(entry);
++ if (!si)
++ continue;
++ }
+ folio = __read_swap_cache_async(entry, gfp_mask, mpol, ilx,
+ &page_allocated, false);
++ if (si)
++ put_swap_device(si);
+ if (!folio)
+ continue;
+ if (page_allocated) {
--- /dev/null
+From 739f04f4a46237536aff07ff223c231da53ed8ce Mon Sep 17 00:00:00 2001
+From: Shawn Lin <shawn.lin@rock-chips.com>
+Date: Tue, 4 Nov 2025 11:51:23 +0800
+Subject: mmc: dw_mmc-rockchip: Fix wrong internal phase calculate
+
+From: Shawn Lin <shawn.lin@rock-chips.com>
+
+commit 739f04f4a46237536aff07ff223c231da53ed8ce upstream.
+
+ciu clock is 2 times of io clock, but the sample clk used is
+derived from io clock provided to the card. So we should use
+io clock to calculate the phase.
+
+Fixes: 59903441f5e4 ("mmc: dw_mmc-rockchip: Add internal phase support")
+Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
+Acked-by: Heiko Stuebner <heiko@sntech.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/dw_mmc-rockchip.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc-rockchip.c
++++ b/drivers/mmc/host/dw_mmc-rockchip.c
+@@ -43,7 +43,7 @@ struct dw_mci_rockchip_priv_data {
+ */
+ static int rockchip_mmc_get_internal_phase(struct dw_mci *host, bool sample)
+ {
+- unsigned long rate = clk_get_rate(host->ciu_clk);
++ unsigned long rate = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
+ u32 raw_value;
+ u16 degrees;
+ u32 delay_num = 0;
+@@ -86,7 +86,7 @@ static int rockchip_mmc_get_phase(struct
+
+ static int rockchip_mmc_set_internal_phase(struct dw_mci *host, bool sample, int degrees)
+ {
+- unsigned long rate = clk_get_rate(host->ciu_clk);
++ unsigned long rate = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
+ u8 nineties, remainder;
+ u8 delay_num;
+ u32 raw_value;
--- /dev/null
+From 9e805625218b70d865fcee2105dbf835d473c074 Mon Sep 17 00:00:00 2001
+From: Rakuram Eswaran <rakuram.e96@gmail.com>
+Date: Thu, 23 Oct 2025 20:24:32 +0530
+Subject: mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rakuram Eswaran <rakuram.e96@gmail.com>
+
+commit 9e805625218b70d865fcee2105dbf835d473c074 upstream.
+
+This patch refactors pxamci_probe() to use devm-managed resource
+allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
+improved readability and automatic cleanup on probe failure.
+
+It also removes redundant NULL assignments and manual resource release
+logic from pxamci_probe(), and eliminates the corresponding release
+calls from pxamci_remove().
+
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
+Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
+Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
+Reviewed-by: Khalid Aziz <khalid@kernel.org>
+Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/pxamci.c | 56 +++++++++++++--------------------------
+ 1 file changed, 18 insertions(+), 38 deletions(-)
+
+diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
+index 26d03352af63..b5ea058ed467 100644
+--- a/drivers/mmc/host/pxamci.c
++++ b/drivers/mmc/host/pxamci.c
+@@ -652,10 +652,9 @@ static int pxamci_probe(struct platform_device *pdev)
+ host->clkrt = CLKRT_OFF;
+
+ host->clk = devm_clk_get(dev, NULL);
+- if (IS_ERR(host->clk)) {
+- host->clk = NULL;
+- return PTR_ERR(host->clk);
+- }
++ if (IS_ERR(host->clk))
++ return dev_err_probe(dev, PTR_ERR(host->clk),
++ "Failed to acquire clock\n");
+
+ host->clkrate = clk_get_rate(host->clk);
+
+@@ -703,46 +702,37 @@ static int pxamci_probe(struct platform_device *pdev)
+
+ platform_set_drvdata(pdev, mmc);
+
+- host->dma_chan_rx = dma_request_chan(dev, "rx");
+- if (IS_ERR(host->dma_chan_rx)) {
+- host->dma_chan_rx = NULL;
++ host->dma_chan_rx = devm_dma_request_chan(dev, "rx");
++ if (IS_ERR(host->dma_chan_rx))
+ return dev_err_probe(dev, PTR_ERR(host->dma_chan_rx),
+ "unable to request rx dma channel\n");
+- }
+
+- host->dma_chan_tx = dma_request_chan(dev, "tx");
+- if (IS_ERR(host->dma_chan_tx)) {
+- dev_err(dev, "unable to request tx dma channel\n");
+- ret = PTR_ERR(host->dma_chan_tx);
+- host->dma_chan_tx = NULL;
+- goto out;
+- }
++
++ host->dma_chan_tx = devm_dma_request_chan(dev, "tx");
++ if (IS_ERR(host->dma_chan_tx))
++ return dev_err_probe(dev, PTR_ERR(host->dma_chan_tx),
++ "unable to request tx dma channel\n");
+
+ if (host->pdata) {
+ host->detect_delay_ms = host->pdata->detect_delay_ms;
+
+ host->power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
+- if (IS_ERR(host->power)) {
+- ret = PTR_ERR(host->power);
+- dev_err(dev, "Failed requesting gpio_power\n");
+- goto out;
+- }
++ if (IS_ERR(host->power))
++ return dev_err_probe(dev, PTR_ERR(host->power),
++ "Failed requesting gpio_power\n");
+
+ /* FIXME: should we pass detection delay to debounce? */
+ ret = mmc_gpiod_request_cd(mmc, "cd", 0, false, 0);
+- if (ret && ret != -ENOENT) {
+- dev_err(dev, "Failed requesting gpio_cd\n");
+- goto out;
+- }
++ if (ret && ret != -ENOENT)
++ return dev_err_probe(dev, ret, "Failed requesting gpio_cd\n");
+
+ if (!host->pdata->gpio_card_ro_invert)
+ mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+
+ ret = mmc_gpiod_request_ro(mmc, "wp", 0, 0);
+- if (ret && ret != -ENOENT) {
+- dev_err(dev, "Failed requesting gpio_ro\n");
+- goto out;
+- }
++ if (ret && ret != -ENOENT)
++ return dev_err_probe(dev, ret, "Failed requesting gpio_ro\n");
++
+ if (!ret)
+ host->use_ro_gpio = true;
+
+@@ -759,16 +749,8 @@ static int pxamci_probe(struct platform_device *pdev)
+ if (ret) {
+ if (host->pdata && host->pdata->exit)
+ host->pdata->exit(dev, mmc);
+- goto out;
+ }
+
+- return 0;
+-
+-out:
+- if (host->dma_chan_rx)
+- dma_release_channel(host->dma_chan_rx);
+- if (host->dma_chan_tx)
+- dma_release_channel(host->dma_chan_tx);
+ return ret;
+ }
+
+@@ -791,8 +773,6 @@ static void pxamci_remove(struct platform_device *pdev)
+
+ dmaengine_terminate_all(host->dma_chan_rx);
+ dmaengine_terminate_all(host->dma_chan_tx);
+- dma_release_channel(host->dma_chan_rx);
+- dma_release_channel(host->dma_chan_tx);
+ }
+ }
+
+--
+2.52.0
+
--- /dev/null
+From a28352cf2d2f8380e7aca8cb61682396dca7a991 Mon Sep 17 00:00:00 2001
+From: Shawn Lin <shawn.lin@rock-chips.com>
+Date: Mon, 20 Oct 2025 09:49:41 +0800
+Subject: mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4
+
+From: Shawn Lin <shawn.lin@rock-chips.com>
+
+commit a28352cf2d2f8380e7aca8cb61682396dca7a991 upstream.
+
+strbin signal delay under 0x8 configuration is not stable after massive
+test. The recommandation of it should be 0x4.
+
+Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
+Tested-by: Alexey Charkov <alchark@gmail.com>
+Tested-by: Hugh Cole-Baker <sigmaris@gmail.com>
+Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-of-dwcmshc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
++++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
+@@ -94,7 +94,7 @@
+ #define DLL_TXCLK_TAPNUM_DEFAULT 0x10
+ #define DLL_TXCLK_TAPNUM_90_DEGREES 0xA
+ #define DLL_TXCLK_TAPNUM_FROM_SW BIT(24)
+-#define DLL_STRBIN_TAPNUM_DEFAULT 0x8
++#define DLL_STRBIN_TAPNUM_DEFAULT 0x4
+ #define DLL_STRBIN_TAPNUM_FROM_SW BIT(24)
+ #define DLL_STRBIN_DELAY_NUM_SEL BIT(26)
+ #define DLL_STRBIN_DELAY_NUM_OFFSET 16
--- /dev/null
+From 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Fri, 7 Nov 2025 06:03:37 -0800
+Subject: net: netpoll: fix incorrect refcount handling causing incorrect cleanup
+
+From: Breno Leitao <leitao@debian.org>
+
+commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 upstream.
+
+commit efa95b01da18 ("netpoll: fix use after free") incorrectly
+ignored the refcount and prematurely set dev->npinfo to NULL during
+netpoll cleanup, leading to improper behavior and memory leaks.
+
+Scenario causing lack of proper cleanup:
+
+1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is
+ allocated, and refcnt = 1
+ - Keep in mind that npinfo is shared among all netpoll instances. In
+ this case, there is just one.
+
+2) Another netpoll is also associated with the same NIC and
+ npinfo->refcnt += 1.
+ - Now dev->npinfo->refcnt = 2;
+ - There is just one npinfo associated to the netdev.
+
+3) When the first netpolls goes to clean up:
+ - The first cleanup succeeds and clears np->dev->npinfo, ignoring
+ refcnt.
+ - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`
+ - Set dev->npinfo = NULL, without proper cleanup
+ - No ->ndo_netpoll_cleanup() is either called
+
+4) Now the second target tries to clean up
+ - The second cleanup fails because np->dev->npinfo is already NULL.
+ * In this case, ops->ndo_netpoll_cleanup() was never called, and
+ the skb pool is not cleaned as well (for the second netpoll
+ instance)
+ - This leaks npinfo and skbpool skbs, which is clearly reported by
+ kmemleak.
+
+Revert commit efa95b01da18 ("netpoll: fix use after free") and adds
+clarifying comments emphasizing that npinfo cleanup should only happen
+once the refcount reaches zero, ensuring stable and correct netpoll
+behavior.
+
+Cc: <stable@vger.kernel.org> # 3.17.x
+Cc: Jay Vosburgh <jv@jvosburgh.net>
+Fixes: efa95b01da18 ("netpoll: fix use after free")
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@debian.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/netpoll.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/net/core/netpoll.c
++++ b/net/core/netpoll.c
+@@ -812,6 +812,10 @@ static void __netpoll_cleanup(struct net
+ if (!npinfo)
+ return;
+
++ /* At this point, there is a single npinfo instance per netdevice, and
++ * its refcnt tracks how many netpoll structures are linked to it. We
++ * only perform npinfo cleanup when the refcnt decrements to zero.
++ */
+ if (refcount_dec_and_test(&npinfo->refcnt)) {
+ const struct net_device_ops *ops;
+
+@@ -821,8 +825,7 @@ static void __netpoll_cleanup(struct net
+
+ RCU_INIT_POINTER(np->dev->npinfo, NULL);
+ call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info);
+- } else
+- RCU_INIT_POINTER(np->dev->npinfo, NULL);
++ }
+
+ skb_pool_flush(np);
+ }
--- /dev/null
+From 9a6b60cb147d53968753a34805211d2e5e08c027 Mon Sep 17 00:00:00 2001
+From: Edward Adam Davis <eadavis@qq.com>
+Date: Thu, 30 Oct 2025 07:51:52 +0900
+Subject: nilfs2: avoid having an active sc_timer before freeing sci
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+commit 9a6b60cb147d53968753a34805211d2e5e08c027 upstream.
+
+Because kthread_stop did not stop sc_task properly and returned -EINTR,
+the sc_timer was not properly closed, ultimately causing the problem [1]
+reported by syzbot when freeing sci due to the sc_timer not being closed.
+
+Because the thread sc_task main function nilfs_segctor_thread() returns 0
+when it succeeds, when the return value of kthread_stop() is not 0 in
+nilfs_segctor_destroy(), we believe that it has not properly closed
+sc_timer.
+
+We use timer_shutdown_sync() to sync wait for sc_timer to shutdown, and
+set the value of sc_task to NULL under the protection of lock
+sc_state_lock, so as to avoid the issue caused by sc_timer not being
+properly shutdowned.
+
+[1]
+ODEBUG: free active (active state 0) object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout
+Call trace:
+ nilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline]
+ nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c:2877
+ nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509
+
+Link: https://lkml.kernel.org/r/20251029225226.16044-1-konishi.ryusuke@gmail.com
+Fixes: 3f66cc261ccb ("nilfs2: use kthread_create and kthread_stop for the log writer thread")
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+24d8b70f039151f65590@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=24d8b70f039151f65590
+Tested-by: syzbot+24d8b70f039151f65590@syzkaller.appspotmail.com
+Signed-off-by: Edward Adam Davis <eadavis@qq.com>
+Cc: <stable@vger.kernel.org> [6.12+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/segment.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/fs/nilfs2/segment.c
++++ b/fs/nilfs2/segment.c
+@@ -2768,7 +2768,12 @@ static void nilfs_segctor_destroy(struct
+
+ if (sci->sc_task) {
+ wake_up(&sci->sc_wait_daemon);
+- kthread_stop(sci->sc_task);
++ if (kthread_stop(sci->sc_task)) {
++ spin_lock(&sci->sc_state_lock);
++ sci->sc_task = NULL;
++ timer_shutdown_sync(&sci->sc_timer);
++ spin_unlock(&sci->sc_state_lock);
++ }
+ }
+
+ spin_lock(&sci->sc_state_lock);
--- /dev/null
+From dd4adb986a86727ed8f56c48b6d0695f1e211e65 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Tue, 28 Oct 2025 12:27:24 -0400
+Subject: selftests/tracing: Run sample events to clear page cache events
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit dd4adb986a86727ed8f56c48b6d0695f1e211e65 upstream.
+
+The tracing selftest "event-filter-function.tc" was failing because it
+first runs the "sample_events" function that triggers the kmem_cache_free
+event and it looks at what function was used during a call to "ls".
+
+But the first time it calls this, it could trigger events that are used to
+pull pages into the page cache.
+
+The rest of the test uses the function it finds during that call to see if
+it will be called in subsequent "sample_events" calls. But if there's no
+need to pull pages into the page cache, it will not trigger that function
+and the test will fail.
+
+Call the "sample_events" twice to trigger all the page cache work before
+it calls it to find a function to use in subsequent checks.
+
+Cc: stable@vger.kernel.org
+Fixes: eb50d0f250e96 ("selftests/ftrace: Choose target function for filter test from samples")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/ftrace/test.d/filter/event-filter-function.tc | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/tools/testing/selftests/ftrace/test.d/filter/event-filter-function.tc
++++ b/tools/testing/selftests/ftrace/test.d/filter/event-filter-function.tc
+@@ -20,6 +20,10 @@ sample_events() {
+ echo 0 > tracing_on
+ echo 0 > events/enable
+
++# Clear functions caused by page cache; run sample_events twice
++sample_events
++sample_events
++
+ echo "Get the most frequently calling function"
+ echo > trace
+ sample_events
--- /dev/null
+From 216158f063fe24fb003bd7da0cd92cd6e2c4d48b Mon Sep 17 00:00:00 2001
+From: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
+Date: Thu, 6 Nov 2025 15:25:32 +0530
+Subject: selftests/user_events: fix type cast for write_index packed member in perf_test
+
+From: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
+
+commit 216158f063fe24fb003bd7da0cd92cd6e2c4d48b upstream.
+
+Accessing 'reg.write_index' directly triggers a -Waddress-of-packed-member
+warning due to potential unaligned pointer access:
+
+perf_test.c:239:38: warning: taking address of packed member 'write_index'
+of class or structure 'user_reg' may result in an unaligned pointer value
+[-Waddress-of-packed-member]
+ 239 | ASSERT_NE(-1, write(self->data_fd, ®.write_index,
+ | ^~~~~~~~~~~~~~~
+
+Since write(2) works with any alignment. Casting '®.write_index'
+explicitly to 'void *' to suppress this warning.
+
+Link: https://lkml.kernel.org/r/20251106095532.15185-1-ankitkhushwaha.linux@gmail.com
+Fixes: 42187bdc3ca4 ("selftests/user_events: Add perf self-test for empty arguments events")
+Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
+Cc: Beau Belgrave <beaub@linux.microsoft.com>
+Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: sunliming <sunliming@kylinos.cn>
+Cc: Wei Yang <richard.weiyang@gmail.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/user_events/perf_test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/testing/selftests/user_events/perf_test.c
++++ b/tools/testing/selftests/user_events/perf_test.c
+@@ -236,7 +236,7 @@ TEST_F(user, perf_empty_events) {
+ ASSERT_EQ(1 << reg.enable_bit, self->check);
+
+ /* Ensure write shows up at correct offset */
+- ASSERT_NE(-1, write(self->data_fd, ®.write_index,
++ ASSERT_NE(-1, write(self->data_fd, (void *)®.write_index,
+ sizeof(reg.write_index)));
+ val = (void *)(((char *)perf_page) + perf_page->data_offset);
+ ASSERT_EQ(PERF_RECORD_SAMPLE, *val);
loongarch-consolidate-early_ioremap-ioremap_prot.patch
loongarch-use-correct-accessor-to-read-fwpc-mwpc.patch
loongarch-let-pte-pmd-_modify-record-the-status-of-_page_dirty.patch
+ipv4-route-prevent-rt_bind_exception-from-rebinding-stale-fnhe.patch
+mm-damon-sysfs-change-next_update_jiffies-to-a-global-variable.patch
+nilfs2-avoid-having-an-active-sc_timer-before-freeing-sci.patch
+net-netpoll-fix-incorrect-refcount-handling-causing-incorrect-cleanup.patch
+mm-secretmem-fix-use-after-free-race-in-fault-handler.patch
+selftests-tracing-run-sample-events-to-clear-page-cache-events.patch
+wifi-mac80211-reject-address-change-while-connecting.patch
+mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order.patch
+fs-proc-fix-uaf-in-proc_readdir_de.patch
+mm-mm_init-fix-hash-table-order-logging-in-alloc_large_system_hash.patch
+mm-damon-stat-change-last_refresh_jiffies-to-a-global-variable.patch
+mm-kmsan-fix-kmsan-kmalloc-hook-when-no-stack-depots-are-allocated-yet.patch
+mm-shmem-fix-thp-allocation-and-fallback-loop.patch
+mm-mremap-honour-writable-bit-in-mremap-pte-batching.patch
+mm-swap-fix-potential-uaf-issue-for-vma-readahead.patch
+mm-huge_memory-fix-folio-split-check-for-anon-folios-in-swapcache.patch
+mmc-sdhci-of-dwcmshc-change-dll_strbin_tapnum_default-to-0x4.patch
+mmc-pxamci-simplify-pxamci_probe-error-handling-using-devm-apis.patch
+mmc-dw_mmc-rockchip-fix-wrong-internal-phase-calculate.patch
+alsa-hda-hdmi-fix-breakage-at-probing-nvhdmi-mcp-driver.patch
+alsa-usb-audio-fix-potential-overflow-of-pcm-transfer-buffer.patch
+asoc-sdw_utils-fix-device-reference-leak-in-is_sdca_endpoint_present.patch
+cifs-client-fix-memory-leak-in-smb3_fs_context_parse_param.patch
+codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch
+crash-fix-crashkernel-resource-shrink.patch
+crypto-hisilicon-qm-fix-device-reference-leak-in-qm_get_qos_value.patch
+smb-client-fix-cifs_pick_channel-when-channel-needs-reconnect.patch
+spi-try-to-get-acpi-gpio-irq-earlier.patch
+x86-microcode-amd-add-zen5-model-0x44-stepping-0x1-minrev.patch
+x86-cpu-amd-add-additional-fixed-rdseed-microcode-revisions.patch
+selftests-user_events-fix-type-cast-for-write_index-packed-member-in-perf_test.patch
+gendwarfksyms-skip-files-with-no-exports.patch
+io_uring-rw-ensure-allocated-iovec-gets-cleared-for-early-failure.patch
+ftrace-fix-bpf-fexit-with-livepatch.patch
--- /dev/null
+From 79280191c2fd7f24899bbd640003b5389d3c109c Mon Sep 17 00:00:00 2001
+From: Henrique Carvalho <henrique.carvalho@suse.com>
+Date: Fri, 7 Nov 2025 18:59:53 -0300
+Subject: smb: client: fix cifs_pick_channel when channel needs reconnect
+
+From: Henrique Carvalho <henrique.carvalho@suse.com>
+
+commit 79280191c2fd7f24899bbd640003b5389d3c109c upstream.
+
+cifs_pick_channel iterates candidate channels using cur. The
+reconnect-state test mistakenly used a different variable.
+
+This checked the wrong slot and would cause us to skip a healthy channel
+and to dispatch on one that needs reconnect, occasionally failing
+operations when a channel was down.
+
+Fix by replacing for the correct variable.
+
+Fixes: fc43a8ac396d ("cifs: cifs_pick_channel should try selecting active channels")
+Cc: stable@vger.kernel.org
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/transport.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/smb/client/transport.c
++++ b/fs/smb/client/transport.c
+@@ -831,7 +831,7 @@ struct TCP_Server_Info *cifs_pick_channe
+ if (!server || server->terminate)
+ continue;
+
+- if (CIFS_CHAN_NEEDS_RECONNECT(ses, i))
++ if (CIFS_CHAN_NEEDS_RECONNECT(ses, cur))
+ continue;
+
+ /*
--- /dev/null
+From 3cd2018e15b3d66d2187d92867e265f45ad79e6f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hansg@kernel.org>
+Date: Sun, 2 Nov 2025 20:09:21 +0100
+Subject: spi: Try to get ACPI GPIO IRQ earlier
+
+From: Hans de Goede <hansg@kernel.org>
+
+commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream.
+
+Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the
+acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called
+on the SPI device.
+
+If there is no driver for the SPI device then the move to spi_probe()
+results in acpi_dev_gpio_irq_get() never getting called. This may
+cause problems by leaving the GPIO pin floating because this call is
+responsible for setting up the GPIO pin direction and/or bias according
+to the values from the ACPI tables.
+
+Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device()
+to ensure the GPIO pin is always correctly setup, while keeping the
+acpi_dev_gpio_irq_get() call added to spi_probe() to deal with
+-EPROBE_DEFER returns caused by the GPIO controller not having a driver
+yet.
+
+Link: https://bbs.archlinux.org/viewtopic.php?id=302348
+Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hansg@kernel.org>
+Link: https://patch.msgid.link/20251102190921.30068-1-hansg@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/spi/spi.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -2866,6 +2866,16 @@ static acpi_status acpi_register_spi_dev
+ acpi_set_modalias(adev, acpi_device_hid(adev), spi->modalias,
+ sizeof(spi->modalias));
+
++ /*
++ * This gets re-tried in spi_probe() for -EPROBE_DEFER handling in case
++ * the GPIO controller does not have a driver yet. This needs to be done
++ * here too, because this call sets the GPIO direction and/or bias.
++ * Setting these needs to be done even if there is no driver, in which
++ * case spi_probe() will never get called.
++ */
++ if (spi->irq < 0)
++ spi->irq = acpi_dev_gpio_irq_get(adev, 0);
++
+ acpi_device_set_enumerated(adev);
+
+ adev->power.flags.ignore_parent = true;
--- /dev/null
+From a9da90e618cd0669a22bcc06a96209db5dd96e9b Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 5 Nov 2025 15:41:19 +0100
+Subject: wifi: mac80211: reject address change while connecting
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit a9da90e618cd0669a22bcc06a96209db5dd96e9b upstream.
+
+While connecting, the MAC address can already no longer be
+changed. The change is already rejected if netif_carrier_ok(),
+but of course that's not true yet while connecting. Check for
+auth_data or assoc_data, so the MAC address cannot be changed.
+
+Also more comprehensively check that there are no stations on
+the interface being changed - if any peer station is added it
+will know about our address already, so we cannot change it.
+
+Cc: stable@vger.kernel.org
+Fixes: 3c06e91b40db ("wifi: mac80211: Support POWERED_ADDR_CHANGE feature")
+Link: https://patch.msgid.link/20251105154119.f9f6c1df81bb.I9bb3760ede650fb96588be0d09a5a7bdec21b217@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mac80211/iface.c | 14 +++++++++++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+--- a/net/mac80211/iface.c
++++ b/net/mac80211/iface.c
+@@ -223,6 +223,10 @@ static int ieee80211_can_powered_addr_ch
+ if (netif_carrier_ok(sdata->dev))
+ return -EBUSY;
+
++ /* if any stations are set known (so they know this vif too), reject */
++ if (sta_info_get_by_idx(sdata, 0))
++ return -EBUSY;
++
+ /* First check no ROC work is happening on this iface */
+ list_for_each_entry(roc, &local->roc_list, list) {
+ if (roc->sdata != sdata)
+@@ -242,12 +246,16 @@ static int ieee80211_can_powered_addr_ch
+ ret = -EBUSY;
+ }
+
++ /*
++ * More interface types could be added here but changing the
++ * address while powered makes the most sense in client modes.
++ */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_P2P_CLIENT:
+- /* More interface types could be added here but changing the
+- * address while powered makes the most sense in client modes.
+- */
++ /* refuse while connecting */
++ if (sdata->u.mgd.auth_data || sdata->u.mgd.assoc_data)
++ return -EBUSY;
+ break;
+ default:
+ ret = -EOPNOTSUPP;
--- /dev/null
+From e1a97a627cd01d73fac5dd054d8f3de601ef2781 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 13 Nov 2025 16:35:50 -0600
+Subject: x86/CPU/AMD: Add additional fixed RDSEED microcode revisions
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit e1a97a627cd01d73fac5dd054d8f3de601ef2781 upstream.
+
+Microcode that resolves the RDSEED failure (SB-7055 [1]) has been released for
+additional Zen5 models to linux-firmware [2]. Update the zen5_rdseed_microcode
+array to cover these new models.
+
+Fixes: 607b9fb2ce24 ("x86/CPU/AMD: Add RDSEED fix for Zen5")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html [1]
+Link: https://gitlab.com/kernel-firmware/linux-firmware/-/commit/6167e5566900cf236f7a69704e8f4c441bc7212a [2]
+Link: https://patch.msgid.link/20251113223608.1495655-1-mario.limonciello@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/amd.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -1020,7 +1020,14 @@ static void init_amd_zen4(struct cpuinfo
+
+ static const struct x86_cpu_id zen5_rdseed_microcode[] = {
+ ZEN_MODEL_STEP_UCODE(0x1a, 0x02, 0x1, 0x0b00215a),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x08, 0x1, 0x0b008121),
+ ZEN_MODEL_STEP_UCODE(0x1a, 0x11, 0x0, 0x0b101054),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x24, 0x0, 0x0b204037),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x44, 0x0, 0x0b404035),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x44, 0x1, 0x0b404108),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x60, 0x0, 0x0b600037),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x68, 0x0, 0x0b608038),
++ ZEN_MODEL_STEP_UCODE(0x1a, 0x70, 0x0, 0x0b700037),
+ {},
+ };
+
--- /dev/null
+From dd14022a7ce96963aa923e35cf4bcc8c32f95840 Mon Sep 17 00:00:00 2001
+From: "Borislav Petkov (AMD)" <bp@alien8.de>
+Date: Fri, 14 Nov 2025 14:01:14 +0100
+Subject: x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev
+
+From: Borislav Petkov (AMD) <bp@alien8.de>
+
+commit dd14022a7ce96963aa923e35cf4bcc8c32f95840 upstream.
+
+Add the minimum Entrysign revision for that model+stepping to the list
+of minimum revisions.
+
+Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches")
+Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/e94dd76b-4911-482f-8500-5c848a3df026@citrix.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/microcode/amd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/cpu/microcode/amd.c
++++ b/arch/x86/kernel/cpu/microcode/amd.c
+@@ -224,6 +224,7 @@ static bool need_sha_check(u32 cur_rev)
+ case 0xb1010: return cur_rev <= 0xb101046; break;
+ case 0xb2040: return cur_rev <= 0xb204031; break;
+ case 0xb4040: return cur_rev <= 0xb404031; break;
++ case 0xb4041: return cur_rev <= 0xb404101; break;
+ case 0xb6000: return cur_rev <= 0xb600031; break;
+ case 0xb6080: return cur_rev <= 0xb608031; break;
+ case 0xb7000: return cur_rev <= 0xb700031; break;
projects / thirdparty / kernel / stable-queue.git / commitdiff
