CVE-2026-64047

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 sk_msg scatterlist ring wraps (sg.end < sg.start),

tlspushrecord() 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 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[msg_pl->sg.start],

             MAXSKBFRAGS - msg_pl->sg.start + 1,

             msg_pl->sg.data);

This places the chain pointer at

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

  &data[start] + (MAXSKBFRAGS - msg_start + 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: sk_msg, zap ingress queue on psock down")

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

by Sabrina).