CVE-2026-46102

What it actually does

This is a Linux kernel denial-of-service vulnerability in the network stream parser. When stream parsing is aborted, such as after a message assembly timeout, the parser can retain a reference to a partially assembled socket buffer in skb_head. Because that buffer is not freed in the abort path, repeated aborts can leak kernel memory. A remote unauthenticated attacker able to trigger the affected stream-parser path can repeatedly consume memory until the system experiences memory pressure, out-of-memory kills, degraded networking, or a crash.

Why it matters to the business

Successful exploitation can make Linux systems unreliable or unavailable by exhausting kernel memory. For internet-facing or high-throughput Linux services, this can cause service outages, failed connections, degraded application performance, node reboots, or cascading impact in clustered environments. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is 0.00501, the issue is not in CISA KEV, and no mature exploit is currently reported.

How an attack unfolds

An attacker establishes network connections that exercise a Linux kernel stream-parser consumer and sends data in a way that causes partial message assembly. The attacker then causes the parser to abort, for example by inducing message assembly timeouts or otherwise ending the parse path before a complete message is processed. In vulnerable kernels, the partially assembled skb remains referenced in strp->skb_head instead of being released. By repeating this pattern across many attempts or connections, the attacker accumulates unreclaimed kernel memory until the host enters memory pressure, starts killing processes, drops network traffic, or becomes unavailable.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for freeing strp->skb_head and resetting parser state in strp_abort_strp(). Because no universal fixed version is provided for all distributions, use the fixed kernel package from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel stable branch. Where immediate patching is not possible, reduce exposure by limiting untrusted network access to services that may exercise kernel stream parsing, applying network-layer rate limits, lowering idle or incomplete-connection timeouts where appropriate, and monitoring for memory pressure. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm the running kernel has been updated, not just that a patched package is installed. Validate with the distribution’s package tooling and by checking the active kernel version after reboot. For source-based validation, confirm the kernel tree contains the fix in net/strparser/strparser.c where strp_abort_strp() frees any retained strp->skb_head and resets the relevant parser state. In production, confirm that memory usage remains stable under normal network load and that no recurring OOM or kernel memory pressure events continue after patching.

Typical attack path

1. Identify a reachable service or protocol path on a Linux host that uses the affected kernel stream parser.
2. Open one or more network connections to the target service.
3. Send incomplete or malformed stream data that causes partial message assembly.
4. Trigger parser abort conditions, such as timeout or interrupted message assembly.
5. Repeat the sequence to leak additional kernel socket-buffer memory.
6. Continue until kernel memory pressure causes service degradation, OOM events, process termination, networking instability, or host unavailability.

How to detect it

There is no known unique exploit artifact for this vulnerability, so detection should focus on evidence of repeated network-triggered memory exhaustion. Review kernel logs, system journal logs, OOM killer events, service restart logs, network connection telemetry, firewall/load-balancer logs, and NetFlow data. Look for sudden increases in incomplete or timed-out connections followed by rising kernel memory consumption, socket-buffer pressure, allocation failures, OOM kills, or host reboots. Correlate source IPs that create many short-lived, incomplete, or timeout-prone sessions with the timing of memory pressure. On systems using endpoint or performance telemetry, examine trends in slab memory, socket buffer usage, failed allocations, and process kills around the incident window. Absence of distinctive strings means exploitation cannot be confirmed from a single log line; confirmation requires correlation between network behavior and kernel memory exhaustion symptoms on an unpatched kernel.

• Out of memory: Killed process
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• Killed process
• oom_reaper
• TCP: out of memory
• kernel: Out of memory
• systemd-oomd
• Connection timed out

What your security team should do

• Prioritize patching internet-facing Linux systems and systems running high-availability network services.
• Track Linux distribution and vendor advisories for exact fixed kernel package versions, since fixed versions vary by downstream backport.
• Reboot systems after kernel update and verify the active running kernel is the patched version.
• Add temporary network controls for exposed services that accept many long-lived or incomplete stream connections, including rate limiting and connection timeout tuning.
• Monitor kernel and system logs for OOM events, memory allocation failures, abnormal connection spikes, and repeated service restarts.
• Review capacity and failover posture for critical Linux services so a single-node memory exhaustion event does not become a broader outage.
• Because the issue is not currently in KEV and EPSS is low, treat it as important availability hardening rather than confirmed active exploitation, unless local telemetry shows suspicious memory-exhaustion patterns.