- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] smb: client: fix memory leak in cifs_construct_tcon()
by Wang Zhaolong 07 Jan '26

07 Jan '26

From: Paulo Alcantara <pc(a)manguebit.org> stable inclusion from stable-v6.6.119 commit f62ffdfb431bdfa4b6d24233b7fd830eca0b801e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11577 CVE: CVE-2025-68295 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3184b6a5a24ec9ee74087b2a550476f386df7dc2 upstream. When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: f2aee329a68f ("cifs: set domainName when a domain-key is used in multiuser") Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.org> Reviewed-by: David Howells <dhowells(a)redhat.com> Cc: Jay Shin <jaeshin(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: linux-cifs(a)vger.kernel.org Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/smb/client/connect.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c index 23e0b902239a..c3acd5a66035 100644 --- a/fs/smb/client/connect.c +++ b/fs/smb/client/connect.c @@ -4196,10 +4196,11 @@ __cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid) reset_cifs_unix_caps(0, tcon, NULL, ctx); #endif /* CONFIG_CIFS_ALLOW_INSECURE_LEGACY */ out: kfree(ctx->username); + kfree(ctx->domainname); kfree_sensitive(ctx->password); kfree(origin_fullpath); kfree(ctx); return tcon; -- 2.34.3

2 1

[PATCH OLK-6.6] cifs: fix memory leak in smb3_fs_context_parse_param error path
by Wang Zhaolong 07 Jan '26

07 Jan '26

From: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> stable inclusion from stable-v6.6.118 commit 7627864dc3121f39e220f5253a227edf472de59e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11561 CVE: CVE-2025-68219 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7e4d9120cfa413dd34f4f434befc5dbe6c38b2e5 ] Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot Reported-by: syzbot+87be6809ed9bf6d718e3(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=87be6809ed9bf6d718e3 Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Reviewed-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/smb/client/fs_context.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c index 137d03781d52..dcb619b64235 100644 --- a/fs/smb/client/fs_context.c +++ b/fs/smb/client/fs_context.c @@ -1722,10 +1722,14 @@ static int smb3_fs_context_parse_param(struct fs_context *fc, cifs_parse_mount_err: kfree_sensitive(ctx->password); ctx->password = NULL; kfree_sensitive(ctx->password2); ctx->password2 = NULL; + kfree(ctx->source); + ctx->source = NULL; + kfree(fc->source); + fc->source = NULL; return -EINVAL; } int smb3_init_fs_context(struct fs_context *fc) { -- 2.34.3

2 1

[PATCH OLK-6.6] smb: client: fix potential cfid UAF in smb2_query_info_compound
by Wang Zhaolong 07 Jan '26

07 Jan '26

From: Henrique Carvalho <henrique.carvalho(a)suse.com> stable inclusion from stable-v6.6.117 commit 939c4e33005e2a56ea8fcedddf0da92df864bd3b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11308 CVE: CVE-2025-40320 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5c76f9961c170552c1d07c830b5e145475151600 upstream. When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80 Cc: stable(a)kernel.org Fixes: 4f1fffa237692 ("cifs: commands that are retried should have replay flag set") Reviewed-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Acked-by: Shyam Prasad N <sprasad(a)microsoft.com> Reviewed-by: Enzo Matsumiya <ematsumiya(a)suse.de> Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/smb/client/smb2ops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index c19643a37fa0..43c6d2f861f4 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -2655,15 +2655,16 @@ smb2_query_info_compound(const unsigned int xid, struct cifs_tcon *tcon, u8 oplock = SMB2_OPLOCK_LEVEL_NONE; struct cifs_open_parms oparms; struct cifs_fid fid; int rc; __le16 *utf16_path; - struct cached_fid *cfid = NULL; + struct cached_fid *cfid; int retries = 0, cur_sleep = 1; replay_again: /* reinitialize for possible replay */ + cfid = NULL; flags = CIFS_CP_CREATE_CLOSE_OP; oplock = SMB2_OPLOCK_LEVEL_NONE; server = cifs_pick_channel(ses); if (!path) -- 2.34.3

2 1

[PATCH OLK-6.6] cifs: client: fix memory leak in smb3_fs_context_parse_param
by Wang Zhaolong 07 Jan '26

07 Jan '26

From: Edward Adam Davis <eadavis(a)qq.com> stable inclusion from stable-v6.6.117 commit 868fc62811d3fabcf5685e14f36377a855d5412d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12582 CVE: CVE-2025-40268 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- 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(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72afd4c236e6bc3f4bac Cc: stable(a)vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.org> Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/smb/client/fs_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c index 137d03781d52..cf233cb9c194 100644 --- a/fs/smb/client/fs_context.c +++ b/fs/smb/client/fs_context.c @@ -1359,16 +1359,18 @@ static int smb3_fs_context_parse_param(struct fs_context *fc, goto cifs_parse_mount_err; default: 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"); goto cifs_parse_mount_err; } -- 2.34.3

2 1

[PATCH OLK-6.6 0/1] mfs: remove FAROUND event for mfsd demo
by Hongbo Li 07 Jan '26

07 Jan '26

Remove FAROUND event for mfsd demo. Hongbo Li (1): mfs: remove FAROUND event for mfsd demo tools/mfs/mfsd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10] net: netpoll: fix incorrect refcount handling causing incorrect cleanup
by Li Xiasong 07 Jan '26

07 Jan '26

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v5.10.247 commit 9b0bb18b4b9dc017c1825a2c5e763615e34a1593 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11640 CVE: CVE-2025-68245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 ] 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(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [ Adjust context ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Xiasong <lixiasong1(a)huawei.com> --- net/core/netpoll.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index f76afab9fd8b..2db43f0604e2 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -851,6 +851,10 @@ void __netpoll_cleanup(struct netpoll *np) synchronize_srcu(&netpoll_srcu); + /* 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; @@ -860,8 +864,7 @@ void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } } EXPORT_SYMBOL_GPL(__netpoll_cleanup); -- 2.34.1

2 1

[PATCH OLK-6.6] net: netpoll: fix incorrect refcount handling causing incorrect cleanup
by Li Xiasong 07 Jan '26

07 Jan '26

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.117 commit c645693180a98606c430825223d2029315d85e9d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11539 CVE: CVE-2025-68245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 ] 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(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: net/core/netpoll.c [conflicts due to not mergered 6c59f16f1770 ("net: netpoll: flush skb pool during cleanup") and 9a95eedc81de ("netpoll: remove netpoll_srcu").] Signed-off-by: Li Xiasong <lixiasong1(a)huawei.com> --- net/core/netpoll.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 1a4d2a61b060..38582335e10c 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -838,6 +838,10 @@ void __netpoll_cleanup(struct netpoll *np) synchronize_srcu(&netpoll_srcu); + /* 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; @@ -847,8 +851,7 @@ void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } } EXPORT_SYMBOL_GPL(__netpoll_cleanup); -- 2.34.1

2 1

[PATCH OLK-6.6] ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
by Li Xiasong 07 Jan '26

07 Jan '26

From: Chuang Wang <nashuiliang(a)gmail.com> stable inclusion from stable-v6.6.117 commit 041ab9ca6e80d8f792bb69df28ebf1ef39c06af8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11640 CVE: CVE-2025-68241 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- 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(a)vger.kernel.org Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible") Signed-off-by: Chuang Wang <nashuiliang(a)gmail.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20251111064328.24440-1-nashuiliang@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Xiasong <lixiasong1(a)huawei.com> --- net/ipv4/route.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 79c354896554..b149d9feb377 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -613,6 +613,11 @@ static void fnhe_remove_oldest(struct fnhe_hash_bucket *hash) 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); -- 2.34.1

2 1

[PATCH OLK-6.6] net: ipv6: fix field-spanning memcpy warning in AH output
by Li Xiasong 07 Jan '26

07 Jan '26

From: Charalampos Mitrodimas <charmitro(a)posteo.net> stable inclusion from stable-v6.6.117 commit f28dde240160f3c48a50d641d210ed6a3b9596ed category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11607 CVE: CVE-2025-40363 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ] Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication. Reported-by: syzbot+01b0667934cdceb4451c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c Signed-off-by: Charalampos Mitrodimas <charmitro(a)posteo.net> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Xiasong <lixiasong1(a)huawei.com> --- net/ipv6/ah6.c | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c index 01005035ad10..5361e2107458 100644 --- a/net/ipv6/ah6.c +++ b/net/ipv6/ah6.c @@ -46,6 +46,34 @@ struct ah_skb_cb { #define AH_SKB_CB(__skb) ((struct ah_skb_cb *)&((__skb)->cb[0])) +/* Helper to save IPv6 addresses and extension headers to temporary storage */ +static inline void ah6_save_hdrs(struct tmp_ext *iph_ext, + struct ipv6hdr *top_iph, int extlen) +{ + if (!extlen) + return; + +#if IS_ENABLED(CONFIG_IPV6_MIP6) + iph_ext->saddr = top_iph->saddr; +#endif + iph_ext->daddr = top_iph->daddr; + memcpy(&iph_ext->hdrs, top_iph + 1, extlen - sizeof(*iph_ext)); +} + +/* Helper to restore IPv6 addresses and extension headers from temporary storage */ +static inline void ah6_restore_hdrs(struct ipv6hdr *top_iph, + struct tmp_ext *iph_ext, int extlen) +{ + if (!extlen) + return; + +#if IS_ENABLED(CONFIG_IPV6_MIP6) + top_iph->saddr = iph_ext->saddr; +#endif + top_iph->daddr = iph_ext->daddr; + memcpy(top_iph + 1, &iph_ext->hdrs, extlen - sizeof(*iph_ext)); +} + static void *ah_alloc_tmp(struct crypto_ahash *ahash, int nfrags, unsigned int size) { @@ -304,13 +332,7 @@ static void ah6_output_done(void *data, int err) memcpy(ah->auth_data, icv, ahp->icv_trunc_len); memcpy(top_iph, iph_base, IPV6HDR_BASELEN); - if (extlen) { -#if IS_ENABLED(CONFIG_IPV6_MIP6) - memcpy(&top_iph->saddr, iph_ext, extlen); -#else - memcpy(&top_iph->daddr, iph_ext, extlen); -#endif - } + ah6_restore_hdrs(top_iph, iph_ext, extlen); kfree(AH_SKB_CB(skb)->tmp); xfrm_output_resume(skb->sk, skb, err); @@ -381,12 +403,8 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff *skb) */ memcpy(iph_base, top_iph, IPV6HDR_BASELEN); + ah6_save_hdrs(iph_ext, top_iph, extlen); if (extlen) { -#if IS_ENABLED(CONFIG_IPV6_MIP6) - memcpy(iph_ext, &top_iph->saddr, extlen); -#else - memcpy(iph_ext, &top_iph->daddr, extlen); -#endif err = ipv6_clear_mutable_options(top_iph, extlen - sizeof(*iph_ext) + sizeof(*top_iph), @@ -437,13 +455,7 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff *skb) memcpy(ah->auth_data, icv, ahp->icv_trunc_len); memcpy(top_iph, iph_base, IPV6HDR_BASELEN); - if (extlen) { -#if IS_ENABLED(CONFIG_IPV6_MIP6) - memcpy(&top_iph->saddr, iph_ext, extlen); -#else - memcpy(&top_iph->daddr, iph_ext, extlen); -#endif - } + ah6_restore_hdrs(top_iph, iph_ext, extlen); out_free: kfree(iph_base); -- 2.34.1

2 1

[PATCH OLK-6.6] Revert "NFS: fix up nfs_release_folio() to try to release the page"
by Wang Zhaolong 07 Jan '26

07 Jan '26

hulk inclusion category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/8332 ------------------ This reverts commit 96780ca55e3cbf4f150fd5a833a61492c9947b5b. Under the following scenario, using NFSv4.1 may lead to deadlock caused by circular waiting. The scenario is: - NFSv4.1 client running heavy multi-threaded buffered I/O (fio-style workload) - server outage (restart/power-off) and/or network blackhole - client under significant memory pressure / reclaim activity (observed in the traces below) The observed behavior is a deadlock cycle involving: - v4.1 session slot table “draining” (NFS4_SLOT_TBL_DRAINING) - state manager thread creation via kthread_run() - kthreadd entering direct reclaim and getting stuck in NFS commit/writeback paths - non-privileged RPC tasks sleeping on slot table waitq due to draining This issue has already been discussed within the upstream. Before a formal fix is developed, it is suggested to revert back the patch that introduced the problem to prevent it from occurring.[1] In addition, this revert patch conflicts with 98ab188dbab3 ("[Backport] NFS: fix nfs release_folio() to not deadlock via kcompactd writeback"); please be aware of this when performing subsequent rollbacks. Link: https://lore.kernel.org/all/20251230071744.9762-1-wangzhaolong@huaweicloud.… [1] Fixes: 96780ca55e3c ("NFS: fix up nfs_release_folio() to try to release the page") Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/nfs/file.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/nfs/file.c b/fs/nfs/file.c index 4994b2873970..0c4abe38b785 100644 --- a/fs/nfs/file.c +++ b/fs/nfs/file.c @@ -27,11 +27,10 @@ #include <linux/nfs_mount.h> #include <linux/mm.h> #include <linux/pagemap.h> #include <linux/gfp.h> #include <linux/swap.h> -#include <linux/compaction.h> #include <linux/uaccess.h> #include <linux/filelock.h> #include "delegation.h" @@ -447,17 +446,12 @@ static void nfs_invalidate_folio(struct folio *folio, size_t offset, static bool nfs_release_folio(struct folio *folio, gfp_t gfp) { dfprintk(PAGECACHE, "NFS: release_folio(%p)\n", folio); /* If the private flag is set, then the folio is not freeable */ - if (folio_test_private(folio)) { - if ((current_gfp_context(gfp) & GFP_KERNEL) != GFP_KERNEL || - current_is_kswapd() || current_is_kcompactd()) - return false; - if (nfs_wb_folio(folio_file_mapping(folio)->host, folio) < 0) - return false; - } + if (folio_test_private(folio)) + return false; return nfs_fscache_release_folio(folio, gfp); } static void nfs_check_dirty_writeback(struct folio *folio, bool *dirty, bool *writeback) -- 2.34.3

2 1