- Kernel - mailweb.openeuler.org

[PATCH v2 OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 21 May '24

21 May '24

Changes in v2: - fix head in commit message Three features related: - add a switch to enable hungtask check for io, patch 1-2 - add a config to control hierarchical throttle, patch 3-4 - support enable/disable blk-mq debugfs dynamically, patch 5-11 Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 2 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 ++++++++++++++++++++++---- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 ++++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 ++- block/blk-sysfs.c | 82 ++++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 17 files changed, 245 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH OLK-6.6 0/1] Fix allmodconfig build error
by Shuai Wu 21 May '24

21 May '24

Fix allmodconfig build error in hiroce3 driver. Shuai Wu (1): net/ethernet/huawei/hiroce3: Fix allmodconfig build error .../hw/hiroce3/bond/roce_bond_common.c | 38 +- .../hw/hiroce3/cq/roce_cq_destroy.c | 15 +- .../hw/hiroce3/host/hmm/hmm_comp_mtt.c | 1 + .../hw/hiroce3/host/hmm/hmm_comp_mw_mr.c | 1 + .../hw/hiroce3/host/hmm/hmm_comp_res.c | 1 + .../infiniband/hw/hiroce3/host/hmm/hmm_mr.c | 98 +---- .../infiniband/hw/hiroce3/host/hmm/hmm_umem.c | 4 +- .../infiniband/hw/hiroce3/host/hmm/hmm_umem.h | 2 +- .../include/rdma/rdma_context_format.h | 4 +- .../include/rdma/rdma_ext_ctx_format.h | 5 +- .../hw/hiroce3/include/rdma/roce_ccf_format.h | 4 +- .../hw/hiroce3/include/rdma/roce_verbs_attr.h | 4 +- .../include/rdma/roce_verbs_attr_qpc_chip.h | 4 +- .../hiroce3/include/rdma/roce_verbs_cq_attr.h | 4 +- .../include/rdma/roce_verbs_ext_attr.h | 4 +- .../include/rdma/roce_verbs_gid_attr.h | 4 +- .../hiroce3/include/rdma/roce_verbs_mr_attr.h | 4 +- .../hw/hiroce3/include/rdma/roce_verbs_pub.h | 4 +- .../include/rdma/roce_verbs_srq_attr.h | 4 +- drivers/infiniband/hw/hiroce3/mr/roce_mr.c | 37 -- drivers/infiniband/hw/hiroce3/roce.h | 1 - drivers/infiniband/hw/hiroce3/roce_main.c | 7 +- .../ethernet/huawei/hinic3/bond/hinic3_bond.c | 1 - .../ethernet/huawei/hinic3/bond/hinic3_bond.h | 4 +- .../ethernet/huawei/hinic3/cqm/cqm_bat_cla.c | 198 +++------ .../huawei/hinic3/cqm/cqm_bitmap_table.c | 10 +- .../huawei/hinic3/cqm/cqm_bloomfilter.c | 69 +--- .../net/ethernet/huawei/hinic3/cqm/cqm_cmd.c | 139 ++----- .../net/ethernet/huawei/hinic3/cqm/cqm_cmd.h | 2 - .../net/ethernet/huawei/hinic3/cqm/cqm_db.c | 192 +++------ .../ethernet/huawei/hinic3/cqm/cqm_define.h | 4 - .../net/ethernet/huawei/hinic3/cqm/cqm_main.c | 178 +++------ .../ethernet/huawei/hinic3/cqm/cqm_object.c | 378 +++++------------- .../huawei/hinic3/cqm/cqm_object_intern.c | 194 +++------ .../ethernet/huawei/hinic3/hw/hinic3_hw_cfg.c | 2 +- .../ethernet/huawei/hinic3/hw/hinic3_hwif.c | 38 -- .../huawei/hinic3/hw/hinic3_multi_host_mgmt.c | 56 ++- .../hinic3/include/bond/bond_common_defs.h | 4 +- .../huawei/hinic3/include/hinic3_common.h | 2 - .../huawei/hinic3/include/hinic3_cqm.h | 11 - .../huawei/hinic3/include/hinic3_cqm_define.h | 4 - .../include/mpu/mpu_outband_ncsi_cmd_defs.h | 4 +- 42 files changed, 474 insertions(+), 1266 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-22.03-LTS-SP1] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH OLK-5.10] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 37e0a494c2c8c6f0570068ab47a3e8319dbac30b
by kernel test robot 21 May '24

21 May '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 37e0a494c2c8c6f0570068ab47a3e8319dbac30b !7586 powerpc/imc-pmu: Add a null pointer check in update_events_in_group() Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-defconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- x86_64-buildonly-randconfig-005-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- x86_64-randconfig-013-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- x86_64-randconfig-075-20240521 | `-- kernel-sched-sparsemask.h:warning:array-subscript-is-outside-array-bounds-of-const-struct-sparsemask_chunk |-- x86_64-randconfig-103-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code `-- x86_64-randconfig-161-20240520 `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code clang_recent_errors |-- x86_64-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension |-- x86_64-buildonly-randconfig-002-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension |-- x86_64-randconfig-004-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension |-- x86_64-randconfig-014-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension |-- x86_64-randconfig-015-20240521 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension `-- x86_64-randconfig-101-20240521 `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension elapsed time: 733m configs tested: 35 configs skipped: 146 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240520 gcc arm64 randconfig-002-20240520 gcc arm64 randconfig-003-20240520 gcc arm64 randconfig-004-20240520 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240521 clang x86_64 buildonly-randconfig-002-20240521 clang x86_64 buildonly-randconfig-003-20240521 gcc x86_64 buildonly-randconfig-004-20240521 clang x86_64 buildonly-randconfig-005-20240521 gcc x86_64 buildonly-randconfig-006-20240521 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240521 clang x86_64 randconfig-002-20240521 clang x86_64 randconfig-003-20240521 clang x86_64 randconfig-004-20240521 clang x86_64 randconfig-005-20240521 clang x86_64 randconfig-006-20240521 clang x86_64 randconfig-011-20240521 clang x86_64 randconfig-012-20240521 gcc x86_64 randconfig-013-20240521 gcc x86_64 randconfig-014-20240521 clang x86_64 randconfig-015-20240521 clang x86_64 randconfig-016-20240521 gcc x86_64 randconfig-071-20240521 gcc x86_64 randconfig-072-20240521 clang x86_64 randconfig-073-20240521 clang x86_64 randconfig-074-20240521 gcc x86_64 randconfig-075-20240521 gcc x86_64 randconfig-076-20240521 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] irqchip/gic-v3-its: Prevent double free on error
by Liu Mingrui 21 May '24

21 May '24

From: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> stable inclusion from stable-v5.10.216 commit aa44d21574751a7d6bca892eb8e0e9ac68372e52 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9HX CVE: CVE-2024-35847 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c26591afd33adce296c022e3480dea4282b7ef91 upstream. The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibab… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 806359f3376a..8a716da480b0 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5210,13 +5210,8 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq set_bit(i, bitmap); } - if (err) { - if (i > 0) - its_vpe_irq_domain_free(domain, virq, i); - - its_lpi_free(bitmap, base, nr_ids); - its_free_prop_table(vprop_page); - } + if (err) + its_vpe_irq_domain_free(domain, virq, i); return err; } -- 2.25.1

2 1

[PATCH OLK-5.10] irqchip/gic-v3-its: Prevent double free on error
by Liu Mingrui 21 May '24

21 May '24

From: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> stable inclusion from stable-v5.10.216 commit aa44d21574751a7d6bca892eb8e0e9ac68372e52 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9HX CVE: CVE-2024-35847 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c26591afd33adce296c022e3480dea4282b7ef91 upstream. The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibab… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 806359f3376a..8a716da480b0 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5210,13 +5210,8 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq set_bit(i, bitmap); } - if (err) { - if (i > 0) - its_vpe_irq_domain_free(domain, virq, i); - - its_lpi_free(bitmap, base, nr_ids); - its_free_prop_table(vprop_page); - } + if (err) + its_vpe_irq_domain_free(domain, virq, i); return err; } -- 2.25.1

2 1

[PATCH OLK-5.10] irqchip/gic-v3-its: Prevent double free on error
by Liu Mingrui 21 May '24

21 May '24

From: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> stable inclusion from stable-v5.10.216 commit aa44d21574751a7d6bca892eb8e0e9ac68372e52 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9HX CVE: CVE-2024-35847 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c26591afd33adce296c022e3480dea4282b7ef91 upstream. The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibab… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 806359f3376a..8a716da480b0 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5210,13 +5210,8 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq set_bit(i, bitmap); } - if (err) { - if (i > 0) - its_vpe_irq_domain_free(domain, virq, i); - - its_lpi_free(bitmap, base, nr_ids); - its_free_prop_table(vprop_page); - } + if (err) + its_vpe_irq_domain_free(domain, virq, i); return err; } -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel