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).
OS | Version | Architecture | Package | Version | Filename |
---|---|---|---|---|---|
ubuntu | 18.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 20.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 22.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 23.10 | noarch | linux | < any | UNKNOWN |
ubuntu | 24.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 14.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 16.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 18.04 | noarch | linux-aws | < any | UNKNOWN |
ubuntu | 20.04 | noarch | linux-aws | < any | UNKNOWN |
ubuntu | 22.04 | noarch | linux-aws | < any | UNKNOWN |
git.kernel.org/linus/ad5185735f7dab342fdd0dd41044da4c9ccfef67 (5.17-rc3)
git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e
git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67
launchpad.net/bugs/cve/CVE-2022-48744
nvd.nist.gov/vuln/detail/CVE-2022-48744
security-tracker.debian.org/tracker/CVE-2022-48744
www.cve.org/CVERecord?id=CVE-2022-48744