From owner-freebsd-hackers Sun Mar 3 17:08:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA24051 for hackers-outgoing; Sun, 3 Mar 1996 17:08:09 -0800 (PST) Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA24046 for ; Sun, 3 Mar 1996 17:08:03 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id BAA22116 for freebsd-hackers@freebsd.org; Mon, 4 Mar 1996 01:07:30 GMT X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 4 Mar 96 1:06:59 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 4 Mar 96 1:06:55 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Mon, 4 Mar 96 1:06:55 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:28291-960304010655-6D77] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: freebsd-hackers@freebsd.org Date: Mon, 4 Mar 96 1:06:55 +0000 Content-Identifier: Bug in Crynwr/Li Message-Id: <"439-960304010943-27C4*/G=Andrew/S=Gordon/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> To: freebsd-hackers@freebsd.org Subject: Bug in Crynwr/Linux mode of lp driver MIME-Version: 1.0 (Generated by NET-TEL X.400 Rfcgate Version 2.2.0) Content-Type: Multipart/Mixed; boundary="E439-960304010943-27C4s/G=Andrew/S=Gordon/O=Net-.b0ndr1y.nested_0" Sender: owner-hackers@freebsd.org Precedence: bulk --E439-960304010943-27C4s/G=Andrew/S=Gordon/O=Net-.b0ndr1y.nested_0 Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit 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] --E439-960304010943-27C4s/G=Andrew/S=Gordon/O=Net-.b0ndr1y.nested_0 Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit 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; --E439-960304010943-27C4s/G=Andrew/S=Gordon/O=Net-.b0ndr1y.nested_0--