From owner-freebsd-current@FreeBSD.ORG Sun Sep 23 09:52:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D6016A41B for ; Sun, 23 Sep 2007 09:52:19 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7F213C494 for ; Sun, 23 Sep 2007 09:52:19 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 103E22E4F8 for ; Sun, 23 Sep 2007 05:52:19 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 23 Sep 2007 05:52:19 -0400 X-Sasl-enc: Opsc9MkKpmUmEN1wXsW/exPiCzAfaBegFn4eoT5nteOh 1190541138 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id A775D41F5 for ; Sun, 23 Sep 2007 05:52:18 -0400 (EDT) Message-ID: <46F6379B.9050000@freebsd.org> Date: Sun, 23 Sep 2007 02:53:31 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: yacc bug in reader.c:end_rule() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2007 09:52:19 -0000 There's a fairly obvious bug in yacc's reader.c but I'm not sure what the right fix is. Witness: end_rule() { int i; if (!last_was_action && plhs[nrules]->tag) { for (i = nitems - 1; pitem[i]; --i) continue; if (pitem[i + 1] == 0 || pitem[i+1]->tag != plhs[nrules]->tag) ... } ...clearly if pitem[nitems-1] == NULL (and nitems is the size of the array from [0,nitems-1]) then the if() will access beyond the bounds of the array. There's also the question of i being able to run below 0 too here. I don't know if the bug is here or if the bug is elsewhere in yacc, but I doubt that the "fix" is s/i + 1/i/. *Maybe* "i = nitems - 2;"? The bug can be masked by using calloc instead of malloc and similar other tricks, but there is something more fundamentaly wrong here. Has anyone else run into this? Darren