From owner-freebsd-hackers@FreeBSD.ORG  Thu Sep 16 23:29:24 2004
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 AB03016A4CE
	for <freebsd-hackers@freebsd.org>;
	Thu, 16 Sep 2004 23:29:24 +0000 (GMT)
Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB3743D53
	for <freebsd-hackers@freebsd.org>;
	Thu, 16 Sep 2004 23:29:24 +0000 (GMT)	(envelope-from gerarra@tin.it)
Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027)
	id 41499A7500036165 for freebsd-hackers@freebsd.org;
	Fri, 17 Sep 2004 01:29:24 +0200
Received: from [192.168.70.225] by ims3a.cp.tin.it with HTTP;
	Fri, 17 Sep 2004 01:29:22 +0200
Date: Fri, 17 Sep 2004 01:29:22 +0200
Message-ID: <4146316C000077FD@ims3a.cp.tin.it>
From: gerarra@tin.it
To: freebsd-hackers@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
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
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2004 23:29:24 -0000

> As you point out,

Seen i said alredy, why repeating? I was pointing out about the problem,
not security issue.
Like FreeBSD user I want the patch for this code and I think is useful re=
porting
bug. It's an important part of the kernel so I didn't prepared a patch al=
redy,
I would like to know how core team will move.

> The number of arguments for a syscall is defined within the kernel and

> is not
> supplied from an untrusted source. This means that this is not a 
> security problem.

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.

> to load a kernel module you must be root (and not in a jail) meaning 
> that if you
> wanted to, the quicker and easier exploit would be
> /bin/sh
>
nice but it doesn't solve the problem.

cheers,
rookie