A race condition exists between the SLIP buffer reallocation routine and its receive path; when the network interface MTU is altered the driver can be left with a new, smaller buffer while the receive code still writes using the older, larger bounds. This out‑of‑bounds write can corrupt memory, potentially enabling arbitrary code execution or denial of service. The likely attack vector requires the ability to change the MTU on a SLIP interface and to generate traffic that triggers the receive path, suggesting a local or compromised system that can manipulate network settings or send crafted packets. It is inferred that the vulnerability is exploitable in environments where SLIP interfaces are active and the kernel lacks the synchronization fix.

All Linux kernel implementations that include the SLIP network driver are affected, until the update that serializes receive processing with the lock is applied. No specific vendor or version ranges are listed, so all current releases are potentially vulnerable.

The flaw causes uncontrolled memory writes, and with a CVSS score of 7.8 it is considered high severity. The EPSS score of <1% suggests low exploitation probability, and the vulnerability is not listed in CISA’s KEV catalog. The absence of proper synchronization in the kernel code still implies a plausible exploitation path for systems that use SLIP interfaces, particularly when an attacker can trigger MTU changes or inject traffic to exercise the race. Nonetheless, the potential impact remains disruptive due to memory corruption.