- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] net: enetc: Do not configure preemptible TCs if SIs do not support
by Li Huafei 07 Jan '25

07 Jan '25

From: Wei Fang <wei.fang(a)nxp.com> stable inclusion from stable-v6.6.66 commit 66127f0d1ecf00604aeab71132bde398fd9ec7c9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAO0 CVE: CVE-2024-56649 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b2420b8c81ec674552d00c55d46245e5c184b260 ] Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs() to configure preemptible TCs. However, only PF is able to configure preemptible TCs. Because only PF has related registers, while VF does not have these registers. So for VF, its hw->port pointer is NULL. Therefore, VF will access an invalid pointer when accessing a non-existent register, which will cause a crash issue. The simplified log is as follows. root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \ mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1 [ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00 [ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400 [ 187.511140] Call trace: [ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.518918] enetc_setup_tc_mqprio+0x180/0x214 [ 187.523374] enetc_vf_setup_tc+0x1c/0x30 [ 187.527306] mqprio_enable_offload+0x144/0x178 [ 187.531766] mqprio_init+0x3ec/0x668 [ 187.535351] qdisc_create+0x15c/0x488 [ 187.539023] tc_modify_qdisc+0x398/0x73c [ 187.542958] rtnetlink_rcv_msg+0x128/0x378 [ 187.547064] netlink_rcv_skb+0x60/0x130 [ 187.550910] rtnetlink_rcv+0x18/0x24 [ 187.554492] netlink_unicast+0x300/0x36c [ 187.558425] netlink_sendmsg+0x1a8/0x420 [ 187.606759] ---[ end trace 0000000000000000 ]--- In addition, some PFs also do not support configuring preemptible TCs, such as eno1 and eno3 on LS1028A. It won't crash like it does for VFs, but we should prevent these PFs from accessing these unimplemented registers. Fixes: 827145392a4a ("net: enetc: only commit preemptible TCs to hardware when MM TX is active") Signed-off-by: Wei Fang <wei.fang(a)nxp.com> Suggested-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/ethernet/freescale/enetc/enetc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c index c17b9e338516..87b27bd7a13b 100644 --- a/drivers/net/ethernet/freescale/enetc/enetc.c +++ b/drivers/net/ethernet/freescale/enetc/enetc.c @@ -28,6 +28,9 @@ EXPORT_SYMBOL_GPL(enetc_port_mac_wr); static void enetc_change_preemptible_tcs(struct enetc_ndev_priv *priv, u8 preemptible_tcs) { + if (!(priv->si->hw_features & ENETC_SI_F_QBU)) + return; + priv->preemptible_tcs = preemptible_tcs; enetc_mm_commit_preemptible_tcs(priv); } -- 2.25.1

2 1

[PATCH OLK-6.6] nvme-pci: fix freeing of the HMB descriptor table
by Yu Kuai 07 Jan '25

07 Jan '25

From: Christoph Hellwig <hch(a)lst.de> stable inclusion from stable-v6.6.64 commit cee3bff51a35cab1c5d842d409a7b11caefe2386 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGGM CVE: CVE-2024-56756 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3c2fb1ca8086eb139b2a551358137525ae8e0d7a ] The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. Fixes: 87ad72a59a38 ("nvme-pci: implement host memory buffer support") Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> --- drivers/nvme/host/pci.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index b701969cf1c2..e0b502573b42 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -153,6 +153,7 @@ struct nvme_dev { /* host memory buffer support: */ u64 host_mem_size; u32 nr_host_mem_descs; + u32 host_mem_descs_size; dma_addr_t host_mem_descs_dma; struct nvme_host_mem_buf_desc *host_mem_descs; void **host_mem_desc_bufs; @@ -1929,10 +1930,10 @@ static void nvme_free_host_mem(struct nvme_dev *dev) kfree(dev->host_mem_desc_bufs); dev->host_mem_desc_bufs = NULL; - dma_free_coherent(dev->dev, - dev->nr_host_mem_descs * sizeof(*dev->host_mem_descs), + dma_free_coherent(dev->dev, dev->host_mem_descs_size, dev->host_mem_descs, dev->host_mem_descs_dma); dev->host_mem_descs = NULL; + dev->host_mem_descs_size = 0; dev->nr_host_mem_descs = 0; } @@ -1940,7 +1941,7 @@ static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred, u32 chunk_size) { struct nvme_host_mem_buf_desc *descs; - u32 max_entries, len; + u32 max_entries, len, descs_size; dma_addr_t descs_dma; int i = 0; void **bufs; @@ -1953,8 +1954,9 @@ static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred, if (dev->ctrl.hmmaxd && dev->ctrl.hmmaxd < max_entries) max_entries = dev->ctrl.hmmaxd; - descs = dma_alloc_coherent(dev->dev, max_entries * sizeof(*descs), - &descs_dma, GFP_KERNEL); + descs_size = max_entries * sizeof(*descs); + descs = dma_alloc_coherent(dev->dev, descs_size, &descs_dma, + GFP_KERNEL); if (!descs) goto out; @@ -1983,6 +1985,7 @@ static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred, dev->host_mem_size = size; dev->host_mem_descs = descs; dev->host_mem_descs_dma = descs_dma; + dev->host_mem_descs_size = descs_size; dev->host_mem_desc_bufs = bufs; return 0; @@ -1997,8 +2000,7 @@ static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred, kfree(bufs); out_free_descs: - dma_free_coherent(dev->dev, max_entries * sizeof(*descs), descs, - descs_dma); + dma_free_coherent(dev->dev, descs_size, descs, descs_dma); out: dev->host_mem_descs = NULL; return -ENOMEM; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
by Zeng Heng 07 Jan '25

07 Jan '25

From: Yongliang Gao <leonylgao(a)tencent.com> stable inclusion from stable-v6.6.64 commit dd4b1cbcc916fad5d10c2662b62def9f05e453d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFG CVE: CVE-2024-56739 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ] If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Signed-off-by: Yongliang Gao <leonylgao(a)tencent.com> Acked-by: Jingqun Li <jingqunli(a)tencent.com> Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/rtc/interface.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index ce051f91829f..1ab619fb978a 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -914,13 +914,18 @@ void rtc_timer_do_work(struct work_struct *work) struct timerqueue_node *next; ktime_t now; struct rtc_time tm; + int err; struct rtc_device *rtc = container_of(work, struct rtc_device, irqwork); mutex_lock(&rtc->ops_lock); again: - __rtc_read_time(rtc, &tm); + err = __rtc_read_time(rtc, &tm); + if (err) { + mutex_unlock(&rtc->ops_lock); + return; + } now = rtc_tm_to_ktime(tm); while ((next = timerqueue_getnext(&rtc->timerqueue))) { if (next->expires > now) -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
by Zeng Heng 07 Jan '25

07 Jan '25

From: Yongliang Gao <leonylgao(a)tencent.com> stable inclusion from stable-v6.6.64 commit dd4b1cbcc916fad5d10c2662b62def9f05e453d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFG CVE: CVE-2024-56739 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ] If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Signed-off-by: Yongliang Gao <leonylgao(a)tencent.com> Acked-by: Jingqun Li <jingqunli(a)tencent.com> Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/rtc/interface.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 16fbcf6835f3..809ada324e4d 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -908,13 +908,18 @@ void rtc_timer_do_work(struct work_struct *work) struct timerqueue_node *next; ktime_t now; struct rtc_time tm; + int err; struct rtc_device *rtc = container_of(work, struct rtc_device, irqwork); mutex_lock(&rtc->ops_lock); again: - __rtc_read_time(rtc, &tm); + err = __rtc_read_time(rtc, &tm); + if (err) { + mutex_unlock(&rtc->ops_lock); + return; + } now = rtc_tm_to_ktime(tm); while ((next = timerqueue_getnext(&rtc->timerqueue))) { if (next->expires > now) -- 2.25.1

2 1

[PATCH OLK-5.10] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
by Zeng Heng 07 Jan '25

07 Jan '25

From: Yongliang Gao <leonylgao(a)tencent.com> stable inclusion from stable-v6.6.64 commit dd4b1cbcc916fad5d10c2662b62def9f05e453d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFG CVE: CVE-2024-56739 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ] If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Signed-off-by: Yongliang Gao <leonylgao(a)tencent.com> Acked-by: Jingqun Li <jingqunli(a)tencent.com> Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/rtc/interface.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 16fbcf6835f3..809ada324e4d 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -908,13 +908,18 @@ void rtc_timer_do_work(struct work_struct *work) struct timerqueue_node *next; ktime_t now; struct rtc_time tm; + int err; struct rtc_device *rtc = container_of(work, struct rtc_device, irqwork); mutex_lock(&rtc->ops_lock); again: - __rtc_read_time(rtc, &tm); + err = __rtc_read_time(rtc, &tm); + if (err) { + mutex_unlock(&rtc->ops_lock); + return; + } now = rtc_tm_to_ktime(tm); while ((next = timerqueue_getnext(&rtc->timerqueue))) { if (next->expires > now) -- 2.25.1

2 1

[PATCH OLK-6.6] io_uring: check for overflows in io_pin_pages
by Long Li 07 Jan '25

07 Jan '25

From: Pavel Begunkov <asml.silence(a)gmail.com> mainline inclusion from mainline-v6.10-rc2 commit 0c0a4eae26ac78379d0c1db053de168a8febc6c9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAFR CVE: CVE-2024-53187 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK> io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow. Cc: stable(a)vger.kernel.org Reported-by: syzbot+2159cbb522b02847c053(a)syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/1b7520ddb168e1d537d64be47414a0629d0d8f8f.17325810… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: io_uring/rsrc.c io_uring/memmap.c [Conflicts due to io_pin_pages() move to io_uring/memmap.c in mainline] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- io_uring/rsrc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c index 0f9dcde72ebf..7ca3d2d2290e 100644 --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -879,7 +879,12 @@ struct page **io_pin_pages(unsigned long ubuf, unsigned long len, int *npages) struct page **pages = NULL; int pret, ret = -ENOMEM; - end = (ubuf + len + PAGE_SIZE - 1) >> PAGE_SHIFT; + if (check_add_overflow(ubuf, len, &end)) + return ERR_PTR(-EOVERFLOW); + if (check_add_overflow(end, PAGE_SIZE - 1, &end)) + return ERR_PTR(-EOVERFLOW); + + end = end >> PAGE_SHIFT; start = ubuf >> PAGE_SHIFT; nr_pages = end - start; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] NFSv4: Fix deadlock during the running of state manager
by Li Lingfeng 07 Jan '25

07 Jan '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBAFF1 -------------------------------- Unlinking file may cause the following deadlock in state manager: [root@localhost test]# cat /proc/2943/stack [<0>] rpc_wait_bit_killable+0x1a/0x90 [<0>] _nfs4_proc_delegreturn+0x60f/0x760 [<0>] nfs4_proc_delegreturn+0x13d/0x2a0 [<0>] nfs_do_return_delegation+0xba/0x110 [<0>] nfs_end_delegation_return+0x32c/0x620 [<0>] nfs_complete_unlink+0xc7/0x290 [<0>] nfs_dentry_iput+0x36/0x50 [<0>] __dentry_kill+0xaa/0x250 [<0>] dput.part.0+0x26c/0x4d0 [<0>] __put_nfs_open_context+0x1d9/0x260 [<0>] nfs4_open_reclaim+0x77/0xa0 [<0>] nfs4_do_reclaim+0x385/0xf40 [<0>] nfs4_state_manager+0x762/0x14e0 [<0>] nfs4_run_state_manager+0x181/0x330 [<0>] kthread+0x1a7/0x1f0 [<0>] ret_from_fork+0x34/0x60 [<0>] ret_from_fork_asm+0x1a/0x30 [root@localhost test]# It can be reproduced by following steps: 1) client: open file 2) client: unlink file 3) server: service restart(trigger state manager in client) 4) client: close file(in nfs4_open_reclaim, between nfs4_do_open_reclaim and put_nfs_open_context) Since the file has been open, unlinking will just set DCACHE_NFSFS_RENAMED for the dentry like this: nfs_unlink nfs_sillyrename nfs_async_unlink // set DCACHE_NFSFS_RENAMED Restarting service will trigger state manager in client. (1) NFS4_SLOT_TBL_DRAINING will be set to nfs4_slot_table since session has been reset. (2) DCACHE_NFSFS_RENAMED is detected in nfs_dentry_iput. Therefore, nfs_complete_unlink is called to trigger delegation return. (3) Due to the slot table being in draining state and sa_privileged being 0, the delegation return will be queued and wait. nfs4_state_manager nfs4_reset_session nfs4_begin_drain_session nfs4_drain_slot_tbl // set NFS4_SLOT_TBL_DRAINING (1) nfs4_do_reclaim nfs4_open_reclaim __put_nfs_open_context __dentry_kill nfs_dentry_iput // check DCACHE_NFSFS_RENAMED (2) nfs_complete_unlink nfs_end_delegation_return nfs_do_return_delegation nfs4_proc_delegreturn _nfs4_proc_delegreturn rpc_run_task ... nfs4_delegreturn_prepare nfs4_setup_sequence nfs4_slot_tbl_draining // check NFS4_SLOT_TBL_DRAINING // and sa_privileged is 0 (3) rpc_sleep_on // set queued and add to slot_tbl_waitq // rpc_task is async and wait in __rpc_execute rpc_wait_for_completion_task __rpc_wait_for_completion_task out_of_line_wait_on_bit rpc_wait_bit_killable // wait for rpc_task to complete <-------- can not get here to wake up rpc_task --------> nfs4_end_drain_session nfs4_end_drain_slot_table nfs41_wake_slot_table On the one hand, the state manager is blocked by the unfinished delegation return. As a result, nfs4_end_drain_session cannot be invoked to clear NFS4_SLOT_TBL_DRAINING and wake up waiting tasks. On the other hand, since NFS4_SLOT_TBL_DRAINING is not cleared, delegation return can only wait in the queue, resulting in a deadlock. Fix it by turning the delegation return into a privileged operation for the case where the nfs_client is in NFS4CLNT_RECLAIM_REBOOT state. Fixes: 977fcc2b0b41 ("NFS: Add a delegation return into nfs4_proc_unlink_setup()") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 5985f326550e..282e5559b176 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6295,7 +6295,8 @@ static int _nfs4_proc_delegreturn(struct inode *inode, struct rpc_cred *cred, co data->lr.roc = false; } - if (!data->inode) + if (!data->inode || + test_bit(NFS4CLNT_RECLAIM_REBOOT, &server->nfs_client->cl_state)) nfs4_init_sequence(&data->args.seq_args, &data->res.seq_res, 1, 1); else -- 2.31.1

2 1

[PATCH OLK-6.6] mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
by Zeng Heng 07 Jan '25

07 Jan '25

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v6.6.64 commit e1ef62e8d262e3f27446d26742208c1c81e9ee18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOS CVE: CVE-2024-56691 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 686fb77712a4bc94b76a0c5ae74c60118b7a0d79 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 9c6235c86332 ("mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device") Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by: Zhang Ning <zhangn1985(a)outlook.com> Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3… Tested-by: Zhang Ning <zhangn1985(a)outlook.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20241005193029.1929139-2-andriy.shevchenko@linux.… Signed-off-by: Lee Jones <lee(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/mfd/intel_soc_pmic_bxtwc.c | 57 +++++++++++++++++++++--------- drivers/usb/typec/tcpm/wcove.c | 4 --- 2 files changed, 40 insertions(+), 21 deletions(-) diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index 8dac0d41f64f..6ea98321bbf2 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -241,16 +241,6 @@ static struct mfd_cell bxt_wc_dev[] = { .num_resources = ARRAY_SIZE(thermal_resources), .resources = thermal_resources, }, - { - .name = "bxt_wcove_usbc", - .num_resources = ARRAY_SIZE(usbc_resources), - .resources = usbc_resources, - }, - { - .name = "bxt_wcove_ext_charger", - .num_resources = ARRAY_SIZE(charger_resources), - .resources = charger_resources, - }, { .name = "bxt_wcove_bcu", .num_resources = ARRAY_SIZE(bcu_resources), @@ -272,6 +262,19 @@ static struct mfd_cell bxt_wc_dev[] = { }, }; +static struct mfd_cell bxt_wc_chgr_dev[] = { + { + .name = "bxt_wcove_usbc", + .num_resources = ARRAY_SIZE(usbc_resources), + .resources = usbc_resources, + }, + { + .name = "bxt_wcove_ext_charger", + .num_resources = ARRAY_SIZE(charger_resources), + .resources = charger_resources, + }, +}; + static int regmap_ipc_byte_reg_read(void *context, unsigned int reg, unsigned int *val) { @@ -426,6 +429,26 @@ static int bxtwc_add_chained_irq_chip(struct intel_soc_pmic *pmic, 0, chip, data); } +static int bxtwc_add_chained_devices(struct intel_soc_pmic *pmic, + const struct mfd_cell *cells, int n_devs, + struct regmap_irq_chip_data *pdata, + int pirq, int irq_flags, + const struct regmap_irq_chip *chip, + struct regmap_irq_chip_data **data) +{ + struct device *dev = pmic->dev; + struct irq_domain *domain; + int ret; + + ret = bxtwc_add_chained_irq_chip(pmic, pdata, pirq, irq_flags, chip, data); + if (ret) + return dev_err_probe(dev, ret, "Failed to add %s IRQ chip\n", chip->name); + + domain = regmap_irq_get_domain(*data); + + return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, cells, n_devs, NULL, 0, domain); +} + static int bxtwc_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -501,14 +524,14 @@ static int bxtwc_probe(struct platform_device *pdev) if (ret) return dev_err_probe(dev, ret, "Failed to add ADC IRQ chip\n"); - /* Add chained IRQ handler for CHGR IRQs */ - ret = bxtwc_add_chained_irq_chip(pmic, pmic->irq_chip_data, - BXTWC_CHGR_LVL1_IRQ, - IRQF_ONESHOT, - &bxtwc_regmap_irq_chip_chgr, - &pmic->irq_chip_data_chgr); + ret = bxtwc_add_chained_devices(pmic, bxt_wc_chgr_dev, ARRAY_SIZE(bxt_wc_chgr_dev), + pmic->irq_chip_data, + BXTWC_CHGR_LVL1_IRQ, + IRQF_ONESHOT, + &bxtwc_regmap_irq_chip_chgr, + &pmic->irq_chip_data_chgr); if (ret) - return dev_err_probe(dev, ret, "Failed to add CHGR IRQ chip\n"); + return ret; /* Add chained IRQ handler for CRIT IRQs */ ret = bxtwc_add_chained_irq_chip(pmic, pmic->irq_chip_data, diff --git a/drivers/usb/typec/tcpm/wcove.c b/drivers/usb/typec/tcpm/wcove.c index 87d4abde0ea2..e08244f555f0 100644 --- a/drivers/usb/typec/tcpm/wcove.c +++ b/drivers/usb/typec/tcpm/wcove.c @@ -621,10 +621,6 @@ static int wcove_typec_probe(struct platform_device *pdev) if (irq < 0) return irq; - irq = regmap_irq_get_virq(pmic->irq_chip_data_chgr, irq); - if (irq < 0) - return irq; - ret = guid_parse(WCOVE_DSM_UUID, &wcove->guid); if (ret) return ret; -- 2.25.1

2 1

[PATCH OLK-6.6 0/6] LoongArch: fix some dwmac/pci/SE/i2c/interrupt issues
by Hongchen Zhang 07 Jan '25

07 Jan '25

Zhao Qunqin (3): pci/quirks: LS7A2000: fix pm transition of devices under pcie port net: stmmac: dwmac-loongson: fix Mac DMA reset drivers/char: add ACPI firmware support for Loongson SE driver wanghongliang (3): LoongArch: fix i2c related issues LoongArch: eiointc: fix ext irq route error LoongArch: adjust the calc method of number of packages. arch/loongarch/configs/loongson3_defconfig | 2 + arch/loongarch/include/asm/topology.h | 4 + arch/loongarch/kernel/setup.c | 1 + arch/loongarch/kernel/smp.c | 3 + drivers/char/loongson_se.c | 440 +++++++----------- drivers/char/lsse_sdf_cdev.c | 310 ++++++------ drivers/gpio/Kconfig | 2 +- drivers/gpio/gpio-loongson-64bit.c | 298 ++++++++++-- drivers/i2c/busses/i2c-ls2x.c | 12 +- drivers/irqchip/irq-loongson-eiointc.c | 47 +- .../ethernet/stmicro/stmmac/dwmac-loongson.c | 14 + drivers/pci/quirks.c | 30 ++ drivers/platform/loongarch/cpu_hwmon.c | 3 +- include/linux/pci.h | 1 + .../include/asm => include/soc/loongson}/se.h | 52 +-- 15 files changed, 711 insertions(+), 508 deletions(-) rename {arch/loongarch/include/asm => include/soc/loongson}/se.h (68%) -- 2.33.0

2 7

[PATCH OLK-5.10] BEAEC[Backport] ALSA: 6fire: Release resources at card release
by Lin Ruifeng 07 Jan '25

07 Jan '25

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.231 commit f2d06d4e129e2508e356136f99bb20a332ff1a00 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAEC CVE: CVE-2024-53239 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a0810c3d6dd2d29a9b92604d682eacd2902ce947 ] The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://patch.msgid.link/20241113111042.15058-6-tiwai@suse.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- sound/usb/6fire/chip.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/usb/6fire/chip.c b/sound/usb/6fire/chip.c index 08c6e6a52eb9..ad6f89845a5c 100644 --- a/sound/usb/6fire/chip.c +++ b/sound/usb/6fire/chip.c @@ -62,8 +62,10 @@ static void usb6fire_chip_abort(struct sfire_chip *chip) } } -static void usb6fire_chip_destroy(struct sfire_chip *chip) +static void usb6fire_card_free(struct snd_card *card) { + struct sfire_chip *chip = card->private_data; + if (chip) { if (chip->pcm) usb6fire_pcm_destroy(chip); @@ -73,8 +75,6 @@ static void usb6fire_chip_destroy(struct sfire_chip *chip) usb6fire_comm_destroy(chip); if (chip->control) usb6fire_control_destroy(chip); - if (chip->card) - snd_card_free(chip->card); } } @@ -137,6 +137,7 @@ static int usb6fire_chip_probe(struct usb_interface *intf, chip->regidx = regidx; chip->intf_count = 1; chip->card = card; + card->private_free = usb6fire_card_free; ret = usb6fire_comm_init(chip); if (ret < 0) @@ -163,7 +164,7 @@ static int usb6fire_chip_probe(struct usb_interface *intf, return 0; destroy_chip: - usb6fire_chip_destroy(chip); + snd_card_free(card); return ret; } @@ -182,7 +183,6 @@ static void usb6fire_chip_disconnect(struct usb_interface *intf) chip->shutdown = true; usb6fire_chip_abort(chip); - usb6fire_chip_destroy(chip); } } } -- 2.22.0

2 1