Memory safety / potential out-of-bounds access in TLS SK_MSG scatterlist wrapping during sg_chain
Description
The commit fixes an off-by-one in how the sg_chain length is computed when a sk_msg scatterlist ring wraps (end < start) in TLS SK_MSG handling. Previously, the code used MAX_SKB_FRAGS - start + 1 as the chain length and started chaining from data[start], which could place the chain pointer at data[MAX_SKB_FRAGS] − effectively an off-by-one that risks reading/writing beyond the intended sg array during the wrap scenario. The patch converts to ARRAY_SIZE(msg_pl->sg.data) for the chain length and removes the start-offset, ensuring the entire sg.data array is considered when wrapping. This addresses a subtle memory-safety vulnerability in the wrap path for TLS SK_MSG, preventing potential out-of-bounds access and related memory corruption or disclosure via the chained scatterlist structure.
Proof of Concept
High-level reproduction outline (no runnable code provided):
1) Build and install a kernel prior to the fix (matching v7.0-rc6 or earlier) that contains the vulnerable sg_chain usage in net/tls/tls_sw.c.
2) Create a TLS SK_MSG path that exercises the wrapped ring condition (sg.end < sg.start) for the sk_msg scatterlist. This can occur when a ring of TLS message fragments wraps around the end of the sg array and additional tail fragments need to be chained to the head.
3) Trigger tls_push_record() so that the code enters the wrapped-chain scenario. In the old code, the chain length is MAX_SKB_FRAGS - sg.start + 1 and chains from sg.data[sg.start], potentially placing the chain pointer at data[MAX_SKB_FRAGS], risking an out-of-bounds access during the join of the front and tail segments.
4) On affected kernels, this can produce memory corruption or a crash (kernel OOPs) under crafted conditions; observe a crash or memory-disclosure-like behavior when processing TLS records.
5) Apply the patched kernel (with ARRAY_SIZE(msg_pl->sg.data) and removal of the start-offset) and repeat step 2. The wrap-path now correctly consumes the entire sg.data array, eliminating the off-by-one and preventing the OOB access.
Notes:
- This PoC outline is high-level and requires careful setup of a controlled test environment (privileged access, exact kernel version, and TLS/skmsg usage that exercises sk_msg wrapping). The exact steps to reproduce can vary by kernel configuration and user-space TLS path (e.g., sockmap usage or TLS offload paths).
Commit Details
Author: Jakub Kicinski
Date: 2026-05-11 17:49 UTC
Message:
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).
Reported-by: 钱一铭 <yimingqian591@gmail.com>
Fixes: 9aaaa56845a0 ("bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://patch.msgid.link/20260511174920.433155-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Triage Assessment
Vulnerability Type: Memory safety issue
Confidence: HIGH
Reasoning:
The commit fixes an off-by-one in how a wrapped sk_msg sg_chain is constructed for TLS SK_MSG handling. Using an incorrect range could cause out-of-bounds access when chaining scatterlist entries, risking memory safety or potential information disclosure. The change switches to ARRAY_SIZE to guarantee correct bounds, addressing a subtle vulnerability in the ring-wrapping path.
Verification Assessment
Vulnerability Type: Memory safety / potential out-of-bounds access in TLS SK_MSG scatterlist wrapping during sg_chain
Confidence: HIGH
Affected Versions: <= v7.0-rc6 (all versions prior to the fix in commit 285943c6e7ca309bbea84b253745154241d9788a).
Code Diff
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 2590e855f6a5a9..2608b0c01849f0 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -800,11 +800,9 @@ static int tls_push_record(struct sock *sk, int flags,
sg_mark_end(sk_msg_elem(msg_pl, i));
}
- if (msg_pl->sg.end < msg_pl->sg.start) {
- sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
- MAX_SKB_FRAGS - msg_pl->sg.start + 1,
+ if (msg_pl->sg.end < msg_pl->sg.start)
+ sg_chain(msg_pl->sg.data, ARRAY_SIZE(msg_pl->sg.data),
msg_pl->sg.data);
- }
i = msg_pl->sg.start;
sg_chain(rec->sg_aead_in, 2, &msg_pl->sg.data[i]);