CVE-2026-68143

What it actually does

This is a race condition in the Linux kernel SLIP network driver. During an MTU change, the driver reallocates receive buffers under a lock, but concurrent receive processing can read the buffer pointer and size without the same serialization. If receive processing races with buffer reallocation, the kernel can write past the end of a newly shrunken buffer or continue writing to a buffer that has already been freed. The likely technical outcomes are kernel memory corruption, use-after-free, out-of-bounds write, kernel crash, and potentially local privilege escalation if an attacker can reliably shape the race and control overwritten memory.

Why it matters to the business

Systems that use or expose SLIP networking can be made unstable and may crash, causing service interruption. In higher-risk scenarios, an attacker with the ability to configure SLIP-related networking or interact with a SLIP data path could potentially turn the memory corruption into elevated kernel privileges. The issue is newly published, is not currently listed in CISA KEV, and no public exploit maturity was provided, but kernel memory-corruption flaws should still be prioritized on systems where SLIP is enabled, serial networking is used, or untrusted users can manage network interfaces or TTY line disciplines.

How an attack unfolds

An attacker first needs a path to exercise the Linux SLIP driver, typically by using a system where SLIP support is enabled and a SLIP interface or line discipline can be configured. The attacker then causes receive activity while repeatedly changing the interface MTU so that sl_realloc_bufs() reallocates the receive buffer at the same time slip_receive_buf() is consuming incoming data. If the MTU is reduced at the right moment, receive processing may continue using an old size against a smaller buffer, producing an out-of-bounds write. Alternatively, receive processing may continue using an old buffer after it has been freed, producing a use-after-free write. A simple exploit would aim to crash the kernel; a more advanced exploit would attempt to control heap layout and overwritten data to gain code execution in kernel context.

How to fix it

Apply a Linux kernel update from the system vendor that includes the fix for the SLIP receive-buffer reallocation race. Because no exact affected product list or fixed package versions were provided, use the vendor advisory, kernel changelog, or distribution security tracker to identify the first patched kernel for each supported platform. Where immediate patching is not possible, reduce exposure by disabling SLIP support if it is not required, preventing the slip module from loading, removing unused SLIP interfaces, restricting access to TTY/serial devices, and limiting CAP_NET_ADMIN or equivalent network-administration privileges to trusted administrators only. If SLIP is required, avoid allowing untrusted users or containers to configure MTU values, line disciplines, or network interfaces until patched.

How to confirm the fix worked

Confirm that the running kernel version includes the vendor backport for the fix that serializes slip_receive_buf() with sl_realloc_bufs(). Do not rely only on upstream version numbers because enterprise distributions often backport fixes. Check whether SLIP is enabled or loaded using kernel configuration and module inventory, such as CONFIG_SLIP, loaded modules, and active interfaces named sl*. Validate that mitigations are effective by confirming the slip module cannot be loaded where SLIP is not required and that non-administrative users cannot change network MTU values or attach the SLIP line discipline. After patching, review kernel logs for absence of new crashes or KASAN reports involving slip_receive_buf(), sl_realloc_bufs(), or drivers/net/slip/slip.c during normal operation or controlled regression testing.

Typical attack path

1. Identify a Linux system with SLIP kernel support enabled or the slip module available.
2. Obtain the ability to configure a SLIP interface, attach the SLIP line discipline, change MTU values, or otherwise influence the SLIP receive path.
3. Generate or control incoming SLIP receive data through the relevant TTY or serial-like channel.
4. Repeatedly trigger MTU changes, especially shrinking the MTU, while receive processing is active.
5. Win the race between receive processing and buffer reallocation.
6. Cause kernel memory corruption through an out-of-bounds write or use-after-free write.
7. Use the corruption to crash the host, or in a more sophisticated attack, attempt privilege escalation in kernel context.

How to detect it

To determine whether this was already exploited, review kernel logs, crash dumps, panic records, KASAN/KFENCE reports, audit logs, and endpoint telemetry for evidence of SLIP driver memory corruption. Focus on messages referencing slip_receive_buf(), sl_realloc_bufs(), drivers/net/slip/slip.c, use-after-free, slab out-of-bounds writes, general protection faults, or kernel Oops events around times when MTU changes or SLIP line discipline changes occurred. Review auditd, sudo, shell history, and EDR records for repeated MTU changes on sl* interfaces, loading of the slip module, use of slattach, or suspicious privileged activity involving TTY devices. There are no widely known exploit-specific network signatures or file artifacts for this issue; detection is primarily behavioral and crash-forensic.

• slip_receive_buf
• sl_realloc_bufs
• drivers/net/slip/slip.c
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: use-after-free
• BUG: KFENCE: memory corruption
• Oops:
• general protection fault
• Kernel panic
• slattach
• modprobe slip
• ip link set sl
• ifconfig sl
• CONFIG_SLIP

What your security team should do

• Prioritize patching Linux systems where SLIP is enabled, serial networking is used, embedded/industrial connectivity depends on SLIP, or users/containers have network-administration capabilities.
• Inventory kernels for SLIP support by checking kernel config, loaded modules, and active sl* interfaces.
• Disable or blacklist the slip module on systems that do not require SLIP.
• Restrict CAP_NET_ADMIN, privileged container access, TTY/serial device access, and MTU-changing permissions to trusted administrators.
• Monitor kernel logs and crash telemetry for SLIP-related use-after-free, out-of-bounds write, KASAN, panic, or Oops events.
• Treat unexplained kernel crashes involving the SLIP driver as potentially security-relevant and preserve crash dumps for analysis.
• Track vendor advisories for exact fixed kernel package versions and deploy them through normal emergency kernel patch workflows where exposure exists.