CVE-2026-64047

What it actually does

This Linux kernel flaw is an off-by-one error in the Kernel TLS (kTLS) networking path when handling a wrapped sk_msg scatter-gather ring. Under specific TLS send conditions, tls_push_record() can place a scatterlist chain pointer at the wrong array entry when the ring wraps, corrupting scatterlist metadata used by the crypto/networking stack. Because this occurs in kernel context and is reachable through network/TLS data handling, the impact can include kernel memory corruption, denial of service through kernel crash, and potentially arbitrary code execution depending on kernel configuration, allocator state, and exploitability constraints.

Why it matters to the business

Systems using affected Linux kernels may be exposed to a high-impact kernel memory corruption condition in the networking stack. A successful attack could disrupt services, crash hosts, or potentially allow deeper system compromise. Although this issue is not currently listed in CISA KEV, has no known mature public exploit in the provided data, and has a low EPSS score, the CVSS severity is critical and the flaw affects a privileged kernel code path, so internet-facing or TLS-heavy Linux services should prioritize kernel updates during the next urgent maintenance window.

How an attack unfolds

An attacker would target a Linux system running an affected kernel with Kernel TLS functionality present. The attacker would need to cause the kernel TLS send path to process an sk_msg scatter-gather list where the ring has wrapped, meaning the end index is lower than the start index. In that wrapped state, tls_push_record() incorrectly calculates the number of scatterlist entries passed to sg_chain(), placing the chain marker one entry too early or at the wrong reserved slot. Repeatedly triggering this condition may corrupt adjacent scatterlist state used by the kernel crypto APIs. In the simplest case this can produce a kernel warning, fault, panic, or service outage. With additional exploit engineering, an attacker may attempt to shape memory layout and turn the corruption into control over kernel memory, potentially leading to code execution or privilege escalation. No known exploitation campaigns or named threat actors were provided for this CVE.

How to fix it

Apply a Linux kernel update that includes the fix for the kTLS sg_chain off-by-one calculation. Because no affected product list or exact fixed package versions were provided, use the fixed kernel releases supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. Reboot systems after installing the fixed kernel and confirm they are running the updated kernel, not merely that the package is installed. Where immediate patching is not possible, reduce exposure by disabling or avoiding Kernel TLS features if operationally feasible, limiting access to TLS services on affected hosts, placing vulnerable systems behind trusted load balancers or reverse proxies, and increasing monitoring for kernel faults in TLS/networking paths. Mitigations should be treated as temporary because the issue is in kernel memory handling.

How to confirm the fix worked

Confirm remediation by verifying that each system is booted into a kernel build that contains the upstream fix for the net/tls sg_chain wrapped sk_msg ring issue. Use distribution advisories and package changelogs to map the CVE to fixed kernel package versions, then validate with commands such as `uname -a`, package manager kernel inventory, and reboot status checks. Review whether kTLS is available or in use by checking kernel configuration, loaded modules, and application behavior where applicable. For exposure validation, identify systems running affected kernel versions and providing TLS-enabled network services, especially high-throughput services that may exercise send-path scatter-gather handling. For fix validation in test environments, run TLS networking regression tests or kTLS workloads and confirm there are no kernel warnings, panics, KASAN reports, or faults referencing `tls_push_record`, `sg_chain`, `sk_msg`, or scatterlist handling.

Typical attack path

1. Identify Linux hosts running an affected kernel with networking workloads that may exercise Kernel TLS paths.
2. Establish or influence TLS traffic that causes sk_msg scatter-gather buffers to fill and wrap.
3. Trigger the vulnerable tls_push_record() path while sg.end is lower than sg.start.
4. Cause the incorrect sg_chain() entry count to corrupt scatterlist metadata in kernel memory.
5. Observe kernel instability or crashes, or attempt to shape memory state for more reliable exploitation.
6. If exploitation is successful beyond denial of service, use resulting kernel compromise to gain control of the host or disrupt dependent services.

How to detect it

To determine whether this issue was already exploited or triggered, review kernel and system logs for crashes, oops reports, panics, KASAN findings, or general protection faults involving the Kernel TLS path, especially `tls_push_record`, `net/tls`, `sk_msg`, `sg_chain`, `scatterlist`, or crypto scatter-gather processing. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump repositories, kdump/vmcore analysis, EDR kernel telemetry, hypervisor reset logs, and service availability monitoring. Look for repeated TLS-related kernel faults temporally associated with inbound or outbound TLS traffic, unexpected host reboots, network service crashes, or load spikes. Because memory corruption may not leave a clean signature and no public exploit indicators were provided, absence of these artifacts does not prove the host was not targeted. If a crash dump is available, inspect stack traces for `tls_push_record()` and scatterlist chaining functions, and correlate with network connection logs around the crash time.

• tls_push_record
• sg_chain
• sk_msg
• scatterlist
• net/tls
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• general protection fault
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• Oops:
• RIP: 0010:tls_push_record
• Call Trace: tls_push_record
• Call Trace: sg_chain

What your security team should do

• Prioritize patching Linux kernels on internet-facing, high-availability, and TLS-heavy systems, even though KEV status and EPSS do not currently indicate active broad exploitation.
• Inventory Linux kernel versions across servers, containers hosts, appliances, and cloud images; map them to vendor advisories that include this fix.
• Schedule reboots after kernel package updates and verify the running kernel version after reboot.
• Ask vendors of network appliances, storage appliances, security gateways, and embedded Linux products whether their firmware includes the corrected kernel code.
• Temporarily reduce exposure for systems that cannot be patched by restricting inbound access, moving TLS termination to patched infrastructure, or disabling kTLS where feasible.
• Enable or review kernel crash, panic, oops, and KASAN logging for evidence of attempts or instability in the TLS/networking stack.
• Monitor for future changes in exploit maturity, EPSS trend, distribution advisories, and any KEV listing, and accelerate remediation if public exploit code or active exploitation appears.