From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-64046: net: tls: prevent chain-after-chain in plain text SG
Date: Sun, 19 Jul 2026 17:38:28 +0200 [thread overview]
Message-ID: <2026071907-CVE-2026-64046-bfdc@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
net: tls: prevent chain-after-chain in plain text SG
Sashiko points out that if end = 0 (start != 0) the current
code will create a chain link to content type right after
the wrap link:
This would create a chain where the wrap link points directly
to another chain link. The scatterlist API sg_next iterator
does not recursively resolve consecutive chain links.
meaning this is illegal input to crypto.
The wrapping link is unnecessary if end = 0. end is the entry after
the last one used so end = 0 means there's nothing pushed after
the wrap:
end start i
v v v
[ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]
Skip the wrapping in this case.
TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0.
This avoids the chain-after-chain.
Move the wrap chaining before marking END and chaining off content
type, that feels like more logical ordering to me, but should not
matter from functional perspective.
The Linux kernel CVE team has assigned CVE-2026-64046 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 5.10.258 with commit 49a5faaa471ddcd37b6893970c9916eb836e7c31
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 5.15.209 with commit 91359966e247c0244c66d50bbb8e74aefa4321c3
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 6.1.175 with commit 410351158dfef2d67fea6603680b3a6013c6ed9d
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 6.6.142 with commit acdc12b71c9aa4be5dcd2c8062753c6d2033e235
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 6.12.92 with commit 929b1548e63ac72e104c07d8ee8cbbeeba2fa89a
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 6.18.34 with commit af855f4c966afafef74faf8390c7b86568c0d46d
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 7.0.11 with commit b9c015ef1a7bf1e8dc67f21c6381f36deb2c3a36
Issue introduced in 5.5 with commit 9aaaa56845a06aeabdd597cbe19492dc01f281ec and fixed in 7.1 with commit ff26a0e8377dec07e4a7230db7675bed1b9a6d03
Issue introduced in 5.4.14 with commit d529d6c9f7e3aaeac13c4948f79799ccb825f29d
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-64046
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/tls/tls_sw.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/49a5faaa471ddcd37b6893970c9916eb836e7c31
https://git.kernel.org/stable/c/91359966e247c0244c66d50bbb8e74aefa4321c3
https://git.kernel.org/stable/c/410351158dfef2d67fea6603680b3a6013c6ed9d
https://git.kernel.org/stable/c/acdc12b71c9aa4be5dcd2c8062753c6d2033e235
https://git.kernel.org/stable/c/929b1548e63ac72e104c07d8ee8cbbeeba2fa89a
https://git.kernel.org/stable/c/af855f4c966afafef74faf8390c7b86568c0d46d
https://git.kernel.org/stable/c/b9c015ef1a7bf1e8dc67f21c6381f36deb2c3a36
https://git.kernel.org/stable/c/ff26a0e8377dec07e4a7230db7675bed1b9a6d03
reply other threads:[~2026-07-19 15:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026071907-CVE-2026-64046-bfdc@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox