Skip to content
Tech News
← Back to articles

Hunting a 34 year old pointer bug in EtherSlip

read original get EtherSlip Vulnerability Patch → more articles
Why This Matters

This article highlights the discovery and investigation of a 34-year-old pointer bug in EtherSlip, a legacy network driver used for serial-to-Ethernet emulation. Its exploration underscores the importance of maintaining and understanding vintage networking tools, which can still influence modern systems and legacy infrastructure. The work also emphasizes the ongoing relevance of debugging and software preservation in the tech industry.

Key Takeaways

Hunting a 34 year old pointer bug in EtherSlip

[email protected]

Posted: 2026-04-19

Tags: DOS, Networking, Segmented memory is hard

A few weeks ago I was revisiting my instructions for running a SLIP connection between a DOS PC and Linux. If you are not familiar with SLIP it stands for Serial Line Internet Protocol, and it lets you run TCP/IP over a PC serial port. TCP/IP is much faster over Ethernet, but a serial port can work too.

There are several packet drivers for DOS that let you make SLIP connections. One that I use often is "EtherSLIP" which is handy because it emulates an Ethernet packet driver but it is really just SLIP over a serial port. The emulation allows you to use programs designed for Ethernet packet drivers unmodified; otherwise, you'd have to run programs that are designed specifically for SLIP packet drivers. All of the mTCP programs expect Ethernet, but they don't actually know what is happening "under the covers" so any packet driver that emulates Ethernet works too. (Besides EtherSLIP there is also a Token Ring packet driver that emulates Ethernet.) EtherSlip is included in the Crynwr packet driver collection, which covers most classic ISA Ethernet cards.

I used Telnet to do my testing and there was something wrong with my cabling; it was slow and dropping packets like crazy. (It turned out to be a hardware problem.) When Telnet exited it gave me this error message:

*** NULL assignment detected

Well, that doesn't sound good. The compiler I use (Open Watcom 1.9) checks the heap at the end of a program to let you know if there was heap corruption, but this is a different error message. I dug through the PDF documentation and I found an explanation in the "Watcom C/C++ Programmer's Guide." Here is a summary of the problem:

Normally it is an error to use a NULL pointer and on a real operating system you will get a signal or an interrupt if you try to read or write using one. 16-bit DOS doesn't have that capability so it is allowed, even if it is an error.

... continue reading