CVE-2022-48744: net/mlx5e: Avoid field-overflowing memcpy()

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Avoid field-overflowing memcpy()

In preparation for FORTIFYSOURCE 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 ETHHLEN 14 #define VLANHLEN 4 ... #define MLX5EXDPMININLINE (ETHHLEN + VLANHLEN) ... struct mlx5etxwqe wqe = mlx5wqcycgetwqe(wq, pi); ... struct mlx5wqeethseg eseg = &wqe->eth; struct mlx5wqedataseg dseg = wqe->data; ... memcpy(eseg->inlinehdr.start, xdptxd->data, MLX5EXDPMININLINE);

target is wqe->eth.inlinehdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlantci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering bytecount (4 bytes), lkey (4 bytes), and addr (8 bytes).

struct mlx5etxwqe { struct mlx5wqectrlseg ctrl; / 0 16 / struct mlx5wqeethseg eth; / 16 16 / struct mlx5wqedataseg data[]; / 32 0 /

/ size: 32, cachelines: 1, members: 3 / / last cacheline: 32 bytes / };

struct mlx5wqeethseg { u8 swpouterl4offset; / 0 1 / u8 swpouterl3offset; / 1 1 / u8 swpinnerl4offset; / 2 1 / u8 swpinnerl3offset; / 3 1 / u8 csflags; / 4 1 / u8 swpflags; / 5 1 / be16 mss; / 6 2 / be32 flowtablemetadata; / 8 4 / union { struct { be16 sz; / 12 2 / u8 start[2]; / 14 2 / } inlinehdr; / 12 4 / struct { be16 type; / 12 2 / be16 vlantci; / 14 2 / } insert; / 12 4 / be32 trailer; / 12 4 / }; / 12 4 /

/ size: 16, cachelines: 1, members: 9 / / last cacheline: 16 bytes / };

struct mlx5wqedataseg { be32 bytecount; / 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 mlx5etxwqe nor struct mlx5eumrwqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations).