CVE-2026-64422

What it actually does

This Linux kernel flaw allows an invalid negative value written to the IPv4 TCP reordering sysctl to be copied into TCP socket state as a large unsigned value. When TCP MTU probing is forced on, that wrapped value can overflow size calculations in the TCP MTU probing path, potentially causing an out-of-bounds kernel memory read. The likely impacts are disclosure of kernel memory and kernel instability or crash. Exploitation requires local privileges sufficient to modify the relevant network sysctl values, such as in a network namespace or with appropriate network administration capability.

Why it matters to the business

Systems running affected Linux kernel builds may be vulnerable to local attacks that can expose sensitive kernel memory or disrupt availability. The operational risk is highest on multi-user Linux servers, container platforms, CI/CD runners, shared hosting, and environments where users or workloads can create or administer network namespaces. This issue is not currently listed in CISA KEV, has no reported exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local kernel flaws can become important in container escape or privilege-chaining scenarios.

How an attack unfolds

An attacker first obtains local code execution with enough privilege to modify IPv4 TCP sysctl settings, commonly through CAP_NET_ADMIN, a privileged container, or control over a network namespace where these sysctls are writable. The attacker sets TCP MTU probing to the mode that always probes, then writes a negative value to the TCP reordering setting. On vulnerable kernels, that negative signed integer is accepted and later stored in an unsigned TCP socket field as a very large value. The attacker then creates TCP activity that enters the MTU probing path. The oversized reordering value causes arithmetic overflow in the MTU probe size calculation, bypassing expected send queue or window checks and driving the kernel into an out-of-bounds read. Depending on kernel configuration, memory layout, and hardening, this may leak kernel memory to the attacker, trigger a kernel warning, or crash the host.

How to fix it

Upgrade to a Linux kernel version that includes the fix for bounded IPv4 TCP reordering sysctl writes and hardened TCP MTU probe size calculations. The fix rejects net.ipv4.tcp_reordering values below 1, requires net.ipv4.tcp_max_reordering to be at least 1, correctly handles namespace-specific sysctl bounds, and computes TCP MTU probe sizing with a wider integer type to prevent signed overflow. If an immediate kernel upgrade is not possible, reduce exposure by restricting local users and workloads that can modify network sysctls, avoiding privileged containers, limiting CAP_NET_ADMIN, disabling untrusted creation of user/network namespaces where feasible, and ensuring net.ipv4.tcp_reordering and net.ipv4.tcp_max_reordering are configured to positive values. Consider setting net.ipv4.tcp_mtu_probing to 0 or 1 instead of 2 as a temporary risk reduction, while recognizing this is not a complete substitute for patching.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for this issue, not only that packages are installed. Validate with uname -r, package manager metadata, vendor advisory status, or kernel changelog entries referencing bounded tcp_reordering sysctl writes, proc_dointvec_minmax use, tcp_max_reordering minimum enforcement, namespace extra2 relocation, or tcp_mtu_probe u64 size calculation. Check current runtime settings with sysctl net.ipv4.tcp_reordering net.ipv4.tcp_max_reordering net.ipv4.tcp_mtu_probing and verify tcp_reordering and tcp_max_reordering cannot be set below 1. In a non-production test system, attempting sysctl -w net.ipv4.tcp_reordering=-1 should be rejected on a fixed kernel. Also review container and namespace policies to confirm untrusted workloads cannot write /proc/sys/net/ipv4/tcp_reordering or related sysctls.

Typical attack path

1. Gain local execution on a vulnerable Linux system or inside a context with permission to write network sysctls.
2. Enable aggressive TCP MTU probing by setting net.ipv4.tcp_mtu_probing to 2.
3. Write a negative value to net.ipv4.tcp_reordering, and potentially manipulate net.ipv4.tcp_max_reordering depending on namespace behavior.
4. Open or manipulate TCP connections so new sockets inherit the malformed TCP reordering value.
5. Trigger TCP MTU probing on the affected socket path.
6. Abuse the resulting out-of-bounds kernel read for information disclosure or cause kernel instability/denial of service.

How to detect it

Look for evidence of suspicious sysctl manipulation and kernel fault artifacts. Relevant log sources include auditd, Linux kernel ring buffer, journald, syslog, EDR process telemetry, shell history where available, container runtime audit logs, Kubernetes audit logs, and host file integrity or command execution telemetry. Search for writes to /proc/sys/net/ipv4/tcp_reordering, /proc/sys/net/ipv4/tcp_max_reordering, and /proc/sys/net/ipv4/tcp_mtu_probing, especially negative tcp_reordering values and tcp_mtu_probing set to 2. Review audit events for sysctl, echo, tee, bash, sh, Python, Perl, or other interpreters writing to these procfs paths. Examine kernel logs for oops, BUG, WARNING, KASAN, UBSAN, general protection fault, page fault, or panic messages with stack traces referencing tcp_mtu_probe or TCP MTU probing. On container platforms, correlate suspicious sysctl writes with privileged pods, hostNetwork workloads, CAP_NET_ADMIN grants, or containers mounting /proc/sys as writable. Because successful exploitation may leave limited user-space artifacts, absence of logs is not proof of non-exploitation; prioritize systems with kernel crashes or memory-safety reports shortly after relevant sysctl changes.

• /proc/sys/net/ipv4/tcp_reordering
• /proc/sys/net/ipv4/tcp_max_reordering
• /proc/sys/net/ipv4/tcp_mtu_probing
• net.ipv4.tcp_reordering=-
• net.ipv4.tcp_reordering = -
• sysctl -w net.ipv4.tcp_reordering=-
• echo -1 > /proc/sys/net/ipv4/tcp_reordering
• net.ipv4.tcp_mtu_probing=2
• sysctl -w net.ipv4.tcp_mtu_probing=2
• echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
• tcp_mtu_probe
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• general protection fault
• Oops:
• RIP: tcp_mtu_probe
• Call Trace: tcp_mtu_probe

What your security team should do

• Prioritize patching shared Linux infrastructure, container hosts, Kubernetes nodes, CI runners, bastion hosts, and multi-user systems where local privilege boundaries matter.
• Inventory Linux systems and container hosts for affected kernel builds using vendor advisories and kernel package metadata.
• Restrict CAP_NET_ADMIN and privileged container usage to trusted workloads only.
• Disable or tightly control unprivileged user and network namespace creation where operationally feasible.
• Audit for writes to /proc/sys/net/ipv4/tcp_reordering, /proc/sys/net/ipv4/tcp_max_reordering, and /proc/sys/net/ipv4/tcp_mtu_probing, especially negative values or tcp_mtu_probing=2.
• Monitor kernel logs for warnings, crashes, KASAN reports, or oops traces involving tcp_mtu_probe.
• Treat suspicious kernel memory-safety alerts on systems with writable network sysctls as potential exploitation attempts, even though public exploit maturity is currently none.