When cslip gets an uncompressed packet, it attempts to save off the TCP/IP

header for use in decompressing subsequant packets. If cslip gets garbage
(such as what happens when there is a port speed mismatch or modem line
noise), it will occasionally mistake the packet as a valid uncompressed
packet. When it tries to save off the header, it doesn't bother to check
for the validity of the header length and will happily clobber not only
the cslip data structure, but parts of other kernel memory that happens
to follow it...causing, ahem, undesired behavior.

0 files changed, 0 insertions, 0 deletions