CVE-2026-64047: net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring

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

net: tls: fix off-by-one in sgchain entry count for wrapped skmsg ring

When an skmsg scatterlist ring wraps (sg.end < sg.start), tlspushrecord() chains the tail portion of the ring to the head using sgchain(). An extra entry in the sg array is reserved for this:

struct skmsgsg { [...] / The extra two elements: 1) used for chaining the front and sections when the list becomes partitioned (e.g. end < start). The crypto APIs require the chaining; 2) to chain tailer SG entries after the message. / struct scatterlist data[MAXMSGFRAGS + 2];

The current code uses MAXSKBFRAGS + 1 as the ring size:

sgchain(&msgpl->sg.data[msgpl->sg.start], MAXSKBFRAGS - msgpl->sg.start + 1, msgpl->sg.data);

This places the chain pointer at

sgchain(data[start], (MAXSKBFRAGS - msgstart + 1) .. = &data[start] + (MAXSKBFRAGS - msgstart + 1) - 1 = data[start + (MAXSKBFRAGS - start + 1) - 1] = data[MAXSKBFRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: skmsg, zap ingress queue on psock down")

Convert to ARRAYSIZE and drop the data[start] / - start (as suggested by Sabrina).