- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/1] CVE-2024-56567
by Liao Chen 31 Dec '24

31 Dec '24

fix CVE-2024-56567 Zicheng Qu (1): [Backport] ad7780: fix division by zero in ad7780_write_raw() drivers/iio/adc/ad7780.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 6

[PATCH OLK-6.6 v2] EDAC/igen6: Avoid segmentation fault on module unload
by Ye Bin 31 Dec '24

31 Dec '24

From: Orange Kao <orange(a)aiven.io> stable inclusion from stable-v6.6.64 commit 830cabb61113d92a425dd3038ccedbdfb3c8d079 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDPH CVE: CVE-2024-56708 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fefaae90398d38a1100ccd73b46ab55ff4610fba ] The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219360 Signed-off-by: Orange Kao <orange(a)aiven.io> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Link: https://lore.kernel.org/r/20241104124237.124109-2-orange@aiven.io Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/edac/igen6_edac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c index a0edb61a5a01..0b408299699a 100644 --- a/drivers/edac/igen6_edac.c +++ b/drivers/edac/igen6_edac.c @@ -1075,6 +1075,7 @@ static int igen6_register_mci(int mc, u64 mchbar, struct pci_dev *pdev) imc->mci = mci; return 0; fail3: + mci->pvt_info = NULL; kfree(mci->ctl_name); fail2: edac_mc_free(mci); @@ -1099,6 +1100,7 @@ static void igen6_unregister_mcis(void) edac_mc_del_mc(mci->pdev); kfree(mci->ctl_name); + mci->pvt_info = NULL; edac_mc_free(mci); iounmap(imc->window); } -- 2.34.1

2 5

[PATCH OLK-6.6 0/1] CVE-2024-56677
by Liao Chen 31 Dec '24

31 Dec '24

fix CVE-2024-56677 Ritesh Harjani (IBM) (1): [Backport] powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init() arch/powerpc/include/asm/fadump.h | 7 +++++++ arch/powerpc/kernel/fadump.c | 6 +----- arch/powerpc/kernel/setup-common.c | 6 ++++-- 3 files changed, 12 insertions(+), 7 deletions(-) -- 2.34.1

2 6

[PATCH openEuler-1.0-LTS] sh: intc: Fix use-after-free bug in register_intc_controller()
by Zhang Kunbo 31 Dec '24

31 Dec '24

From: Dan Carpenter <dan.carpenter(a)linaro.org> stable inclusion from stable-v4.19.325 commit 3c7c806b3eafd94ae0f77305a174d63b69ec187c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAEH CVE: CVE-2024-53165 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 63e72e551942642c48456a4134975136cdcb9b3c ] In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let's only add it to the list after everything has succeeded. Fixes: 2dcec7a988a1 ("sh: intc: set_irq_wake() support") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> Signed-off-by: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- drivers/sh/intc/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c index 46f0f322d4d8..48fe5fab5693 100644 --- a/drivers/sh/intc/core.c +++ b/drivers/sh/intc/core.c @@ -194,7 +194,6 @@ int __init register_intc_controller(struct intc_desc *desc) goto err0; INIT_LIST_HEAD(&d->list); - list_add_tail(&d->list, &intc_list); raw_spin_lock_init(&d->lock); INIT_RADIX_TREE(&d->tree, GFP_ATOMIC); @@ -380,6 +379,7 @@ int __init register_intc_controller(struct intc_desc *desc) d->skip_suspend = desc->skip_syscore_suspend; + list_add_tail(&d->list, &intc_list); nr_intc_controllers++; return 0; -- 2.34.1

2 5

[PATCH OLK-6.6 0/1] CVE-2024-56567
by Liao Chen 31 Dec '24

31 Dec '24

fix CVE-2024-56567 Zicheng Qu (1): [Backport] ad7780: fix division by zero in ad7780_write_raw() drivers/iio/adc/ad7780.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 6

[PATCH openEuler-1.0-LTS] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 31 Dec '24

31 Dec '24

From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v4.19.325 commit d16109c9fdc1b8cea4fe63b42e06e926c3f68990 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 1cf4019689a5..8b8453dab660 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -472,11 +472,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0

2 5

[PATCH OLK-6.6 v2] drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()
by Ye Bin 31 Dec '24

31 Dec '24

From: Li Huafei <lihuafei1(a)huawei.com> stable inclusion from stable-v6.6.64 commit 237f2dbfa00576bb1aa8dc2dce403c64e53270e6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFJ CVE: CVE-2024-56752 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a2f599046c671d6b46d93aed95b37241ce4504cf ] When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex before returning the error. Fixes smatch warning: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'. Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generate golden context during first object alloc") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: Lyude Paul <lyude(a)redhat.com> Signed-off-by: Lyude Paul <lyude(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241026173844.2392679-1-lihu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c index 3648868bb9fc..cd533d16b966 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c @@ -443,6 +443,7 @@ gf100_gr_chan_new(struct nvkm_gr *base, struct nvkm_chan *fifoch, ret = gf100_grctx_generate(gr, chan, fifoch->inst); if (ret) { nvkm_error(&base->engine.subdev, "failed to construct context\n"); + mutex_unlock(&gr->fecs.mutex); return ret; } } -- 2.34.1

2 2

[PATCH OLK-6.6] octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c
by Jinjie Ruan 31 Dec '24

31 Dec '24

From: Dipendra Khadka <kdipendra88(a)gmail.com> stable inclusion from stable-v6.6.64 commit c5a6c5af434671aea739a5a41c849819144f02c9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFA CVE: CVE-2024-56726 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ac9183023b6a9c09467516abd8aab04f9a2f9564 ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 2ca89a2c3752 ("octeontx2-pf: TC_MATCHALL ingress ratelimiting offload") Signed-off-by: Dipendra Khadka <kdipendra88(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c index c1c99d7054f8..7417087b6db5 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c @@ -203,6 +203,11 @@ int cn10k_alloc_leaf_profile(struct otx2_nic *pfvf, u16 *leaf) rsp = (struct nix_bandprof_alloc_rsp *) otx2_mbox_get_rsp(&pfvf->mbox.mbox, 0, &req->hdr); + if (IS_ERR(rsp)) { + rc = PTR_ERR(rsp); + goto out; + } + if (!rsp->prof_count[BAND_PROF_LEAF_LAYER]) { rc = -EIO; goto out; -- 2.34.1

2 5

[PATCH OLK-5.10] virtio/vsock: Fix accept_queue memory leak
by Zhang Changzhong 31 Dec '24

31 Dec '24

From: Michal Luczaj <mhal(a)rbox.co> mainline inclusion from mainline-v6.12 commit d7b0ff5a866724c3ad21f2628c22a63336deec3f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB8IUG CVE: CVE-2024-53119 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 Fixes: 3fe356d58efa ("vsock/virtio: discard packets only when socket is really closed") Reviewed-by: Stefano Garzarella <sgarzare(a)redhat.com> Signed-off-by: Michal Luczaj <mhal(a)rbox.co> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/vmw_vsock/virtio_transport_common.c [71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/vmw_vsock/virtio_transport_common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 4102689..05edf0a 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1061,6 +1061,14 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt, return -ENOMEM; } + /* __vsock_release() might have already flushed accept_queue. + * Subsequent enqueues would lead to a memory leak. + */ + if (sk->sk_shutdown == SHUTDOWN_MASK) { + virtio_transport_reset_no_sock(t, pkt); + return -ESHUTDOWN; + } + child = vsock_create_connected(sk); if (!child) { virtio_transport_reset_no_sock(t, pkt); -- 2.9.5

2 5

[PATCH openEuler-22.03-LTS-SP1] virtio/vsock: Fix accept_queue memory leak
by Zhang Changzhong 31 Dec '24

31 Dec '24

From: Michal Luczaj <mhal(a)rbox.co> mainline inclusion from mainline-v6.12 commit d7b0ff5a866724c3ad21f2628c22a63336deec3f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB8IUG CVE: CVE-2024-53119 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 Fixes: 3fe356d58efa ("vsock/virtio: discard packets only when socket is really closed") Reviewed-by: Stefano Garzarella <sgarzare(a)redhat.com> Signed-off-by: Michal Luczaj <mhal(a)rbox.co> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/vmw_vsock/virtio_transport_common.c [71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/vmw_vsock/virtio_transport_common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index c9ee925..bcc0a46 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1054,6 +1054,14 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt, return -ENOMEM; } + /* __vsock_release() might have already flushed accept_queue. + * Subsequent enqueues would lead to a memory leak. + */ + if (sk->sk_shutdown == SHUTDOWN_MASK) { + virtio_transport_reset_no_sock(t, pkt); + return -ESHUTDOWN; + } + child = vsock_create_connected(sk); if (!child) { virtio_transport_reset_no_sock(t, pkt); -- 2.9.5

2 5