CVE-2022-48744

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Avoid field-overflowing memcpy()<br /> <br /> In preparation for FORTIFY_SOURCE performing compile-time and run-time<br /> field bounds checking for memcpy(), memmove(), and memset(), avoid<br /> intentionally writing across neighboring fields.<br /> <br /> Use flexible arrays instead of zero-element arrays (which look like they<br /> are always overflowing) and split the cross-field memcpy() into two halves<br /> that can be appropriately bounds-checked by the compiler.<br /> <br /> We were doing:<br /> <br /> #define ETH_HLEN 14<br /> #define VLAN_HLEN 4<br /> ...<br /> #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)<br /> ...<br /> struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);<br /> ...<br /> struct mlx5_wqe_eth_seg *eseg = &amp;wqe-&gt;eth;<br /> struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;<br /> ...<br /> memcpy(eseg-&gt;inline_hdr.start, xdptxd-&gt;data, MLX5E_XDP_MIN_INLINE);<br /> <br /> target is wqe-&gt;eth.inline_hdr.start (which the compiler sees as being<br /> 2 bytes in size), but copying 18, intending to write across start<br /> (really vlan_tci, 2 bytes). The remaining 16 bytes get written into<br /> wqe-&gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr<br /> (8 bytes).<br /> <br /> struct mlx5e_tx_wqe {<br /> struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */<br /> struct mlx5_wqe_eth_seg eth; /* 16 16 */<br /> struct mlx5_wqe_data_seg data[]; /* 32 0 */<br /> <br /> /* size: 32, cachelines: 1, members: 3 */<br /> /* last cacheline: 32 bytes */<br /> };<br /> <br /> struct mlx5_wqe_eth_seg {<br /> u8 swp_outer_l4_offset; /* 0 1 */<br /> u8 swp_outer_l3_offset; /* 1 1 */<br /> u8 swp_inner_l4_offset; /* 2 1 */<br /> u8 swp_inner_l3_offset; /* 3 1 */<br /> u8 cs_flags; /* 4 1 */<br /> u8 swp_flags; /* 5 1 */<br /> __be16 mss; /* 6 2 */<br /> __be32 flow_table_metadata; /* 8 4 */<br /> union {<br /> struct {<br /> __be16 sz; /* 12 2 */<br /> u8 start[2]; /* 14 2 */<br /> } inline_hdr; /* 12 4 */<br /> struct {<br /> __be16 type; /* 12 2 */<br /> __be16 vlan_tci; /* 14 2 */<br /> } insert; /* 12 4 */<br /> __be32 trailer; /* 12 4 */<br /> }; /* 12 4 */<br /> <br /> /* size: 16, cachelines: 1, members: 9 */<br /> /* last cacheline: 16 bytes */<br /> };<br /> <br /> struct mlx5_wqe_data_seg {<br /> __be32 byte_count; /* 0 4 */<br /> __be32 lkey; /* 4 4 */<br /> __be64 addr; /* 8 8 */<br /> <br /> /* size: 16, cachelines: 1, members: 3 */<br /> /* last cacheline: 16 bytes */<br /> };<br /> <br /> So, split the memcpy() so the compiler can reason about the buffer<br /> sizes.<br /> <br /> "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe<br /> nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object<br /> code changes (i.e. only source line number induced differences and<br /> optimizations).