- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index ea519c4fa7b3..3bb9c0dced6e 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1205,10 +1205,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index 2b00359e4825..bf6251fa5c3d 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1169,10 +1169,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH OLK-6.6] netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
by superdcc97＠163.com 12 Jun '26

12 Jun '26

From: Qi Tang <tpluszz77(a)gmail.com> stable inclusion from stable-v6.6.134 commit 2898080c054ea4d6ddfaaf21bbedbc229a9a8376 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14558 CVE: CVE-2026-43026 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 35177c6877134a21315f37d57a5577846225623e ] ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Qi Tang <tpluszz77(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_conntrack_netlink.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 67a0762915e3..90c32031bcf1 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -3571,6 +3571,12 @@ ctnetlink_alloc_expect(const struct nlattr * const cda[], struct nf_conn *ct, exp, nf_ct_l3num(ct)); if (err < 0) goto err_out; +#if IS_ENABLED(CONFIG_NF_NAT) + } else { + memset(&exp->saved_addr, 0, sizeof(exp->saved_addr)); + memset(&exp->saved_proto, 0, sizeof(exp->saved_proto)); + exp->dir = 0; +#endif } return exp; err_out: -- 2.43.0

2 1

[PATCH] [PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..dbceebb97ed4 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,9 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time for each loop operation is approximately 100ns to 500ns, + * and the ITS should clear the DT cache within 1,000,000 loops. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

1 0

[PATCH OLK-5.10] mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()
by Jinjiang Tu 11 Jun '26

11 Jun '26

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.136 commit 115a5266749dcde7fe4127e8623d19c752088f69 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14332 CVE: CVE-2026-31586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Dennis Zhou <dennis(a)kernel.org> Reviewed-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: David Hildenbrand <david(a)kernel.org> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Josef Bacik <josef(a)toxicpanda.com> Cc: JP Kobryn <inwardvessel(a)gmail.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Martin KaFai Lau <martin.lau(a)linux.dev> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: mm/backing-dev.c [Wupeng Ma: context conflicts] Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/backing-dev.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/backing-dev.c b/mm/backing-dev.c index bc406d62c617..ffc14382dc53 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -537,12 +537,13 @@ static void cgwb_release_workfn(struct work_struct *work) wb_shutdown(wb); css_put(wb->memcg_css); - css_put(wb->blkcg_css); - mutex_unlock(&wb->bdi->cgwb_release_mutex); /* triggers blkg destruction if no online users left */ blkcg_unpin_online(blkcg); + css_put(wb->blkcg_css); + mutex_unlock(&wb->bdi->cgwb_release_mutex); + fprop_local_destroy_percpu(&wb->memcg_completions); wb_exit(wb); call_rcu(&wb->rcu, cgwb_free_rcu); -- 2.43.0

2 1

[PATCH OLK-6.6 0/13] Update Share Pool
by Yin Tirui 11 Jun '26

11 Jun '26

Zhou Guanghui (1): mm: reserve address range for svsp fs/hugetlbfs/inode.c | 13 +++++ include/linux/ascend_vm.h | 69 ++++++++++++++++++++++++++ include/linux/share_pool.h | 11 ++-- include/uapi/asm-generic/mman-common.h | 1 + mm/Makefile | 1 + mm/ascend_vm.c | 21 ++++++++ mm/mmap.c | 15 ++++-- 7 files changed, 125 insertions(+), 6 deletions(-) create mode 100644 include/linux/ascend_vm.h create mode 100644 mm/ascend_vm.c -- 2.43.0

2 14

回复：[kernel] 驱动 Hht2dr 内核合入申请
by 刘俊豪 11 Jun '26

11 Jun '26

尊敬的 openEuler SIG 团队：您好！我司华澜微电子股份有限公司申请将 Hst2dr驱动（用于SAS HBA）加入 openEuler 内核，便于后续业务部署。烦请协助推进驱动合入相关事宜。如需要补充任何信息或材料，请随时与我联系。联系人：刘俊豪电子邮箱：junhao.liu(a)sage-micro.com.cn 感谢您的支持！华澜微电子股份有限公司 2026 年 06 月 11 日

1 0

[PATCH OLK-5.10] jbd2: limit checkpoint buffers scanned per j_list_lock hold during shrink
by Zizhi Wo 10 Jun '26

10 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9375 -------------------------------- When the shrinker walks a journal's checkpoint list via jbd2_journal_shrink_checkpoint_list(), it holds j_list_lock across each call to journal_shrink_one_cp_list() and only releases it when need_resched() or spin_needbreak() becomes true. journal_shrink_one_cp_list() charges the scan budget (nr_to_scan) only for buffers it actually frees. In JBD2_SHRINK_BUSY_SKIP mode, when metadata is heavily contended, most buffers are busy and cannot be freed, so "nr_to_scan" decreases slowly and the loop keeps walking the list for a long time. On large journals under heavy ext4 writeback, a single shrinker invocation can therefore hold j_list_lock long enough to starve other CPUs spinning for the same lock, triggering softlockups. Fix this by introducing a user-configurable per-hold budget that bounds the number of checkpoint buffers examined while j_list_lock is held, preventing the shrinker from walking the list for an unbounded time. The cap is disabled by default (value 0, preserving the previous behaviour) and can be enabled at runtime via /sys/module/jbd2/parameters/shrink_batch. Fixes: 82c2be921b1a ("jbd2,ext4: add a shrinker to release checkpointed buffers") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/jbd2/checkpoint.c | 48 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index 727f3505280c..ca7d60f6a858 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -19,10 +19,23 @@ #include <linux/jbd2.h> #include <linux/errno.h> #include <linux/slab.h> #include <linux/blkdev.h> #include <trace/events/jbd2.h> +#include <linux/moduleparam.h> + +/* + * Max number of checkpoint buffers to examine while holding j_list_lock + * in a single pass. + * + * Tunable at runtime via /sys/module/jbd2/parameters/shrink_batch. + * A value of 0 disables the per-hold cap (legacy behaviour). + */ +static unsigned int jbd2_shrink_batch; +module_param_named(shrink_batch, jbd2_shrink_batch, uint, 0644); +MODULE_PARM_DESC(shrink_batch, + "Max checkpoint buffers examined per j_list_lock hold during shrink (0 = unlimited)"); /* * Unlink a buffer from a transaction checkpoint list. * * Called with j_list_lock held. @@ -364,11 +377,12 @@ enum shrink_type {SHRINK_DESTROY, SHRINK_BUSY_STOP, SHRINK_BUSY_SKIP}; * * Called with j_list_lock held. */ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, enum shrink_type type, - bool *released) + bool *released, + unsigned long *scan_budget) { struct journal_head *last_jh; struct journal_head *next_jh = jh; unsigned long nr_freed = 0; int ret; @@ -383,10 +397,22 @@ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, next_jh = jh->b_cpnext; if (type == SHRINK_DESTROY) { ret = __jbd2_journal_remove_checkpoint(jh); } else { + /* + * Charge budget per examined buffer, not per freed one, + * so a run of busy buffers (the 'continue' path below, + * freeing nothing) still bounds how long one j_list_lock + * hold walks the checkpoint list. + */ + if (scan_budget) { + if (*scan_budget == 0) + break; + (*scan_budget)--; + } + ret = jbd2_journal_try_remove_checkpoint(jh); if (ret < 0) { if (type == SHRINK_BUSY_SKIP) continue; break; @@ -422,12 +448,23 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, bool __maybe_unused released; tid_t first_tid = 0, last_tid = 0, next_tid = 0; tid_t tid = 0; unsigned long nr_freed = 0; unsigned long freed; + unsigned long scan_budget; + unsigned int batch = READ_ONCE(jbd2_shrink_batch); again: + /* + * Reset the per-hold examination budget on every (re)acquire of + * j_list_lock: one hold examines at most `batch` buffers, decoupled + * from journal size, list length and busy ratio, so the lock hold + * stays short even when the whole list is busy and nothing is freed. + * batch == 0 means no cap, exactly the legacy behaviour. + */ + scan_budget = batch; + spin_lock(&journal->j_list_lock); if (!journal->j_checkpoint_transactions) { spin_unlock(&journal->j_list_lock); goto out; } @@ -452,13 +489,17 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, transaction = next_transaction; next_transaction = transaction->t_cpnext; tid = transaction->t_tid; freed = journal_shrink_one_cp_list(transaction->t_checkpoint_list, - SHRINK_BUSY_SKIP, &released); + SHRINK_BUSY_SKIP, &released, + batch ? &scan_budget : NULL); nr_freed += freed; (*nr_to_scan) -= min(*nr_to_scan, freed); + + if (batch && scan_budget == 0) + break; if (*nr_to_scan == 0) break; if (need_resched() || spin_needbreak(&journal->j_list_lock)) break; } while (transaction != last_transaction); @@ -505,12 +546,13 @@ void __jbd2_journal_clean_checkpoint_list(journal_t *journal, bool destroy) last_transaction = transaction->t_cpprev; next_transaction = transaction; do { transaction = next_transaction; next_transaction = transaction->t_cpnext; + /* destroy/clean path: clear everything, no scan budget */ journal_shrink_one_cp_list(transaction->t_checkpoint_list, - type, &released); + type, &released, NULL); /* * This function only frees up some memory if possible so we * dont have an obligation to finish processing. Bail out if * preemption requested: */ -- 2.52.0

2 1

[PATCH OLK-6.6 0/2] xfrm: Fix CVE-2026-43091 RCU use-after-free in policy netns exit
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Sashiko Review <sashiko(a)example.com> This patch series fixes CVE-2026-43091 in the OLK-6.6 branch. * Patch 1: Add synchronize_rcu() before freeing policy hash tables to prevent RCU use-after-free during policy netns exit. * Patch 2: Move the RCU sync from per-netns .exit to .pre_exit to avoid O(N) RCU grace periods during batch netns cleanup. Steffen Klassert (1): xfrm: Wait for RCU readers during policy netns exit Usama Arif (1): xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit net/xfrm/xfrm_policy.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6 0/2] CVE-2026-31588
by Xinyu Zheng 10 Jun '26

10 Jun '26

Sean Christopherson (1): KVM: x86: Use scratch field in MMIO fragment to hold small write values Xinyu Zheng (1): fix "KVM: x86: Use scratch field in MMIO fragment to hold small write values" KABI CRC break issue arch/x86/include/uapi/asm/kvm.h | 3 +++ arch/x86/kvm/x86.c | 15 ++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.34.1

2 3