From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 120671AB367 for ; Thu, 20 Jun 2024 11:17:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718882252; cv=none; b=o991iOdfZyGSAQJ/W0MonEPVOb9i4/QKh2gzOwY3OCeaKbVVILmiUBUEH5pePwOJ7OdhQ963tcV0ucC4o/QaEwKch0TCqNcM3nQPV+YYGiOLMiQ380X2oh4H3u8TgVUjsqZjYj/StZLXL+o4GeBXTX1sxE371PLlFrSxiv8R0Hs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718882252; c=relaxed/simple; bh=2c0lKkJrR26youQynzMaVqy8nH+kWX1/BuwPDg0b5DA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=MDPUXB2Y3v+bzjs8rauO41XHUzkpiMCoucDp2lbX/Hkph1PlE+xTrZ6DSAzUEHizfjICwxHAxYa9Juecfj6L3shOXyEv23ThVtZDhJH/J6vrfWtGszpHM3SrNoeieDMidflTZrUmhSsqLIqIIrBHumwMIvlr/Ae2+/ixMe3Cj+I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ZlMreld5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ZlMreld5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CFFBC2BD10; Thu, 20 Jun 2024 11:17:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1718882251; bh=2c0lKkJrR26youQynzMaVqy8nH+kWX1/BuwPDg0b5DA=; h=From:To:Cc:Subject:Date:Reply-to:From; b=ZlMreld56Y9yvq5AOUAnxXYmNJa+4uZcJVwdxCZJJ4HDlWtQog8I5+/vxdPPvPYoa cz1yUluw2+u5U7dWqwyY5ZnsSyUAFDfuMOLNSgQSvy/FLOUs7Yd53+Ffqus9d0UlzF DMGrKjLIskvvKe+CVlHJ9MvqR+CAXg+Ryh670k0s= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2022-48744: net/mlx5e: Avoid field-overflowing memcpy() Date: Thu, 20 Jun 2024 13:16:24 +0200 Message-ID: <2024062003-CVE-2022-48744-0f03@gregkh> X-Mailer: git-send-email 2.45.2 Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-to: , X-Developer-Signature: v=1; a=openpgp-sha256; l=5211; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=2c0lKkJrR26youQynzMaVqy8nH+kWX1/BuwPDg0b5DA=; b=owGbwMvMwCRo6H6F97bub03G02pJDGkl/MUTtgg7Fu+f8ijh151D19ZMOfje79/jfRl/EyX4F jrtW3X7SUcsC4MgE4OsmCLLl208R/dXHFL0MrQ9DTOHlQlkCAMXpwBMJLSLYb5v4p1El/d/xJJf TWMz+MqWV8kqYsywYOofj97un/VvVR4ldcRlsL/+byPpBgA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit Description =========== In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). The Linux kernel CVE team has assigned CVE-2022-48744 to this issue. Affected and fixed versions =========================== Issue introduced in 4.9 with commit b5503b994ed5 and fixed in 5.16.6 with commit 8fbdf8c8b8ab Issue introduced in 4.9 with commit b5503b994ed5 and fixed in 5.17 with commit ad5185735f7d Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2022-48744 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/net/ethernet/mellanox/mlx5/core/en.h drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67