- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
by Liu Jian 09 Sep '24

09 Sep '24

From: Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> stable inclusion from stable-v5.10.224 commit b7b8d9f5e679af60c94251fd6728dde34be69a71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXYL CVE: CVE-2024-44971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit e3862093ee93fcfbdadcb7957f5f8974fffa806a ] bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak. This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount. Fixes: 771089c2a485 ("net: dsa: bcm_sf2: Ensure that MDIO diversion is used") Signed-off-by: Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> Tested-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Link: https://patch.msgid.link/20240806011327.3817861-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/dsa/bcm_sf2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c index a5849663f65c..d0f94a5fae5a 100644 --- a/drivers/net/dsa/bcm_sf2.c +++ b/drivers/net/dsa/bcm_sf2.c @@ -558,8 +558,10 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds) of_remove_property(child, prop); phydev = of_phy_find_device(child); - if (phydev) + if (phydev) { phy_device_remove(phydev); + phy_device_free(phydev); + } } err = mdiobus_register(priv->slave_mii_bus); -- 2.34.1

2 1

[PATCH OLK-5.10] mptcp: pm: avoid possible UaF when selecting endp
by Liu Jian 09 Sep '24

09 Sep '24

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> mainline inclusion from mainline-v6.11-rc5 commit 48e50dcbcbaaf713d82bf2da5c16aeced94ad07d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOY17 CVE: CVE-2024-44974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with. Reported-by: Paolo Abeni <pabeni(a)redhat.com> Closes: https://lore.kernel.org/45cd30d3-7710-491c-ae4d-a1368c00beb1@redhat.com Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-14-38035d40de5… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/mptcp/pm_netlink.c [Did not backport 90d930882139 ("mptcp: constify a bunch of of helpers"), 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set"), 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk").] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/mptcp/pm_netlink.c | 44 ++++++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 0d6f3d912891..824420c4e8f9 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -128,11 +128,13 @@ static bool lookup_subflow_by_saddr(const struct list_head *list, return false; } -static struct mptcp_pm_addr_entry * +static bool select_local_address(const struct pm_nl_pernet *pernet, - struct mptcp_sock *msk) + struct mptcp_sock *msk, + struct mptcp_pm_addr_entry *new_entry) { - struct mptcp_pm_addr_entry *entry, *ret = NULL; + struct mptcp_pm_addr_entry *entry; + bool found = false; rcu_read_lock(); spin_lock_bh(&msk->join_list_lock); @@ -146,19 +148,23 @@ select_local_address(const struct pm_nl_pernet *pernet, if (entry->addr.family == ((struct sock *)msk)->sk_family && !lookup_subflow_by_saddr(&msk->conn_list, &entry->addr) && !lookup_subflow_by_saddr(&msk->join_list, &entry->addr)) { - ret = entry; + *new_entry = *entry; + found = true; break; } } spin_unlock_bh(&msk->join_list_lock); rcu_read_unlock(); - return ret; + + return found; } -static struct mptcp_pm_addr_entry * -select_signal_address(struct pm_nl_pernet *pernet, unsigned int pos) +static bool +select_signal_address(struct pm_nl_pernet *pernet, unsigned int pos, + struct mptcp_pm_addr_entry *new_entry) { - struct mptcp_pm_addr_entry *entry, *ret = NULL; + struct mptcp_pm_addr_entry *entry; + bool found = false; int i = 0; rcu_read_lock(); @@ -171,12 +177,14 @@ select_signal_address(struct pm_nl_pernet *pernet, unsigned int pos) if (!(entry->addr.flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) continue; if (i++ == pos) { - ret = entry; + *new_entry = *entry; + found = true; break; } } rcu_read_unlock(); - return ret; + + return found; } static void check_work_pending(struct mptcp_sock *msk) @@ -306,7 +314,7 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) { struct mptcp_addr_info remote = { 0 }; struct sock *sk = (struct sock *)msk; - struct mptcp_pm_addr_entry *local; + struct mptcp_pm_addr_entry local; struct pm_nl_pernet *pernet; pernet = net_generic(sock_net((struct sock *)msk), pm_nl_pernet_id); @@ -318,13 +326,12 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) /* check first for announce */ if (msk->pm.add_addr_signaled < msk->pm.add_addr_signal_max) { - local = select_signal_address(pernet, - msk->pm.add_addr_signaled); - if (local) { - if (mptcp_pm_alloc_anno_list(msk, local)) { + if (select_signal_address(pernet, + msk->pm.add_addr_signaled, &local)) { + if (mptcp_pm_alloc_anno_list(msk, &local)) { msk->pm.add_addr_signaled++; - mptcp_pm_announce_addr(msk, &local->addr, false); + mptcp_pm_announce_addr(msk, &local.addr, false); } } else { /* pick failed, avoid fourther attempts later */ @@ -339,13 +346,12 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) msk->pm.subflows < msk->pm.subflows_max) { remote_address((struct sock_common *)sk, &remote); - local = select_local_address(pernet, msk); - if (local) { + if (select_local_address(pernet, msk, &local)) { msk->pm.local_addr_used++; msk->pm.subflows++; check_work_pending(msk); spin_unlock_bh(&msk->pm.lock); - __mptcp_subflow_connect(sk, &local->addr, &remote); + __mptcp_subflow_connect(sk, &local.addr, &remote); spin_lock_bh(&msk->pm.lock); return; } -- 2.34.1

2 1

[PATCH OLK-6.6] bnxt_en: Fix double DMA unmapping for XDP_REDIRECT
by Liu Jian 09 Sep '24

09 Sep '24

From: Somnath Kotur <somnath.kotur(a)broadcom.com> stable inclusion from stable-v6.6.48 commit fa4e6ae38574d0fc5596272bee64727d8ab7052b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXZU CVE: CVE-2024-44984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit 8baeef7616d5194045c5a6b97fd1246b87c55b13 ] Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 Fixes: 578fcfd26e2a ("bnxt_en: Let the page pool manage the DMA mapping") Reviewed-by: Andy Gospodarek <andrew.gospodarek(a)broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil(a)broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur(a)broadcom.com> Signed-off-by: Michael Chan <michael.chan(a)broadcom.com> Reviewed-by: Jacob Keller <jacob.e.keller(a)intel.com> Link: https://patch.msgid.link/20240820203415.168178-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c index 8cb9a99154aa..2845796f782c 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c @@ -297,11 +297,6 @@ bool bnxt_rx_xdp(struct bnxt *bp, struct bnxt_rx_ring_info *rxr, u16 cons, * redirect is coming from a frame received by the * bnxt_en driver. */ - rx_buf = &rxr->rx_buf_ring[cons]; - mapping = rx_buf->mapping - bp->rx_dma_offset; - dma_unmap_page_attrs(&pdev->dev, mapping, - BNXT_RX_PAGE_SIZE, bp->rx_dir, - DMA_ATTR_WEAK_ORDERING); /* if we are unable to allocate a new buffer, abort and reuse */ if (bnxt_alloc_rx_data(bp, rxr, rxr->rx_prod, GFP_ATOMIC)) { -- 2.34.1

2 1

[PATCH OLK-6.6] mptcp: pm: avoid possible UaF when selecting endp
by Liu Jian 09 Sep '24

09 Sep '24

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> stable inclusion from stable-v6.6.48 commit 9a9afbbc3fbfca4975eea4aa5b18556db5a0c0b8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOY17 CVE: CVE-2024-44974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- commit 48e50dcbcbaaf713d82bf2da5c16aeced94ad07d upstream. select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with. Reported-by: Paolo Abeni <pabeni(a)redhat.com> Closes: https://lore.kernel.org/45cd30d3-7710-491c-ae4d-a1368c00beb1@redhat.com Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-14-38035d40de5… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/mptcp/pm_netlink.c | 64 ++++++++++++++++++++++-------------------- 1 file changed, 34 insertions(+), 30 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index b81fa77ce054..aa56696cdc78 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -148,11 +148,13 @@ static bool lookup_subflow_by_daddr(const struct list_head *list, return false; } -static struct mptcp_pm_addr_entry * +static bool select_local_address(const struct pm_nl_pernet *pernet, - const struct mptcp_sock *msk) + const struct mptcp_sock *msk, + struct mptcp_pm_addr_entry *new_entry) { - struct mptcp_pm_addr_entry *entry, *ret = NULL; + struct mptcp_pm_addr_entry *entry; + bool found = false; msk_owned_by_me(msk); @@ -164,17 +166,21 @@ select_local_address(const struct pm_nl_pernet *pernet, if (!test_bit(entry->addr.id, msk->pm.id_avail_bitmap)) continue; - ret = entry; + *new_entry = *entry; + found = true; break; } rcu_read_unlock(); - return ret; + + return found; } -static struct mptcp_pm_addr_entry * -select_signal_address(struct pm_nl_pernet *pernet, const struct mptcp_sock *msk) +static bool +select_signal_address(struct pm_nl_pernet *pernet, const struct mptcp_sock *msk, + struct mptcp_pm_addr_entry *new_entry) { - struct mptcp_pm_addr_entry *entry, *ret = NULL; + struct mptcp_pm_addr_entry *entry; + bool found = false; rcu_read_lock(); /* do not keep any additional per socket state, just signal @@ -189,11 +195,13 @@ select_signal_address(struct pm_nl_pernet *pernet, const struct mptcp_sock *msk) if (!(entry->flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) continue; - ret = entry; + *new_entry = *entry; + found = true; break; } rcu_read_unlock(); - return ret; + + return found; } unsigned int mptcp_pm_get_add_addr_signal_max(const struct mptcp_sock *msk) @@ -520,9 +528,10 @@ __lookup_addr(struct pm_nl_pernet *pernet, const struct mptcp_addr_info *info, static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) { - struct mptcp_pm_addr_entry *local, *signal_and_subflow = NULL; struct sock *sk = (struct sock *)msk; + struct mptcp_pm_addr_entry local; unsigned int add_addr_signal_max; + bool signal_and_subflow = false; unsigned int local_addr_max; struct pm_nl_pernet *pernet; unsigned int subflows_max; @@ -573,23 +582,22 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) if (msk->pm.addr_signal & BIT(MPTCP_ADD_ADDR_SIGNAL)) return; - local = select_signal_address(pernet, msk); - if (!local) + if (!select_signal_address(pernet, msk, &local)) goto subflow; /* If the alloc fails, we are on memory pressure, not worth * continuing, and trying to create subflows. */ - if (!mptcp_pm_alloc_anno_list(msk, &local->addr)) + if (!mptcp_pm_alloc_anno_list(msk, &local.addr)) return; - __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); + __clear_bit(local.addr.id, msk->pm.id_avail_bitmap); msk->pm.add_addr_signaled++; - mptcp_pm_announce_addr(msk, &local->addr, false); + mptcp_pm_announce_addr(msk, &local.addr, false); mptcp_pm_nl_addr_send_ack(msk); - if (local->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) - signal_and_subflow = local; + if (local.flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) + signal_and_subflow = true; } subflow: @@ -600,26 +608,22 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) bool fullmesh; int i, nr; - if (signal_and_subflow) { - local = signal_and_subflow; - signal_and_subflow = NULL; - } else { - local = select_local_address(pernet, msk); - if (!local) - break; - } + if (signal_and_subflow) + signal_and_subflow = false; + else if (!select_local_address(pernet, msk, &local)) + break; - fullmesh = !!(local->flags & MPTCP_PM_ADDR_FLAG_FULLMESH); + fullmesh = !!(local.flags & MPTCP_PM_ADDR_FLAG_FULLMESH); msk->pm.local_addr_used++; - __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); - nr = fill_remote_addresses_vec(msk, &local->addr, fullmesh, addrs); + __clear_bit(local.addr.id, msk->pm.id_avail_bitmap); + nr = fill_remote_addresses_vec(msk, &local.addr, fullmesh, addrs); if (nr == 0) continue; spin_unlock_bh(&msk->pm.lock); for (i = 0; i < nr; i++) - __mptcp_subflow_connect(sk, &local->addr, &addrs[i]); + __mptcp_subflow_connect(sk, &local.addr, &addrs[i]); spin_lock_bh(&msk->pm.lock); } mptcp_pm_nl_check_work_pending(msk); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] usb: gadget: core: Check for unset descriptor
by Ye Bin 09 Sep '24

09 Sep '24

From: Chris Wulff <crwulff(a)gmail.com> mainline inclusion from mainline-v6.11-rc3 commit 973a57891608a98e894db2887f278777f564de18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXZ1 CVE: CVE-2024-44960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Wulff <crwulff(a)gmail.com> Link: https://lore.kernel.org/r/20240725010419.314430-2-crwulff@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/usb/gadget/udc/core.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index b45dd7827ff9..1335a715f5dd 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -99,12 +99,10 @@ int usb_ep_enable(struct usb_ep *ep) goto out; /* UDC drivers can't handle endpoints with maxpacket size 0 */ - if (usb_endpoint_maxp(ep->desc) == 0) { - /* - * We should log an error message here, but we can't call - * dev_err() because there's no way to find the gadget - * given only ep. - */ + if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) { + WARN_ONCE(1, "%s: ep%d (%s) has %s\n", __func__, ep->address, ep->name, + (!ep->desc) ? "NULL descriptor" : "maxpacket 0"); + ret = -EINVAL; goto out; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] usb: gadget: core: Check for unset descriptor
by Ye Bin 09 Sep '24

09 Sep '24

From: Chris Wulff <crwulff(a)gmail.com> mainline inclusion from mainline-v6.11-rc3 commit 973a57891608a98e894db2887f278777f564de18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXZ1 CVE: CVE-2024-44960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Wulff <crwulff(a)gmail.com> Link: https://lore.kernel.org/r/20240725010419.314430-2-crwulff@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/usb/gadget/udc/core.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index 7330c1999104..77ee0dbc52c5 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -99,12 +99,10 @@ int usb_ep_enable(struct usb_ep *ep) goto out; /* UDC drivers can't handle endpoints with maxpacket size 0 */ - if (usb_endpoint_maxp(ep->desc) == 0) { - /* - * We should log an error message here, but we can't call - * dev_err() because there's no way to find the gadget - * given only ep. - */ + if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) { + WARN_ONCE(1, "%s: ep%d (%s) has %s\n", __func__, ep->address, ep->name, + (!ep->desc) ? "NULL descriptor" : "maxpacket 0"); + ret = -EINVAL; goto out; } -- 2.34.1

2 1

[PATCH OLK-5.10] usb: gadget: core: Check for unset descriptor
by Ye Bin 09 Sep '24

09 Sep '24

From: Chris Wulff <crwulff(a)gmail.com> mainline inclusion from mainline-v6.11-rc3 commit 973a57891608a98e894db2887f278777f564de18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXZ1 CVE: CVE-2024-44960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Wulff <crwulff(a)gmail.com> Link: https://lore.kernel.org/r/20240725010419.314430-2-crwulff@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/usb/gadget/udc/core.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index e80aa717c8b5..dd2fafc5b0c3 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -99,12 +99,10 @@ int usb_ep_enable(struct usb_ep *ep) goto out; /* UDC drivers can't handle endpoints with maxpacket size 0 */ - if (usb_endpoint_maxp(ep->desc) == 0) { - /* - * We should log an error message here, but we can't call - * dev_err() because there's no way to find the gadget - * given only ep. - */ + if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) { + WARN_ONCE(1, "%s: ep%d (%s) has %s\n", __func__, ep->address, ep->name, + (!ep->desc) ? "NULL descriptor" : "maxpacket 0"); + ret = -EINVAL; goto out; } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 14696/23701] drivers/base/node.c:429:5: sparse: sparse: symbol 'register_mem_block_under_node_early' was not declared. Should it be static?
by kernel test robot 07 Sep '24

07 Sep '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 13b424f97ef548612c760cfd0892f96de96707e0 commit: f38a43c2e1f2214acbda5d46af4518aa1d9d5e92 [14696/23701] mm: don't rely on system state to detect hot-plug operations config: x86_64-randconfig-123-20240906 (https://download.01.org/0day-ci/archive/20240907/202409072051.qFE23qXy-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240907/202409072051.qFE23qXy-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202409072051.qFE23qXy-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/base/node.c:429:5: sparse: sparse: symbol 'register_mem_block_under_node_early' was not declared. Should it be static? drivers/base/node.c:429:5: warning: no previous prototype for 'register_mem_block_under_node_early' [-Wmissing-prototypes] 429 | int register_mem_block_under_node_early(struct memory_block *mem_blk, void *arg) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vim +/register_mem_block_under_node_early +429 drivers/base/node.c 427 428 /* register memory section under specified node if it spans that node */ > 429 int register_mem_block_under_node_early(struct memory_block *mem_blk, void *arg) 430 { 431 int nid = *(int *)arg; 432 unsigned long pfn, sect_start_pfn, sect_end_pfn; 433 434 sect_start_pfn = section_nr_to_pfn(mem_blk->start_section_nr); 435 sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr); 436 sect_end_pfn += PAGES_PER_SECTION - 1; 437 for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) { 438 int page_nid; 439 440 /* 441 * memory block could have several absent sections from start. 442 * skip pfn range from absent section 443 */ 444 if (!pfn_present(pfn)) { 445 pfn = round_down(pfn + PAGES_PER_SECTION, 446 PAGES_PER_SECTION) - 1; 447 continue; 448 } 449 450 /* 451 * We need to check if page belongs to nid only at the boot 452 * case because node's ranges can be interleaved. 453 */ 454 page_nid = get_nid_for_pfn(pfn); 455 if (page_nid < 0) 456 continue; 457 if (page_nid != nid) 458 continue; 459 460 return do_register_memory_block_under_node(nid, mem_blk); 461 } 462 /* mem section does not span the specified node */ 463 return 0; 464 } 465 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 7679/30000] kernel/locking/lockdep.o: warning: objtool: lockdep_unregister_key()+0x30b: unreachable instruction
by kernel test robot 07 Sep '24

07 Sep '24

Hi Waiman, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c431540f5e2720652e293713c7358952cd0148de commit: b91170be2b1f1ef673f5e79c7a4beb5673a8f881 [7679/30000] locking/lockdep: Avoid potential access of invalid memory in lock_class config: x86_64-randconfig-073-20240907 (https://download.01.org/0day-ci/archive/20240907/202409071717.JoTK5KQp-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240907/202409071717.JoTK5KQp-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202409071717.JoTK5KQp-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/locking/lockdep.o: warning: objtool: lockdep_unregister_key()+0x30b: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 v2 0/2] CVE-2024-44972
by Yifan Qiao 07 Sep '24

07 Sep '24

Change Log: v2: Add CVE number inside the commit msg. Naohiro Aota (1): btrfs: fix invalid mapping of extent xarray state Qu Wenruo (1): btrfs: do not clear page dirty inside extent_write_locked_range() fs/btrfs/extent_io.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) -- 2.39.2

2 3