- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] nf_tables: nft_dynset: fix possible stateful expression memleak in error path
by Dong Chenchen 07 Apr '26

07 Apr '26

From: Pablo Neira Ayuso <pablo(a)netfilter.org> mainline inclusion from mainline-v7.0-rc3 commit 0548a13b5a145b16e4da0628b5936baf35f51b43 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14034 CVE: CVE-2026-23399 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330 Fixes: 563125a73ac3 ("netfilter: nftables: generalize set extension to support for several expressions") Reported-by: Gurpreet Shergill <giki.shergill(a)proton.me> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Florian Westphal <fw(a)strlen.de> Conflicts: include/net/netfilter/nf_tables.h net/netfilter/nft_dynset.c [commit 9dad402b89e8 is not backport] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- include/net/netfilter/nf_tables.h | 2 ++ net/netfilter/nf_tables_api.c | 4 ++-- net/netfilter/nft_dynset.c | 10 +++++++++- 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/include/net/netfilter/nf_tables.h b/include/net/netfilter/nf_tables.h index e1c4d903f39b..0f890ff1769b 100644 --- a/include/net/netfilter/nf_tables.h +++ b/include/net/netfilter/nf_tables.h @@ -859,6 +859,8 @@ void *nft_set_elem_init(const struct nft_set *set, u64 timeout, u64 expiration, gfp_t gfp); int nft_set_elem_expr_clone(const struct nft_ctx *ctx, struct nft_set *set, struct nft_expr *expr_array[]); +void nft_set_elem_expr_destroy(const struct nft_ctx *ctx, + struct nft_set_elem_expr *elem_expr); void nft_set_elem_destroy(const struct nft_set *set, void *elem, bool destroy_expr); void nf_tables_set_elem_destroy(const struct nft_ctx *ctx, diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 98d3156179ee..9d5f7bafa4d6 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -6471,8 +6471,8 @@ static void __nft_set_elem_expr_destroy(const struct nft_ctx *ctx, } } -static void nft_set_elem_expr_destroy(const struct nft_ctx *ctx, - struct nft_set_elem_expr *elem_expr) +void nft_set_elem_expr_destroy(const struct nft_ctx *ctx, + struct nft_set_elem_expr *elem_expr) { struct nft_expr *expr; u32 size; diff --git a/net/netfilter/nft_dynset.c b/net/netfilter/nft_dynset.c index a81bd69b059b..8ea45d61ed88 100644 --- a/net/netfilter/nft_dynset.c +++ b/net/netfilter/nft_dynset.c @@ -30,18 +30,26 @@ static int nft_dynset_expr_setup(const struct nft_dynset *priv, const struct nft_set_ext *ext) { struct nft_set_elem_expr *elem_expr = nft_set_ext_expr(ext); + struct nft_ctx ctx = { + .net = read_pnet(&priv->set->net), + .family = priv->set->table->family, + }; struct nft_expr *expr; int i; for (i = 0; i < priv->num_exprs; i++) { expr = nft_setelem_expr_at(elem_expr, elem_expr->size); if (nft_expr_clone(expr, priv->expr_array[i], GFP_ATOMIC) < 0) - return -1; + goto err_out; elem_expr->size += priv->expr_array[i]->ops->size; } return 0; +err_out: + nft_set_elem_expr_destroy(&ctx, elem_expr); + + return -1; } static void *nft_dynset_new(struct nft_set *set, const struct nft_expr *expr, -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] xdp: Fix CVE-2026-23343
by Dong Chenchen 07 Apr '26

07 Apr '26

Fix CVE-2026-23343 Larysa Zaremba (2): xdp: use modulo operation to calculate XDP frag tailroom xdp: produce a warning when calculated tailroom is negative net/core/filter.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10 1/3] xen/privcmd: restrict usage in unprivileged domU
by Zhang Yuwei 07 Apr '26

07 Apr '26

From: Juergen Gross <jgross(a)suse.com> mainline inclusion from mainline-v7.0-rc6 commit 453b8fb68f3641fea970db88b7d9a153ed2a37e8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14027 CVE: CVE-2026-31788 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 Reported-by: Teddy Astie <teddy.astie(a)vates.tech> Fixes: 1c5de1939c20 ("xen: add privcmd driver") Signed-off-by: Juergen Gross <jgross(a)suse.com> Conflicts: drivers/xen/privcmd.c [commit bf4afc53b77ae not merged] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> it push" to publish your local commits) --- drivers/xen/privcmd.c | 62 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 5 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 28537a1a0e0b..cb50038c0c9c 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -10,6 +10,7 @@ #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt #include <linux/kernel.h> +#include <linux/kstrtox.h> #include <linux/module.h> #include <linux/sched.h> #include <linux/slab.h> @@ -24,7 +25,8 @@ #include <linux/seq_file.h> #include <linux/miscdevice.h> #include <linux/moduleparam.h> - +#include <linux/notifier.h> +#include <linux/wait.h> #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> @@ -37,7 +39,7 @@ #include <xen/page.h> #include <xen/xen-ops.h> #include <xen/balloon.h> - +#include <xen/xenbus.h> #include "privcmd.h" MODULE_LICENSE("GPL"); @@ -59,6 +61,11 @@ struct privcmd_data { domid_t domid; }; +/* DOMID_INVALID implies no restriction */ +static domid_t target_domain = DOMID_INVALID; +static bool restrict_wait; +static DECLARE_WAIT_QUEUE_HEAD(restrict_wait_wq); + static int privcmd_vma_range_is_mapped( struct vm_area_struct *vma, unsigned long addr, @@ -878,13 +885,16 @@ static long privcmd_ioctl(struct file *file, static int privcmd_open(struct inode *ino, struct file *file) { - struct privcmd_data *data = kzalloc(sizeof(*data), GFP_KERNEL); + struct privcmd_data *data; + if (wait_event_interruptible(restrict_wait_wq, !restrict_wait) < 0) + return -EINTR; + + data = kzalloc(sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; - /* DOMID_INVALID implies no restriction */ - data->domid = DOMID_INVALID; + data->domid = target_domain; file->private_data = data; return 0; @@ -977,6 +987,45 @@ static struct miscdevice privcmd_dev = { .fops = &xen_privcmd_fops, }; +static int init_restrict(struct notifier_block *notifier, + unsigned long event, + void *data) +{ + char *target; + unsigned int domid; + + /* Default to an guaranteed unused domain-id. */ + target_domain = DOMID_IDLE; + + target = xenbus_read(XBT_NIL, "target", "", NULL); + if (IS_ERR(target) || kstrtouint(target, 10, &domid)) { + pr_err("No target domain found, blocking all hypercalls\n"); + goto out; + } + + target_domain = domid; + + out: + if (!IS_ERR(target)) + kfree(target); + + restrict_wait = false; + wake_up_all(&restrict_wait_wq); + + return NOTIFY_DONE; +} + +static struct notifier_block xenstore_notifier = { + .notifier_call = init_restrict, +}; + +static void __init restrict_driver(void) +{ + restrict_wait = true; + + register_xenstore_notifier(&xenstore_notifier); +} + static int __init privcmd_init(void) { int err; @@ -984,6 +1033,9 @@ static int __init privcmd_init(void) if (!xen_domain()) return -ENODEV; + if (!xen_initial_domain()) + restrict_driver(); + err = misc_register(&privcmd_dev); if (err != 0) { pr_err("Could not register Xen privcmd device\n"); -- 2.22.0

2 3

[PATCH OLK-6.6 1/3] xen/privcmd: restrict usage in unprivileged domU
by Zhang Yuwei 07 Apr '26

07 Apr '26

From: Juergen Gross <jgross(a)suse.com> mainline inclusion from mainline-v7.0-rc6 commit 453b8fb68f3641fea970db88b7d9a153ed2a37e8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14027 CVE: CVE-2026-31788 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 Reported-by: Teddy Astie <teddy.astie(a)vates.tech> Fixes: 1c5de1939c20 ("xen: add privcmd driver") Signed-off-by: Juergen Gross <jgross(a)suse.com> Conflicts: drivers/xen/privcmd.c [commit bf4afc53b77ae not merged] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/xen/privcmd.c | 62 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 5 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 61aaded483e1..3c97710fc094 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -12,6 +12,7 @@ #include <linux/eventfd.h> #include <linux/file.h> #include <linux/kernel.h> +#include <linux/kstrtox.h> #include <linux/module.h> #include <linux/mutex.h> #include <linux/poll.h> @@ -30,7 +31,8 @@ #include <linux/seq_file.h> #include <linux/miscdevice.h> #include <linux/moduleparam.h> - +#include <linux/notifier.h> +#include <linux/wait.h> #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> @@ -43,7 +45,7 @@ #include <xen/page.h> #include <xen/xen-ops.h> #include <xen/balloon.h> - +#include <xen/xenbus.h> #include "privcmd.h" MODULE_LICENSE("GPL"); @@ -65,6 +67,11 @@ struct privcmd_data { domid_t domid; }; +/* DOMID_INVALID implies no restriction */ +static domid_t target_domain = DOMID_INVALID; +static bool restrict_wait; +static DECLARE_WAIT_QUEUE_HEAD(restrict_wait_wq); + static int privcmd_vma_range_is_mapped( struct vm_area_struct *vma, unsigned long addr, @@ -1156,13 +1163,16 @@ static long privcmd_ioctl(struct file *file, static int privcmd_open(struct inode *ino, struct file *file) { - struct privcmd_data *data = kzalloc(sizeof(*data), GFP_KERNEL); + struct privcmd_data *data; + if (wait_event_interruptible(restrict_wait_wq, !restrict_wait) < 0) + return -EINTR; + + data = kzalloc(sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; - /* DOMID_INVALID implies no restriction */ - data->domid = DOMID_INVALID; + data->domid = target_domain; file->private_data = data; return 0; @@ -1255,6 +1265,45 @@ static struct miscdevice privcmd_dev = { .fops = &xen_privcmd_fops, }; +static int init_restrict(struct notifier_block *notifier, + unsigned long event, + void *data) +{ + char *target; + unsigned int domid; + + /* Default to an guaranteed unused domain-id. */ + target_domain = DOMID_IDLE; + + target = xenbus_read(XBT_NIL, "target", "", NULL); + if (IS_ERR(target) || kstrtouint(target, 10, &domid)) { + pr_err("No target domain found, blocking all hypercalls\n"); + goto out; + } + + target_domain = domid; + + out: + if (!IS_ERR(target)) + kfree(target); + + restrict_wait = false; + wake_up_all(&restrict_wait_wq); + + return NOTIFY_DONE; +} + +static struct notifier_block xenstore_notifier = { + .notifier_call = init_restrict, +}; + +static void __init restrict_driver(void) +{ + restrict_wait = true; + + register_xenstore_notifier(&xenstore_notifier); +} + static int __init privcmd_init(void) { int err; @@ -1262,6 +1311,9 @@ static int __init privcmd_init(void) if (!xen_domain()) return -ENODEV; + if (!xen_initial_domain()) + restrict_driver(); + err = misc_register(&privcmd_dev); if (err != 0) { pr_err("Could not register Xen privcmd device\n"); -- 2.22.0

2 3

[PATCH OLK-6.6] sched/fair: scale wake_wide() threshold by SMT width
by Zhang Qiao 07 Apr '26

07 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8882 -------------------------------- wake_wide() uses sd_llc_size as the spreading threshold to detect wide waker/wakee relationships and to disable wake_affine() for those cases. On SMT systems, sd_llc_size counts logical CPUs rather than physical cores. This inflates the wake_wide() threshold, allowing wake_affine() to pack more tasks into one LLC domain than the actual compute capacity of its physical cores can sustain. The resulting SMT interference may cost more than the cache-locality benefit wake_affine() intends to gain. Scale the factor by the SMT width of the current CPU so that it approximates the number of independent physical cores in the LLC domain, making wake_wide() more likely to kick in before SMT interference becomes significant. On non-SMT systems the SMT width is 1 and behaviour is unchanged. Signed-off-by: Zhang Qiao <zhangqiao22(a)huawei.com> --- kernel/sched/fair.c | 5 +++++ kernel/sched/features.h | 2 ++ 2 files changed, 7 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ad30bb800961..4100998e18cd 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7850,6 +7850,11 @@ static int wake_wide(struct task_struct *p) unsigned int slave = p->wakee_flips; int factor = __this_cpu_read(sd_llc_size); + /* Scale factor to physical-core count to account for SMT interference. */ + if (sched_feat(WA_SMT)) + factor = DIV_ROUND_UP(factor, + cpumask_weight(cpu_smt_mask(smp_processor_id()))); + if (master < slave) swap(master, slave); if (slave < factor || master < slave * factor) diff --git a/kernel/sched/features.h b/kernel/sched/features.h index 24a0c853a8a0..c9ad8e72ecd0 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -128,3 +128,5 @@ SCHED_FEAT(SOFT_DOMAIN, false) #ifdef CONFIG_SCHED_SOFT_QUOTA SCHED_FEAT(SOFT_QUOTA, false) #endif + +SCHED_FEAT(WA_SMT, false) -- 2.18.0

2 1

[PATCH OLK-6.6] sched/fair: scale wake_wide() threshold by SMT width
by Zhang Qiao 07 Apr '26

07 Apr '26

hulk inclusion category: perfermance bugzilla: https://atomgit.com/openeuler/kernel/issues/8882 -------------------------------- wake_wide() uses sd_llc_size as the spreading threshold to detect wide waker/wakee relationships and to disable wake_affine() for those cases. On SMT systems, sd_llc_size counts logical CPUs rather than physical cores. This inflates the wake_wide() threshold, allowing wake_affine() to pack more tasks into one LLC domain than the actual compute capacity of its physical cores can sustain. The resulting SMT interference may cost more than the cache-locality benefit wake_affine() intends to gain. Scale the factor by the SMT width of the current CPU so that it approximates the number of independent physical cores in the LLC domain, making wake_wide() more likely to kick in before SMT interference becomes significant. On non-SMT systems the SMT width is 1 and behaviour is unchanged. Signed-off-by: Zhang Qiao <zhangqiao22(a)huawei.com> --- kernel/sched/fair.c | 5 +++++ kernel/sched/features.h | 2 ++ 2 files changed, 7 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ad30bb800961..4100998e18cd 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7850,6 +7850,11 @@ static int wake_wide(struct task_struct *p) unsigned int slave = p->wakee_flips; int factor = __this_cpu_read(sd_llc_size); + /* Scale factor to physical-core count to account for SMT interference. */ + if (sched_feat(WA_SMT)) + factor = DIV_ROUND_UP(factor, + cpumask_weight(cpu_smt_mask(smp_processor_id()))); + if (master < slave) swap(master, slave); if (slave < factor || master < slave * factor) diff --git a/kernel/sched/features.h b/kernel/sched/features.h index 24a0c853a8a0..c9ad8e72ecd0 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -128,3 +128,5 @@ SCHED_FEAT(SOFT_DOMAIN, false) #ifdef CONFIG_SCHED_SOFT_QUOTA SCHED_FEAT(SOFT_QUOTA, false) #endif + +SCHED_FEAT(WA_SMT, false) -- 2.18.0

2 1

[PATCH OLK-6.6 0/2] Fix riscv check-build warning
by Tengda Wu 07 Apr '26

07 Apr '26

Fix rsicv check-build warning. Björn Töpel (1): riscv: Replace function-like macro by static inline function Tengda Wu (1): Revert "riscv: stacktrace: Disable KASAN checks for non-current tasks" arch/riscv/include/asm/cacheflush.h | 15 ++++++++++----- arch/riscv/kernel/stacktrace.c | 16 ---------------- 2 files changed, 10 insertions(+), 21 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] ice: Fix memory leak in ice_set_ringparam()
by Pan Taixi 07 Apr '26

07 Apr '26

From: Zilin Guan <zilin(a)seu.edu.cn> mainline inclusion from mainline-v7.0-rc3 commit fe868b499d16f55bbeea89992edb98043c9de416 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23389 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan <zilin(a)seu.edu.cn> Reviewed-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/ice/ice_ethtool.c [Context conflicts due to different memory allocation function used] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_ethtool.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index dd58b2372dc0..bab857a6dc18 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -2839,7 +2839,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, rx_rings = kcalloc(vsi->num_rxq, sizeof(*rx_rings), GFP_KERNEL); if (!rx_rings) { err = -ENOMEM; - goto done; + goto free_xdp; } ice_for_each_rxq(vsi, i) { @@ -2869,7 +2869,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, } kfree(rx_rings); err = -ENOMEM; - goto free_tx; + goto free_xdp; } } @@ -2920,6 +2920,13 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, } goto done; +free_xdp: + if (xdp_rings) { + ice_for_each_xdp_txq(vsi, i) + ice_free_tx_ring(&xdp_rings[i]); + kfree(xdp_rings); + } + free_tx: /* error cleanup if the Rx allocations failed after getting Tx */ if (tx_rings) { -- 2.34.1

2 1

[PATCH OLK-5.10] ice: Fix memory leak in ice_set_ringparam()
by Pan Taixi 07 Apr '26

07 Apr '26

From: Zilin Guan <zilin(a)seu.edu.cn> mainline inclusion from mainline-v7.0-rc3 commit fe868b499d16f55bbeea89992edb98043c9de416 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23389 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan <zilin(a)seu.edu.cn> Reviewed-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/ice/ice_ethtool.c [ Context conflicts due to different memory allocation function used. Also, ice_for_each_xdp_txq is introduced in unmmerged commit 2faf63b650bb ("ice: make use of ice_for_each_* macros"), use normal for loops here instead. ] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_ethtool.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index 9659668279dc..585ae5e92558 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -2865,7 +2865,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, rx_rings = kcalloc(vsi->num_rxq, sizeof(*rx_rings), GFP_KERNEL); if (!rx_rings) { err = -ENOMEM; - goto done; + goto free_xdp; } ice_for_each_rxq(vsi, i) { @@ -2894,7 +2894,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, } kfree(rx_rings); err = -ENOMEM; - goto free_tx; + goto free_xdp; } } @@ -2945,6 +2945,13 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, } goto done; +free_xdp: + if (xdp_rings) { + for (i = 0; i < vsi->num_xdp_txq; i++) + ice_free_tx_ring(&xdp_rings[i]); + kfree(xdp_rings); + } + free_tx: /* error cleanup if the Rx allocations failed after getting Tx */ if (tx_rings) { -- 2.34.1

2 1

[PATCH OLK-6.6] pstore/ram: fix buffer overflow in persistent_ram_save_old()
by Pan Taixi 07 Apr '26

07 Apr '26

From: Sai Ritvik Tanksalkar <stanksal(a)purdue.edu> stable inclusion from stable-v6.6.128 commit cff0ef043e16feb5a02307c8f9d0117a96c5587c category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8792 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5669645c052f235726a85f443769b6fc02f66762 ] persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. Fixes: 201e4aca5aa1 ("pstore/ram: Should update old dmesg buffer before reading") Signed-off-by: Sai Ritvik Tanksalkar <stanksal(a)purdue.edu> Link: https://patch.msgid.link/20260201132240.2948732-1-stanksal@purdue.edu Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yuan can <yuancan(a)huawei.com> Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/pstore/ram_core.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index f1848cdd6d34..c9eaacdec37e 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -298,6 +298,17 @@ void persistent_ram_save_old(struct persistent_ram_zone *prz) if (!size) return; + /* + * If the existing buffer is differently sized, free it so a new + * one is allocated. This can happen when persistent_ram_save_old() + * is called early in boot and later for a timer-triggered + * survivable crash when the crash dumps don't match in size + * (which would be extremely unlikely given kmsg buffers usually + * exceed prz buffer sizes). + */ + if (prz->old_log && prz->old_log_size != size) + persistent_ram_free_old(prz); + if (!prz->old_log) { persistent_ram_ecc_old(prz); prz->old_log = kvzalloc(size, GFP_KERNEL); -- 2.34.1

2 1