External risk intelligence

Linux Kernel TLS Offload Off-by-One Error

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-64047

This vulnerability exists within the internal TLS offload implementation of the Linux kernel network stack. While it involves network data processing, it requires a specific, non-default configuration (using kernel-level TLS offload). It is not directly exposed as an internet-facing service or application endpoint, and its reachability is constrained by the underlying system architecture.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This security issue affects the Linux kernel's network handling, specifically concerning how data is managed for encrypted connections. A flaw in the calculation of data segments could potentially be exploited, but the affected technology is used in specialized network configurations rather than typical end-user devices. The primary concern is to verify if this specific internal kernel functionality is in use within our environment.

Flaw in Linux kernel network data handling.
Matters for specialized network configurations.
Confirm relevance and exposure within our environment.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by sending specially crafted network traffic to a system running a vulnerable Linux kernel. The flaw lies in how the kernel handles network message segmentation for TLS connections, specifically when a message ring needs to wrap around. If an attacker can trigger this specific wrapping condition with malformed data, it could lead to memory corruption, potentially allowing them to compromise the system.

Requires network access to the target.
Triggered by a specific message ring wrap.
Can lead to significant system compromise.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could affect the integrity and availability of network traffic processed by the Linux kernel's TLS offload feature when handling wrapped scatterlist rings. This occurs when the scatterlist wraps, and an incorrect entry count in the scatterlist ring could lead to issues with chaining data segments.

Network data integrity and availability.
Incorrect chaining of data segments.
Potential for data corruption or dropped packets.

Operational Fix

Recommended remediation, mitigation, and detection steps

This Linux kernel vulnerability impacts the TLS offload implementation within the network stack. Infrastructure or platform teams managing Linux systems are likely responsible for assessing and addressing this issue. The first practical step involves identifying all systems utilizing kernel-level TLS offload, confirming their exposure and business criticality, and then coordinating remediation efforts with accountable owners, potentially involving vendor engagement if specific hardware or software components are involved.

Infrastructure/platform teams own the fix.
Verify kernel TLS offload configurations.
Plan remediation based on criticality.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Linux kernel TLS offload feature?

The Linux kernel TLS offload feature is a specialized networking capability that moves the encryption and decryption of TLS traffic from user-space applications directly into the kernel. By processing these encrypted connections at the kernel level, it aims to improve performance and efficiency for data-heavy network operations, though it is typically enabled only in specific infrastructure or high-performance computing environments rather than on standard desktop systems.

How does this off-by-one error impact kernel memory?

This vulnerability involves an off-by-one error during the chaining of scatterlist entries, which are memory structures used by the kernel to manage data buffers. Because the logic incorrectly calculates the array size during a message ring wrap, the kernel may attempt to access or chain memory outside of the intended bounds. This incorrect memory access can lead to memory corruption, potentially disrupting system integrity or causing unexpected application behavior.

When is this vulnerability triggered by network traffic?

The flaw is specifically triggered when the internal message ring needs to wrap around—a condition that occurs when the end of the data buffer is reached and the system must link the tail back to the head. It does not trigger during standard, non-wrapping network traffic. An attacker would need to send precisely crafted network traffic designed to force this specific wrapping condition in the kernel's TLS offload processing logic.

How should I assess if my systems are at risk?

According to Halo Surface Signal, this vulnerability is classified as unlikely to be directly reachable from the internet because it exists within a specific internal kernel implementation. You should determine if your systems have the kernel-level TLS offload feature explicitly configured and active. If this feature is disabled or unused, the underlying code path containing the flaw is not exercised, significantly reducing the practical relevance of this CVE for those systems.

What is the first step to remediate CVE-2026-64047?

Your first step is to conduct an inventory of your Linux infrastructure to identify which systems have the kernel-level TLS offload feature enabled. Once you have identified these specific systems, coordinate with your platform or infrastructure teams to verify their current kernel versions. Because this is a kernel-level issue, the resolution typically requires applying vendor-supplied security updates to the Linux kernel that correct the scatterlist chaining logic.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.