CVE-2026-45843

What it actually does

This flaw is an out-of-bounds read in the Linux kernel SLIP/CSLIP Van Jacobson TCP header decompression path. A malformed, short compressed SLIP frame can cause slhc_uncompress() to read beyond the actual compressed packet buffer because decode() and pull16() did not properly enforce packet-length bounds. The over-read data can be incorporated into the SLIP compression state and later reflected into reconstructed packets, creating a kernel-memory information disclosure condition and limited packet/header corruption risk. The issue affects systems using the Linux kernel SLIP driver with compressed TCP header handling enabled or reachable.

Why it matters to the business

Organizations still using SLIP/CSLIP interfaces, embedded Linux networking, legacy serial IP links, industrial equipment, lab systems, or appliances built on affected Linux kernels could unintentionally expose sensitive in-memory data through network traffic. Operationally, exploitation could also corrupt reconstructed TCP traffic and cause hard-to-diagnose communication failures on affected links. The CVSS score is high, but current EPSS is low and it is not listed in CISA KEV, so remediation should be prioritized most urgently for systems where SLIP/CSLIP is enabled or exposed to untrusted peers.

How an attack unfolds

An attacker needs the ability to send crafted SLIP/CSLIP traffic to a vulnerable Linux system or device using compressed SLIP TCP header processing. The attacker sends a deliberately short VJ-compressed TCP frame whose change byte indicates optional fields are present even though the frame does not contain enough bytes for them. The vulnerable decompression routine advances through the packet and reads beyond the compressed frame boundary. Those extra bytes are folded into the cached decompression state and may be reflected into subsequent reconstructed packets. By repeating this process and observing traffic returned or forwarded across the SLIP link, the attacker may recover kernel-adjacent memory contents or induce malformed TCP packet reconstruction. There is no indication from the provided data of known public exploitation, ransomware use, or active KEV-tracked exploitation.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the fix for the SLIP decompression bounds checks in slhc_uncompress(), decode(), and pull16(). Where package-specific fixed versions are not available, use the latest stable or distribution security kernel containing the upstream fix described as "slip: bound decode() reads against the compressed packet length." If immediate patching is not possible, disable SLIP/CSLIP where not required, unload or blacklist the slip/slhc kernel modules if operationally safe, disable compressed SLIP/VJ TCP header compression, and restrict access to any serial, virtual, or network path that can deliver SLIP frames. Embedded and appliance vendors should backport the bounds-checking patch to maintained kernel branches and rebuild affected firmware images.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel package includes the SLIP bounds-checking fix, not just that an updated package is installed. Validate with uname/package-manager output, vendor advisories, kernel changelogs, or source review of drivers/net/slip/slhc.c showing decode() and pull16() bounded against the packet end and checksum reads guarded by length checks. Check whether exposure exists by reviewing kernel configuration and runtime state for SLIP support, compressed SLIP support, loaded slip/slhc modules, and active SLIP interfaces. For high-assurance validation, run a controlled negative test with malformed short compressed SLIP frames against a patched test system using KASAN or equivalent instrumentation and confirm the frame is rejected without out-of-bounds reads or state corruption.

Typical attack path

1. Identify a Linux system, appliance, embedded device, or legacy host using SLIP/CSLIP networking with TCP header compression enabled.
2. Gain the ability to send frames over the affected SLIP link or through a network path that terminates into the vulnerable SLIP interface.
3. Craft a short VJ-compressed TCP frame where the change byte requests fields that are not actually present in the packet.
4. Transmit the malformed compressed frame to trigger an out-of-bounds read in the kernel decompression path.
5. Cause the over-read bytes to be incorporated into the cached SLIP compression state.
6. Observe subsequent reconstructed packets for leaked data or corrupted TCP header values.
7. Repeat with variations to maximize disclosure or disrupt affected communications.

How to detect it

Reliable post-exploitation detection is difficult because successful triggering may not generate kernel logs, crashes, or persistent artifacts. Focus on exposure and anomaly hunting. Review kernel logs, system journals, module-load telemetry, endpoint inventory, and configuration management data for use of SLIP/CSLIP, slip, and slhc. Inspect network or serial-link captures for short VJ-compressed TCP frames with change bytes indicating optional fields that exceed the available packet length, repeated malformed compressed SLIP frames, malformed reconstructed TCP headers, unexpected checksum anomalies, or unexplained corruption on SLIP links. On systems with observability tooling, look for kernel warnings, KASAN/OOB read reports, soft lockups, or unusual packet reconstruction errors around SLIP interfaces. Forensic review should include whether slip/slhc modules were loaded unexpectedly, whether SLIP interfaces were created outside approved maintenance windows, and whether untrusted peers had access to the affected link. Absence of logs does not rule out exploitation.

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and legacy network endpoints that enable SLIP, CSLIP, CONFIG_SLIP, CONFIG_SLIP_COMPRESSED, slip.ko, or slhc.ko.
• Prioritize patching systems with active SLIP/CSLIP interfaces or exposure to untrusted serial, modem, virtual serial, radio, tunnel, or appliance-management links.
• Apply vendor kernel updates or backport the upstream SLIP decompression bounds-checking fix where no packaged fixed version is available.
• Disable SLIP/CSLIP and VJ TCP header compression wherever they are not explicitly required.
• Restrict physical and logical access to SLIP endpoints until remediation is complete.
• Add monitoring for unexpected loading of slip or slhc modules and creation of SLIP interfaces on systems where they are not approved.
• Capture and review SLIP-link traffic on critical systems for malformed compressed frames, unexplained TCP header corruption, or repeated short compressed frames.
• Treat this as lower urgency for general-purpose Linux servers with no SLIP/CSLIP support enabled, but verify rather than assume the feature is absent.