From owner-freebsd-hackers@freebsd.org Fri Jun 17 14:17:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CFF5A77728; Fri, 17 Jun 2016 14:17:41 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from mail.ptrcrt.ch (gahr.cloud.tilaa.com [84.22.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5BB16E9; Fri, 17 Jun 2016 14:17:39 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from webmail.ptrcrt.ch (www.gahr.ch [192.168.1.2]) by mail.ptrcrt.ch (OpenSMTPD) with ESMTPSA id 5f49fc65 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 17 Jun 2016 14:10:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 17 Jun 2016 16:10:57 +0200 From: Pietro Cerutti To: Abhinav Upadhyay Cc: freebsd-hackers@freebsd.org, owner-freebsd-hackers@freebsd.org Subject: Re: Possible bug in ul(1) Organization: The FreeBSD Project In-Reply-To: References: Message-ID: X-Sender: gahr@FreeBSD.org User-Agent: Roundcube Webmail/1.2.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:17:41 -0000 On 2016-06-15 22:59, Abhinav Upadhyay wrote: > Hi, > > NetBSD's ul(1) had a bug, where it would dump core for certain inputs > containing really long lines. For example, we had two man pages for > which it would crash: > > man evrpc | ul > man xdm | ul > > We had a statically allocated buffer (struct CHAR obuf[MAXBUF]) for > representing columns in the lines of the input file, and for really > long lines, we would try to read beyond the size of the buffer and > crash. We've fixed it by using reallocarr(3) and friends [1]. > > FreeBSD also uses a statically allocated buffer, but it ensures that > it never reads beyond the fixed size of the buffer and therefore > doesn't crash for such bad inputs. > > line 170: while ((c = getwc(f)) != WEOF && col < MAXBUF) switch(c) { > > However, it stops reading the file just at the point where the number > of columns in the line exceeds the buffer size and exits with status > 0. I think, if it is not going to read the complete file, it should > exit with a non-0 status, so that the user gets to know that the > output from ul(1) is not complete? Or, probably it would be better to > fix ul(1) so that it is able to read files with arbitrarily long > lines. :) > > PS: I'm not subscribed to the list, so please keep me CC'ed. > > [1]: > http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ul/ul.c.diff?r1=1.16&r2=1.17&only_with_tag=MAIN Bug report and patch submitted at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210344. Thanks! -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp