CVE-2026-64046

What it actually does

This flaw is in the Linux kernel networking TLS implementation, commonly referred to as kTLS. Under a specific scatter-gather list layout, the kernel can construct an invalid chain-after-chain scatterlist entry while preparing plaintext data for TLS encryption. The scatterlist iterator does not recursively resolve consecutive chain links, so malformed internal input can be passed into the crypto layer. Depending on kernel version, configuration, crypto driver behavior, and memory layout, the result may range from a kernel warning or crash to memory corruption with potential confidentiality, integrity, and availability impact. The CVSS vector indicates unauthenticated network reachability with low attack complexity and no user interaction, but public exploit maturity is currently reported as none and EPSS is low.

Why it matters to the business

Successful exploitation could disrupt Linux systems that process TLS traffic using kernel TLS, potentially causing service crashes, host instability, or in the worst case compromise of kernel memory. Internet-facing TLS services, reverse proxies, load balancers, API gateways, storage services, and high-throughput applications that enable kTLS are the most relevant risk areas. Although this is not currently listed in CISA KEV and has no known ransomware association, the high severity and kernel-level impact warrant timely patching, especially for externally reachable systems and shared infrastructure where a kernel crash can affect many services.

How an attack unfolds

An attacker targets a Linux system running a vulnerable kernel where kTLS is enabled or used by an application. The attacker establishes or interacts with a TLS connection in a way that causes the kernel TLS send path to build a plaintext scatter-gather list with a wrap boundary condition where the end index is zero while the start index is nonzero. In the vulnerable code path, the kernel creates a chain link immediately followed by another chain link, which is invalid for the scatterlist API. When the TLS crypto path processes that structure, it may dereference or traverse the malformed list incorrectly, leading to a kernel fault, memory corruption, or other undefined behavior. Practical exploitability depends heavily on whether the target application uses kTLS, the configured TLS version and cipher paths, and the kernel crypto backend or hardware offload in use.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for the net/tls change described as preventing chain-after-chain entries in plaintext scatter-gather lists. If no exact package fixed version is provided by the vulnerability feed, track vendor advisories for the deployed distribution and update to the first kernel build that backports this fix. Reboot systems after installing the updated kernel, because kernel fixes are not effective until the patched kernel is running. Where immediate patching is not possible, reduce exposure by disabling kTLS use in applications, disabling TLS hardware/software offload features that rely on kTLS where feasible, avoiding application options that enable kernel TLS acceleration, restricting external access to affected TLS services, and applying rate limits or upstream filtering. If the TLS kernel module is loadable and not required, consider blacklisting or preventing loading of the kTLS module as a temporary mitigation, after confirming operational impact.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is a vendor-fixed build containing the net/tls scatterlist patch. Check vendor changelogs, package advisory metadata, or kernel source/backport notes for the fix text related to 'net: tls: prevent chain-after-chain in plain text SG'. Reboot after updating and verify with uname or package tooling that the active kernel matches the fixed build. Validate exposure by checking whether the kernel supports kTLS and whether applications enable it through TCP_ULP 'tls' or equivalent TLS acceleration options. In a staging environment, run representative TLS traffic through services that previously used kTLS and monitor for kernel warnings, oops messages, service resets, or crypto/scatterlist errors. Do not rely solely on package installation status; confirm the active booted kernel is patched.

Typical attack path

1. Identify a Linux-hosted TLS service or application likely to use kernel TLS, such as a high-throughput web server, proxy, storage service, or custom application using kTLS socket options.
2. Establish TLS connections to the service and send or trigger traffic patterns that exercise the kernel TLS plaintext send path.
3. Manipulate record sizing, buffering, or connection behavior so the vulnerable scatter-gather wrap condition is reached.
4. Cause the kernel to pass an invalid chain-after-chain scatterlist into the crypto layer.
5. Observe service interruption, kernel oops, host crash, or other signs of memory corruption; in a more advanced scenario, attempt to shape memory state for stronger exploitation.

How to detect it

To assess whether this was already exploited, review kernel logs, system journal, crash dumps, and uptime/reboot records for crashes or warnings involving kTLS, TLS socket handling, scatter-gather lists, or crypto operations. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel entries, netconsole logs, kdump/vmcore artifacts, hypervisor reset events, and application logs from TLS-facing services showing abrupt connection resets immediately before a host crash. Look for kernel stack traces containing net/tls functions such as tls_sw_sendmsg, tls_push_record, tls_do_encryption, tls_encrypt_sg, tls_device, or scatterlist traversal functions. Correlate these events with spikes in inbound TLS connections, unusual record sizes, repeated connection resets, or traffic from the same remote sources. Absence of logs does not prove absence of exploitation because kernel memory corruption may cause abrupt resets without persistent artifacts, especially if crash dumping or persistent journald storage is not enabled.

• tls_sw_sendmsg
• tls_push_record
• tls_do_encryption
• tls_encrypt_sg
• tls_device
• tls_sw
• scatterlist
• sg_next
• BUG: unable to handle kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• RIP: 0010:tls_
• RIP: 0010:sg_next
• TCP_ULP
• tls.ko
• /sys/module/tls
• /proc/modules

What your security team should do

• Prioritize patching externally reachable Linux systems that terminate or originate high-volume TLS traffic and may use kTLS.
• Inventory systems with kTLS support enabled, loaded TLS kernel modules, TLS offload, or applications configured for kernel TLS acceleration.
• Monitor vendor advisories for exact fixed kernel package versions for each Linux distribution in use, then roll out patched kernels with reboot coordination.
• Temporarily disable application-level kTLS acceleration or TLS offload where patching must be delayed.
• Add monitoring for kernel oops, panic, general protection fault, TLS kernel symbols, scatterlist errors, and unexplained reboots on TLS-facing systems.
• Treat repeated kernel crashes correlated with inbound TLS traffic as potentially suspicious, even without a public exploit.
• Because the issue is high severity despite low current EPSS and no KEV listing, schedule remediation based on exposure and use of kTLS rather than waiting for confirmed exploitation.