- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] drm/amd/display: Avoid overflow from uint32_t to uint8_t
by Li Huafei 18 Oct '24

18 Oct '24

From: Alex Hung <alex.hung(a)amd.com> mainline inclusion from mainline-v6.11-rc1 commit d6b54900c564e35989cf6813e4071504fa0a90e0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVU7X CVE: CVE-2024-47661 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [WHAT & HOW] dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira(a)amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c [ Not backport e53524cdcc02d(“drm/amd/display: Refactor HWSS into component folder”), conflict due to file renaming. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c index 42c802afc468..f5d1070e2b59 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c @@ -262,7 +262,7 @@ bool dmub_abm_set_pipe(struct abm *abm, { union dmub_rb_cmd cmd; struct dc_context *dc = abm->ctx; - uint32_t ramping_boundary = 0xFFFF; + uint8_t ramping_boundary = 0xFF; memset(&cmd, 0, sizeof(cmd)); cmd.abm_set_pipe.header.type = DMUB_CMD__ABM; diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c index 1b08749b084b..840dfd237247 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c @@ -142,7 +142,7 @@ static bool dmub_abm_set_pipe(struct abm *abm, uint32_t otg_inst, { union dmub_rb_cmd cmd; struct dc_context *dc = abm->ctx; - uint32_t ramping_boundary = 0xFFFF; + uint8_t ramping_boundary = 0xFF; memset(&cmd, 0, sizeof(cmd)); cmd.abm_set_pipe.header.type = DMUB_CMD__ABM; -- 2.25.1

2 1

[PATCH OLK-5.10] media: go7007: fix a memleak in go7007_load_encoder
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit b49fe84c6cefcc1c2336d793b53442e716c95073 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9IB CVE: CVE-2024-27074 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b9b683844b01d171a72b9c0419a2d760d946ee12 ] In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. Fixes: 95ef39403f89 ("[media] go7007: remember boot firmware") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/media/usb/go7007/go7007-driver.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/go7007/go7007-driver.c b/drivers/media/usb/go7007/go7007-driver.c index 6650eab913d8..3c66542ce284 100644 --- a/drivers/media/usb/go7007/go7007-driver.c +++ b/drivers/media/usb/go7007/go7007-driver.c @@ -80,7 +80,7 @@ static int go7007_load_encoder(struct go7007 *go) const struct firmware *fw_entry; char fw_name[] = "go7007/go7007fw.bin"; void *bounce; - int fw_len, rv = 0; + int fw_len; u16 intr_val, intr_data; if (go->boot_fw == NULL) { @@ -109,9 +109,11 @@ static int go7007_load_encoder(struct go7007 *go) go7007_read_interrupt(go, &intr_val, &intr_data) < 0 || (intr_val & ~0x1) != 0x5a5a) { v4l2_err(go, "error transferring firmware\n"); - rv = -1; + kfree(go->boot_fw); + go->boot_fw = NULL; + return -1; } - return rv; + return 0; } MODULE_FIRMWARE("go7007/go7007fw.bin"); -- 2.17.1

2 1

[PATCH OLK-5.10] drm/lima: fix a memleak in lima_heap_alloc
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit f2e80ac9344aebbff576453d5c0290b332e187ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q978 CVE: CVE-2024-35829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 04ae3eb470e52a3c41babe85ff8cee195e4dcbea ] When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Qiang Yu <yuq825(a)gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117071328.3811480-1-alex… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/lima/lima_gem.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c index 11223fe348df..894175f2ed49 100644 --- a/drivers/gpu/drm/lima/lima_gem.c +++ b/drivers/gpu/drm/lima/lima_gem.c @@ -74,29 +74,34 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm) } else { bo->base.sgt = kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL); if (!bo->base.sgt) { - sg_free_table(&sgt); - return -ENOMEM; + ret = -ENOMEM; + goto err_out0; } } ret = dma_map_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); - if (ret) { - sg_free_table(&sgt); - kfree(bo->base.sgt); - bo->base.sgt = NULL; - return ret; - } + if (ret) + goto err_out1; *bo->base.sgt = sgt; if (vm) { ret = lima_vm_map_bo(vm, bo, old_size >> PAGE_SHIFT); if (ret) - return ret; + goto err_out2; } bo->heap_size = new_size; return 0; + +err_out2: + dma_unmap_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); +err_out1: + kfree(bo->base.sgt); + bo->base.sgt = NULL; +err_out0: + sg_free_table(&sgt); + return ret; } int lima_gem_create_handle(struct drm_device *dev, struct drm_file *file, -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/lima: fix a memleak in lima_heap_alloc
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit f2e80ac9344aebbff576453d5c0290b332e187ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q978 CVE: CVE-2024-35829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 04ae3eb470e52a3c41babe85ff8cee195e4dcbea ] When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Qiang Yu <yuq825(a)gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117071328.3811480-1-alex… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/lima/lima_gem.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c index 11223fe348df..894175f2ed49 100644 --- a/drivers/gpu/drm/lima/lima_gem.c +++ b/drivers/gpu/drm/lima/lima_gem.c @@ -74,29 +74,34 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm) } else { bo->base.sgt = kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL); if (!bo->base.sgt) { - sg_free_table(&sgt); - return -ENOMEM; + ret = -ENOMEM; + goto err_out0; } } ret = dma_map_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); - if (ret) { - sg_free_table(&sgt); - kfree(bo->base.sgt); - bo->base.sgt = NULL; - return ret; - } + if (ret) + goto err_out1; *bo->base.sgt = sgt; if (vm) { ret = lima_vm_map_bo(vm, bo, old_size >> PAGE_SHIFT); if (ret) - return ret; + goto err_out2; } bo->heap_size = new_size; return 0; + +err_out2: + dma_unmap_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); +err_out1: + kfree(bo->base.sgt); + bo->base.sgt = NULL; +err_out0: + sg_free_table(&sgt); + return ret; } int lima_gem_create_handle(struct drm_device *dev, struct drm_file *file, -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] octeontx2-af: Use separate handlers for interrupts
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Subbaraya Sundeep <sbhatta(a)marvell.com> stable inclusion from stable-v5.10.214 commit 766c2627acb2d9d1722cce2e24837044d52d888a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9N9 CVE: CVE-2024-27030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ] For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c index c26652436c53..5465a80e8973 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c @@ -1885,10 +1885,9 @@ static void rvu_queue_work(struct mbox_wq_info *mw, int first, } } -static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +static irqreturn_t rvu_mbox_pf_intr_handler(int irq, void *rvu_irq) { struct rvu *rvu = (struct rvu *)rvu_irq; - int vfs = rvu->vfs; u64 intr; intr = rvu_read64(rvu, BLKADDR_RVUM, RVU_AF_PFAF_MBOX_INT); @@ -1902,6 +1901,18 @@ static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) rvu_queue_work(&rvu->afpf_wq_info, 0, rvu->hw->total_pfs, intr); + return IRQ_HANDLED; +} + +static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +{ + struct rvu *rvu = (struct rvu *)rvu_irq; + int vfs = rvu->vfs; + u64 intr; + + /* Sync with mbox memory region */ + rmb(); + /* Handle VF interrupts */ if (vfs > 64) { intr = rvupf_read64(rvu, RVU_PF_VFPF_MBOX_INTX(1)); @@ -2216,7 +2227,7 @@ static int rvu_register_interrupts(struct rvu *rvu) /* Register mailbox interrupt handler */ sprintf(&rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], "RVUAF Mbox"); ret = request_irq(pci_irq_vector(rvu->pdev, RVU_AF_INT_VEC_MBOX), - rvu_mbox_intr_handler, 0, + rvu_mbox_pf_intr_handler, 0, &rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], rvu); if (ret) { dev_err(rvu->dev, -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: go7007: fix a memleak in go7007_load_encoder
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit b49fe84c6cefcc1c2336d793b53442e716c95073 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9IB CVE: CVE-2024-27074 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b9b683844b01d171a72b9c0419a2d760d946ee12 ] In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. Fixes: 95ef39403f89 ("[media] go7007: remember boot firmware") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/media/usb/go7007/go7007-driver.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/go7007/go7007-driver.c b/drivers/media/usb/go7007/go7007-driver.c index 6650eab913d8..3c66542ce284 100644 --- a/drivers/media/usb/go7007/go7007-driver.c +++ b/drivers/media/usb/go7007/go7007-driver.c @@ -80,7 +80,7 @@ static int go7007_load_encoder(struct go7007 *go) const struct firmware *fw_entry; char fw_name[] = "go7007/go7007fw.bin"; void *bounce; - int fw_len, rv = 0; + int fw_len; u16 intr_val, intr_data; if (go->boot_fw == NULL) { @@ -109,9 +109,11 @@ static int go7007_load_encoder(struct go7007 *go) go7007_read_interrupt(go, &intr_val, &intr_data) < 0 || (intr_val & ~0x1) != 0x5a5a) { v4l2_err(go, "error transferring firmware\n"); - rv = -1; + kfree(go->boot_fw); + go->boot_fw = NULL; + return -1; } - return rv; + return 0; } MODULE_FIRMWARE("go7007/go7007fw.bin"); -- 2.17.1

2 1

[PATCH OLK-5.10] octeontx2-af: Use separate handlers for interrupts
by Guo Mengqi 17 Oct '24

17 Oct '24

From: Subbaraya Sundeep <sbhatta(a)marvell.com> stable inclusion from stable-v5.10.214 commit 766c2627acb2d9d1722cce2e24837044d52d888a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9N9 CVE: CVE-2024-27030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ] For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c index acbc67074f59..23b829f974de 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c @@ -1969,10 +1969,9 @@ static void rvu_queue_work(struct mbox_wq_info *mw, int first, } } -static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +static irqreturn_t rvu_mbox_pf_intr_handler(int irq, void *rvu_irq) { struct rvu *rvu = (struct rvu *)rvu_irq; - int vfs = rvu->vfs; u64 intr; intr = rvu_read64(rvu, BLKADDR_RVUM, RVU_AF_PFAF_MBOX_INT); @@ -1986,6 +1985,18 @@ static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) rvu_queue_work(&rvu->afpf_wq_info, 0, rvu->hw->total_pfs, intr); + return IRQ_HANDLED; +} + +static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +{ + struct rvu *rvu = (struct rvu *)rvu_irq; + int vfs = rvu->vfs; + u64 intr; + + /* Sync with mbox memory region */ + rmb(); + /* Handle VF interrupts */ if (vfs > 64) { intr = rvupf_read64(rvu, RVU_PF_VFPF_MBOX_INTX(1)); @@ -2300,7 +2311,7 @@ static int rvu_register_interrupts(struct rvu *rvu) /* Register mailbox interrupt handler */ sprintf(&rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], "RVUAF Mbox"); ret = request_irq(pci_irq_vector(rvu->pdev, RVU_AF_INT_VEC_MBOX), - rvu_mbox_intr_handler, 0, + rvu_mbox_pf_intr_handler, 0, &rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], rvu); if (ret) { dev_err(rvu->dev, -- 2.17.1

2 1

[PATCH OLK-6.6] drm/amd/display: Ensure index calculation will not overflow
by Tong Tiangen 17 Oct '24

17 Oct '24

From: Alex Hung <alex.hung(a)amd.com> stable inclusion from stable-v6.6.50 commit 3dc6bb57dab36b38b7374af0ac916174c146b6ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARV8L CVE: CVE-2024-46726 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8e2734bf444767fed787305ccdcb36a2be5301a2 ] [WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c index 50b0434354f8..c08169de3660 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c @@ -1453,10 +1453,9 @@ void dcn_bw_update_from_pplib_fclks( ASSERT(fclks->num_levels); vmin0p65_idx = 0; - vmid0p72_idx = fclks->num_levels - - (fclks->num_levels > 2 ? 3 : (fclks->num_levels > 1 ? 2 : 1)); - vnom0p8_idx = fclks->num_levels - (fclks->num_levels > 1 ? 2 : 1); - vmax0p9_idx = fclks->num_levels - 1; + vmid0p72_idx = fclks->num_levels > 2 ? fclks->num_levels - 3 : 0; + vnom0p8_idx = fclks->num_levels > 1 ? fclks->num_levels - 2 : 0; + vmax0p9_idx = fclks->num_levels > 0 ? fclks->num_levels - 1 : 0; dc->dcn_soc->fabric_and_dram_bandwidth_vmin0p65 = 32 * (fclks->data[vmin0p65_idx].clocks_in_khz / 1000.0) / 1000.0; -- 2.25.1

2 1

[PATCH OLK-5.10] greybus: Fix use-after-free bug in gb_interface_release due to race condition.
by Tong Tiangen 17 Oct '24

17 Oct '24

From: Sicong Huang <congei42(a)163.com> stable inclusion from stable-v5.10.221 commit 2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2E CVE: CVE-2024-39495 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce upstream. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object "intf". The possible execution flow that may lead to the issue is as follows: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (free) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (use) Fix it by canceling the work before kfree. Signed-off-by: Sicong Huang <congei42(a)163.com> Link: https://lore.kernel.org/r/20240416080313.92306-1-congei42@163.com Cc: Ronnie Sahlberg <rsahlberg(a)ciq.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/greybus/interface.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/greybus/interface.c b/drivers/greybus/interface.c index 9ec949a438ef..52ef6be9d449 100644 --- a/drivers/greybus/interface.c +++ b/drivers/greybus/interface.c @@ -694,6 +694,7 @@ static void gb_interface_release(struct device *dev) trace_gb_interface_release(intf); + cancel_work_sync(&intf->mode_switch_work); kfree(intf); } -- 2.25.1

2 1

[PATCH OLK-6.6] RDMA/hns: Fix flush cqe error when racing with destroy qp
by Chengchang Tang 17 Oct '24

17 Oct '24

From: wenglianfa <wenglianfa(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXK5A ---------------------------------------------------------------------- QP needs to be modified to IB_QPS_ERROR to trigger HW flush cqe. But when this process races with destroy qp, the destroy-qp process may modify the QP to IB_QPS_RESET first. In this case flush cqe will fail since it is invalid to modify qp from IB_QPS_RESET to IB_QPS_ERROR. Add lock and bit flag to make sure pending flush cqe work is completed first. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> Signed-off-by: Xinghai Cen <cenxinghai(a)h-partners.com> --- drivers/infiniband/hw/hns/hns_roce_device.h | 2 ++ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 7 +++++++ drivers/infiniband/hw/hns/hns_roce_qp.c | 14 ++++++++++++-- 3 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h index 8add4742c094..7e139134b765 100644 --- a/drivers/infiniband/hw/hns/hns_roce_device.h +++ b/drivers/infiniband/hw/hns/hns_roce_device.h @@ -674,6 +674,7 @@ struct hns_roce_dev; enum { HNS_ROCE_FLUSH_FLAG = 0, + HNS_ROCE_STOP_FLUSH_FLAG = 1, }; struct hns_roce_work { @@ -740,6 +741,7 @@ struct hns_roce_qp { enum hns_roce_cong_type cong_type; bool delayed_destroy_flag; struct hns_roce_mtr_node *mtr_node; + spinlock_t flush_lock; }; struct hns_roce_ib_iboe { diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index bc0b944ecfac..18e969b96fd1 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -6020,8 +6020,15 @@ int hns_roce_v2_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata) { struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device); struct hns_roce_qp *hr_qp = to_hr_qp(ibqp); + unsigned long flags; int ret; + /* Make sure flush_cqe() is complete */ + spin_lock_irqsave(&hr_qp->flush_lock, flags); + set_bit(HNS_ROCE_STOP_FLUSH_FLAG, &hr_qp->flush_flag); + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); + flush_work(&hr_qp->flush_work.work); + ret = hns_roce_v2_destroy_qp_common(hr_dev, hr_qp, udata); if (ret) ibdev_err_ratelimited(&hr_dev->ib_dev, diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c index 2eb2694acf21..a62b1b96655a 100644 --- a/drivers/infiniband/hw/hns/hns_roce_qp.c +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c @@ -71,11 +71,18 @@ static void flush_work_handle(struct work_struct *work) void init_flush_work(struct hns_roce_dev *hr_dev, struct hns_roce_qp *hr_qp) { struct hns_roce_work *flush_work = &hr_qp->flush_work; + unsigned long flags; + + spin_lock_irqsave(&hr_qp->flush_lock, flags); + /* Exit flush_work after destroy_qp() */ + if (test_bit(HNS_ROCE_STOP_FLUSH_FLAG, &hr_qp->flush_flag)) { + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); + return; + } - flush_work->hr_dev = hr_dev; - INIT_WORK(&flush_work->work, flush_work_handle); refcount_inc(&hr_qp->refcount); queue_work(hr_dev->irq_workq, &flush_work->work); + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); } void flush_cqe(struct hns_roce_dev *dev, struct hns_roce_qp *qp) @@ -1225,6 +1232,7 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev, struct ib_udata *udata, struct hns_roce_qp *hr_qp) { + struct hns_roce_work *flush_work = &hr_qp->flush_work; struct hns_roce_ib_create_qp_resp resp = {}; struct ib_device *ibdev = &hr_dev->ib_dev; struct hns_roce_ib_create_qp ucmd = {}; @@ -1236,6 +1244,8 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev, hr_qp->state = IB_QPS_RESET; hr_qp->flush_flag = 0; + flush_work->hr_dev = hr_dev; + INIT_WORK(&flush_work->work, flush_work_handle); ret = set_qp_param(hr_dev, hr_qp, init_attr, udata, &ucmd); if (ret) { -- 2.33.0

2 1