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 results in uncontrolled memory writes, which is a highly severe type of vulnerability. The EPSS score is not available and the flaw is not yet listed in CISA’s KEV, but the lack of a mitigation in the kernel code suggests a high likelihood of exploitation on systems that use SLIP. Attackers would need the ability to trigger MTU changes or to inject traffic that exercises the race, so the overall exploitability depends on local privilege and network configuration, but the potential impact remains severe.