Date: Mon, 4 Mar 96 1:06:55 +0000 From: Andrew.Gordon@net-tel.co.uk To: freebsd-hackers@freebsd.org Subject: Bug in Crynwr/Linux mode of lp driver Message-ID: <"439-960304010943-27C4*/G=Andrew/S=Gordon/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
The new Linux/Crynwr-compatible mode of the lp (IP over parallel port) driver
has at least one bug that causes panics if oversize packets are received.
1) The major difference of this protocol over the old is that the packet
length is transmitted in front of the data. Unfortunately, the
code trusts the supplied value, and will overrun a buffer if the
sending implementation sends a packet that is too big. This bug
did not apply to the old mode (with implicit length) as the
length was checked. Patch attached.
2) It looks to me as if there is still a race where buffer overruns can
occur in either protocol as the MTU is changing - either if the
MTU is decreasing and a packet arrives of the old MTU in length,
or in the more obscure case where malloc fails to supply a buffer
of the desired new size (code in lpioctl(), manipulating sc->sc_ifbuf
and sc->sc_if.if_mtu). Maybe lpioctl() is called at a suitable spl
that this can't happen? Perhaps someone more knowledgeable would
care to comment.
[By way of amusement, the implementation provoking bug 1 was on an Acorn BBC
Micro, in a mix of 6502 assembler and basic]
[-- Attachment #2 --]
Patch to src/sys/i386/isa/lpt.c
I was working with FreeBSD-stable as of CTM patch no. 46, but the same
problem applies to -current.
*** lpt.c-stable-ctm46 Mon Mar 4 00:41:30 1996
--- lpt.c Mon Mar 4 00:44:56 1996
***************
*** 1078,1083 ****
--- 1078,1085 ----
if (j == -1)
goto err;
len = len + (j << 8);
+ if (len > sc->sc_if.if_mtu + MLPIPHDRLEN)
+ goto err;
bp = sc->sc_ifbuf;