CVE-2026-64047

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

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

When an sk_msg scatterlist ring wraps (sg.end < sg.start),

tls_push_record() chains the tail portion of the ring to the head

using sg_chain(). An extra entry in the sg array is reserved for

this:

struct sk_msg_sg {

[...]

/* 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[MAX_MSG_FRAGS + 2];

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

sg_chain(&msg_pl->sg.data[msg_pl->sg.start],

MAX_SKB_FRAGS - msg_pl->sg.start + 1,

msg_pl->sg.data);

This places the chain pointer at

sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =

&data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =

data[start + (MAX_SKB_FRAGS - start + 1) - 1] =

data[MAX_SKB_FRAGS]

instead of the true last entry. This is likely due to a "race" of

the commit under Fixes landing close to

commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")

Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested

by Sabrina).