CVE-2026-68143: Linux SLIP Race Fixed in Kernel Updates

The NVD record, sourced from kernel.org and published on August 10, identifies the fault in

. The upstream patch was authored by Sungmin Kang and had already entered the networking tree in late July; the Linux 7.2-rc5 change list documented by LWN.net includes it. The CVE publication therefore formalizes a bug that kernel maintainers had already fixed, rather than announcing a newly landed patch.

The important operational detail is that SLIP is a serial-line networking protocol, not the ordinary Ethernet, Wi-Fi, VPN, Hyper-V, or WSL virtual networking path used on a typical Windows PC. A system must have the SLIP driver compiled in or available as a module, attach it to a TTY or serial device, and process receive data while the interface’s MTU is changed to enter the vulnerable race.

A buffer lifetime bug in the SLIP receive path​

The flaw sits between two routines that access the SLIP device’s receive buffer.

replaces the receive buffer,

, and updates its size when an administrator changes the MTU. It does so while holding the driver’s lock.

The receive-side routine,

, previously read the receive-buffer pointer and its size without holding that same lock. That left a timing window in which receive processing could use a pointer or size value that had ceased to be valid.

Kernel.org’s CVE description identifies two separate failure modes:

• Shrinking the MTU can expose a new, smaller buffer while the receive routine still trusts the old, larger size limit, leading to an out-of-bounds write.
• Receive processing can load the old buffer pointer just before reallocation frees that buffer, then continue writing into freed memory.

Both are kernel-memory-safety failures. They can crash a system or corrupt kernel state; the record does not establish a working exploit, a remote attack path, a privilege boundary, or exploitation in the wild. NVD had not assigned CVSS v2, v3, or v4 scoring as of August 11, so treating this as a scored remote-code-execution issue would be going beyond the public evidence.

The patch takes the straightforward corrective route: it holds

while each receive batch is consumed, serializing receive processing with buffer reallocation. It does not add bounds checks around an otherwise valid concurrent design; it removes the unsafe concurrency between buffer replacement and buffer use.

The CVE’s version data points to fixes in maintained branches​

The CVE record describes Linux versions from 2.6.12 onward as affected at the source-code level, then identifies fixed points for maintained release lines. The listed corrected upstream versions are:

Those numbers should be used as upstream reference points, not as a substitute for a distributor advisory. Enterprise Linux, Ubuntu, Debian, SUSE, and appliance vendors routinely backport a security patch while retaining an older-looking base version. Conversely, a self-built kernel can carry an upstream version number yet omit a backport or configuration choice relevant to the local system.

The CVE record also provides five stable-tree commit references, confirming that this was backported across several supported branches rather than being left only in the development kernel. That is useful for maintainers building their own kernel packages: the remedy is available as a small, targeted backport rather than requiring a jump to a new major kernel series.

There is an awkward metadata detail worth noting. The CVE entry supplied to NVD shows the public record as published on August 11, while the NVD quick-information panel lists its own publication and last-modified dates as August 10. The change history says kernel.org submitted the record on August 10. This is a record-timestamp discrepancy, not evidence of multiple vulnerabilities or a changed patch, but it is a reminder to track the referenced commits and vendor packages rather than relying on one portal’s displayed date.

Why ordinary Windows installations are outside the affected path​

SLIP, short for Serial Line Internet Protocol, turns a serial TTY connection into a network interface. Linux implements it as a TTY line discipline: received characters from a serial device are passed into the SLIP driver, which assembles network packets. It remains useful in specialized embedded, industrial, lab, radio, and serial-console environments, but it is not part of a normal modern Windows networking stack.

The affected file exists only in the Linux kernel. Windows’ built-in USB serial driver, Windows networking stack, and standard Windows virtual networking components are not covered by CVE-2026-68143. Installing a Windows cumulative update will not be the direct remediation for this CVE because the vulnerable component is not in Windows itself.

WSL requires more care. Microsoft documents that WSL 1 uses a translation layer and does not run a full Linux kernel. WSL 2 runs a Microsoft-built Linux kernel in a managed virtual machine, and Microsoft services that kernel through Windows Update and the WSL update mechanism.

That makes WSL 2 a possible platform for the affected code, but not proof that any particular Windows machine is vulnerable. The public CVE record does not say whether Microsoft’s WSL kernel configuration enables

, whether the module is shipped, or whether a stock WSL setup can practically attach a SLIP interface. In a standard developer WSL environment with no SLIP serial networking, the vulnerable code path is unlikely to be active.

The situations that deserve an actual check are more specific:

• WSL 2 environments using custom kernels, USB/IP-attached serial hardware, development boards, radios, or serial-network adapters should verify whether SLIP is configured and loaded.
• Windows workstations hosting Linux virtual machines need assessment inside each Linux guest, because the guest’s kernel—not the Windows host kernel—contains the driver.
• Container hosts need host-level assessment. Containers share the host kernel, so a containerized workload using SLIP operates against the host’s vulnerable or patched kernel.
• Embedded Linux devices, network appliances, and serial console servers are more plausible users of this driver than conventional desktop Linux installations.

What administrators should check and update​

First, establish whether SLIP exists in the running Linux kernel and whether a SLIP interface is active. On a conventional Linux system, these checks are sufficient to separate a theoretical source-level exposure from a configured driver:

uname -r
grep -E '^CONFIG_SLIP=' /boot/config-$(uname -r) 2>/dev/null || \
zgrep -E '^CONFIG_SLIP=' /proc/config.gz 2>/dev/null
lsmod | grep '^slip'
ip -details link show type slip

means the driver is built into the kernel;

means it can be loaded as a module; no matching setting generally means the vulnerable driver is absent. A compiled module is not the same as an active exposure, but it should prompt a package update rather than be dismissed.

Administrators should then install the kernel update provided by their Linux distribution or appliance vendor that incorporates the upstream fix. Do not pin remediation solely to

when a vendor supplies backports; validate the vendor’s advisory or changelog for CVE-2026-68143 or the SLIP receive-serialization patch.

For WSL 2, check the running kernel with

in PowerShell or

inside the distribution, then update WSL with:

A routine

inside a WSL distribution may update user-space packages without replacing Microsoft’s separately serviced WSL kernel. Microsoft’s WSL documentation specifically places kernel servicing on the Windows and WSL update path.

The practical conclusion is narrow but firm: prioritize CVE-2026-68143 on systems that use SLIP over serial links, and update the kernel rather than attempting to mitigate it in user space. For ordinary Windows PCs and default WSL development installations with no SLIP device or driver, this CVE does not create a new Windows networking emergency.