From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 02:52:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C0EC16A4CE for ; Sat, 18 Sep 2004 02:52:19 +0000 (GMT) Received: from keylime.silverwraith.com (keylime.silverwraith.com [69.55.228.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A64443D1F for ; Sat, 18 Sep 2004 02:52:19 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com ([69.55.228.10]) by keylime.silverwraith.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8VKk-000Mew-Kq; Fri, 17 Sep 2004 19:52:18 -0700 Received: (from avleen@localhost)i8I2qIHp087094; Fri, 17 Sep 2004 19:52:18 -0700 (PDT) (envelope-from lists-freebsd@silverwraith.com) X-Authentication-Warning: keylime.silverwraith.com: avleen set sender to lists-freebsd@silverwraith.com using -f Date: Fri, 17 Sep 2004 19:52:18 -0700 From: Avleen Vig To: viro@parcelfarce.linux.theplanet.co.uk Message-ID: <20040918025217.GB54961@silverwraith.com> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 02:52:19 -0000 On Fri, Sep 17, 2004 at 12:59:36AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote: > > Inside the kernel? i can define a syscall accepting 30 args and it could > > send in panic freebsd kernel. I think it's a problem and a patch 'must' > > occur. > > You could also define a syscall with no arguments and have it call > panic(9). So what? The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet: irc.mindspring.com (Earthlink user access only)