ghsa-932h-84vw-p6cw
Vulnerability from github
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).
{
"affected": [],
"aliases": [
"CVE-2022-48744"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:12Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid field-overflowing memcpy()\n\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\n\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\n\nWe were doing:\n\n\t#define ETH_HLEN 14\n\t#define VLAN_HLEN 4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n struct mlx5_wqe_eth_seg *eseg = \u0026wqe-\u003eeth;\n struct mlx5_wqe_data_seg *dseg = wqe-\u003edata;\n\t...\n\tmemcpy(eseg-\u003einline_hdr.start, xdptxd-\u003edata, MLX5E_XDP_MIN_INLINE);\n\ntarget is wqe-\u003eeth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe-\u003edata[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\n\nstruct mlx5e_tx_wqe {\n struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */\n struct mlx5_wqe_eth_seg eth; /* 16 16 */\n struct mlx5_wqe_data_seg data[]; /* 32 0 */\n\n /* size: 32, cachelines: 1, members: 3 */\n /* last cacheline: 32 bytes */\n};\n\nstruct mlx5_wqe_eth_seg {\n u8 swp_outer_l4_offset; /* 0 1 */\n u8 swp_outer_l3_offset; /* 1 1 */\n u8 swp_inner_l4_offset; /* 2 1 */\n u8 swp_inner_l3_offset; /* 3 1 */\n u8 cs_flags; /* 4 1 */\n u8 swp_flags; /* 5 1 */\n __be16 mss; /* 6 2 */\n __be32 flow_table_metadata; /* 8 4 */\n union {\n struct {\n __be16 sz; /* 12 2 */\n u8 start[2]; /* 14 2 */\n } inline_hdr; /* 12 4 */\n struct {\n __be16 type; /* 12 2 */\n __be16 vlan_tci; /* 14 2 */\n } insert; /* 12 4 */\n __be32 trailer; /* 12 4 */\n }; /* 12 4 */\n\n /* size: 16, cachelines: 1, members: 9 */\n /* last cacheline: 16 bytes */\n};\n\nstruct mlx5_wqe_data_seg {\n __be32 byte_count; /* 0 4 */\n __be32 lkey; /* 4 4 */\n __be64 addr; /* 8 8 */\n\n /* size: 16, cachelines: 1, members: 3 */\n /* last cacheline: 16 bytes */\n};\n\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\n\n\"pahole\" shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \"objdump -d\" shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).",
"id": "GHSA-932h-84vw-p6cw",
"modified": "2024-06-20T12:31:21Z",
"published": "2024-06-20T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48744"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.